sssd experts,
This is an adcli join question. Very infrequently, it appears that our AD
joins create CNF records in AD.
All about Active Directory CNF object finding validation and removing -
Microsoft Q&A
<https://learn.microsoft.com/en-us/answers/questions/101494/all-about-active…>
In all our reading, we read about one possible explanation for CNF
records. Several “AD join” clients (like adcli join) if there’s a network
interruption or other sudden DC inaccessibility, it’ll try a second DC
before failing. In that case, if the initial join on the first DC is far
enough along, there’ll be a machine account created on the first DC. And
(of course) there’ll be a second machine account created on the second DC –
from the successful AD join. Then when replication occurs, the two DCs
will realize that each has a different machine account for the same
machine. So one will be marked “<hostname><space>CNF-guid=xxx…”.
We showed our AD team our research and they agreed with us. They said;
This lines up with what we typically see on the AD side.
From the AD side, this looks less like a Linux specific issue and more like
a *timing* issue during the *join/rejoin/reset/delete* activity.
If a computer join partially succeeds and the machine is retried too
quickly before AD fully converges, duplicate computer objects can be created
and one may end up as a CNF conflict object.
The key point here is *timing*.
If a system is un-joined or a join partially fails and it’s retried i
*mmediately*, AD may not have fully settled yet which is when these
duplicates get created.
Our general guidance (same as Windows systems) is to wait before retrying.
We often quote *30 minutes* as a safe window before rejoining a system with
the *same hostname* to allow AD replication/convergence to complete.
Our former AD integration product (a commercial product) didn't create CNF
objects. Presumably because if the AD machine account creation partially
succeeded and then there was a hiccup, it didn't retry on another AD DC.
Instead it just returned failure and the server build would fail.
How can we convince adcli join to do this behavior, instead of re-trying on
a second DC when a partial join + hiccup occurs?
Again, not a huge problem -- just a slight annoyance. Mainly when a
machine drops off the network and we retry to re-join, it fails. Because
of the CNF record. We have to delete the CNF record then adcli join works
fine.
FYI -- here's what we do when we do an adcli join:
first we kinit as the service principal authorized to create machine
accounts in our OU.
Then we run ..
FQDN=$(hostname --fqdn | tr [A-Z] [a-z])
adcli join --domain="$JOINDOMAIN" --login-user=${ACCOUNTNAME}
--login-ccache="/tmp/krb5cc_$SVCNAME" --service-name='host'
--service-name='RestrictedKrbHost' --os-name="$OS_NAME"
--os-version="$OS_VERSION_FULL " --domain-ou="$OU_CONTAINER" --show-details
--host-keytab=/etc/krb5.keytab --host-fqdn=$FQDN
--user-principal="host/$FQDN@$JOINDOMAIN" 2>&1 | tee /tmp/adcli_join.out
Thanks,
Spike White
Linux Engineer
