Quoting Sumit Bose <sbose(a)redhat.com> on Tue, Dec 13 09:51:
hmm, in theory the attribute should be filled during the join with
values matching the keytab entry. You can try to add the entries
manually. Here at least 'RestrictedKrbHost/phys-adtest' and
'RestrictedKrbHost/phys-adtest.tou.t3.ucdavis.edu' should be added.
You can check if it is working or not without SSSD by calling:
kinit aduser(a)T3.UCDAVIS.EDU
This works before and after the change to servicePrincipalName in AD.
klist shows a good service principal.
kvno RestrictedKrbHost/phys-adtest(a)TOU.T3.UCDAVIS.EDU
Before I updated AD to add the entries to servicePrincipalName this
failed with:
root@phys-adtest:~# kvno RestrictedKrbHost/phys-adtest(a)TOU.T3.UCDAVIS.EDU
kvno: Server not found in Kerberos database while getting credentials for
RestrictedKrbHost/phys-adtest(a)TOU.T3.UCDAVIS.EDU
After I updated servicePrincipalName this succeeds(!) with:
root@phys-adtest:~# kvno RestrictedKrbHost/phys-adtest(a)TOU.T3.UCDAVIS.EDU
RestrictedKrbHost/phys-adtest(a)TOU.T3.UCDAVIS.EDU: kvno = 3
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?
Thanks everyone for the help!
--
Omen Wild
Systems Administrator
Metro Cluster