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

[Burgess, Adam]

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

[Tris Mabbs]

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.

[steve]

On Thu, 2013-09-05 at 19:45 +0100, Tris Mabbs wrote:

> 5. Are you *absolutely* sure that your idmap back-ends are doing what you
> thought?

Here's another few cents:
What you are describing is almost certainly mismatched gidNumbers.
Depending on where the SID to GID mapping came from it will be
different. Most certainly not what you want.

So: Avoid anything other than the ad backend like the plague.

Add gidNumber to the DN of the group and uidNumber and gidNumber to the
DN of the user. Use sssd to pull that info from AD on _anything_ unix be
it the DC, the file server or a solaris/linux client.
HTH
Steve

[Burgess, Adam]

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

[Burgess, Adam]

I think I have answered this in my other mail. There are no mismatches. Our AD backend is via an integration layer so that a UNIX account is essentially an AD account anyway and all its attributes and group memberships come from AD. The name service resolves all correctly and samba does too in terms of the final smbd process context that is created (ie its euid/gid are as you would expect and supplementary gid list is too).

However, the checking open right functions simply ignore the PGID, and this seems to give the resulting client access difference (Windows 7 seemingly listening to the access denied reply, with XP ignoring it and soldiering on so that Samba then actually gives the access) - this a little bit of guessing on my part as my debugging is not complete. I have noticed that the open access_mask requested with Windows 7 client is 0x81 while other clients request 0x20089 or 0x100001 for example.

-----Original Message-----
From: samba-...@lists.samba.org [mailto:samba-...@lists.samba.org] On Behalf Of steve
Sent: 05 September 2013 20:24
To: sa...@lists.samba.org
Subject: Re: [Samba] primary GID based access for user in 16 supplementary groups

On Thu, 2013-09-05 at 19:45 +0100, Tris Mabbs wrote:

> 5. Are you *absolutely* sure that your idmap back-ends are doing what
> you thought?

Here's another few cents:
What you are describing is almost certainly mismatched gidNumbers.
Depending on where the SID to GID mapping came from it will be different. Most certainly not what you want.

So: Avoid anything other than the ad backend like the plague.

Add gidNumber to the DN of the group and uidNumber and gidNumber to the DN of the user. Use sssd to pull that info from AD on _anything_ unix be it the DC, the file server or a solaris/linux client.
HTH
Steve

[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.b...@hp.com]

Sent: 06 September 2013 09:27
To: Tris Mabbs; sa...@lists.samba.org
Subject: RE: [Samba] primary GID based access for user in 16 supplementary
groups

...

[Burgess, Adam]

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-Samb...@Firstgrade.Co.UK]

[Tris Mabbs]

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.

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