[Freeipa-users] Kerberos realm for different domain

[Alexander Bokovoy]

On pe, 16 joulu 2016, Brian Candler wrote:
>On 16/12/2016 08:21, Alexander Bokovoy wrote:
>>
>>So you can have IPA masters with FQDNs in totally different DNS domains
>>than dictated by their Kerberos realm and --domain options.
>
>That I understand - not only can the IPA masters have FQDNs in 
>different DNS domains, but indeed the member machines of that realm as 
>well.
>
>What was unclear to me was whether "ipa-server-install --domain xxx" 
>affects the content of the database being built (and therefore 
>replicated later to the slaves), or is just something local to the 
>host itself.
>
>In the manpage for "ipa-client-install" it's much clearer: in that 
>case, it says that --domain is the starting domain for LDAP server 
>auto-discovery.
>
>To clarify, there are several DNS auto-discovery mechanisms. Two of 
>them are described in the MIT docs at
>https://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Using-DNS
>
>(1) Map hostname aaa.bbb.ccc to realm xxx.yyy.zzz
>
>Look for TXT records for _kerberos.aaa.bbb.ccc, _kerberos.bbb.ccc, 
>_kerberos.ccc. The TXT record gives the realm that this host belongs 
>to.
>
>(2) Realm xxx.yyy.zzz to Kerberos servers for that realm
>
>Given realm xxx.yyy.zzz, look for in the DNS for SRV records for
>_kerberos._udp.xxx.yyy.zzz
>_kerberos-master._udp.xxx.yyy.zzz
>_kpasswd._udp.xxx.yyy.zzz
>
>This is all very clear.
>
>Now, the manpage for ipa-client-install describes another one, which 
>is where I get a bit fuzzy:
>
>(3)
>
>   DNS Autodiscovery
>       Client installer by default tries to search for 
>_ldap._tcp.DOMAIN  DNS SRV  records for all domains that are parent to
>its hostname.  For example, if a client machine has a hostname
>'client1.lab.example.com',  the installer will try to retrieve
>an IPA server hostname from _ldap._tcp.lab.example.com,
>_ldap._tcp.example.com and _ldap._tcp.com DNS  SRV  records,
>respectively. The discovered domain is then used to configure client
>components (e.g. SSSD and Kerberos 5 configuration) on
>the machine.
>
>What it doesn't actually say (but I believe must be true) is that what 
>it calls the "discovered domain" is in fact the *realm* to use.  If 
>so, effectively this is algorithm (2) in reverse: instead of using it 
>for realm to SRV mapping, you hunt for a domain which contains the 
>right SRV records and use this to infer your realm.
>
>Is that right?
In case of IPA client you need to deal with both Kerberos realm and
application-level LDAP servers. The latter aren't related to Kerberos
realm themselves. However, authentication to them is based on GSSAPI and
thus Kerberos. So discovery of the LDAP servers is done via SRV records
according to https://tools.ietf.org/html/draft-ietf-ldapext-locate-08
and RFC2782 but Kerberos configuration is done based on the
corresponding DNS SRV records too (_ldap versus _kerberos for two
different purposes).

It became customary when Active Directory was introduced in 2000, that
when both _ldap.<protocol>.domain and _kerberos.<protocol>.domain DNS
SRV records exist, they are assumed to be explaining the services from
the same Kerberos realm. On MIT Kerberos side use of DNS TXT record
allows you to easily discover the actual name of the realm too. On
Active Directory side it is not the case but there realm name is equal
to the DNS domain name for the AD domains and additional DNS domains are
actually discovered through completely different means -- by using
netr_DsRGetForestTrustInformation function over LSA pipe.

>(Is this a mechanism modelled on Active Directory? Otherwise, I would 
>have thought you could use MIT algorithm (1) to discover your realm)
https://tools.ietf.org/html/draft-ietf-ldapext-locate-08 was driven by
Microsoft and since early 2000s was implemented in many LDAP libraries.
Needless to say, OpenLDAP utilities supports DNS SRV records discovery too,
see -H option in ldapsearch manual page for example.

>>After all, these are *flexibility* options. They are not supposed to
>>make sense in all combinations. Where they aren't making sense, you are
>>allowed to shoot yourself in your feet if you know what you are doing.
>>
>Absolutely, and I don't want to get this wrong and have to start again :-)
>
>OK, I have a final question on the planning of realms and DNS.
>
>As we've already said, in an IPA-only installation, the machines which 
>are members of the realms can happily have hostnames which are 
>unrelated to the realm name: e.g.
>
>     IPA.EXAMPLE.COM
>         | | |
>machines <name>.foo.com
>machines <name>.bar.com
>
>A user in IPA.EXAMPLE.COM can login to host <name>.foo.com, either 
>because their krb5.conf has a static domain->realm mapping, or there's 
>a DNS entry: _kerberos.foo.com TXT "IPA.EXAMPLE.COM"
>
>However, suppose I plan to end up with a trust to an Active Directory 
>/ Samba4 realm:
>
>AD.EXAMPLE.COM <--trust--> IPA.EXAMPLE.COM
>    | | |                      | | |
>    users                    machines
>
>I want to allow users in the AD.EXAMPLE.COM realm to login to machines 
>in the IPA.EXAMPLE.COM realm.
>
>Will this still work when the machines are in different DNS domains? 
Yes, it will. Here is the catch: you need to make sure these different
DNS domains all mentioned in 'ipa realmdomains-show' and if not, they
should be added by use of 'ipa realmdomains-mod'. None of these domains
must overlap with Active Directory domains, of course.

When trust is established, Active Directory DCs will retrieve and
validate list of name routing suffixes associated with IPA forest using 
netr_DsRGetForestTrustInformation LSA RPC call. 'ipa realmdomains-*'
commands manage what exactly we return there.

We automatically manage realm domains list if IPA does control the DNS
server -- adding a DNS zone will cause an entry added to the 'ipa
realmdomains-*'. However, if DNS domains are managed externally, it is
your duty to manage realm domains too.

-- 
/ Alexander Bokovoy