On 08/01/2023 14:19, Michael Tokarev via samba wrote:> 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.
Most of the time it isn't really a bug, it is trying to do things in a
away that works on Windows but do not work on Samba. Windows has the
concept of allowing users to join machines to the domain (and presumably
demote them), Samba does not do this. Samba only allows machines to be
joined to the domain by Administrator and members of Domain Admins
(provided the correct privileges are granted).
>
> 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?
It actually tells you above, it is a UUID, also known as a GUID.
Samba has bug for this, it seems that when you demote a DC, its dns GUID
record gets left behind, see:
https://bugzilla.samba.org/show_bug.cgi?id=12534
>
> 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:
It is in sam.ldb (do not touch anything in sam.ldb.d), but you will
probaly have to use ldbsearch with '--cross-ncs' to see it.
>
> # 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... :)
It isn't, but it may work if you can fix the UUID dns record, if not, we
will cross that bridge when we come to it ;-)
Rowland