Thanks Tris. We have not seen any issue with primary group not matching file/directory group owner - but I will look out for this in future.
We are using NFSv4 but as I understood it this still uses AUTH_SYS authentication method by default and this is what prevents us moving to >16 groups. We do have such memberships and struggle enough already without trying to reduce this to 15 in order to work around this particular issue. Essentially our problem generally revolves around ACLs that gives access to objects for a given group that happens to be the primary group of many accounts because there are so many accounts that must belong to it, (we are also not prepared to attempt splitting the group into multiple ones and allocating the users between them as this makes for even more management headaches doing this allocation and then having to add all of these groups to the objects ACLs). Our IDMAP backend works well - that much I am confident of. The backend is itself the Quest ID Mapper that uses Quest Authentication Services integration to AD - we are not actually using UNIX attributes directly on the AD objects but that is another story. Suffice to say that SID-UID and SID-GID mappings in both directions all seems to work correctly for all AD user/group accounts that are setup be shall we say "UNIX enabled". In our UNIX environment AD is the backend for NSS (name services switch) - ie we have single identity management directory between Windows and UNIX environments (thus we can't just remove some AD memberships to suit Samba based access). There is a another problem with the Samba IDMAP operations which is not an issue of the backend but of the caching method and general SID-to-UNIX-ID lookup method. I have posted about that separately. Independent of that issue we need to know how Samba is designed to work in the case described before we can say whether Windows 7 client of Windows XP is working correctly, and then look for potential workarounds/fixes. I myself would like to see a config switch to choose between implicit UNIX PGID membership and not. SMBD should also be able to programmatically not add in an actual supplementary group membership from the UNIX security token if this is the primary GID of the account (this prevent the issue of blowing any limit). Adam -----Original Message----- From: Tris Mabbs [mailto:[email protected]] Sent: 05 September 2013 19:46 To: Burgess, Adam; [email protected] Subject: RE: [Samba] primary GID based access for user in 16 supplementary groups Hiya Adam, We too have had no end of problems with this sort of issue using Samba on Solaris (11 in our case) running against AD and using (predominantly) "Windows 7" clients. Someone with more knowledge of the Samba internals can probably answer your questions about what is the correct behaviour, and why this is happening. However if you're like me, it's more urgent actually to have something working than to know the precise details of implementation of some rather nasty protocols ... So - my $0.02, in case it's of any use. 1. For whatever reason, Samba does not play nicely when the GID of an object does not match the account's primary GID. One easy way (we've found anyway - YMMV) to demonstrate this is to locate any "$RECYCLE.BIN" directory for a user, change the GID to that of another group of which the user is a member, then open the desktop "Recycle Bin" - you'll get a whinge about "The recycle bin on \\server\path\to\$RECYCLE.BIN is corrupted. Do you want to empty the Recycle Bin for this drive?" (or words to that effect). 2. Things work much more smoothly when the AD group membership for the user includes the primary GID (and that's set as the primary group name in the Unix attributes for the account). It's not a cure for all ills, but it did clear up a number of similar problems we had. 3. That, as you pointed out, may well break the Solaris internal limit of 16 groups. However, is that really a problem for you? More than 16 will break NFSv3, but if you're not using NFSv3 then the worst that will happen is you'll get whinged at at boot time and that's it. Depending on your version of Solaris, there is an internal hard-coded kernel limit; as of OpenSolaris "snv_129" it was increased from 32 (the limit you may well have) to 1024, but if you're not over the limit (without including the primary GID) at 16 then 32 will easily be sufficient for you anyway. We run with "set ngroups_max = 1024" in our "/etc/system" (not that we need that many, but ...) and things generally troll along smoothly as a result. Oh, depending (again) on which version you're running - if you've patched your Solaris systems to a stage where they use Grub, don't forget the obligatory "bootadm update-archive", but I'm sure you know that already :-). 4. You've not gone into details of when (or even if) you might need to use different GIDs on directories (or files, for that matter), though you did point out that anything created will be created with the primary GID anyway. Again, I'm sure you're aware of this, but you might find setting the SGID bit on folders to be useful to force different group ownership of anything created in that directory. If, that is, you need to be able to create new filesystem objects with a group ownership of anything other than the primary GID ... 5. Are you *absolutely* sure that your idmap back-ends are doing what you thought? It may be worthwhile running "wbinfo -U <UID>" and checking the SID for that UID against AD ("whoami /all |more" in a CMD window is very useful in this context ...); then "wbinfo -S <SID>" and confirming that it comes back to the correct UID. We've also had some very odd behaviour where it looks as though everything is correct, but the UID is actually being mapped to a transient SID from an allocating back-end. It maps to and fro correctly, and Samba seems able (in our case) correctly to identify the user (presumably from the Kerberos tickets) when a connection is established, and so the correct UID is extracted from AD. However since that UID then maps to a transient SID when looked up (rather than the real SID which it should match), you will get all sorts of bizarre permissions behaviour. Same UID, different SID, never the 'twain shall meet ... Hopefully at least some of that may prove useful! Cheers, Tris Mabbs. -----Original Message----- From: Burgess, Adam [mailto:[email protected]] Sent: 05 September 2013 17:02 To: [email protected] Subject: [Samba] primary GID based access for user in 16 supplementary groups We observe a difference between a Windows 7 client and Windows 2003/XP client when accessing directories that should be accessible via the UNIX accounts primary group GID. Windows client refuses access. Ignoring for now why the two different client behaviours (either some subtle difference in the requests or the way the Samba reply is dealt with) the question is what should be the correct behaviour? We are running Samba 3.6.6 on Solaris with 16 limit on supplementary group, using ADS security, Kerberos PAC based group membership resolution via winbindd IDMAP lookup to simple LDAP backend. The SIDs in the PAC which resolve to valid GIDs are just the supplementary groups that would be expected for the UNIX name services resolution for the user account. The primary GID does resolve to a valid AD group SID too but this group does not contain the AD user account as a member and so is not present in the Kerberos PAC of course. In this case the smbd establishes the UNIX token context with correct UID/GID (primary) and the correct list of supplementary groups. However when checking the open rights for a directory with ACLs that allow only the primary GID read/execute access to a directory for example the result is ACCESS DENIED. For example debug level 10 log line: [2013/08/30 13:38:45.318680, 10, pid=22761] smbd/open.c:139(smbd_check_open_rights) smbd_check_open_rights: file pgidaccessonlydir requesting 0x81 returning 0x1 (NT_STATUS_ACCESS_DENIED) This prevents access from a Windows 7 client. If we add the AD user account as a member of the PGID mapped AD group account as a workaround, then this would consume a supplementary group slot in the smbd process context which would break any access for accounts that are already in 16 supplementary groups. Also it should be noted that once any access is given to a directory any files that might be created would be created with the user accounts PGID as its group owner. This makes it even more bizarre that this group would not be considered as part of the membership when using winbind idmapping. I would think that the Windows token SIDs should be combined with the UNIX context PGID's resolved SID for the expected behaviour from a UNIX perspective, but from an AD/Windows perspective it makes more sense that only PAC SIDs are used (but this creates an inability to use the already constrained 16 supplementary groups and to use PGID at all for resource control). PGID based resource control is required on Solaris when using a supplementary group membership would not work due to the number of members total name string length would blow the NSS buf limit for group membership list (eg 8K). What is the behaviour intended to be - implicit membership to UNIX PGID or not? How can we resolve this problem for Windows 7 client access to UNIX PGID access based resources? Cheers, Adam -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
