samba - Jan 2023 - Issues demoting a samba DC.

On 08/01/2023 11:04, Michael Tokarev via samba wrote:
> Hello!
> 
> I'm trying to remove a DC from our samba domain (samba 4.17.4).
> It was the primary controller (with FSMO roles), - I successfully
> transferred the roles to another DC.? Now it's time to demote:
> 
> ai# samba-tool domain demote -U mjt-adm
> Using svdcp.tls.msk.ru as partner server for the demotion
> Password for [TLS\mjt-adm]:
> Deactivating inbound replication
> Asking partner server svdcp.tls.msk.ru to synchronize from us
> Changing userControl and container
> Error while demoting, re-enabling inbound replication
> ERROR(ldb): Error while renaming CN=AI,OU=Domain 
> Controllers,DC=tls,DC=msk,DC=ru to 
> CN=AI,CN=Computers,DC=tls,DC=msk,DC=ru - LDAP error 50 
> LDAP_INSUFFICIENT_ACCESS_RIGHTS -? <acl:access_denied renaming 
> CN=AI,OU=Domain Controllers,DC=tls,DC=msk,DC=ru> <>
> 
> mjt-adm is a user with admin rights (domain admins group) in the dc.
> It is interesting I can not use Administrator account for this,
> it asks for the password twice, and refuses to work saying
> login is incorrect, even if the same password works for
> smbclient.
> 
> Now, after the first attempt to demote, some things doesn't work
> right, eg:
> 
> ai# samba-tool drs showrepl
> ERROR(runtime): DsReplicaGetInfo of type 0 failed - (8453, 
> 'WERR_DS_DRA_ACCESS_DENIED')
> 
> (it definitely worked at least before the FSMO roles transfer).
> 
> Should I force-remove it from another DC?
> 
> Thanks,
> 
> /mjt
> 
If you get any errors whilst trying to demote a DC, then it is probably 
quicker to forcibly demote the DC on another DC, why waste time trying 
to fix something you are trying to get rid of ?

Just as a note, I never have problems like this, but I always use 
Administrator, your problem was possibly a privilege problem that was 
reported as a permissions problem.

Rowland

08.01.2023 14:21, Rowland Penny via samba wrote:
..
>> ai# samba-tool domain demote -U mjt-adm
..
>> ERROR(ldb): Error while renaming CN=AI,OU=Domain
Controllers,DC=tls,DC=msk,DC=ru to CN=AI,CN=Computers,DC=tls,DC=msk,DC=ru - LDAP
error 50
>> LDAP_INSUFFICIENT_ACCESS_RIGHTS -? <acl:access_denied renaming
CN=AI,OU=Domain Controllers,DC=tls,DC=msk,DC=ru> <>
..
> If you get any errors whilst trying to demote a DC, then it is probably
quicker to forcibly demote the DC on another DC, why waste time trying to fix
> something you are trying to get rid of ?
The problem with this approach is that we don't know what's happening,
and thus
unable to fix the bugs.

I removed this DC the "use the force" way, from another DC.
Turned it off for sure too, - so it wont get contacted by a chance.
Especially cleaned up all DNS caches from the old names as well.

But now I've a lot of messages on another DC's log.samba (the one
which now has FSMO roles):

[2023/01/08 17:10:55.689675,  0]
../../source4/librpc/rpc/dcerpc_util.c:681(dcerpc_pipe_auth_recv)
   Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for 
ncacn_ip_tcp:192.168.19.6[49153,seal,krb5,target_hostname=4b38bf02-0354-44f7-b1b2-4bc8bd73784a._msdcs.tls.msk.ru,target_principal=GC/svdcp.tls.msk.ru/tls.msk.ru,abstract_syntax=e3514235-4b06-11d1-ab04-00c04fc2dcd2/0x00000004,localaddress=192.168.177.8]
NT_STATUS_NO_LOGON_SERVERS

What is e3514235-4b06-11d1-ab04-00c04fc2dcd2 where it tries to bind to?

4b38bf02-0354-44f7-b1b2-4bc8bd73784a is the other DC's alias (svdcp vs
svdcm):

# dnsget 4b38bf02-0354-44f7-b1b2-4bc8bd73784a._msdcs.tls.msk.ru
4b38bf02-0354-44f7-b1b2-4bc8bd73784a._msdcs.tls.msk.ru. CNAME svdcp.tls.msk.ru.
svdcp.tls.msk.ru. A 192.168.19.6

I haven't found the string e3514235-4b06-11d1-ab04-00c04fc2dcd2 anywhere in
/var/lib/samba/ or similar dirs, the only single mention of it is in
private/spn_update_list:

# These are not supported yet:
# NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/${HOSTNAME}
# Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/${HOSTNAME}

(yes, commented out).

What it is doing here?  It *looks* like this is being logged when the this DC
(msdcm) is trying to replicate to msdcp, - but that one reports successful
replication, while this one (svdcm) shows errors in replication:

==== INBOUND NEIGHBORS ===DC=tls,DC=msk,DC=ru
	Pereslavl-Office\SVDCP via RPC
		DSA object GUID: 4b38bf02-0354-44f7-b1b2-4bc8bd73784a
		Last attempt @ Sun Jan  8 17:15:55 2023 MSK failed, result 1311
(WERR_NO_LOGON_SERVERS)
		12 consecutive failure(s).
		Last success @ Sun Jan  8 16:22:13 2023 MSK

I'm not sure this is how things are supposed to be... :)

Thanks!

/mjt