RFC2307 on a Samba DC - HowTo

[Marc Muehlfeld]

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

[Franz Pförtsch]

Hello Marc,

I do not have the Unix - Attribute tab?
Do I have to install the sfu utilities?

regards
Franz

[Giuseppe Ragusa]

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

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

[steve]

On Sun, 2014-05-18 at 19:36 +0200, Marc Muehlfeld 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

Re:
'Check if RFC2307 is enabled in your Active Directory

If you have a working Samba Active Directory, you can check the
following, to find out, if RFC2307 is already enabled:'

Marc,
Your howto is misleading.
rfc2307 is ALWAYS activated for a Samba4 DC.

Your howto applies only if a user wishes to use windows to manage
rfc2307. samba-tool and ldbedit can be used to manage rfc2307 without
any special provisioning nor schema extension.

Steve

[Rowland Penny]

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

[Giuseppe Ragusa]

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

[Rowland Penny]

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

[Marc Muehlfeld]

Hello Franz,

Am 18.05.2014 20:12, schrieb Franz Pförtsch:
> I do not have the Unix - Attribute tab?
> Do I have to install the sfu utilities?

If you follow
https://wiki.samba.org/index.php/Installing_RSAT_on_Windows_for_AD_Management
you should have it.


Or do you use XP? There you had to register a DLL:
https://support.microsoft.com/kb/921913/en


Regards,
Marc

[Giuseppe Ragusa]

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

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

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.

Regards,
Giuseppe

[Marc Muehlfeld]

Hello Steve,

Am 18.05.2014 21:07, schrieb steve:
> 'Check if RFC2307 is enabled in your Active Directory
>
> If you have a working Samba Active Directory, you can check the
> following, to find out, if RFC2307 is already enabled:'
>
> Marc,
> Your howto is misleading.
> rfc2307 is ALWAYS activated for a Samba4 DC.
>
> Your howto applies only if a user wishes to use windows to manage
> rfc2307. samba-tool and ldbedit can be used to manage rfc2307 without
> any special provisioning nor schema extension.

I did some changes in the complete HowTo, to be more specific:
https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC



Regards,
Marc

[steve]

Mmm
The implication is that the ypserv NIS schema _has_ to be installed and
that windows is the only way to work with rfc2307. There is no mention
of samba-tool to do the same on the DC.

how about this as the first paragraph:
'Samba4 comes complete with a complete set of rfc2307 attributes which
are available immediately following a default provision. The following
howto is only needed should you need to work with rfc2307 from a windows
computer.'

Then another howto on manipulation rfc2307 on the DC from the Unix side:
1. samba-tool
2. ldbedit
3. ldbmodify

HTH
Steve

[Marc Muehlfeld]

Am 19.05.2014 00:40, schrieb steve:
> The implication is that the ypserv NIS schema _has_ to be installed and
> that windows is the only way to work with rfc2307. There is no mention
> of samba-tool to do the same on the DC.
>
> how about this as the first paragraph:
> 'Samba4 comes complete with a complete set of rfc2307 attributes which
> are available immediately following a default provision. The following
> howto is only needed should you need to work with rfc2307 from a windows
> computer.'

That RFC2307 is already enabled per default, is already mentioned in the
first section. The rest of the HowTo are general information, byside the
ADUC stuff at the end and not just Windows related.

And I even use the ypServ30 schema if I'm administrating on Linux,
because I increment there the next UID/GID, like ADUC does. So it's easy
to track the last used IDs and I stay ADUC compatible if other
administrators or I use ADUC.

> Then another howto on manipulation rfc2307 on the DC from the Unix side:
> 1. samba-tool
> 2. ldbedit
> 3. ldbmodify

Feel free to register an account and add it. As more people contributing
to the Wiki, as faster we are getting a great documentation ;-)



Regards,
Marc

[Niklas Andersson]

Looks really good! Going to be very useful for lots of people. I really
liked the explanation about why it makes sense to have rfc2307 and always
get the same UID.

Great job!

//Niklas

[Günter Kukkukk]

Am 18.05.2014 19:36, schrieb Marc Muehlfeld:
> 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 Marc,

thanks a lot - great new info! :-)

I'm not 100% sure atm, but i think some further clarifications regarding
${NETBIOSNAME} aka "Netbios Name", ...
are needed.

At the top you use:
-------------------------------------
Server information used in this HowTo

Inside this HowTo, we will be using the following configuration/settings:

Domain Controller Name: DC1 <==== !!! smb.conf: "netbios name = DC1" ?
Installation Directory: /usr/local/samba/
LDAP Domain DN: DC=samdom,DC=example,DC=com
Netbios Name: samdom <==== !!! what is meant here - a "netbios hostname" or a "netbios domain"?
NIS Domain: samdom
--------------------------------------

Later down in section
--------------------------------------
Extending the Schema for NIS Extensions

# sed -i -e 's/${DOMAINDN}/DC=samdom,DC=example,DC=com/g' \
-e 's/${NETBIOSNAME}/samdom/g' \ <==== is that really right?
-e 's/${NISDOMAIN}/samdom/g' \
/tmp/ypServ30.ldif
--------------------------------------

In "ypServ30.ldif" this replacement is done then in many places:

msSFU30MasterServerName: ${NETBIOSNAME} <=== is that expected ?
-------------------------------------------------------------------------

The following command will list some *basic* domain infos:
samba-tool domain info li4771-131

Forest : addlz.kukkukk.com
Domain : addlz.kukkukk.com
Netbios domain : ADDLZ
DC name : li4771-131.addlz.kukkukk.com
DC netbios name : LI4771-131
Server site : Default-First-Site-Name
Client site : Default-First-Site-Name

to get some relationship to the "legacy NETBIOS names".

Cheers, G�nter
--

[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

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
>

[Rowland Penny]

Hi, I can understand Marc' point of view here, but Steve has raised a
valuable point, there are other ways of managing RFC2307 attributes in
Samba4 AD.
You can use ldb-tools, but this really requires a lot of knowledge and
is not for a beginner. The other method is to use samba-tool, now whilst
this will allow you to create a new user, it also has its problems.

If you want to create a new user with samba-tool it is fairly simple:

samba-tool user add username userpassword

Unfortunately, this is not how windows does it! If you create a user
through ADUC, you must also supply the users first & last names.

If you want your user to be a Unix user as well you can add:
'--uid-number=UID_NUMBER --gid-number=GID_NUMBER'

You must supply the two numbers and keep track of them yourself, there
is nowhere in samba4 AD (as standard) to store these numbers.

The last big problem is, if you carry out a classicupgrade, you get the
posix objectClasses in AD, NO windows tools will add these objectClasses
and if you then start to add users (either by ADUC or samba-tool), then
these new users will not get the posix objectClasses. This could then
lead to incorrect results being returned by searches of AD by external
tools, if these tools rely on the posix objectClasses.

IMHO, parts of samba-tool need to be re-written to make it work in the
same way as ADUC, I would do this if I could but, I do not have any
coding ability with python, bash scripts yes, python a big no.

Rowland

[steve]

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

[Rowland Penny]

On 19/05/14 03:53, G�nter Kukkukk wrote:
> Am 18.05.2014 19:36, schrieb Marc Muehlfeld:

>> 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, Gunter is correct, ${NETBIOSNAME} should be set to the hostname of
your first DC i.e. the one that you provisioned.

Here is the proof:

From ypServ30.ldif:

dn: CN=${NISDOMAIN},CN=mail,CN=ypServ30,CN=RpcServices,CN=System,${DOMAINDN}
objectClass: top
objectClass: msSFU30DomainInfo
msSFU30MasterServerName: ${NETBIOSNAME}
msSFU30OrderNumber: 10000
msSFU30Domains: ${NISDOMAIN}

From my server (sanitized):

dn:
CN=example,CN=mail,CN=ypServ30,CN=RpcServices,CN=System,DC=example,DC=com
objectClass: top
objectClass: msSFU30DomainInfo
msSFU30MasterServerName: DC1
msSFU30OrderNumber: 10000
msSFU30Domains: example

Rowland

[Marc Muehlfeld]

Hello G�nter,

Am 19.05.2014 04:53, schrieb G�nter Kukkukk:
> Netbios Name: samdom <==== !!! what is meant here - a "netbios hostname" or a "netbios domain"?

Thanks. This should be netbios _domain_. I've changed that.

> Later down in section
> --------------------------------------
> Extending the Schema for NIS Extensions
>
> # sed -i -e 's/${DOMAINDN}/DC=samdom,DC=example,DC=com/g' \
> -e 's/${NETBIOSNAME}/samdom/g' \ <==== is that really right?
> -e 's/${NISDOMAIN}/samdom/g' \
> /tmp/ypServ30.ldif
> --------------------------------------

Right. This should be "DC1". I've changed that, too.





Thanks for proofreading.


Regards,
Marc

[Marc Muehlfeld]

Hello,

Am 19.05.2014 11:39, schrieb Rowland Penny:
> Hi, Gunter is correct, ${NETBIOSNAME} should be set to the hostname of
> your first DC i.e. the one that you provisioned.
>
> Here is the proof:
>
> From ypServ30.ldif:
>
> dn:
> CN=${NISDOMAIN},CN=mail,CN=ypServ30,CN=RpcServices,CN=System,${DOMAINDN}
> objectClass: top
> objectClass: msSFU30DomainInfo
> msSFU30MasterServerName: ${NETBIOSNAME}
> msSFU30OrderNumber: 10000
> msSFU30Domains: ${NISDOMAIN}
>
> From my server (sanitized):
>
> dn:
> CN=example,CN=mail,CN=ypServ30,CN=RpcServices,CN=System,DC=example,DC=com
> objectClass: top
> objectClass: msSFU30DomainInfo
> msSFU30MasterServerName: DC1
> msSFU30OrderNumber: 10000
> msSFU30Domains: example

I already changed that in the HowTo.


But does anybody has some background information about
msSFU30MasterServerName?

What requires to know this servername? It's inside the directory and can
be accessed on all DCs. And what would happen if "DC1" is demoted some day?


Regards,
Marc

[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

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

[Marc Muehlfeld]

Hello Rowland,

Am 19.05.2014 11:00, schrieb Rowland Penny:
> If you want your user to be a Unix user as well you can add:
> '--uid-number=UID_NUMBER --gid-number=GID_NUMBER'
>
> You must supply the two numbers and keep track of them yourself, there
> is nowhere in samba4 AD (as standard) to store these numbers.

I think --use-rfc2307 should be default on provisioning. It does not
hurt and brings no disadvantages if not used. But samba-tool could use
it, like ADUC, to automatically get the next free UID/GID. And it would
be ADUC compatible.

I had created a feature request for that:
https://bugzilla.samba.org/show_bug.cgi?id=10619

> The last big problem is, if you carry out a classicupgrade, you get the
> posix objectClasses in AD, NO windows tools will add these objectClasses
> and if you then start to add users (either by ADUC or samba-tool), then
> these new users will not get the posix objectClasses. This could then
> lead to incorrect results being returned by searches of AD by external
> tools, if these tools rely on the posix objectClasses.

Can you open a enhancement request in bugzilla for that, please?



Regards,
Marc