The Samba-Bugzilla – Bug 12394
RID allocation from moved RID master fails with missing mandatory attribute
Last modified: 2017-06-29 06:46:05 UTC
rIDNextRid and rIDPreviousAllocationPool are non-replicated, are normally unset and yet required attributes. On the RID master, they are set for the RID sets for the other DCs, but this does not hold once you move the role.
Fails with a message like:
objectclass_attrs: at least one mandatory attribute ('rIDNextRID') on entry 'CN=RID Set,xxxxxx' wasn't specified!
For users hurting with this, in the meantime before you can get a patched Samba:
Set rIDNextRID and rIDPreviousAllocationPool to 0
on any 'CN=RID Set' object on the RID Master (as these values are not
replicated) for any DC where these values are not yet set.
NEVER change a valid value to 0, just add the attribute on each CN=RID
You can see that this is reasonable because for servers that got their
RID set from the current RID master, these should already have zeros
for this attribute.
That should fix things for you, until we can get you the C patch to
remove the incorrect schema restriction.
This has happened because as the RID Master FSMO role moves around the 0 values don't move with it (they are not replicated). Thankfully tests in the patch will ensure this is not repeated.
(In reply to Clive Ferreira from comment #0)
At what stage does this error happen?
Does the replication of the role transfer already fail?
Or the allocation request of a new range against the new role owner?
(In reply to Stefan Metzmacher from comment #2)
The error does not occur until you are requesting a new range against the role owner. However, technically the CN=RID Set object is in an invalid state prior to the role transfer. The only reason we do not notice is because we never modify the RID sets for DCs (which are not itself) if we are not the RID master, where the values are set.
Fixed in master with 79dd22aacb4c12bd008d9ad354ec5ec088560748
Patches for the backport to 4.4. and 4.5 to be attached shortly.
(In reply to Andrew Bartlett from comment #4)
The fix is in Samba 4.5.2 as 2be252946f65c9c1edc5676aae90a4b9e4a7d390 from 79dd22aacb4c12bd008d9ad354ec5ec088560748 in master.
We need a backport just the fix to 4.4, backporting the test will be to cumbersome.
Samba 4.4 is not getting maintenance fixes any more (just security) so closing this bug as fixed.