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

[Burgess, Adam]

Regarding NFS/GSS/KRB5 I know of the ktkt_warnd but that in itself is nowhere near enough - that just renews renewable tickets.  Session based cred caches issue I would think is not solved (how does gssd know which ticket to use for a user context on NFS client) - I know it always worked for uid based ones.  All this of course is moot as I am sure it will be a 100PD project minimum.

ACLs we use are accessed from UNIX (Solaris/HPUX/potentially Linux) clients (over NFS) and from Windows (XP/2K3/2K8/7) clients (over SMB/CIFS).  Hence proper unification is required.  16 group limit stays with us and any group samba sees for membership is what will be seen by UNIX NSS (aside from PGID of course).

Regarding technical user group, I will request to join now.  

BTW, regarding PACs since you are there asking about their decoding) do you happen to know if future versions of Samba will use the user account SID to lookup the user name for UNIX account (ie get AD SID, then get UNIX UID, then get UNIX account name) when determining the actual UNIX account context, rather than the way it works now which relies on cr4ppy string case adjustments which is not technically clean and requires the UNIX account name to match the Windows sAMAccountName to some extent?  As it stands you could not have two accounts with the same samAccountName in two different AD domains accessing the same service, without using the mess of username mappings.  Not important for us right now but just thought I would throw it out there.

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

	Hiya Adam,

> Thanks again.

	You're welcome - sorry I don't seem to be being much help :-(

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

	It's (fortunately, 'cause it really needed it ...) substantially been improved:

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

	Since "Solaris 10" (I believe that's what you're using from your other post?) 6/06, that's (theoretically ...) all handled for you by "ktkt_warnd".
	I.e., somewhat since your last looking at it - might be worth a quick look at again, depending on how up-to-date your "Solaris 10" boxes are, of course ...  And "ktkt_warnd" may not know what's needed, depending on how your Samba Kerberos interacts with the system Kerberos - it's more designed for maintenance of tickets issued as the result of interactive logins - but it might be worth a quick play around with just to see ...

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

	Hopefully not - "ktkt_warnd" should already (hopefully) be able to do most of what you'd need to code, and the NFS id mapping/GSS/... system does seem to work properly, or at least acceptably, now.  We use it ourselves for NFS mounting some filesystems from "Server 2008 R2" boxes, and all the ID mapping actually works correctly (much to my surprise - Soracle playing nicely with Microsoft?! ...).

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

	Yes, that could be a problem, unless you can use something other than AUTH_SYS ...
	However, if the ACL is being applied at the point of access (Samba), based on the AD groups, then it is less of a problem anyway.  You're not worrying about group access being passed over-the-wire for NFS, because it's Samba that's applying the constructed ACL based on the AD group membership
(*and* any underlying filesystem permissions, but if Samba is the only point of access then that's not a problem anyway).
	I.e., if Samba is the only way by which the ACLs need to be applied to the NFS mounted filesystem, it shouldn't matter whether NFS is handling the groups correctly because it's never having to.  The only group authentication presented over NFS will be the primary group; because it's the primary group, that will always be in the NFS group list anyway (it's the supplementary groups that overflow the 16 group limit).
	Now if you're needing to regulate access for other points of access as well (E.g., local processes) then that doesn't necessarily work; if it's just via Samba then it should work regardless (though remember to recompile Samba if you change the kernel group limit or it will all core-dump on you ...).

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

	Particularly with Samba, it all gets horrendously more complex because of mapping DOS attributes onto permissions bits (as you're obviously aware), which can leave you with some extremely strange permissions being set at the filesystem level and all sorts of headaches.  E.g., as you mention, execute bits being applied to newly created files ...
	If you're not mapping DOS attributes through Samba then it's all much simpler and more predictable.
	Still don't like the little perishers though! :-)

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

	Heh!

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

	You have to request membership; as I understand it, if you're seen to be asking questions which need to be in the technical group then that will be granted.
	Or at least that's how I understand it, and that's how it's worked for me (I've got a couple of conversations going on at the moment, with some extremely helpful Samba developers, regarding decoding Kerberos PACs in particular ...).
	Request membership and see what happens :-)

> Adam

	Tris.

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