We're using FreeIPA 4.5.0 on CentOS 7.4.

We've set up a two-way trust between our 2 FreeIPA servers and our AD domain 
(forest an domain levels both on 2012 R2). So far, everything works as 
expected, and we're able to perform SSO to both FreeIPA instances with AD 

In our AD domain, the UPN suffix of most accounts is different from the DNS 
name of the domain, thus also from the its Kerberos realm. We use a custom UPN 
suffix (@pep06.fr) to match user names to email addresses. Such configuration 
is pretty common in AD environments.

After I set up the AD trust, I added our custom UPN (@pep06.fr) to the list of 
alternate UPN suffices in the Trusts section of the FreeIPA Web UI. I thought 
this was enough to make FreeIPA aware of our custom UPN suffix, and to have all 
Kerberos requests for @pep06.fr directed to the KDC of the AD domain.

I was wrong: while Kerberos delegation for SSO is working fine, we're unable to 
log in with explicit AD credentials. System logs report that sssd fails to find 
a KDC for the 'PEP06.FR' Kerberos realm which, indeed, does not exist, as it is 
constructed from our alternate UPN suffix:

[sssd[krb5_child[3810]]][3810]: Cannot find KDC for realm "PEP06.FR"

This limitation also prevents us from using IPA sudo rules involving AD users: 
since sssd is unable to derive the name of the real Kerberos realm, it fails to 
find a KDC to query, and rule evaluations always fail. This happens no matter 
if sudo is run from a SSO-authenticated session.

Is this a known limitation of FreeIPA or a configuration issue on my side? If 
this is a limitation, should I expect it to be adressed any soon?

Many thanks,

Administrateur systèmes
Pupilles de l'Enseignement Public 06
35 boulevard de la Madeleine - 06000 Nice
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to