Re: [Freeipa-devel] krb5.conf on IPA server and SSSD setup
On Tue, Jan 29, 2013 at 10:50:02PM +0200, Alexander Bokovoy wrote: Hi! I've been chasing few bugs in FreeIPA's trusted domains support and found out some grave bugs in both SSSD and FreeIPA. On FreeIPA server side we configure krb5.conf using following settings: - includedir /var/lib/sss/pubconf/krb5.include.d [libdefaults] ... default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true ... [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.com -- Then SSSD generates files which contain domain_realm mapping for trusted domains in /var/lib/sss/pubconf/krb5.include.d and libkrb5 will read them as part of the krb5.conf sourcing. Few problems here: 1. KDC needs to know this mapping information in order to issue referrals to the clients. There is heuristic in libkrb5 that uses domain_realm mapping first and default_realm value if mapping didn't catch the principal which was not found in the database. 2. krb5.conf is parsed by applications usually only on startup. KDC is not an exception, so any changes to krb5.conf would require to restart KDC if we want them to be noticed. 3. Adding new trust implies therefore KDC restart. It also implies that SSSD should have updated the mapping which is not neccessary true time-wise. As result, operations like mapping trusted domain users via external groups in IPA might fail as IPA code running on IPA server needs to contact LDAP service at trusted domain's Global Catalog using SASL GSSAPI authentication. When ticket is obtained, we don't specify explicitly the realm of the service principal, it is constructed by underlying libldap/libsasl code. If explicit domain_realm mapping is in place on client side (and here client is the server as request is issued from IPA httpd code), trusted domain's Global Catalog host will be automatically mapped to trusted domain realm. Otherwise KDC will hint the client with referral to proper KDC for trusted domain realm. This is the step that might fail if trusted domain is sub-domain of IPA domain, for example, ad.example.com. In this case our explicit mapping for example.com will prevail and requests will always be sent for principal in EXAMPLE.COM realm. More to that, since client and KDC are the same host, KDC will use domain_realm mapping as well and hint client with referral to itself (since .example.com = EXAMPLE.COM). Obtaining ticket will fail again. So, I was trying to solve this issue and I've got to following setup with Nalin's help: 1. Define following settings in [libdefaults] of krb5.conf default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true realm_try_domains = 0 realm_try_domains = 0 forces libkrb5 to fallback discovery of realm to domain of the host via DNS if there is no other explicit mapping. 2. Remove any explicit domain_realm mapping for our default realm since it will be implicitly generated from default_realm value by the fallback code anyway. With these changes both KDC and libkrb5 will be able to properly serve out both own domain and trusted domain requests. At some point SSSD will kick in with its explicit mapping for trusted domain realm. Still, KDC will not be able to see this mapping until restart but in Krb5 1.12 we are getting new pluggable interface that will allow to refresh KDC configuration. If set up an environment like discussed above, and FreeIPA server and an AD server where the AD DNS domain is a sub-domain of the the IPA DNS domain. Then tried to run ldapsearch, smbclient, nsupdate and kvno accessing the AD server. Here are my findings: ldapsearch: - does not work in the default configuration - works even if no domain_realm mapping is available, but in this case the ipa client utility does not work anymore - works with full domain_realm, i.e. IPA and AD DNS domains are listed - setting realm_try_domains or not does not make any difference smbclient: - does not work in the default configuration - does not work with missing domain_realm mapping - works with full domain_realm - setting realm_try_domains or not does not make any difference nsupdate: - does not work in any configuration if the realm option is missing in the input file - works in all configurations if the realm option is given - setting realm_try_domains or not does not make any difference kvno: - I used 'kvno -S server ad-server.ad.domain' - does not work in the default configuration - works even if no domain_realm mapping is available - works with full domain_realm - setting realm_try_domains or not does not make any difference In the case without a domain_realm mapping ldapsearch and kvno first try to get a ticket with the default_realm and the KDC returns UNKNOWN_SERVER. As a second step they try to get a cross realm ticket where the
Re: [Freeipa-devel] krb5.conf on IPA server and SSSD setup
On Fri, 01 Feb 2013, Sumit Bose wrote: If set up an environment like discussed above, and FreeIPA server and an AD server where the AD DNS domain is a sub-domain of the the IPA DNS domain. Then tried to run ldapsearch, smbclient, nsupdate and kvno accessing the AD server. Here are my findings: ldapsearch: - does not work in the default configuration - works even if no domain_realm mapping is available, but in this case the ipa client utility does not work anymore - works with full domain_realm, i.e. IPA and AD DNS domains are listed - setting realm_try_domains or not does not make any difference smbclient: - does not work in the default configuration - does not work with missing domain_realm mapping - works with full domain_realm - setting realm_try_domains or not does not make any difference nsupdate: - does not work in any configuration if the realm option is missing in the input file - works in all configurations if the realm option is given - setting realm_try_domains or not does not make any difference kvno: - I used 'kvno -S server ad-server.ad.domain' - does not work in the default configuration - works even if no domain_realm mapping is available - works with full domain_realm - setting realm_try_domains or not does not make any difference I'm finding hard to parse notes above (what is 'default configuration'?). In the case without a domain_realm mapping ldapsearch and kvno first try to get a ticket with the default_realm and the KDC returns UNKNOWN_SERVER. As a second step they try to get a cross realm ticket where the realm is the uppercase version of the destinations DNS domain. Yes, this is expected behavior and this is what we want to see. Please note that if you put own realm to domain_realm mapping, KDC will use it to build referral and force you to connect to itself rather than the destination KDC. It happens because .example.com takes precedence over .ad.example.com if the latter is not specified. So KDC sees that host does not exist in its own realm but finds mapping in domain_realm section which covers the host foo.ad.example.com (.example.com) and returns that as a referral which then fails because the same KDC is queried on second attempt. With full domain_realm mapping all clients except nsupdate directly ask for the cross realm ticket. For me it looks like realm_try_domains is not needed but domain_realm mappings are. Please note that once you start adding trusted domains, includedir entry in krb5.conf will bring the mappings to them automatically. Since all applications you tested are short-lived, they will read krb5.conf on their startup and those mappings will always be actual for them. For KDC, however, problem is in actualizing domain_realm mapping, as KDC is a long-living process and does not re-read krb5.conf periodically or on any changes. In our case krb5.conf is not changed but some files in includdir are so it is even more complex. I there anything else which I should test? I think we need to find solution that does not force KDC to issue referral to its own domain. Ideally, if we could use separate krb5.conf for KDC where domain_realm mapping for own domain does not exist, we could have solved referral issue. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] krb5.conf on IPA server and SSSD setup
Hi! I've been chasing few bugs in FreeIPA's trusted domains support and found out some grave bugs in both SSSD and FreeIPA. On FreeIPA server side we configure krb5.conf using following settings: - includedir /var/lib/sss/pubconf/krb5.include.d [libdefaults] ... default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true ... [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.com -- Then SSSD generates files which contain domain_realm mapping for trusted domains in /var/lib/sss/pubconf/krb5.include.d and libkrb5 will read them as part of the krb5.conf sourcing. Few problems here: 1. KDC needs to know this mapping information in order to issue referrals to the clients. There is heuristic in libkrb5 that uses domain_realm mapping first and default_realm value if mapping didn't catch the principal which was not found in the database. 2. krb5.conf is parsed by applications usually only on startup. KDC is not an exception, so any changes to krb5.conf would require to restart KDC if we want them to be noticed. 3. Adding new trust implies therefore KDC restart. It also implies that SSSD should have updated the mapping which is not neccessary true time-wise. As result, operations like mapping trusted domain users via external groups in IPA might fail as IPA code running on IPA server needs to contact LDAP service at trusted domain's Global Catalog using SASL GSSAPI authentication. When ticket is obtained, we don't specify explicitly the realm of the service principal, it is constructed by underlying libldap/libsasl code. If explicit domain_realm mapping is in place on client side (and here client is the server as request is issued from IPA httpd code), trusted domain's Global Catalog host will be automatically mapped to trusted domain realm. Otherwise KDC will hint the client with referral to proper KDC for trusted domain realm. This is the step that might fail if trusted domain is sub-domain of IPA domain, for example, ad.example.com. In this case our explicit mapping for example.com will prevail and requests will always be sent for principal in EXAMPLE.COM realm. More to that, since client and KDC are the same host, KDC will use domain_realm mapping as well and hint client with referral to itself (since .example.com = EXAMPLE.COM). Obtaining ticket will fail again. So, I was trying to solve this issue and I've got to following setup with Nalin's help: 1. Define following settings in [libdefaults] of krb5.conf default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true realm_try_domains = 0 realm_try_domains = 0 forces libkrb5 to fallback discovery of realm to domain of the host via DNS if there is no other explicit mapping. 2. Remove any explicit domain_realm mapping for our default realm since it will be implicitly generated from default_realm value by the fallback code anyway. With these changes both KDC and libkrb5 will be able to properly serve out both own domain and trusted domain requests. At some point SSSD will kick in with its explicit mapping for trusted domain realm. Still, KDC will not be able to see this mapping until restart but in Krb5 1.12 we are getting new pluggable interface that will allow to refresh KDC configuration. And here I'm coming to grave error in the SSSD code: the name of explicit mapping file contains non-filtered domain name, which contains dot. krb5.conf manual page states that includedir allows to source all files which names are constructed from alpha-numeric chars, dashes and underscores. Files with other characters are ignored. So dots as in domain_realm_example.com are ignored and our mapping is never sourced. For IDN domains we also will need to transform the name into its Punycode (RFC3492) to avoid breaking out of alpha-numeric space. I'd suggest replacing dots with underscores. File name is irrelevant to libkrb5 after it was read as part of includedir processing, and files are only written by the SSSD. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
