[Samba] dc1 stopped replicate after kutil change

[Rowland Penny]

On Thu, 2021-07-08 at 09:34 -0500, John Farmer via samba wrote:
> We are having an issue with replication after a kutil  change was
> made.
> 
> Replication from dc1 to dc2-12 is failing:
> 
> samba-tool drs showrepl
> 
> Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for 
> ncacn_ip_tcp:10.243.0.90[49153,seal,target_hostname=dc1.ad.companynam
> e,abstract_syntax=e3514235-4b06-11d1-ab04-
> 00c04fc2dcd2/0x00000004,localaddress=10.243.0.90] 
> NT_STATUS_LOGON_FAILURE
> ERROR(<class 'samba.drs_utils.drsException'>): DRS connection to 
> dc1.ad.companyname failed - drsException: DRS connection to 
> dc1.ad.companyname failed: (3221225581, 'The attempted logon is 
> invalid. This is either due to a bad username or authentication
> information.')
>    File "/usr/lib64/python3.6/site-packages/samba/netcmd/drs.py", 
> line 55, in drsuapi_connect
>      (ctx.drsuapi, ctx.drsuapi_handle,
> ctx.bind_supported_extensions) 
> = drs_utils.drsuapi_connect(ctx.server, ctx.lp, ctx.creds)
>    File "/usr/lib64/python3.6/site-packages/samba/drs_utils.py",
> line 
> 63, in drsuapi_connect
>      raise drsException("DRS connection to %s failed: %s" % (server,
> e))
> 
> 
> With further debug we found this error:
> 
> Failed to get kerberos credentials: kinit for DC1$@AD.companyname 
> failed (Preauthentication failed)
> 
> Wrong username or password: kinit for DC1$@AD.companyname failed 
> (Preauthentication failed)
> 
> 
> kinit -V -k -t /etc/krb5.keytab DC1$@AD.companyname
> Using default cache: /tmp/krb5cc_0
> Using principal: DC1AD.companyname at AD.companyname
> Using keytab: /etc/krb5.keytab
> kinit: Keytab contains no suitable keys for 
> DC1AD.companyname at AD.companyname while getting initial credentials
> 
> 
> kinit -V -k -t /etc/krb5.keytab
> kinit: Cannot determine realm for host (principal
> host/dc1.ad.companyname@)
> 
> Looks like someone made some changes using adcli, we can't quite 
> figure out what is going on.
> 
> this issue is only on dc1 not on any of the other dc's
> 

If 'dc1' is the DC holding all the FSMO roles, then transfer them to
another DC, seize them if you must. Demote dc1, clean it up and then
rejoin it to the domain, preferably with a new hostname e.g. dc01
When you clean it up, remove adcli, realmd and sssd if they are
installed.

This is probably the easiest way out of your problem.

Rowland