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

[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-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org] On Behalf Of steve
Sent: 05 September 2013 20:24
To: samba at 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


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba