Re: [Samba] samba-tool ntacl sysvol check errors (samba 4.7.4 AD DC)
- Date: Thu, 11 Jan 2018 13:14:40 +0000
- From: Rowland Penny via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] samba-tool ntacl sysvol check errors (samba 4.7.4 AD DC)
On Thu, 11 Jan 2018 13:47:12 +0100
Kacper Wirski via samba <samba@xxxxxxxxxxxxxxx> wrote:
> To answer my own question:
> I solved it (I think).
> There were 2 causes basically:
> 1) I had messed up idmap.ldb on DC's (one with PDC FSMO was fine, the
> other two had more-or-less wrong mappings). I simply:
> created hot backup of idmap.ldb on DC1, stopped samba on other dc's,
> and overwritten idmap.ldb there.
> the above solved issue of GPO not being accessed
> 2) sysvolcheck was a bit trickier, but after reading some of the
> archives i realized, that "proper" way is for DOMAIN ADMINS to be
> owner as user and group. I had previously setup GUID in RSAT for
> domain admins, and DC's use rfc.
> I removed GUID for this group, run net cache flush on each DC and on
> DC1 i ran sysvolreset. All acl (with getfacl) look OK, and
> sysvolcheck returns 0 error.
> domain admins is now the owner as user and group of Policies.
> If anyone has some comment if there's some mistake in what I did and
> if I might end up getting some errors in the future, I'd be more than
> glad to hear it.
> Also I have a related question:
> let's suppose i don't set UID or GID for group/user in domain and let
> samba DC dynamically add it to idmap.ldb
> Then let's suppose I want to add this user as ACL to GPO "xyz". DC
> with PDC is guaranteed to make correct mapping since it's the one
> that I'm configuring GPO on, but what's keeping other DC's to use
> same mapping? Is it just that idmap increments +1 for every new user?
> I think there is room for error, when more than 1 user/group is added
> at a time, before they manage to replicate to other DC's, then order
> in which local idmapping is done might be different on DC's. I
> tested it yesterday in test environment: I added 2 users to DC3 with
> no UID, and on DC3 and DC2 they were mapped to 3000127 (1st) 3000128
> (2nd), and on DC1 1st(3000128 and 2nd 3000127. Then, obviously, when
> I applied ACL for user 1st, after sysvol rsynced to dc2 and dc3, they
> had messed up mappings - copying idmap.ldb from DC1 again solved this
> So question: how can You prevent such scenario? Are you supposed to
> periodically "sync" idmap.ldb from one DC to others to keep mappings
> in order? Is using RFC option for assigining UID/GID the only way?
idmap.ldb is a bit like a mixture of the winbind 'ad' and 'rid'
backends, in that the IDs are calculated for you and the next available
ID is used. The problem is that the IDs are set on each DC on a first
come basis, this leads, as you have found, to different IDs on each DC.
To 'fix' this problem, you need to sync idmap.ldb between the DCs, even
if you were give all your normal users and groups uidNumber &
gidNumber attributes, you would still need to sync idmap.ldb
To unsubscribe from this list go to the following URL and read the