[Samba] primary GID based access for user in 16 supplementary groups

Fri Sep 6 05:31:06 MDT 2013

Thanks again.

We would love to move to RPCSEC_GSS KRB5 based authorization for NFS - but that in itself is a major project.  I looked at this thoroughly 8 years ago (and had it functionally working, long before Linux even had NFSv4) but it was not really operationally viable for certain reasons (such as i) unattended operations needing automatic ticket renewal past the final expiry time which requires keytab stores for such accounts with password rollover processes etc, ii) session based credentials caches as used with ticket forwarding, iii) and the NFS id mapping and gsscred system was far from operationally viable).  This may have improved a little since I looked at it before but I suspect not too much so would need hundreds of many days work for myself to code operational solutions.  Actually Kerberos/GSSAPI/SSPI is an area I am (dare I say it) quite expert and I have Samba configured in a way which is as much as possible using only Kerberos (via dedicated keytab etc, only the annoying secrets.tdb computer password store prevents it from being a "proper" Kerberos implementation).  I have used Centrify too, btw.

As for ACLs - I am afraid they are required! Again because of the 16 group limitation!!!!!  If all file objects use owner GID access control only then you end up with many separate "groups" of accounts needing to be in that resource group which implies also a user ends up being in many many groups.  Actually in the most part I find they work very well, and Samba almost behaves correctly these days when evaluating them - the only issue I have seen is with directory defaults as Samba decides to manage file creation ACL inheritance itself rather than allowing OS posix ACL defaults to be applied (eg. issue with insecure execute bit being applied to newly created files because this is required for newly created directories to allow change dir access etc).

Essentially you have to imagine the groups we see evaluated via Samba user context will be identical as those for a UNIX login for the same user - it is completely unified.  That is all except for the UNIX PGID!!!

Regarding posting my questions in the technical group I thought this was not allowed for non-samba developers, otherwise both of my current queries would already have been sent there.

Adam

-----Original Message-----
From: Tris Mabbs [mailto:TM-Samba201302 at Firstgrade.Co.UK] 
Sent: 06 September 2013 10:15
To: Burgess, Adam
Cc: samba at lists.samba.org
Subject: RE: [Samba] primary GID based access for user in 16 supplementary groups

Hiya Adam,

> We have not seen any issue with primary group not matching 
> file/directory
group owner - but I will look out for this in future.  

Yes, it was a bit of an obscure one to track down, and I'm still not convinced I've got to the bottom of it - we have a working solution now and that's where I had to stop poking around.  Thought I'd mention it though in case it applied in your case.

> 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. ...

Well yes, and no.
Using AUTH_SYS will trip the 16 group limit problem, yes.  That's part of the definition for NFS defined in RFC<something I can't remember> - that's where the 16 group limit comes from and it's not tuneable.
Were you to be using Linux, there's a "magic" hack which gets around this, by ignoring the group list supplied by NFS and looking up the membership for itself.  Haven't played with it myself, but I believe (anecdotally) that it works well.  However that's absolutely no use whatsoever to you in a Solaris environment!
Where NFSv4 *does* score over the earlier versions is that you have *other* authentication methods available - you don't have to use AUTH_SYS.  In particular, as you're integrating all this with AD for unified identity management, there are going to be Kerberos tickets floating around the place and you could potentially use AUTH_KRB5 instead.  Bingo - problem gone.  OK, so nothing in computing is ever quite that simple, but get AUTH_KRB5 working and "Bingo - problem gone".  So that might be a solution for you to this problem, and potentially simplify your account management as well.

> Essentially our problem generally revolves around ACLs that gives 
> access
to objects for a given group ...

Eurgh - stop right there.
ACLs - work of The Devil! :-)
Potentially ACLs are going to cause you major headaches on NFS mounts anyway
- "The wonderful thing about standards is that there's so many to choose from"; NFS ACLs are supposed to be able to be mapped to and fro versus the underlying filesystem (whatever ACL mechanism that's using); personally I've never had ACLs work correctly on NFS shares of pretty much any underlying filesystem, and also be mapped correctly on the client end.  I've also not seen ACLs work consistently and reliably with Samba (and I believe there were a couple of recent threads on that exact subject in the support fora, but don't quote me on that ...).
Now, since you're accessing this using Samba, and Samba works out group membership based on the AD groups and uses that primarily to control access, effectively merged with the local filesystem permissions (as I understand it
- I'm not a Samba guru and could be wrong ...), you might have more luck achieving the equivalent of group-based ACLs by nested group membership in the AD groups.
As you're using "Quest", I don't know how well that would work - I'm afraid I've heard of "Quest" but never used it (just Samba/native OS support for AD integration, oh and "Centrify" ...).  However I don't see why it *wouldn't* work.
So where you use "setfacl" ("Set F*ck-All", as I tend to think of it ...
Pardon the language - really NOT a fan of ACLs, so many issues ...) to permit group write to a directory, and one of the groups happens to be users' primary GID; instead define an AD group ("(Unix) Access 'xxxx'
resource", or some similarly descriptive name) with however Quest assigns a GID to that group, then set the group ownership on the objects to the GID of that group, then include in that group all the other groups to which you're currently granting access via ACLs.
E.g.:
	/someshare/controlled_resource:
	ACLs:
		Grant R/W access to groups:
			users1
			users2
			...
	Instead:
		Create AD group "(Unix) Access 'controlled_resource'",
		Assign (say) GID 10000 to that group,
		chgrp 10000 /someshare/controlled_resource
		chmod g=rwx,g+s /someshare/controlled_resource
		Include "users1", "users2", ... in that group.
Same effect, no ACLs, Samba should be happy.  You might need to tweak the file/directory creation modes masks for Samba, and be careful of the effects of mapping system (etc.) attributes (which are mapped using Unix permissions bits), but get the right combination of Samba options and that should work.
If I've understood correctly what you're trying to achieve, that is ...
Of course, nesting groups like that may simplify, or may make more complex, your group membership issues, but that's not a problem anyway if you move to
AUTH_KRB5 ...

As for your IDMAP cacheing issue - yes, I saw that :-)  IMHO you might not get a response in this group about that - it looked like a "bit" (ha!) more of an in-depth technical issue and, if you get no responses here, you might need to put it into the samba-technical forum - in my experience, the Samba developers are extremely good about monitoring this forum for issues, but there tends to be so much traffic in here (asked by users and can be answered by other users) that more complex technical questions can occasionally get overlooked.

Hope that helps, and good luck!

Cheers,

Tris.

-----Original Message-----
From: Burgess, Adam [mailto:adam.burgess at hp.com]
Sent: 06 September 2013 09:27
To: Tris Mabbs; samba at lists.samba.org
Subject: RE: [Samba] primary GID based access for user in 16 supplementary groups

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-----
...