On Thu, Nov 28, 2013 at 02:53:54PM -0500, Simo Sorce wrote: > On Thu, 2013-11-28 at 10:11 +0100, Sumit Bose wrote: > > On Thu, Nov 28, 2013 at 08:54:40AM +0000, [email protected] wrote: > > > Hi All, > > > I'm after some help tracking this problem down. I am > > > seeing this from a few different OSes all with the same AD realm: CentOS > > > 6.4, SLES 11SP3 and opensuse 13.1 all of which run sssd 1.9.x and SLES 11 > > > SP2 running sssd 1.5.11. The ldap side of things seems to be working OK > > > as getent passwd is returning what I expect. The kerberos side of things > > > is not, although kinit as a user works: > > > > > > client:/var/log/sssd # kinit user > > > Password for [email protected]: > > > client:/var/log/sssd # > > > > > > It looks like the realm is being truncated somehow so DOM.COMPANY.COM is > > > getting truncated to COMPANY.COM for the kerberos lookups. I see this in > > > the krb5_child.log file: > > > > My wild guess it that the userPrincipalName LDAP attribute in your AD > > contains something like '[email protected]'. If this attribute is > > found SSSD prefers the content over a generated principal (given user > > name + configured realm). To avoid this you can set ldap_user_principal > > in sssd.conf to a non-existing attribute name, e.g. > > > > ldap_user_principal = blablabla > > > > Nevertheless the principal from userPrincipalName should in general work > > as well (at least with recent versions of SSSD). You have to switch on > > enterprise principals and canonicalization and set 'dns_lookup_kdc = > > true' in krb5.conf. > > Doesn't SSSD 1.9 support enterprise principals ? > > Simo.
No, 1.10 and later. Also, this particular user was running even 1.5.x on SLES. _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
