Hi,
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 accounts.
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,
Marin BERNARD Administrateur systèmes Pupilles de l'Enseignement Public 06 35 boulevard de la Madeleine - 06000 Nice
freeipa-users@lists.fedorahosted.org