On Thu, Apr 28, 2016 at 2:13 AM, Rowland penny <rpenny at samba.org> wrote:> On 28/04/16 07:31, Mueller wrote: >> >> This is a normal behaviour if you are using several dcs. Users und groups >> do have another gid/uid on each server >> until you fix it manually. This was a hard experiennce and work even fo >> rme which I suggest that this should be >> the next goal for the samba 4 developers to solve and fix it in an easy >> way for the admins. >> In my opinion, if I run several dcs in a domain this should be done >> between the dcs automatically without intervention. >> >> Greetings >> Daniel >> >> EDV Daniel Müller >> >> >> > > It isn't really a problem until you start copying files between DCs by means > other than Samba ones. It is very similar to using the 'rid' backend i.e. > Samba creates the UID , but with one big difference, the 'rid' backend > calculates the UID from the users RID, this way, the user should get the > same UID wherever the 'rid' backend is used. With idmap.ldb, the user just > gets the next UID available i.e. first come, first served. > > In my opinion, the 'Well known SIDs' need to be allocated fixed IDs and then > winbind usage brought into line with the way a 'domain member' works. >Now I can barely understand what the problem might be. I'll take a look at the wiki page to better understand what's wrong and how to fix it. I'll be back... Have a nice day :)
On 28/04/16 18:03, Jason Voorhees wrote:> On Thu, Apr 28, 2016 at 2:13 AM, Rowland penny <rpenny at samba.org> wrote: >> On 28/04/16 07:31, Mueller wrote: >>> This is a normal behaviour if you are using several dcs. Users und groups >>> do have another gid/uid on each server >>> until you fix it manually. This was a hard experiennce and work even fo >>> rme which I suggest that this should be >>> the next goal for the samba 4 developers to solve and fix it in an easy >>> way for the admins. >>> In my opinion, if I run several dcs in a domain this should be done >>> between the dcs automatically without intervention. >>> >>> Greetings >>> Daniel >>> >>> EDV Daniel Müller >>> >>> >>> >> It isn't really a problem until you start copying files between DCs by means >> other than Samba ones. It is very similar to using the 'rid' backend i.e. >> Samba creates the UID , but with one big difference, the 'rid' backend >> calculates the UID from the users RID, this way, the user should get the >> same UID wherever the 'rid' backend is used. With idmap.ldb, the user just >> gets the next UID available i.e. first come, first served. >> >> In my opinion, the 'Well known SIDs' need to be allocated fixed IDs and then >> winbind usage brought into line with the way a 'domain member' works. >> > Now I can barely understand what the problem might be. I'll take a > look at the wiki page to better understand what's wrong and how to fix > it. > > I'll be back... Have a nice day :)The fix is fairly simple, you need to copy idmap.ldb from the first DC to the second and then keep them in sync. Rowland
On Thu, 28 Apr 2016, Jason Voorhees wrote:> Now I can barely understand what the problem might be. I'll take a > look at the wiki page to better understand what's wrong and how to fix > it.I believe this is the part you're looking for, which explains the problem and gives the solution: https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups
Hey guys, thanks for your time. Unfortunately, I've been busy so I wasn't able to test it again. Just today I started to read, investigate and test all this stuff you suggested me. I don't fully understand yet how uidNumbers and xidNumbers work, all I know is that Zentyal is using the old winbind daemon instead of the new winbindd. There are many concepts that I don't know how they relate to each other, but this is what I've tested: 1. On the 2nd. DC, I've remounted the filesystem with acl and xattr options. 2. On the 2nd. DC, I've disabled apparmor. 3. From the 1st DC, I've modified my rsync script to also include the X option to synchronize extented attributes too. 4. I've backed up idmap.ldb from 1st. DC using "tdbbackup -s bak idmap.ldb" and copied to 2nd. DC as idmap.ldb. Then I ran "samba-tool ntacl sysvolreset" on the 2nd DC and restarted Samba. 5. I've copied the original idmap.ldb file from 1st to 2nd DC, ran "samba-tool ntacl sysvolreset" on 2nd DC and restarted Samba again. 6. I've synchronized the sysvol share from 1st to 2nd DC using rsync -aAHSX, ran "samba-tool ntacl sysvolreset" on 2nd DC and restarted Samba again. I've tried to access one of my shares on the 2nd DC but I always got the same error "NT_STATUS_ACCESS_DENIED listing \*". So in the middle of the night (02:00 am) and giving up just for today... The only "strange" thing I notice is this: If I connect to a certain share in the 1st DC I see a log like this: 127.0.0.1 (ipv4:127.0.0.1:55282) connect to service Central initially as user AGN\cchavarrias (uid=2502, gid=2513) (pid 26854) But on the 2nd DC the log look like this: __1 (ipv6:::1:33880) connect to service Central initially as user AGN\cchavarrias (uid=2502, gid=100) (pid 8708) On the 1st DC, "cchavarria" user is using GID 2513 (domain users group from Samba) but on the 2nd DC is using GID 100 (default group from OS). If I run the "id" command on both DCs, the information is the same: On DC 1: # id cchavarrias uid=2502(cchavarrias) gid=2513(domain users) groups=2513(domain users),2512(domain admins),3124(usuarios) On DC 2: # id cchavarrias uid=2502(cchavarrias) gid=2513(domain users) groups=2513(domain users),3124(usuarios),2512(domain admins) I wonder if the fact that GID 100 is being used on the 2nd DC is causing any problems due to ACLs not granted to group with GID 100. However, cchavarrias user has full permissions through ACLs in both DCs for every share. P.S.: By using ldbsearch over idmap.ldb I noticed that xidNumber attribute is the same for cchavarrias user in both, 1st and 2nd DC, so I guess xidNumbers match correctly. Am I right? On Thu, Apr 28, 2016 at 12:12 PM, Sketch <smblist at rednsx.org> wrote:> On Thu, 28 Apr 2016, Jason Voorhees wrote: > >> Now I can barely understand what the problem might be. I'll take a >> look at the wiki page to better understand what's wrong and how to fix >> it. > > > I believe this is the part you're looking for, which explains the problem > and gives the solution: > > https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups >