[Samba] Use of gidNumber attribute in user entry

[Rowland Penny]

Again, see inline comments:

On Mon, 21 Nov 2016 17:40:49 +0100
mathias dufresne via samba <samba at lists.samba.org> wrote:

> 2016-11-21 16:00 GMT+01:00 Rowland Penny via samba
> <samba at lists.samba.org>:
> 
> >
> > See inline comments:
> >
> > On Mon, 21 Nov 2016 14:47:13 +0000
> > Brian Candler via samba <samba at lists.samba.org> wrote:
> >
> > > A few questions about Unix groups in Samba.
> > >
> > > (1) "samba-tool user add" has an option to set --gid-number.
> > > However, I can't see that this attribute is ever used. Can
> > > someone confirm if this is true?
> >
> > Not sure if it is ever really used, what I can say is, you do not
> > need it.
> >
> 
> It is used when you are using which use it. Just an example: SSSD is
> configurable and you can tell that specific tool to use any LDAP
> attribute to set LINUX/UNIX users' primary group.
> This options should set in your user objects the field named
> gidNumber. I believe RFC2307 tells that gidNumber is default field
> for UNIX primary group.

OK, I will change it to:

Not sure if it is ever really used by Samba apart from secondary groups.

And again 'sssd' is NOT part of Samba!
 
> 
> Winbind does not use field gidNumber to fill UNIX primary group but
> use primaryGroupID which is in fact Windows primary group (ie: domain
> users by default). This difference is because Samba and Winbind are
> mainly meant to server Windows, not UNIX/Linux (just run on them).

Samba has always been aimed at windows, even its name is derived from
SMB, do you have a problem with that ?
 
> 
> 
> >
> > >  From digging around previous mailing list postings (*), I surmise
> > > the following:
> > >
> > > - the user's Unix primary gid is taken from their primary
> > > *Windows* group (primaryGroupID, which points to the RID of a
> > > Windows group entry)
> >
> > Correct
> >
> > >
> > > - the Windows primary group must have a gidNumber attribute,
> > > otherwise the user is not visible in Unix at all
> >
> > Correct
> >
> > >
> > > - therefore the gidNumber attribute from the user entry appears
> > > to be ignored. Is that right?
> >
> > As I said, you do not need to add a gidNumber to a user, they are
> > all members of 'Domain Users', in fact, if this is changed, windows
> > doesn't like it.
> >
> 
> Ignored by Winbind[d].

Yes, you can change a users primary group in AD, you have to jump
through a couple of hoops to do it, but you can do it. However, if you
do change it, it upsets windows, unless of course you add the user as a
member of 'Domain Users', so why bother ?

> 
> 
> >
> > >
> > > (2) I can create a new Windows group using "samba-tool group add",
> > > but if I set the --gid-number for the group it rejects the request
> > > unless I also pass in a --nis-domain:
> >
> > Correct
> >
> 
> >
> > >  > ERROR: Both --gid-number and --nis-domain have to be set for a
> > > RFC2307-enabled group. Operation cancelled.
> > >
> > > What value should I put for nis-domain? Just the workgroup name?
> > > AFAICS it ends up in the "msSFU30NisDomain" attribute but I don't
> > > know what this is used for, or why it's mandatory.
> >
> > It was added because this is what ADUC does when adding Unix
> > attributes.
> >
> 
> Microsoft AD emulates NIS+ (ex Yellow Pages). NIS are organised in
> domains. For that they added some update of their LDAP schema (which
> should be called msSFU3x).
> msSFU30 + NIS + Domain => msSFU30NisDomain :)
> 

Yes, that is how it was named, but what does it actually do ?

> That's the UNIX way to named the domain. These NIS domain are to get
> AD user on UNIX (and Linux) platforms.

The strange thing is 'workgroup' was used before SFU was written.

> 
> 
> >
> > >
> > > (3) It's traditional in Unix circles to have a primary group per
> > > user with the same name as the user, as this makes it feasible to
> > > use umask 0002 and easy file sharing.  Does this approach have to
> > > be abandoned when using AD/Samba as the user directory?
> >
> > Yes, you cannot have a group with the same name as a user, so no
> > user private groups.
> >
> 
> sAMAccountName must be unique in AD and users, groups and computer
> have all a sAMAccountName. This field is limited to 20 characters,
> not in LDAP but in Windows, when Windows system has to use that
> field, if it is more than 20 characters Windows gives an error
> message.
> 
> 

Doesn't that mean the same as 'no user private groups' ?

Rowland