What are the issues with dns_lookup_realm ?

[Brian Candler]

On Mon, Oct 04, 2010 at 12:57:17PM -0400, Greg Hudson wrote:
> Yes.  The precedence order of domain-relam mappings is:
> 
>   1. krb5.conf domain_realms
>   2. KDC referrals
>   3. DNS TXT lookups, if turned on
>   4. The domain heuristic, if turned on
>   5. The upper-cased parent realm of the hostname
>   6. The default realm, if the hostname has no parent realm
> 
> So the default realm is actually not used in very many cases.

FWIW, I just had a very odd situation with mod_auth_kerb, which appears to
be related to chosing a realm.

It was all working fine with true kerberos authentication (*):

<Location /testapp>
  AuthName "Hello Kerberos World"
  AuthType Kerberos
  # Allow fallback to Basic Auth?
  KrbMethodK5Passwd Off
  KrbAuthRealms IDM.EXAMPLE.COM
  Krb5Keytab /etc/httpd/conf/krb5.keytab
  require valid-user
</Location>

But when I tried to add fallback to Basic Auth (KrbMethodK5Passwd On) for
non-Kerberos users, no usernames/passwords were being accepted.  This was
odd because mod_auth_kerb only needs to authenticate as the user principal,
which normally can happen from any host - even when the client IP/hostname
doesn't itself map to any realm.

The error message from /var/log/http/ssl_error_log was unhelpful:

[Mon Oct 11 11:20:17 2010] [error] [client 172.31.131.185] krb5_verify_init_creds() failed: Key table entry not found

What was even more odd, if I did a 'su' to the apache user, I was able to
'kinit' using one of the usernames/passwords which apache was rejecting as
Basic Auth credentials. Surely mod_auth_kerb should be doing the same??

I did find a solution in the end. krb5.conf has

[libdefaults]
 default_realm = IDM.EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true

The machine's primary name is uk1-sys-rds1.maint.example.com
and there is a DNS entry for this subdomain to map to a realm:

_kerberos.maint.example.com.	TXT "IDM.EXAMPLE.COM"

However the clients were connecting to a virtual host
"rails.api.example.com" on that machine.  The apache keytab file had service
principals for both HTTP/rails.api.example.com at IDM.EXAMPLE.COM and
HTTP/uk1-sys-rds1.maint.example.com at IDM.EXAMPLE.COM, just to be sure.

The change which made password authentication work was to add a DNS entry
for the api domain:

_kerberos.api.example.com.	TXT "IDM.EXAMPLE.COM"

I tried tcpdumps of udp port 88 in both cases. Before the DNS addition,
there was a 4 packet exchange.  After the DNS addition there was a much
longer exchange, but the first 4 packets seemed to have pretty much the same
contents.

The fact that adding the DNS record fixed things suggests that it was a
hostname-to-realm mapping issue. But I'd really like to know what principal
it was looking for when I got the "Key table entry not found" error message.

This particular Apache server is running CentOS 4.6 with only kerberos
1.3.4, so perhaps a newer version would have given a better error message.

Regards,

Brian.

(*) That is: using Chrome where I had started it with
  /opt/google/chrome/google-chrome --auth-server-whitelist=*.example.com
and with Firefox where I had gone to about:config and set
  network.negotiate-auth.trusted-uris	example.com