[Samba] Samba 4 two DCs no matching UID/GID
rowlandpenny at googlemail.com
Wed Dec 10 14:26:52 MST 2014
On 10/12/14 21:05, Tim wrote:
> Thanks for your answer and time you offer for me. That makes it a bit
> I searched the web and found that rsat needs to have the nis tools
Good luck with trying to install 'Service for NIS', it installs on a
windows AD DC, you haven't got a windows AD DC, you have a Samba AD DC
and guess what, it already has the core of 'Service for NIS' installed,
> Does it create Unix uid/gid automatically then?
> Without rfc2307 information it makes no sense to me to have a *nix
> machine for file services and another one for backup purposes, when
> uid and gid are not same (due to preserve acls).
> And for now the xid is set on the FS.
Hard luck, that is just the way it is, **WHY* *do you think that it is
recommended to not use the DC as a fileserver ???
> I haven't created a user or group with rsat nis tools enabled yet. But
> I strongly hope that nis information will be generated automatically
> in the AD then. I'll try it tomorrow.
If you use the UNIX_Attributes tab in ADUC to give your users
'uidNumbers' etc, then it is likely that you will start at '10000'. Once
you give your first user a 'uidNumber' then the next ID number will be
stored in AD.
> Manual setting these attributes will not be comfortable and could be
> forgotten when creating a new user or group. In the end filesystem
> permissions on different filers will be corrupt - especially when one
> DC will crash.
That is why I am advising you to use ADUC, it is either that or writing
your own bash script around samba-tool or the ldb-tools.
> Am 10. Dezember 2014 20:58:06 MEZ, schrieb Rowland Penny
> <rowlandpenny at googlemail.com>:
> On 10/12/14 18:58, Tim wrote:
>> At the moment numbers start at 3000000 and counting. In my eyes
>> it would make sense, that these number be stored in the AD when
>> provisioned with rfc2307. Or it should be replicated by drs.
> The numbers you are seeing are coming from idmap.ldb, now as you
> are using Sernet packages on Centos7, this will be in
> /var/lib/samba/private/idmap.ldb. The number 3000000 is an
> xidNumber and is the result of samba4 mapping SID-RID to something
> that Unix will understand.
> If you just used the Samba4 AD DC for authentication and didn't
> store *anything* on the DC, you wouldn't need 'xidNumbers',
> 'uidNumbers' or 'gidNumbers', but then there is 'Sysvol'. You need
> this for GPO's etc, but again, access is only allowed by windows
> users, so the xidNumbers are sufficient. I hope you can see, if
> you only have windows users, you only need rfc2307 attributes when
> you store users files on the DC.
> As for storing Unix ID numbers in AD when provisioning with
> rfc2307, this does not and will not happen, Windows does not give
> users the rfc2307 attributes when 'Service for NIS' is added to AD
> and for a very good reason, all users might not require them.
>> says the following:
>> No need for manual ID counting when using the default Microsoft
>> tools. E. g. the next free UID and GID is stored directly in
>> Active Directory and will be incremented when creating a new user
>> or group.
>> But what is needed for this? Manual setting of NIS domain in Unix
> If you create your users with samba-tool on the DC, one of the
> options is '--uid-number=', but you have to enter the number
> yourself, samba-tool has nowhere to store the next uidNumber.
>> The problem chapter describes my situation - but both DC have set
>> idmap_ldb:use rfc2307 = yes
> The setting just tells the DC to use rfc2307, it does not set any,
> as I said, this is done by idmap.ldb, only problem is that the
> xidNumbers for a user are not forced to be the same on **both** DC's
>> I forgot to say that my server is CentOS 7 with most recent
>> SerNet Samba 4.1.13
>> Am 10. Dezember 2014 19:25:50 MEZ, schrieb Rowland Penny
>> <rowlandpenny at googlemail.com>:
>> On 10/12/14 17:30, Tim wrote:
>>> I will try this tomorrow. Possibly this is my fix.
>>> When a domain is provisioned with rfc2307 it would make
>>> sense that Unix attributes especially uid/gid would
>>> automatically be set.
>> This is a common misconception, it does not happen, one
>> reason being, what number do you start at ??
>>> A member also needs this to be set for unique fs acls right?
>> This is where winbind works if there are RFC2307 attributes
>> in AD, it can be set up to pull all the required attributes
>> from AD, this is one of the reasons that it is recommended to
>> use member servers with a DC.
>>> Am 10. Dezember 2014 18:07:02 MEZ, schrieb Rowland Penny
>>> <rowlandpenny at googlemail.com>:
>>> On 10/12/14 16:33, Tim wrote:
>>>> I think I will only need uid and gid due to fs stuff.
>>>> There are only Windows clients in that domain.
>>>> So when the IDs are the same on both DCs, all will be
>>>> fine I think.
>>>> In RSAT there are no Unix attributes set. As an
>>>> example: user1 has uid 3000021 on DC1 (first
>>>> provisioned one). DRS seems fine. On DC2 user1 gets uid
>>>> If I set ID in RSAT Unix attributes after choosing
>>>> domain, the IDs mentioned above will be overwritten?
>>>> Standard in Unix attributes is that ID is not set. E.g.
>>>> I set ID 2000021 in RSAT this ID will be set for user1
>>>> on both DCs because of use rfc2307 = yes?
>>>> Am 10. Dezember 2014 16:10:58 MEZ, schrieb Rowland
>>>> Penny <rowlandpenny at googlemail.com>:
>>>> On 10/12/14 14:39, Tim wrote:
>>>> I found this. But I didn't find it related to
>>>> DC idmapping replication. I have two pieces of
>>>> hardware. My goal is realize an active
>>>> directory for the windows clients and a file
>>>> server. The AD should have redundancy (this is
>>>> why I provisioned two DCs). The file should
>>>> integrate snapshots like a NetApp system
>>>> (snapshots are done by rsnapshot). The snapshot
>>>> functionality works so far by mounting cifs
>>>> shares read only of the backup hardware. But I
>>>> will try this via NFS due to permissions.
>>>> Mounting cifs shares leads to irritating
>>>> permissions of ~snapshot folders ("Everyone"
>>>> has full permissions). So how would sssd help
>>>> to replicate the ids regarding idmapping to the
>>>> secondary DC? It seems that this is my only
>>>> problem. Another option is to have only one DC
>>>> with NFS regarding snapshots and a file server
>>>> who is integrating the snapshots as mentioned
>>>> above. But then I have to backup the idmapping
>>>> file of the file server or does it get the ids
>>>> from the AD DC so that I don't have to backup?
>>>> The FS stores the ACL by using the IDs. I am
>>>> using XFS. Thanks in advance Tim Am 10.
>>>> Dezember 2014 13:48:40 MEZ, schrieb Rowland
>>>> Penny <rowlandpenny at googlemail.com>: On
>>>> 10/12/14 12:21, rintimtim at gmx.net wrote: Thanks
>>>> for the advice of copying the idmap.ldb. That
>>>> works. After adding zum users the uid and gid
>>>> begin to differ again. I read that it is not
>>>> recommended to run a DC as a fileserver but in
>>>> my case it's not really an option. It's a
>>>> network of twelve clients, so four servers are
>>>> incommensurate to this amount of clients. I
>>>> searched regarding sssd, because my
>>>> nsswitch.conf also has it. But how do I have to
>>>> configure it all? My actual nsswitch.conf
>>>> provides the following: passwd: files sss
>>>> shadow: files sss group: files sss services:
>>>> files sss netgroup: files sss Another
>>>> alternative seems to be regarding the idmap.ldb
>>>> with my unidirectional rsync replication of the
>>>> sysvol-folder. *Gesendet:* Mittwoch, 10.
>>>> Dezember 2014 um 11:01 Uhr *Von:* "Rowland
>>>> Penny" <rowlandpenny at googlemail.com> *An:* Tim
>>>> <rintimtim at gmx.net>, samba at lists.samba.org
>>>> *Betreff:* Re: [Samba] Samba 4 two DCs no
>>>> matching UID/GID On 09/12/14 22:49, Tim wrote:
>>>> But will this idmap.ldb change work for
>>>> upcoming new users or groups so that uid/gid
>>>> will not be different? The wiki tells us about
>>>> built-in groups. Those have the right ids. Am
>>>> 9. Dezember 2014 23:03:44 MEZ, schrieb Rowland
>>>> Penny <rowlandpenny at googlemail.com>: On
>>>> 09/12/14 21:07, Tim wrote: Hello all, I have a
>>>> fresh install of two CentOS 7 machines. On DC1
>>>> I made a domain provision with --use-rfc2307.
>>>> In DC2 I made a join as DC - both exactly as
>>>> the wiki advised. In fact of its missing I
>>>> added the idmap use rfc2307 yes parameter to
>>>> smb.conf. I will have an extra share on both
>>>> DCs. Today I realized, that wbinfo shows
>>>> different UID/GID for the same users or groups
>>>> on the DC's. I created the users/groups via
>>>> RSAT. I don't have a Unix attributes tab in
>>>> RSAT. Is that my problem for different uid/gid?
>>>> Thanks in advance Tim Hi, I think your problem
>>>> is that idmap.ldb does not replicate to the new
>>>> DC, this means that users get different UID's
>>>> on the two DC's. If you run: ldbedit -e nano -H
>>>> /var/lib/samba/private/idmap.ldb on each DC,
>>>> you will be able to see the differences. The
>>>> cure ? copy idmap.ldb from the first DC to any
>>>> secondary DC's after the join. It is documented
>>>> , near the bottom of the page. Rowland I take
>>>> it that you didn't read this page on the wiki:
>>>> You are running into one of the problems why it
>>>> is not recommended to use the DC as a
>>>> fileserver, you have two choices here, either
>>>> set up a separate member server to use as a
>>>> fileserver, or use sssd or nlscd to pull the
>>>> RFC2307 attributes that you will need to add to
>>>> the users/groups. Whatever you do, you will
>>>> need to copy idmap.ldb to any secondary DC's.
>>>> Rowland Did you search on the samba wiki ???? :
>>>> OK, another wikipage:https://wiki.samba.org/index.php/RFC2307_backend
>>>> The only way to ensure that your users have consistent uidNumbers &
>>>> gidNumbers on **any** Unix machine, is to use the RFC2307 attributes.
>>>> The attributes are all available out of the box with Samba4, you just
>>>> have to give your users and groups the required attributes.
>>>> Once you have given your users & groups these attributes, you then have
>>>> to use something to pull these attributes. Winbind is available from
>>>> Samba, but winbind on the DC is different from the winbind that is used
>>>> on a member server or client. The winbind that is available on the DC
>>>> will not pull any RFC2307 attributes other than 'uidNumber' &
>>>> 'gidNumber'. What this means is, if you want to use different
>>>> unixHomeDirectories & loginShell's, you need to use sssd or nlscd.
>>> By default, no users have a uidNumber and no groups have
>>> a gidNumber. If you use the UNIX_Attributes tab in ADUC,
>>> the default start number is 10000, though you can change
>>> this, I wouldn't bother. Just update any users via ADUC,
>>> AD will then store the next uidNumber (or gidNumber) for
>>> you. If you then go to the DC and run 'getent passwd
>>> <the user you just updated on ADUC>', you will find that
>>> the users ID number will have changed to whatever you
>>> used in ADUC. This same command should give the same
>>> result on the second DC, though there may be a problem
>>> on both DC's if the cache hasn't cleared, if so, wait a
>>> short while, or run 'net cache flush'.
>>> If you update users with ADUC, do not add users with
>>> samba-tool and try to add the users uidNumber at the
>>> same time, you could use a number that is already in use
>>> for another user. You can use the same number for a
>>> group as a user, they are different objects.
>>> If you do use ADUC to add the users uidNumber and the
>>> user already has any info stored on the DC, you will
>>> need to change the ownership of this info to the user
>>> (the info will show as belonging to the users old
More information about the samba