krb5.conf on IPA server and SSSD setup

[Alexander Bokovoy]

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

[Jakub Hrozek]

On Tue, Jan 29, 2013 at 10:50:02PM +0200, Alexander Bokovoy wrote:
>  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. 
Please file a ticket

[Alexander Bokovoy]

On Tue, 29 Jan 2013, Jakub Hrozek wrote:
> On Tue, Jan 29, 2013 at 10:50:02PM +0200, Alexander Bokovoy wrote:
> > 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.
>
> Please file a ticket 
https://bugzilla.redhat.com/show_bug.cgi?id=905650
https://fedorahosted.org/sssd/ticket/1795

-- 
/ Alexander Bokovoy

[Jakub Hrozek]

On Tue, Jan 29, 2013 at 10:03:38PM +0100, Jakub Hrozek wrote:
>  On Tue, Jan 29, 2013 at 10:50:02PM +0200, Alexander Bokovoy wrote:
>  > 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.
>  
>  Please file a ticket 
OK, I cloned the F18 bug into:
https://fedorahosted.org/sssd/ticket/1795

[Pavel Březina]

On 01/29/2013 09:50 PM, Alexander Bokovoy wrote:
>  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. 
Does anybody know what is the purpose of this restriction?

[Sumit Bose]

On Thu, Jan 31, 2013 at 11:31:35AM +0100, Pavel Březina wrote:
>  On 01/29/2013 09:50 PM, Alexander Bokovoy wrote:
>  >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.
>  
>  Does anybody know what is the purpose of this restriction? 
from util/profile/prof_parse.c:

/*
 * Include files within dirname.  Only files with names consisting entirely of
 * alphanumeric chracters, dashes, and underscores are included, in order to
 * avoid including editor backup files, .rpmsave files, and the like.
 */
static errcode_t parse_include_dir(char *dirname, struct parse_state
*state)

HTH

bye,
Sumit

>  
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-devel