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