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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
