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 -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
