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
  default_realm = EXAMPLE.COM
  dns_lookup_realm = false
  dns_lookup_kdc = true

  .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

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

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

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

Reply via email to