| Description | when running `adcli preset-computer -D mycorp.tld -U ad-join-user -O OU=… --one-time-password pass123 --verbose hostname`, then the command will sometime fail to set the onetime password: "! Cannot set computer password: Authentication error"
This however only fails when run on a host that is already AD joined.
From the output of KRB5_TRACE and ´adcli --verbose´, I found that the issue happens when `adcli` gets one DC from DNS, I assume for for LDAP stuff (seen by the verbose output from adcli: "* Discovering domain controllers: _ldap._tcp.mycorp.tld", "* Sending NetLogon ping to domain controller: dc02.mycorp.tld"), and _another_ DC is used for Kerberos (seen by KRB5_TRACE "Initiating TCP connection to stream <ip of DC01>:88"). I don't know enough about the details, but for some reason it is able to create the compute object, just not the OTP.
Forcing a DC with the `--domain-controller` option, doesn't affect the DC that KRB5_TRACE shows, only the DC shown by the `adcli` verbose output.
When this is run on a node that is _not_ joined to the AD, then the KRB5_TRACE output shows that it is connecting to the same DC that the `adcli` verbose output is showing.
stracing the `adcli` command, showed that it (I assume that it is libkrb5?) reads the /var/lib/sss/pubconf/kdcinfo.MYCORP.TLD file, which SSSD fills with information about DC's.
It seems consistent that the DC used in the KRB5_TRACE output is the first entry in this file, if it exists (which it only does when the node is AD joined)
I remember seeing an old bug report for `adcli`, something about multiple DC's, and the solution was to make `adcli` write its own krb5.conf file, in order to force a DC with the `--domain-controller`.
However it kind of seems that
1. `adcli` should ignore the kdcinfo, when a DC is enforced. And
2. if no DC is enforced, then either the DC gotten from DNS or the first line from the kdcinfo file should be used for everything, not a mix.
I'm not quite sure if this is an `adcli` or `libkrb5` issue. |
|---|
| Additional Information | This issue was originally discovered, when trying to use the realm_ad plugin in Foreman, where a DC was defined in the yaml config. Sometimes it would just and then work, and other times it would fail for longer periods of time.
One solution that seems to work is to enforce the same DC in sssd.conf as in the Foreman realm_ad config. This makes sure that the first line in the kdcinfo file matches the pinned dc in foreman.
However this reduces the high availability of AD, by pinning to one specific DC. It should just work from DNS and or from site information from SSSD.
I have set major severity due to this.
I'm sadly not able to share any logs. But I have tried to add the relevant parts from my debugging, and I can supply with info as needed. |
|---|
