The Samba-Bugzilla – Bug 12771
rodc password sync for members of the "allowed rodc replication group" is not working
Last modified: 2018-10-22 20:55:44 UTC
Tested on garming rodc wip branch
When the user is sync'ed to the rodc, the replpropertymetadata attribute unicodepassword is incremented at the same value as on the RWDC, and it prevents sync'ing of the credentials on the first authentication of the domain members.
So when someone logs in, the event of the need of sync'ing of the password is properly catched and logged, but nothing is sync'ed because replpropertymetadata is already at the same value.
How to reproduce
If we update the password on RWDC, and kinit on the RODC rightaway before replication, then sync'ing of credential is ok
If we let the replication go first, the incremented value in replpropertymetadata is incremented, but no credential is copied
And then we are back at the initial status.
This problem is there both for user account and machine account
how to test
samba-tool user add testuser
samba-tool group addmembers "Allowed RODC Password Replication Group" testuser
samba-tool drs replicate srvrodc srvdc dc=testdom,dc=lan
The event of sync'ing the credential is logged
../source4/dsdb/repl/drepl_secret.c:54: repl secret completed OK for 'CN=testuser,CN=Users,DC=testdom,DC=lan'
But when looking for supplementalcredentials, it is still missing on RODC
As observed, the replication call will be sent out, however no secrets will be replicated. The cause appears to be an invalid construction of the RODC partial attribute set. samba-tool rodc preload constructs the set correctly, however the internal replication server fails to include the secret attributes in the list of those given. The fix should be simple, but I will need to write some additional tests.
This also hints on a slightly different bug, i.e. replpropertymetadata merging from a remote server where the attribute was not included in the partial attribute set. This will need to be resolved for global catalog servers to function correctly.
(In reply to Garming Sam from comment #1)
On further analysis, it appears the issue is actually with incorrect USN filtering of GetNCChanges extended operations. If a standard replication was able to preceed the replication of secrets, the client would pass a higher USN than the password change and therefore the server would not pass back the result.
I've got the patch in a new branch garming-rodc-wip-1 on the Catalyst git server.
Was fixed in 4.7 release.