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-boun...@lists.samba.org [mailto:samba-boun...@lists.samba.org] On 
Behalf Of steve
Sent: 05 September 2013 20:24
To: samba@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
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Reply via email to