RFC2307 on a Samba DC - HowTo

[Giuseppe Ragusa]

On Mon May 19 02:18:05 MDT 2014, 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'

You exactly hit the nail with this example!

> Problem is, if you change the users 'primaryGroupID' and the user goes 
> to a windows machine, they are not a member of 'Domain Users'.

I could not say it better!

Beside your example (that has complete gidNumber assignment for all groups involved), the RFC2307 gidNumber (aka "POSIX-only primary group") attribute for the user in post-3.5.0 Samba implementation has the following limitation:

a Windows user for whom the Windows primary group cannot be changed (for example: to something different from "Domain Users") nor modified (ie: adding gidNumber to "Domain Users") is not able to login to UNIX with idmap_ad even if it's gidNumber correctly points to a (different, arguably "special-purpose-created") valid (with gidNumber and correct Windows membership maintained) Windows group

Given all the wonderful flexibility afforded by Samba in almost every aspect of system/network management, the fact that to use RFC2307 we must set the Windows primary group to a group with gidNumber set and the user's own gidNumber is ignored is (to me, obviously) a strange lack of flexibility (if not a regression wrt pre-3.5.0).

OTOH, from what I recall reading the code years ago, the idmap subsystem refactoring and plugin-based structure came along ignoring this use case altogether and justifying the new reasoning along the lines of "Windows-side rules for all group membership logic, ALSO for primary group" (which is a coherent choice, after all).

So, from your example now I see that this is still the case and that no hacking on idmap.ldb can give back the previous functionality yet, while still using idmap_ad.

As a final note, I recall that there was back then a new idmap_rfc2307 plugin to be investigated as an alternative path to the same goal (making user's gidNumber rule wrt user's primary group notion UNIX-side).

> Rowland
> > Regards,
> > Giuseppe
> >

Regards,
Giuseppe