[Samba] SID ... conflicts with our current RID set in ...

[Andrew Bartlett]

On Tue, 2021-06-01 at 17:31 +0100, Rowland penny via samba wrote:
> On 01/06/2021 17:07, Marco Gaiarin via samba wrote:
> > Doing some health check on my samba AD domain, i've got this:
> > 
> >   root at vdcpp1:~# samba-tool dbcheck --cross-ncs
> >   Checking 5173 objects
> >   [... some warnings...]
> >   SID S-1-5-21-160080369-3601385002-3131615632-2100 for
> > CN=ENRICO,OU=Computers,OU=SanVito,OU=FVG,DC=ad,DC=fvg,DC=lnf,DC=it
> > conflicts with our current RID set in CN=RID
> > Set,CN=VDCPP1,OU=Domain Controllers,DC=ad,DC=fvg,DC=lnf,DC=it
> >   Please use --fix to fix these errors
> >   Checked 5173 objects (1 errors)
> > 
> > Two question:
> > 
> > 1) why this error is DC specific and not domain-wide?
> 
> Because every DC has (or should have) its own RID pool
> 
> >   DC RID is not
> >   written in AD but only in local DB?
> 
> RID's are in AD
> 
> >   If i run 'samba-tool dbcheck --cross-ncs' in another DC, there's
> > no error...
> 
> Different RID pool
> 
> > 2) it is safe to use '--fix'? Or, because 'ENRICO' is a simple
> > windows
> >   pc, it is safer to simply delete 'ENRICO' computer account and
> > rejoin
> >   it?
> 
> Try '--fix' first, you can always fall back to leaving the domain
> and 
> rejoining if it doesn't work.

Thanks Rowland, this explains things very well. 

As background, which should probably go into the wiki some day, with
the above:

The 'fix' will advance the local RID allocation state in ridNextRid
attribute until the conflict is resolved.

However this should not ever have happened, if there was only ever one
RID master the pools should never have overlapped and it should have
been impossible for this to happen.  

Stealing RID master roles would be one way to get into this muddle, as
would an improper domain restore.  If neither of these have happened,
some investigation might be worthwhile.

We don't currently have a way to detect if multiple DCs think they have
the same RID pool, which might be the root cause here.  

Thankfully Samba objects pretty fast when that conflicting SID is
created, but by this stage it is frustrating, as we stop being able to
add users.

If that is confirmed to be the case, the only end-user fix would be a
demote and re-join, it would be nice if we could instead have a dbcheck
rule that compared rIDPreviousAllocationPool on our DC with the
rIDAllocationPool of every other DC.  Still not actually enough to
prove this won't happen, but all we can do given
that rIDPreviousAllocationPool is FLAG_ATTR_NOT_REPLICATED.

Andrew Bartlett


> 
> > 
> > Thanks.
> > 
> 
> 
-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions