Hi all, Following this thread with interest, as we are also having some issues with GPO (they work on and off, unpredictably) We checked iddap.ldb on the DCs and noticed differences between DCs. We would like to ask some questions: On 10-6-2016 9:26, Rowland penny wrote:> Well, it is and it isn't, yes winbindd will display the user & group > names for sysvol, but sysvol still isn't replicated between DCs. I think > this means that when you sync sysvol manually, you will get the ID's > from the first DC applied to sysvol on the second DC and if there is a > difference in ID numbers between the DC's, you will either just get a > number or, even worse, a wrong name returned. > > I could be wrong, but I still think you need to keep idmap.ldb in sync > on all DCs, if you are syncing sysvol.We are on sernet-samba-4.4.4 on the DCs, and "winbindd -D" is running on DCs. We understand we need to keep idmap.ldb in sync. We did this in the past, but it seems they have gotten out of sync again. One question: HOW OFTEN do we need to do manually sync the imap.ldb files? After each and every regular user addition/deletion? We are currently on sernet-4.4.4 on the 3 DCs, but on our fileserver we are still on samba 4.2.11 and sssd. Would that last bit have any impact on the GPO situation..? (i don't think so, because GPOs are on the DCs and not on the fileserver..?) Since our idmap.ldb differs per DC, HOW to choose which one to copy to the other DCs? Choosing wrongly will probably have major implications..? Sorry to ask so many questions, hopefully someone will answer. Best regards, MJ
On 6/20/2016 1:19 PM, lists wrote:> Hi all, > > Following this thread with interest, as we are also having some issues > with GPO (they work on and off, unpredictably) > We checked iddap.ldb on the DCs and noticed differences between DCs. > > We would like to ask some questions: > > On 10-6-2016 9:26, Rowland penny wrote: >> Well, it is and it isn't, yes winbindd will display the user & group >> names for sysvol, but sysvol still isn't replicated between DCs. I think >> this means that when you sync sysvol manually, you will get the ID's >> from the first DC applied to sysvol on the second DC and if there is a >> difference in ID numbers between the DC's, you will either just get a >> number or, even worse, a wrong name returned. >> >> I could be wrong, but I still think you need to keep idmap.ldb in sync >> on all DCs, if you are syncing sysvol. > > We are on sernet-samba-4.4.4 on the DCs, and "winbindd -D" is running > on DCs. > > We understand we need to keep idmap.ldb in sync. We did this in the > past, but it seems they have gotten out of sync again. > One question: HOW OFTEN do we need to do manually sync the imap.ldb > files? After each and every regular user addition/deletion? > > We are currently on sernet-4.4.4 on the 3 DCs, but on our fileserver > we are still on samba 4.2.11 and sssd. Would that last bit have any > impact on the GPO situation..? (i don't think so, because GPOs are on > the DCs and not on the fileserver..?) > > Since our idmap.ldb differs per DC, HOW to choose which one to copy to > the other DCs? Choosing wrongly will probably have major implications..? > > Sorry to ask so many questions, hopefully someone will answer. > > Best regards, > MJ >Mine are also out of sync. Using Samba 4.4.4 on Ubuntu 12.04. I no longer keep the idmap.ldb in sync as I thought this was no longer needed since version 4.2 or greater unless using winbind. I also never would reset sysvol on the other DC's when replicating using rsync. I don't believe it was ever in the wiki. Clarification from someone would be helpful. -- -James
On 20/06/16 18:19, lists wrote:> Hi all, > > Following this thread with interest, as we are also having some issues > with GPO (they work on and off, unpredictably) > We checked iddap.ldb on the DCs and noticed differences between DCs. > > We would like to ask some questions: > > On 10-6-2016 9:26, Rowland penny wrote: >> Well, it is and it isn't, yes winbindd will display the user & group >> names for sysvol, but sysvol still isn't replicated between DCs. I think >> this means that when you sync sysvol manually, you will get the ID's >> from the first DC applied to sysvol on the second DC and if there is a >> difference in ID numbers between the DC's, you will either just get a >> number or, even worse, a wrong name returned. >> >> I could be wrong, but I still think you need to keep idmap.ldb in sync >> on all DCs, if you are syncing sysvol. > > We are on sernet-samba-4.4.4 on the DCs, and "winbindd -D" is running > on DCs.If you are using Sernet 4.4.4 packages, you must have a Sernet subscription, you may get quicker help there.> > We understand we need to keep idmap.ldb in sync. We did this in the > past, but it seems they have gotten out of sync again. > One question: HOW OFTEN do we need to do manually sync the imap.ldb > files? After each and every regular user addition/deletion?I was wrong, if you are using 4.2.0 or later, you do not need to sync idmap.ldb, winbindd should report the correct user/groupname.> > We are currently on sernet-4.4.4 on the 3 DCs, but on our fileserver > we are still on samba 4.2.11 and sssd. Would that last bit have any > impact on the GPO situation..? (i don't think so, because GPOs are on > the DCs and not on the fileserver..?) >It shouldn't, because, as you say, GPO's are only stored on the DC's.> Since our idmap.ldb differs per DC, HOW to choose which one to copy to > the other DCs? Choosing wrongly will probably have major implications..?try running getfacl on the sysvol dir, you should get something like this: root at dc1:~# getfacl /usr/local/samba/var/locks/sysvol getfacl: Removing leading '/' from absolute path names # file: usr/local/samba/var/locks/sysvol # owner: root # group: BUILTIN\134administrators # flags: -s- user::rwx user:root:rwx user:BUILTIN\134administrators:rwx group::rwx group:BUILTIN\134administrators:rwx group:BUILTIN\134server\040operators:r-x group:3000002:rwx group:3000003:r-x mask::rwx other::--- default:user::rwx default:user:root:rwx default:user:BUILTIN\134administrators:rwx default:group::--- default:group:BUILTIN\134administrators:rwx default:group:BUILTIN\134server\040operators:r-x default:group:3000002:rwx default:group:3000003:r-x default:mask::rwx default:other::--- You should have two mapped users/groups and two unmapped ones. Repeat on the other DCs, then open 'idmap.ldb' on each DC with ldbedit and check that the unmapped ones are mapped to the same windows RIDs, which should be CN=S-1-5-18 and CN=S-1-5-11 If they are all the same, no problem, if not, then we will come to that if we have to :-) Rowland> > Sorry to ask so many questions, hopefully someone will answer. > > Best regards, > MJ >
On 20/06/16 18:49, lingpanda101 at gmail.com wrote:> On 6/20/2016 1:19 PM, lists wrote: >> Hi all, >> >> Following this thread with interest, as we are also having some >> issues with GPO (they work on and off, unpredictably) >> We checked iddap.ldb on the DCs and noticed differences between DCs. >> >> We would like to ask some questions: >> >> On 10-6-2016 9:26, Rowland penny wrote: >>> Well, it is and it isn't, yes winbindd will display the user & group >>> names for sysvol, but sysvol still isn't replicated between DCs. I >>> think >>> this means that when you sync sysvol manually, you will get the ID's >>> from the first DC applied to sysvol on the second DC and if there is a >>> difference in ID numbers between the DC's, you will either just get a >>> number or, even worse, a wrong name returned. >>> >>> I could be wrong, but I still think you need to keep idmap.ldb in sync >>> on all DCs, if you are syncing sysvol. >> >> We are on sernet-samba-4.4.4 on the DCs, and "winbindd -D" is running >> on DCs. >> >> We understand we need to keep idmap.ldb in sync. We did this in the >> past, but it seems they have gotten out of sync again. >> One question: HOW OFTEN do we need to do manually sync the imap.ldb >> files? After each and every regular user addition/deletion? >> >> We are currently on sernet-4.4.4 on the 3 DCs, but on our fileserver >> we are still on samba 4.2.11 and sssd. Would that last bit have any >> impact on the GPO situation..? (i don't think so, because GPOs are on >> the DCs and not on the fileserver..?) >> >> Since our idmap.ldb differs per DC, HOW to choose which one to copy >> to the other DCs? Choosing wrongly will probably have major >> implications..? >> >> Sorry to ask so many questions, hopefully someone will answer. >> >> Best regards, >> MJ >> > > Mine are also out of sync. Using Samba 4.4.4 on Ubuntu 12.04. I no > longer keep the idmap.ldb in sync as I thought this was no longer > needed since version 4.2 or greater unless using winbind. > > I also never would reset sysvol on the other DC's when replicating > using rsync. I don't believe it was ever in the wiki. Clarification > from someone would be helpful. >If you use Samba < 4.2.0 with the 'winbind' part of the 'samba' binary, then you had to, but if you use Samba >= 4.2.0, then this uses the separate 'winbindd' binary and this will map the BUILTIN users & groups correctly. Rowland
Hi Rowland, list, On 20-6-2016 20:04, Rowland penny wrote:> If you are using Sernet 4.4.4 packages, you must have a Sernet > subscription, you may get quicker help there.Well I'm not sure this kind of support is included, but even if it were, then others would not benefit from the dialogue with their support. :-)> I was wrong, if you are using 4.2.0 or later, you do not need to sync > idmap.ldb, winbindd should report the correct user/groupname.It does do that on all DCs, yes.> try running getfacl on the sysvol dir, you should get something like this: > > root at dc1:~# getfacl /usr/local/samba/var/locks/sysvol...snip> default:mask::rwx > default:other::--- > > You should have two mapped users/groups and two unmapped ones. > Repeat on the other DCs, then open 'idmap.ldb' on each DC with ldbedit > and check that the unmapped ones are mapped to the same windows RIDs, > which should be CN=S-1-5-18 and CN=S-1-5-11So, they are the same on DC2 and DC3, but the xid for CN=S-1-5-18 is different on DC4 (DC4 is 3000024, compared to 3000300 on the DC2/DC3) Also getfacl /var/lib/samba/sysvol looks very different on DC4:> root at dc4:~# getfacl /var/lib/samba/sysvol/ > getfacl: Removing leading '/' from absolute path names > # file: var/lib/samba/sysvol/ > # owner: root > # group: BUILTIN\134administrators > user::rwx > user:root:rwx > user:BUILTIN\134administrators:rwx > user:3000009:r-x > user:OURDOMAIN\134proxmox$:rwx > group::rwx > group:BUILTIN\134server\040operators:r-x > group:BUILTIN\134administrators:rwx > group:3000009:r-x > group:OURDOMAIN\134proxmox$:rwx > mask::rwx > other::--- > default:user::rwx > default:user:root:rwx > default:user:BUILTIN\134administrators:rwx > default:user:3000009:r-x > default:user:OURDOMAIN\134proxmox$:rwx > default:group::--- > default:group:BUILTIN\134server\040operators:r-x > default:group:BUILTIN\134administrators:rwx > default:group:3000009:r-x > default:group:OURDOMAIN\134proxmox$:rwx > default:mask::rwx > default:other::---So the 'unmapped group' 3000300 has become a domain group. I'm guessing that we need to solve this. Could you tell me how?> If they are all the same, no problem, if not, then we will come to that > if we have to :-)Well, then if you would be so kind...? ;-) Thanks very much Rowland! MJ