At 11:07 AM 7/8/2021, Rowland Penny via samba wrote:>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
DC1 does hold the FSMO rolls problem is I'm not really sure what to
clean up here.
net ads testjoin
kerberos_kinit_password AD at AD.companyname failed: Client not found in
Kerberos database
kerberos_kinit_password AD at AD.companyname failed: Client not found in
Kerberos database
Join to domain is not valid: The name provided is not a properly
formed account name.
net rpc testjoin
connect_to_domain_password_server: unable to open the domain client
session to machine DC1. Flags[0x00000000] Error was :
NT_STATUS_NO_TRUST_SAM_ACCOUNT.
Join to domain 'AD' is not valid: NT_STATUS_NO_TRUST_SAM_ACCOUNT
kinit -V -k -t /etc/krb5.keytab
kinit: Cannot determine realm for host (principal host/dc1.ad.companyname@)
wbinfo -t
checking the trust secret for domain AD via RPC calls succeeded