[Samba] Issues demoting a samba DC.

[Michael Tokarev]

08.01.2023 18:19, Rowland Penny via samba wrote:
..
>> 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 don't even know how it works on windows, I always managed stuff from linux.
And I never tried any advanced operations by unprivileged users, always using
an administrative account (member of Domain Admins group).  (Sometimes it is
not sufficient though, I've hit a situation where I had to grant an additional
privilege to this user the other day, something in context of adding a printer).

>> 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

Hmm.  This is actually fun.  In my DNS all the records associated with this
host, together with this very gc._msdcs record, has been removed automatically,
- I just dropped this DC's dns_update_cache file from the common DNS namespace
and regenerated it the usual way. Yes, this record is still in the samba domain
database somewhere - I just deleted it with samba-tool dns delete as stated in
this bug.  But it was not actually used in my case, because it has been in the
deleted DC "dns_update_cache" file only, and this is where my dns configuration
comes from.  So in my case it is just a small cleanup of an old record, which
does not do anything actually.

BTW, what's the way to dump whole DNS zone from a samba DC?

>> 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.

any string can be searched in a binary file with plain old grep, it is
easy to use for a quick check.  If it is in sam.ldb[.d]. more appropriate
tools can be used, but `grep -ir foo /var/lib/samba/' does the quick-n-dirty
search. I just used the wrong string, -- cut-n-pasted the different line by
mistake.  I found it later when realized my mistake. And found it as the SPN
for this DC.


>> 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 ;-)

FWIW. This bug (samba not removing old GC._msdcs record) should actually not
prevent it from working and being unable to bind to its own uuid). Because
besides the A record of the removed DC, there are A records for all other
DCs in there too. So this is definitely a *set*, not a single A.  So it
should be able to contact other hosts for this just fine.

And nope, after removing this stale A gc._msdcs record from samba DNS, it
still does not work and still logs the same error message, apparenlty when
trying to log in to the other DC for replication:

[2023/01/08 18:50:43.390974,  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_princi

I'll try to strace it to find out what's going on.

Unfortunately I still don't know what does it *mean*, what exactly it tries
to do when "binding to uuid"?

Thanks,

/mjt