View Issue Details

IDProjectCategoryView StatusLast Update
0017379CentOS-7adclipublic2020-05-30 07:39
Reporterjesper.reenberg Assigned To 
Status newResolutionopen 
Product Version7.8-2003 
Summary0017379: adcli preset-computer fails to set a onetime password, when multiple DC's and sites exist, and the machine is AD joined.
Descriptionwhen 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 InformationThis 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.
TagsNo tags attached.




2020-05-20 14:59

reporter   ~0036968

And Of cause I forgot to include information about the various package versions.



2020-05-20 16:08

reporter   ~0036970

After some more systematic testing, it seems that all other commands works fine when different DC's are used (e.g., reset-computer and delete-computer).
I even just had an `adcli delete-computer` that first contacted site-b-dc02, figured to do a site discovery and discovered sita-a instead, and got sita-a-dc01, but made kerberos connection to site-b-dc01.

But when setting a one time password, that would fail. (the setup has two sites, with two DC's in each).

Issue History

Date Modified Username Field Change
2020-05-20 14:55 jesper.reenberg New Issue
2020-05-20 14:59 jesper.reenberg Note Added: 0036968
2020-05-20 16:08 jesper.reenberg Note Added: 0036970