Hi,

 

The client systems are the FreeIPA servers! Both are running on up-to-date CentOS 7.4 with sssd 1.15.2.

 

Thanks,

 

Marin

 


De : Alexander Bokovoy <abokovoy@redhat.com>
Envoyé : Tuesday, January 9, 2018 4:44:36 PM
À : FreeIPA users list
Cc : Marin BERNARD
Objet : Re: [Freeipa-users] sudo fails as the Kerberos realm from an alternate UPN suffix
 
On ti, 09 tammi 2018, Marin BERNARD via FreeIPA-users wrote:
>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?
Without looking into debug SSSD logs it is hard to say where your
problem lies.

You said nothing about your client systems where this happens. What
distribution and what SSSD version they are using?

Support for enterprise principals were added to SSSD some time ago but
coordination with IPA support for UPN suffixes was added in (or backported
to) 1.14.1.

--
/ Alexander Bokovoy