[Freeipa-devel] Determine KDC for a website

[Martin Kosek]

On Thu, 2011-03-17 at 20:03 -0400, Adam Young wrote:
> I'm trying to figure out what should happen in the following case;
> 
> 
> A user goes to a website that they've never visited before.
> The site is using Kerberos, and thus the browser gets back a "Negotiate" 
> response.
> 
> At this point, the browser chops the hostname off the URL and requests 
> the TXT record for "_kerberos."+domain
> This gives the browser back the REALM.
> 
> 
> Now, there seems to be an understanding that the default REALM to domain 
> mapping should be  REALM.to_lower.

Yeah, Kerberos does this. This resulted in #1100 yesterday.

> 
> Now to find the KDC for the server, I can do a DNS query  for the SRV 
> record
> 
> "_kerberos._udp." + domain.

Correct.

> 
> 
> However, when I have a krb5 conf setup that does not explicitly set the 
> kdc value below....
> 
> [realms]
>   AYOUNG.BOSTON.DEVEL.REDHAT.COM = {
>    kdc = ipa14.ayoung.boston.devel.redhat.com:88
> }

Hm... This is what a configuration that IPA client installation produces
and for which KDC autodiscovery works for me:

[libdefaults]
  default_realm = TESTRELM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes

[realms]
  TESTRELM = {
    pkinit_anchors = FILE:/etc/ipa/ca.crt
  }

[domain_realm]
  .idm.lab.bos.redhat.com = TESTRELM
  idm.lab.bos.redhat.com = TESTRELM

[appdefaults]
  pam = {
    debug = false
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false
  }

> ...I cannot kinit against the realm AYOUNG.BOSTON.DEVEL.REDHAT.COM.  
> I've confirmed that I can query my IPA server's DNS server and get the 
> appropriate records.
> 
> Is there a step I am missing, or is this lookup no supported in the 
> library?  Is there some way I can better debug this?

What does your DNS log shows? I enabled DNS queries to be logged in my
"named" and `kinit admin at TESTRELM` with the above configuration made the
following queries:

18-Mar-2011 10:00:50.617 client 10.16.78.142#51316: query: _kerberos._udp.TESTRELM IN SRV + (10.16.78.111)
18-Mar-2011 10:00:50.621 client 10.16.78.142#60264: query: kdc.testrelm IN A + (10.16.78.111)
18-Mar-2011 10:00:50.621 client 10.16.78.142#60264: query: kdc.testrelm IN AAAA + (10.16.78.111)
18-Mar-2011 10:00:50.622 client 10.16.78.142#35208: query: _kerberos._tcp.TESTRELM IN SRV + (10.16.78.111)
18-Mar-2011 10:00:50.628 client 10.16.78.142#54654: query: _kerberos-master._udp.TESTRELM IN SRV + (10.16.78.111)
18-Mar-2011 10:00:50.630 client 10.16.78.142#54235: query: kdc.testrelm IN A + (10.16.78.111)
18-Mar-2011 10:00:50.649 client 10.16.78.142#49681: query: _kerberos-master._udp.TESTRELM IN SRV + (10.16.78.111)
18-Mar-2011 10:00:50.650 client 10.16.78.142#57950: query: _kerberos-master._tcp.TESTRELM IN SRV + (10.16.78.111)
18-Mar-2011 10:00:51.062 client 10.16.78.142#54733: query: vm-111.idm.lab.bos.redhat.com IN A + (10.16.78.111)
18-Mar-2011 10:00:51.063 client 10.16.78.142#46147: query: 111.78.16.10.in-addr.arpa IN PTR + (10.16.78.111)
...

And it successfully logs to Kerberos realm.

Martin