Quoting Omen Wild <omen(a)ucdavis.edu> on Tue, Dec 13 12:28:
So, looking over the verbose output to how we joined the domain (realm
-v join
tou.t3.ucdavis.edu -U metro-0omentest(a)TOU.T3.UCDAVIS.EDU) I
see an error when it tried to set servicePrincipalName (full output attached):
! Couldn't set service principals on computer account
CN=phys-adtest,OU=METRO-OU-AdminPCS,OU=METRO-OU-Computers,OU=METRO,OU=DEPARTMENTS,DC=tou,DC=T3,DC=UCDAVIS,DC=EDU:
00002083: AtrErr: DSID-03151785, #1:
0: 00002083: DSID-03151785, problem 1006 (ATT_OR_VALUE_EXISTS), data 0, Att 90303
(servicePrincipalName)
It seems likely this is because we have to pre-stage the computer object
in AD in order to place it in a folder/location where we have write
privileges. Does anyone know of a workaround that doesn't involve us
manually editing servicePrincipalName after the fact?
I found a user with a similar problem
<
https://bugs.freedesktop.org/show_bug.cgi?id=86107> and the workaround
described there (adcli delete-computer , adcli join ... --host-fqdn=$(facter fqdn)) works!
So it looks like the issue is not sssd at this point, but how adcli does
the join. If anyone has any more tips I would love to hear them.
Thank you everyone for your help!
--
Omen Wild
Systems Administrator
Metro Cluster