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. https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC#Configuring_RFC2307_and_NIS_Extensions_in_a_Samba_AD 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 attributes? The problem chapter describes my situation - but both DC have set idmap_ldb:use rfc2307 = yes 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. > >Rowland > >> >> 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 3000017. >>> 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? >>> >>> Regards >>> Tim >>> >>> 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 here: >>> https://wiki.samba.org/index.php/Join_a_domain_as_a_DC , >>> near the bottom of the page. Rowland I take it that you >>> didn't read this page on the wiki: >>> https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO 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 ???? : >>> >https://wiki.samba.org/index.php/Local_user_management_and_authentication/sssd >>> Rowland >>> >>> >>> >>> 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. >>> >>> Rowland >>> >> >> 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 uidNumber). >> >> Rowland >>
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.> > https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC#Configuring_RFC2307_and_NIS_Extensions_in_a_Samba_AD > 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 > attributes?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 Rowland> 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. > > Rowland > >> >> 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 3000017. >>> 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? >>> >>> Regards >>> Tim >>> >>> 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 >>> here: >>> https://wiki.samba.org/index.php/Join_a_domain_as_a_DC >>> , near the bottom of the page. Rowland I take it >>> that you didn't read this page on the wiki: >>> https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO >>> 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 ???? >>> : >>> https://wiki.samba.org/index.php/Local_user_management_and_authentication/sssd >>> Rowland >>> >>> >>> >>> 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. >>> >>> Rowland >>> >> >> 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 uidNumber). >> >> Rowland >> >
Thanks for your answer and time you offer for me. That makes it a bit clearer. I searched the web and found that rsat needs to have the nis tools 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. 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. 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. 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. > >> >> >https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC#Configuring_RFC2307_and_NIS_Extensions_in_a_Samba_AD >> 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 >> attributes? > >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 > >Rowland > >> 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. >> >> Rowland >> >>> >>> 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 3000017. >>>> 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? >>>> >>>> Regards >>>> Tim >>>> >>>> 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 >>>> here: >>>> >https://wiki.samba.org/index.php/Join_a_domain_as_a_DC >>>> , near the bottom of the page. Rowland I take it >>>> that you didn't read this page on the wiki: >>>> https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO >>>> 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 ???? >>>> : >>>> >https://wiki.samba.org/index.php/Local_user_management_and_authentication/sssd >>>> Rowland >>>> >>>> >>>> >>>> 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. >>>> >>>> Rowland >>>> >>> >>> 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 uidNumber). >>> >>> Rowland >>> >>