On Fri, Nov 20, 2020 at 10:03:38AM -0600, Spike White wrote:

All,

This is just an annoyance that occurs periodically and we can't figure out why. We know how to remediate once seen.

Every now and then, on a new build the sssd join/configure will fail. For example, a server provisioner today built 10 boxes and 2 failed. Upon closer inspection, we see that AD domain has machine accounts with funky names.

For example, these three VMs were built. ausflinfsfdcap01 - 03. 01 and 02 built fine, sssd installed, adcli join succeeded, life was good. We find the usual machine accounts in the usual OU. CN=ausflinfsfdcap01, CN=ausflinfsfdcap02

On 03, the adcli join failed. In AD, we find the following funky machine accounts (in the usual OU):

CN=AUSFLINFSFDCAP0\0ACNF:5020ab3d-243a-4ef1-827b-d421c0dcf3d0

Hi,

this is the way AD indicates replication conflicts. The reason is that your hostname is too long. The computer name stored in the sAMAccountName attribute is limited to 16 characters while the last will be always a '$' for computer accounts. The reason for this limitation is the NetBIOS history of various protocols used in the in Windows environment.

Your name 'ausflinfsfdcap01', 'ausflinfsfdcap02' have already 16 characters and adcli will replace the last one with a '$' to meet the limitation. As a result the value written to the sAMAccountName attribute will in both cases be 'ausflinfsfdcap0$' and since there is a unique constraint of this attribute this is not allowed.

In your case 'ausflinfsfdcap01' and 'ausflinfsfdcap02' where created on 2 different AD DCs before the first one was able to replicate the new data to the second. At the time the data was replicated the conflict was detected and the object with the "funky" name was created so that the data is not lost but the object would not be used for normal operations.

If you would try the same operation with always the same AD DC ('-S' option of adcli or the fully-qualified name of the DC instead of the domain name with 'realm join') you would get an error when trying to join the second computer because now the DC can immediately detect the conflict.

To get around this you have to use a different "computer name" which will be written to the sAMAccountName attribute, e.g. 'aflinfsfdcap01', 'aflinfsfdcap02', ... which must be not longer than 15 characters. You can specify the name with the '--computer-name' option with either realm or adcli.

HTH

bye, Sumit

CN=AUSFLINFSFDCAP0

This first machine account name is fairly typical when this failure occurs. This second I've never seen this particular type of funky name server. I.e., a truncated hostname.

When I try adcli join again right now, it will fail (because of these funky named machine accounts).

I delete these funky machine accounts via ldapdelete. Example:

ldapdelete -H ldap://ausdcamer.example.com 'CN=AUSFLINFSFDCAP0\0ACNF:5020ab3d-243a-4ef1-827b-d421c0dcf3d0,OU=Servers,OU=UNIX,DC=example,DC=com'

then I delete /etc/krb5.keytab file (if it exists) and re-run the adcli join -- which then succeeds.

So like I say -- we know how to work around this failure mode. It's just a nuisance at this point. Usually occurs << 10% of builds.

But does anyone know why these funky-named machine accounts arise? And how to avoid this?

Spike

---

sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...