On 04/10/2013 03:32 PM, Sumit Bose wrote:
I guess it is related to the content of the userPrincipalName in AD. The
@HP.COM will be listed here. SSSD prefers the content of this attribute
to generating the Kerberos principal based on the user and the realm
name. But with AD it is a bit more difficult because the names listed in
the attribute can have suffixes which are different from the Kerberos
realm, making it difficult for the Linux client to find the right KDC.
As a short cut you can just set
ldap_user_principal = SomeAttributeNameThatDoesNotExists
in the domain section of sssd.conf. Then sssd cannot find a Kerberos
principal on the server and build one based on the name and the realm.
To be on the safe side you can add krb5_realm =
AMERICAS.CPQCORP.NET to
sssd.conf (if you not already have it).
The correct solution is
https://fedorahosted.org/sssd/ticket/1842 where
I'm current running some final tests before I send the patch to
sssd-devel. So hopefully in the next sssd release you do not need the
fix mentioned above.
HTH
bye,
Sumit
That did the trick, Sumit - thanks a million. For the first time, I have
sssd logins working directly.
Very nice, thanks again.
/Harry