On Tue, Dec 13, 2016 at 05:28:42PM -0800, Omen Wild wrote:
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.
I guess making sure that the hostname command returns the
fully-qualified domain name of the host would help as well. If there are
other application running on the host expecting the short name maybe the
fqdn can be set just during the join?
bye,
Sumit
Thank you everyone for your help!
--
Omen Wild
Systems Administrator
Metro Cluster
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org