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
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.
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
On Tue, Jan 09, 2018 at 05:16:03PM +0000, Marin BERNARD via FreeIPA-users wrote:
Hi,
The client systems are the FreeIPA servers! Both are running on up-to-date CentOS 7.4 with sssd 1.15.2.
There is https://pagure.io/SSSD/sssd/issue/3431 which is fixed upstream in 1.15.3 which might prevent the automatic enabling of enterprise principals on the clients if the domain objects are already stored in the cache of SSSD.
bye, Sumit
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
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi,
The client systems are the FreeIPA servers! Both are running on up-to-
date CentOS 7.4 with sssd 1.15.2.
There is https://pagure.io/SSSD/sssd/issue/3431 which is fixed upstream in 1.15.3 which might prevent the automatic enabling of enterprise principals on the clients if the domain objects are already stored in the cache of SSSD.
bye, Sumit
Yes, but I tried to flush the sssd cache several times before writing to the list. I used sssd_cache -E though ; I did not try to remove the whole /var/db/sssd directory. As far as I understand it, automatic enabling of enterprise principal is handled by sssd providers like AD or IPA providers. Does the FreeIPA provider shipped with sssd 1.15 implement this feature?
On Wed, Jan 10, 2018 at 09:22:05AM +0000, Marin BERNARD wrote:
Hi,
The client systems are the FreeIPA servers! Both are running on up-to-
date CentOS 7.4 with sssd 1.15.2.
There is https://pagure.io/SSSD/sssd/issue/3431 which is fixed upstream in 1.15.3 which might prevent the automatic enabling of enterprise principals on the clients if the domain objects are already stored in the cache of SSSD.
bye, Sumit
Yes, but I tried to flush the sssd cache several times before writing to the list. I used sssd_cache -E though ; I did not try to remove the whole /var/db/sssd directory.
Unfortunately you have to remove the cache with rm in this case, sss_cache -E just invalidates the entries by resetting a timestamp.
As far as I understand it, automatic enabling of enterprise principal is handled by sssd providers like AD or IPA providers. Does the FreeIPA provider shipped with sssd 1.15 implement this feature?
Yes, but with the isssue mentioned above.
HTH
bye, Sumit
On Tue, Jan 09, 2018 at 03:26:57PM +0000, 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?
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.
HTH
bye, Sumit
Many thanks,
Marin BERNARD 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-leave@lists.fedorahosted.org
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.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Marin BERNARD -
Sumit Bose