This is described in Debian bug #520309. In Bugzilla 6155, we described some brokeness with 'force group', which was fixed in 3.3.2. Apparently, another Debian user still found problems with 'force group' From his words: I have a samba pdc that uses an ldapsam backend. Everything seems to work, with the expection of the following share: [store] path = /store hide unreadable = yes csc policy = disable force group = +Power Users inherit acls = true volume = STORE create mask = 0666 directory mask = 0777 When I connect to this share from either smbclient or Windows on a domain workstation, the connection is denied and samba logs "make_connection: connection to store denied due to security descriptor." If I comment out "force group", connections succeed. The users I tested with were members of "power users", but I also tested with just "force group = username" (the name of the actual user), which should have had no effect for that user as his primary gid was already his own usergroup. But the connection was denied even so. The [global] section of my smb.conf reads as follows: [global] dos charset = CP852 display charset = UTF-8 workgroup = KORN netbios name = PDC server string = PDC auth methods = guest sam update encrypted = Yes obey pam restrictions = Yes passdb backend = ldapsam:ldap://192.168.0.99/ pam password change = Yes passwd chat debug = Yes log level = 1 debug class = yes debug prefix timestamp = yes syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 min protocol = LANMAN1 announce version = 9.9 name resolve order = lmhosts host wins bcast time server = Yes deadtime = 1440 max smbd processes = 30 socket options = SO_KEEPALIVE IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192 hostname lookups = Yes add machine script = /usr/local/sbin/add-machine "%u" logon script = %u.cmd logon path = logon drive = N: logon home = \\%L\%u\profile domain logons = Yes os level = 255 preferred master = Yes domain master = Yes ldap admin dn = cn=admin,dc=intra ldap group suffix = ou=Group ldap idmap suffix = ou=idmap ldap machine suffix = ou=Computers ldap passwd sync = Yes ldap user suffix = ou=People ldap suffix = dc=intra,dc=guy ldap ssl = no panic action = /usr/share/samba/panic-action %d ldapsam:trusted = yes ldapsam:editposix = yes admin users = root, Administrator hosts allow = 192.168.0.0/24, 127.0.0.0/8 profile acls = Yes use sendfile = Yes hide dot files = No map archive = No algorithmic rid base = 100000 unix password sync = yes client ntlmv2 auth = yes acl group control = yes force unknown acl user = yes smb ports = 445 139 min receivefile size = 32k disable netbios = no reset on zero vc = yes ea support = yes map acl inherit = yes server signing = auto printcap name = cups printing = cups cups options = "raw" mangle prefix = 3 hide special files = yes map read only = permissions wins support = yes preload = guy utmp = yes delete readonly = yes dos filemode = yes
Created attachment 4034 [details] Log of a failed attempt This is a level 3 log of a failed attempt (with "force group" enabled, then)
Created attachment 4035 [details] Log of a successful attempt This is a log of a successful attempt (without "force group").
"denied due to security descriptor" Very, very likely the smb.conf is not the whole story, but the user has put stuff into share_info.tdb. If the user does not intend to use security descriptors for shares, an option to test might be moving share_info.tdb away. Can you test that? If share_info.tdb intentionally contains security descriptors, please also upload that together with the output of "net getlocalsid" and "net getdomainsid". Thanks, Volker
(In reply to comment #3) Hi, > "denied due to security descriptor" > > Very, very likely the smb.conf is not the whole story, but the user has put > stuff into share_info.tdb. If the user does not intend to use security > descriptors for shares, an option to test might be moving share_info.tdb away. > > Can you test that? > > If share_info.tdb intentionally contains security descriptors, please also > upload that together with the output of "net getlocalsid" and "net > getdomainsid". Sorry, I didn't include this in my original report: I did come across the suggested "solution" of removing share_info.tdb and tried, but it didn't help. (It would also have surprised me if it had, as this is a completely new samba setup and to the best of my knowledge I didn't do anything fancy with share_info.tdb.) Anyway, just to make sure, I tested again. I stopped smbd and nmbd, removed share_info.tdb, uncommented the force group line in smb.conf, started the daemons and tried to connect to the share via smbclient. Sure enough, I get "make_connection: connection to store denied due to security descriptor." in the log. To be absolutely sure, I again commented the force group line out, restarted the daemons again, and tried smbclient again, and this time, it worked.
Just re-checked the code. The relevant piece is in make_connection_snum() where we print this debug message if share_access_check fails. And share_access_check only fails if a security descriptor in share_info.tdb denies access. If there is nothing in share_info.tdb, we fake up a security descriptor allowing everything to the World SID. The only thing I could imagine is that with "force group" being set we do not include the World SID in the user token. Two things: To make 100% certain, can you do a find / -name share_info.tdb to make sure you removed the right share_info.tdb. Please don't feel offended by such a simple-looking request, I've seen quite a few of those. Second, debug level 3 is not enough, we need a debug level 10 log of both the failure and success. Thanks, Volker
Just for the sake of it: share_info.tdb lives in /var/lib/samba with Debian packages
Hi, > Two things: To make 100% certain, can you do a > > find / -name share_info.tdb > > to make sure you removed the right share_info.tdb. Please don't feel offended > by such a simple-looking request, I've seen quite a few of those. No offense taken; I can certainly do that (maybe later today or tomorrow), but it would be extremely surprising to find a share_info.tdb outside /var/lib/samba (which was the one I removed). > Second, debug level 3 is not enough, we need a debug level 10 log of both the > failure and success. OK, will do. Stay tuned. :) Thanks, Andras
Created attachment 4036 [details] Failed attempt (with force group), log level 10 Connecting with smbclient.
Created attachment 4037 [details] Successful attempt (without force group), log level 10 Again, with smbclient.
(In reply to comment #7) > > find / -name share_info.tdb > > > > to make sure you removed the right share_info.tdb. Please don't feel offended > > by such a simple-looking request, I've seen quite a few of those. > > No offense taken; I can certainly do that (maybe later today or tomorrow), but > it would be extremely surprising to find a share_info.tdb outside > /var/lib/samba (which was the one I removed). Sorry, no surprise (i.e. no other share_info.tdb). > > Second, debug level 3 is not enough, we need a debug level 10 log of both the > > failure and success. > > OK, will do. Stay tuned. :) Attached. What immediately catches the eye is this: Found group Power Users (S-1-5-32-547) not in our domain -- ignoring.lookup_name: Unix Group\Power Users => Unix Group (domain), Power Users (name) And also this: sid S-1-22-2-252 -> gid 252 I don't have this SID in my LDAP; group 252 is the power users group, and it looks like this: dn: cn=Power Users,ou=Group,dc=intra,dc=guy objectClass: posixGroup objectClass: sambaGroupMapping objectClass: top cn: Power Users userPassword:: e2NyeXB0fXg= gidNumber: 252 memberUid: guy sambaSID: S-1-5-32-547 sambaGroupType: 5 displayName: Power Users
Created attachment 4038 [details] Failed attempt with force group set to a domain group I set "force group = +guy" for this test to avoid the "not in our domain" message. Still can't connect.
(In reply to comment #11) > Created an attachment (id=4038) [details] > Failed attempt with force group set to a domain group > > I set "force group = +guy" for this test to avoid the "not in our domain" > message. Still can't connect. > Try using fully qualified names like: Unix Users\guy or BUILTIN\Power Users
(In reply to comment #12) > > I set "force group = +guy" for this test to avoid the "not in our domain" > > message. Still can't connect. > > > > Try using fully qualified names like: > Unix Users\guy > or > BUILTIN\Power Users Tried both, but still no luck (attaching logs). How/where/as what is "Unix Users" even supposed to exist? Andras
Created attachment 4039 [details] force group = +BUILTIN\Power Users
Created attachment 4040 [details] force group = +Unix Users\guy
Jeremy, is that related to the "force user" issue described in bug #6291?
I just asked our user to try 3.3.4 packages to check whether the issue is fixed (in such case, it could likely be a duplicate of #6291). Christian Perrier
(In reply to comment #17) > I just asked our user to try 3.3.4 packages to check whether the issue is fixed > (in such case, it could likely be a duplicate of #6291). Sorry, still no luck. Running 3.3.4 now and the problem persists. Andras Ps. Christian, maybe you'd like to update the bug fields to 3.3.4 (I had also tried 3.3.3 which was b0rken in the same way, fwiw). I can't because I'm not the reporter.
I'm sorry, but this still has the "denied due to security descriptor". If you really don't have anything in your share_info.tdb, I think I need to log in to that box. This is absolutely weird, I do not see how this can happen. Volker
(In reply to comment #19) > I'm sorry, but this still has the "denied due to security descriptor". Yes. > If you > really don't have anything in your share_info.tdb, I think I need to log in to > that box. This is absolutely weird, I do not see how this can happen. I can't give you access to this specific box, but I'm fairly sure I can reproduce this issue elsewhere. I'll get back to you when I'm done (maybe this week). Andras
(In reply to comment #20) > > If you > > really don't have anything in your share_info.tdb, I think I need to log in to > > that box. This is absolutely weird, I do not see how this can happen. > > I can't give you access to this specific box, but I'm fairly sure I can > reproduce this issue elsewhere. I'll get back to you when I'm done (maybe this > week). OK, it took a bit longer than expected, but I now have a virtualbox instance with samba and ldap inside that can be used to reproduce the problem. I'm uploading it somewhere, but it'll take a while, it's about 600M. I'll get back to you with the URL and suchlike when the upload is complete; this was just to let you know that I haven't forgotten. :) Andras
OK, please get http://elan.rulez.org/~korn/tmp/samba-vbox.tar.bz2 (bzip compressed it to around 250M). The size of the file is 262057706 bytes; md5: 4bcebd20a0d295beeb2cd8a6de4f0de8; sha1: 927aaaaf724a135a307d30060344e9508dda6c36. Please tell me when I can stop hosting it. The tar contains the contents of a ~/.VirtualBox directory, including virtualbox.xml, so be careful not to overwrite your own if you have one. The virtual image is of a 64bit computer (to more closely match the environment where I originally experienced the problem). All passwords (root, ldap admin etc.) are "qazwsx". There is a test user called "guy" (whose password is also qazwsx); he can log in, but with the current smb.conf can't access the \\localhost\store share. If you comment out "force group" in smb.conf and reload smbd, the "guy" user can access \\localhost\store again. The error message is, as before, "denied due to security descriptor"; the samba logs in /var/log/samba already contain at least one example, resulting from experiments with "smbclient -U guy '\\localhost\store'". I even renamed the share_info.tdb file once and retested, with the same result. As far as I know, the virtualbox image contains no sensitive information. You may have to adapt some configfiles (like /etc/apt/sources.list or /etc/hosts or /etc/resolv.conf) to suit your own network environment though. I'm sorry, but I couldn't think of a much simpler way to enable you to experiment with a failing setup; if you can't run virtualbox for some reason, I can arrange for this instance to be started and accessible to you from the Internet. Please don't hesitate to tell me if there's anything more I can do to help. Andras
Ok, I've downloaded it. But it might take a (long) while because I only use VMware for historical reasons and not VirtualBox. I don't know if I will have a VirtualBox environment any time soon. Sorry, Volker
(In reply to comment #23) > Ok, I've downloaded it. But it might take a (long) while because I only use > VMware for historical reasons and not VirtualBox. I don't know if I will have a > VirtualBox environment any time soon. OK, would it help if I copied the contents of the filesystem out and provided a separate tar of only that? You'd need something to run it in, but even a chroot would conceivably do.
Yep, that would be great! Volker
(In reply to comment #25) > Yep, that would be great! OK, here you are: http://elan.rulez.org/~korn/tmp/samba-rootfs.tar.bz2 Contrary to the Virtualbox image, I didn't actually try to reproduce the problem with this system in a chroot or vserver, but I don't see why it should behave differently. Again, please tell me when I can remove the file from the web host. Thanks Andras
Thanks, got it. md5sum is d7369ec2fa38bde89abef546aeda0b6c. I'll look at it tomorrow or tuesday. Volker
Ok, this took a while. This is very, very confusing but technically not a bug. You have ldapsam:trusted=yes with an invalid LDAP database. The primary group of user "guy", also "guy" does not have a sambaGroupMapping. This is the invalid configuration part. This leads to the token not assigning the SID for the primary group, which would be the second SID in the token. Normally, this SID is being taken by the primary unix group's SID. That SID missing means that the next SID that is normally assigned, World (S-1-1-0), takes its place. The thing the "force group" parameter does is overwrite this SID in the token. So S-1-1-0 is not part of the token. In the access checks for a share we check against the security descriptor, the default if none is there is "All rights to S-1-1-0". But as S-1-1-0 has just been overwritten by "force group", this fails. To fix this, you could either not use "ldapsam:editposix" anymore or assign sambaGroupMapping entries to all your groups. I think without the live data I would never have found this.... Thanks, Volker
Hmmm. Maybe we should add some protection that we don't allow login with such a broken LDAP db? Volker
And another comment, sorry: You should either remove ldapsam:trusted or fix your LDAP db. I wrote you should remove ldapsam:editposix. That does not help. Sorry for the confusion. Volker
(In reply to comment #28) Hi, Thanks for investigating! > Ok, this took a while. This is very, very confusing but technically not a bug. > You have ldapsam:trusted=yes with an invalid LDAP database. The primary group > of user "guy", also "guy" does not have a sambaGroupMapping. This is the > invalid configuration part. This leads to the token not assigning the SID for > the primary group, which would be the second SID in the token. Normally, this > SID is being taken by the primary unix group's SID. That SID missing means I'm either missing something or disagreeing with you, I don't know which. :) To me, the intuitive behaviour would be for Samba to join all Unix groups the connecting user is a member of, regardless of whether they have sambaGroupMappings; as I understood it so far, sambaGroupMappings are only there for the benefit of Windows. If a group has no mapping, then Windows can't see it (meaning that Samba doesn't advertise it in any way). Why is it necessary for all groups, even the ones only used on the Unix side, to have sambaGroupMappings? If a group that has no such mapping owns a file, that ownership needn't be reported to Windows at all (as it's not necessary that a file be owned by a user as well as a group in Winland). It can be omitted from ACLs reported to Windows too. I can't currently think of a scenario that would make it necessary to insist on all Unix groups to have sambaGroupMappings. In any case, I'd consider the misleading error message to be a bug; at least a warning to the effect of "Group 'foo' doesn't have a sambaGroupMapping, ignoring it" should, I think, be logged. Andras
The error message is there: [2009/03/31 00:47:14, 5] smbldap_search_ext: base => [ou=Group,dc=intra,dc=guy], filter => [(&(objectClass=sambaGroupMapping)(gidNumber=1000))], scope => [2] [2009/03/31 00:47:14, 4, class=passdb] ldapsam_getgroup: Did not find group, filter was (&(objectClass=sambaGroupMapping)(gidNumber=1000)) The problem is that we don't deny access for that user. But this would be a new bug against ldapsam:trusted. Volker
(In reply to comment #31) > (In reply to comment #28) > > Hi, > > Thanks for investigating! > > > Ok, this took a while. This is very, very confusing but technically not a bug. > > You have ldapsam:trusted=yes with an invalid LDAP database. The primary group > > of user "guy", also "guy" does not have a sambaGroupMapping. This is the > > invalid configuration part. This leads to the token not assigning the SID for > > the primary group, which would be the second SID in the token. Normally, this > > SID is being taken by the primary unix group's SID. That SID missing means > > I'm either missing something or disagreeing with you, I don't know which. :) To > me, the intuitive behaviour would be for Samba to join all Unix groups the > connecting user is a member of, regardless of whether they have > sambaGroupMappings; as I understood it so far, sambaGroupMappings are only > there for the benefit of Windows. If a group has no mapping, then Windows can't > see it (meaning that Samba doesn't advertise it in any way). > > Why is it necessary for all groups, even the ones only used on the Unix side, > to have sambaGroupMappings? If a group that has no such mapping owns a file, > that ownership needn't be reported to Windows at all (as it's not necessary > that a file be owned by a user as well as a group in Winland). It can be > omitted from ACLs reported to Windows too. I can't currently think of a > scenario that would make it necessary to insist on all Unix groups to have > sambaGroupMappings. > > In any case, I'd consider the misleading error message to be a bug; at least a > warning to the effect of "Group 'foo' doesn't have a sambaGroupMapping, > ignoring it" should, I think, be logged. > > Andras > Andras, UNIX groups that have no members who are both UNIX and Samba/Windows users do not need to be mapped to Windows groups. However, all UNIX groups of which Windows users are members require a Windows group mapping. Given that there are usually not many UNIX groups, why not map all of them so that you will not get caught out at a later time. Volker's advice is good advice. - John T.
(In reply to comment #33) > (In reply to comment #31) > > (In reply to comment #28) > > > > I'm either missing something or disagreeing with you, I don't know which. :) To > > me, the intuitive behaviour would be for Samba to join all Unix groups the > > connecting user is a member of, regardless of whether they have > > sambaGroupMappings; as I understood it so far, sambaGroupMappings are only > > there for the benefit of Windows. If a group has no mapping, then Windows can't > > see it (meaning that Samba doesn't advertise it in any way). > > > > Why is it necessary for all groups, even the ones only used on the Unix side, > > to have sambaGroupMappings? If a group that has no such mapping owns a file, > > that ownership needn't be reported to Windows at all (as it's not necessary > > that a file be owned by a user as well as a group in Winland). It can be > > omitted from ACLs reported to Windows too. I can't currently think of a > > scenario that would make it necessary to insist on all Unix groups to have > > sambaGroupMappings. > > > > In any case, I'd consider the misleading error message to be a bug; at least a > > warning to the effect of "Group 'foo' doesn't have a sambaGroupMapping, > > ignoring it" should, I think, be logged. > > > > Andras > > > > UNIX groups that have no members who are both UNIX and Samba/Windows users do > not need to be mapped to Windows groups. However, all UNIX groups of which > Windows users are members require a Windows group mapping. I understand that this is how things are, but not why, given the above. Windows just needn't know about the groups that have no windows mappings; they could still be used on the Unix side. > Given that there are usually not many UNIX groups, why not map all of them so > that you will not get caught out at a later time. Volker's advice is good > advice. I can certainly map all of them, which works around this limitation. That this is necessary surprises me though, for the reasons outlined above. Also, I think it might actually be useful to hide some Unix groups from Windows. For example, suppose I have a Unix directory, a subdirectory of a share, owned by group "foo", with posix ACLs like d:g:foo:rwx,g:foo:rwx. Also suppose some of my users (the Unix users their Windows accounts are mapped to) are members of group foo. If Samba worked the way I had assumed it did, then group foo wouldn't be visible to any Windows based access control manipulation tools; thus, the ability of group foo to read and write this directory couldn't be removed by Windows users even by accident, resulting in a sort of mandatory access control. There may be other means to this end, but this is straightforward in the sense that no magic at all is involved on the Unix side and no fancy Samba configuration is needed. Andras
(In reply to comment #34) > Also, I think it might actually be useful to hide some Unix groups from > Windows. (But I realise the query optimisations related to ldapsam:trusted may make this unfeasible.)