samba - Jan 2018 - samba-tool ntacl sysvol check errors (samba 4.7.4 AD DC)

Hello,

Since I updated recently my samba DC's, I've noticed some werid 
behaviour on windows stations (seems random?) with some GPO's not being 
applied from time to time (reboot or even logoff-login usually does the 
trick). When policy is not applied and I run "gpupdate" on windows 
client  I'm getting output, that policy xxx (Default domain policy) 
could not be processed and because of this no other policy will be 
processed.

So i ran samba-tool ntacl sysvolcheck on DC with PDC FSMO, and I'm 
getting errors like this:

ERROR(<class 'samba.provision.ProvisioningError'>): uncaught
exception -
ProvisioningError: DB ACL on GPO directory 
/usr/local/samba/var/locks/sysvol/mydomain.com/Policies/{77B4CB26-79A1-44B7-A003-1D8848B58128}
O:DAG:DAD:PAI(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
does not match expected value 
O:DAG:DAD:P(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
from GPO object
   File 
"/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/__init__.py",
line 176, in _run
     return self.run(*args, **kwargs)
   File 
"/usr/local/samba/lib64/python2.7/site-packages/samba/netcmd/ntacl.py",
line 270, in run
     lp)
   File 
"/usr/local/samba/lib64/python2.7/site-packages/samba/provision/__init__.py",
line 1723, in checksysvolacl
     direct_db_access)
   File 
"/usr/local/samba/lib64/python2.7/site-packages/samba/provision/__init__.py",
line 1674, in check_gpos_acl
     domainsid, direct_db_access)
   File 
"/usr/local/samba/lib64/python2.7/site-packages/samba/provision/__init__.py",
line 1621, in check_dir_acl
     raise ProvisioningError('%s ACL on GPO directory %s %s does not 
match expected value %s from GPO object' % (acl_type(direct_db_access), 
path, fsacl_sddl, acl))

I'm not sure what to make out of it. I understand that ACL are somehow 
correct ("does not match expected value ").

I've run sysvol reset, but I didn't notice anything change.

I also tried recreating that policy via RSAT and GPO management snap-in. 
I'v edone "copy -> paste (use default settings)". Policy was
added with
new policy ID, with completely default settings, but I got error with ID 
of the "new" policy.

samba-tool dbcheck --cross-ncs shows no errors, from windows client all 
permissions seem fine, samba daemon doesn't generate any errors.

Only issue is that windows client occasionaly doesn't apply some (not 
all) of the policies, but after restart they're fine. I'm not sure if 
i'm even on the right track.

Can someone maybe explain what this error means, and how to possibly fix it?

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 issue.

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?

Regards,

Kacper

On Thu, 11 Jan 2018 13:47:12 +0100
Kacper Wirski via samba <samba at lists.samba.org> 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
> issue.
> 
> 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?
> 
> Regards,
> 
> Kacper
> 
> 
> 
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
 
Rowland

On Thu, 11 Jan 2018 14:35:09 +0100
Kacper Wirski <kacper.wirski at gmail.com> wrote:
> Thank You,
> 
> this information would be useful in the wiki, about sysvol and
> potential issues, I think, since it can really mess up GPO
> application when using some non-default ACL for
> users/groups/computers added after "last" idmap sync. Unless
it's
> there and I didn't find it :)
> 
I think it is there, but not in a direct way. I will have a look and if
it does need clarifying, I will update the page.

Rowland