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

Reply via email to