Thanks, your advice was helpful.
By the way, does 'default_realm' reference in /etc/krb5.conf is for finding realm
for users AND hosts?
[libdefaults]
..
default_realm = C.MY.DOMAIN
If authentication is against AD+Krb, is there difference between 'ad' and 'krb5' providers in options:
access_provider =
auth_provider =
chpass_provider =
best,
Longina
-----Original Message-----
From: sssd-users-bounces(a)lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Sumit Bose
Sent: 15. marts 2013 13:54
To: sssd-users(a)lists.fedorahosted.org
Subject: Re: [SSSD-users] override upn
On Fri, Mar 15, 2013 at 12:29:16PM +0100, Longina Przybyszewska wrote:
> Hi,
> This is sssd-1.9.4 Ubuntu 12.10;
> id_provider = ad
> auth_provider = krb5
>
> Users in domain c.my.domain with userPrincipalName=name at student.my.domain, can not login to the computer.
>
> The computer has joined AD in yet another domain 'nat.c.my.domain'
>
> All user information can be retrieved from AD, from that computer, at
> least with commands:
> ldapsearch (as user, after kinit user_name at c.my.domain),
>
> or as root on that computer:
>
> id name at student.my.domain
> id name at c.my.domain
> id name
>
> From krb5_child.log I can see that Kerberos refuses to issue TGT, as
> search is done for non existing realm name at STUDENT.MY.DOMAIN
>
> Apparently, domain part in upn is treated as krb realm.
>
> I have mapped student.my.domain domain to C.MY.DOMAIN realm in
> /etc/krb5.conf [domain_realm] ...
> student.my.domain = C.MY.DOMAIN
> ....
This won't work here, because this entries are used to find a realm for a fully qualified host name.
If the realm STUDENT.MY.DOMAIN is handled by AD you can add a
STUDENT.MY.DOMAIN = {
...
}
section to the [realms] section in /etc/krb5.conf pointing to the AD server.
>
> and
> in sssd.conf I have configured domain pointing to C.MY.DOMAIN realm.
>
> [domain/student.my.domain]
> ....
> krb5_realm = C.MY.DOMAIN
The attribute read from LDAP will always be preferred. As a workaround you can add
ldap_user_principal = some_non_existing_attribute_name
As a result sssd is not able to read the principal from LDAP and will construct one with the user name and the realm given in krb5_realm.
HTH
bye,
Sumit
> ....
>
> Is there any way to configure sssd to fix it?
>
> Longina
>
>
> --