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

[Tris Mabbs]

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