RFC2307 on a Samba DC - HowTo

Mon May 19 03:20:44 MDT 2014

On Mon, 2014-05-19 at 09:18 +0100, Rowland Penny wrote:
> On 18/05/14 22:56, Giuseppe Ragusa wrote:
> > On Sun May 18 15:13:44 MDT 2014, Rowland Penny wrote:
> > > On 18/05/14 21:09, Giuseppe Ragusa wrote:
> > > > Hi,
> > > >
> > > > On Sun May 18 13:43:50 MDT 2014, Rowland Penny wrote:
> > > > > On 18/05/14 19:38, Giuseppe Ragusa wrote:
> > > > > >> Hello,
> > > > > >>
> > > > > >> I've finished a new HowTo this week (please proofread):
> > > > > >>
> > > > > >> https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC
> > > > > >>
> > > > > >>
> > > > > >> Regards,
> > > > > >> Marc
> > > > > > Hi,
> > > > > >
> > > > > > Looks good to me, but I wonder if the long standing quirk of 
> > ignoring
> > > > > > the "primary Group ID" RFC2307 attribute and honouring 
> > Windows-side
> > > > > > group settings for primary group too is still in effect and
> > > > > > must be someway described in the wiki page (it affected 
> > Winbind for
> > > > > > sure, never tested SSSD).
> > > > >
> > > > > Now I could be acting stupid here by asking this, but what "primary
> > > > > group ID" RFC2307 attribute are you referring to?
> > > > >
> > > > > The 'primaryGroupID'  attribute is a windows attribute and has 
> > nothing
> > > > > to do with Unix, you need to use the 'gidNumber' attribute.
> > > > >
> > > > > Rowland
> > > >
> > > > Exactly: I was referring to the gidNumber stored together with
> > > > uidNumber (etc.) as user POSIX attributes.
> > > >
> > > > Sorry for the confusion / improper reference.
> > > >
> > > > Regards,
> > > > Giuseppe
> > > >
> > > > > > I think (and reported about two years ago on this list) that up to
> > > > > > Samba 3.5.0 the behavior was different (primary group taken from
> > > > > > POSIX attributes in RFC2307 fields), but changed afterwards 
> > and could
> > > > > > be the culprit behind:
> > > > > >
> > > > > > https://bugzilla.samba.org/show_bug.cgi?id=8694
> > > > > >
> > > > > > https://bugzilla.samba.org/show_bug.cgi?id=7582
> > > > > >
> > > > > > https://bugzilla.samba.org/show_bug.cgi?id=8905
> > > > > >
> > > > > > I even started an (aborted, unfortunately) effort at adding 
> > back the
> > > > > > former behavior through a configuration option (totally rewritten
> > > > id mapping
> > > > > > plugin structure made the relevant information "unavailable where
> > > > needed"
> > > > > > and would so require a substantial development work beyond my
> > > > possibilities atm).
> > > > > >
> > > > > > Regards,
> > > > > > Giuseppe
> > > > > >
> > > >
> > > I think that what you hitting here is that idmap.ldb maps Domain Users
> > > to xidnumber '100' and this number is usually beneath the range set in
> > > smb.conf and therefore never gets pulled by winbind and if the users
> > > group doesn't get pulled, then neither does the user. Setting a
> > > gidNumber on Domain users that is inside the range will cure the 
> > problem.
> > >
> > > There was some talk about giving the windows 'well know SIDs' a 
> > fixed id
> > > number, IMHO this cannot come soon enough.
> > >
> > > Rowland
> >
> > Hi,
> >
> > I don't know if with "xidnumber" you refer to an internal Samba 
> > mapping, but 100 seems to be an awful choice of a gid mapping since I 
> > recall Linux distros giving gid 100 to common local user groups like 
> > "users" (maybe it was some time ago and newer distros obey the rule 
> > "uid/gid > 500" or even higher).
> 
> Yes, samba4 maps 'Domain Users' to the 'users' group, this seems like a 
> good idea until you throw winbind into the mix and then it doesn't make 
> any sense at all!
> 
> >
> > Anyway in my emails of two years ago I stated that my use case for the 
> > aforementioned restoring of previous behavior was on large AD 
> > installations with Windows primary group left at its "Domain Users" 
> > default value and powers-that-be not wanting to touch that all 
> > important group in any way (I know that the simple adding of a 
> > gidNumber is innocuous, but I'm not in a position to argue...).
> >
> 
> This is a strange idea, microsoft added the required attributes to AD 
> for just such a case, I would image that the 'powers-that-be' do not 
> really understand this.
> 
> > Anyway, many thanks for your suggestion: I will check idmap.ldb and 
> > maybe I will try to modify that, if you think that forcing it inside 
> > the range will allow the user to have it's own RFC2307 gidNumber 
> > effective afterwards.
> >
> 
> For 'getent passwd' to return an AD user, the user must have a 
> 'uidNumber' & 'gidNumber'. The problem is that 'Domain Users' must have 
> a 'gidNumber' or the users 'primaryGroupID' must be changed.
> 
> Let me show you an example:
> 
> running 'getent passwd testuser' on the Samba4 AD server before adding 
> Unix attributes:
> 
> DOMAIN\testuser:*:3000049:10000:Test User:/home/DOMAIN/testuser:/bin/bash
> 
> After adding Unix attributes:
> 
> DOMAIN\testuser:*:10008:10000:Test User:/home/DOMAIN/testuser:/bin/bash
> 
> On a client after adding Unix attributes:
> 
> testuser:*:10008:10000:Test User:/home/DOMAIN/testuser:/bin/bash
> 
> In the first result, the user is being mapped by idmap.ldb and has a 
> large id number, '10000' is the 'uidNumber' for 'Domain Users', the 
> other two show the users new 'uidNumber' but still show the user as 
> being a member of 'Domain Users'.
> 
> If we examine the users attributes in AD, we will find these:
> 
> uid: testuser
> msSFU30Name: testuser
> msSFU30NisDomain: home
> uidNumber: 10008
> gidNumber: 10002
> loginShell: /bin/bash
> unixHomeDirectory: /home/DOMAIN/testuser
> 
> This clearly shows that the users 'gidNumber' is not '10000'
> 
> Problem is, if you change the users 'primaryGroupID' and the user goes 
> to a windows machine, they are not a member of 'Domain Users'.

Hi
This is asier to understand if we examin what information need be held
in ADs LDAP and what nss needs to do with it. AD primaryGroupID is the
RID of the group. Assign a gidNumber to that group and this now becomes
the gid which is listed as the gid from the output of getent user. It is
not part of rfc2307 but it is _very_ handy for us to define something
which is difficult to define otherwise. We are attempting to emulate a
UNIX user in /etc/passwd. It is also given as the first group output by
the command 'groups'.

Here's me as a domain user in AD:
getent passwd steve2
steve2:*:3000021:20513:steve2:/home/users/steve2:/bin/bash

groups steve2
steve2 : Domain Users staff2

in the directory I am:
primaryGroupID: 513
uidNumber: 3000021
gidNumber: 20513
loginShell: /bin/bash
unixHomeDirectory: /home/users/steve2
memberOf: CN=staff2,CN=Users,DC=our,DC=domain

The only change to Domain Users is the addition of:
gidNumber: 20513

Note '513', the RID for Domain Users

When working on a Linux client, AD is completely transparent to me. I obey all the UNIX rules as if I were a /etc/passwd user.
HTH
Steve