> 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?
Does 'ipa trust-find' show 'pep06.fr' in the 'UPN suffixes:' list
?
As Alexander said recent version of SSSD should detect the usage of
alternative UPN suffixes based on the presence of the 'UPN suffixes' in
the trusted domain object. For older version you can set
'krb5_use_enterprise_principal = True' in the [domain/...] section of
sssd.conf on the IPA clients.
Thanks a lot!
Adding 'krb5_use_enterprise_principal = True' to sssd.conf just made it work!
PS: I'm sorry for the unintelligible title of this thread.