RFC2307 on a Samba DC - HowTo

[Rowland Penny]

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

Rowland
> Regards,
> Giuseppe
>