Realm mapping gone wrong on some hosts

[Tillman Hodgson]

Howdy folks,

On 2 of my hosts my cross-realm trust seems to have fallen apart, from
other hosts it appears to be working.

My domain -> realm mapping is 1:1, i.e. a host resides in the realm with
the same name as it's domain (but upper-cased). The exception is the
sole ROSPA.CA host -- it's dual-homed, but resides only in the ROSPA.CA
realm.

Realm 1: SEEKINGFIRE.PRV
Hosts: athena,coyote,blues,etc

Realm 2: ROSPA.CA
Hosts: caliban

The KDC is on surya, which is a mit-krb5-1.3.4nb2 package running on a
NetBSD host.

I can `telnet -a caliban` from all machines in the SEEKINGFIRE.PRV realm
/except/ for two hosts (my laptop and blues). When it works it's because
of the cross-realm trust (and my ~/.k5login on caliban), so the trust
krbtgt keys appear to be in place and working. When it doesn't work it
looks like this:

$ telnet -a caliban
Trying 192.168.23.30...
Connected to caliban.rospa.ca (192.168.23.30).
Escape character is '^]'.
telnetd: Authorization failed.
Connection closed by foreign host.

Note that this was working for quite some time (at least a year).
However, the rospa.ca domain was recently transferred and renewed ... I
have a nagging suspicion DNS problems have occured which might be behind
this problem (though I still provide the master zone file myself and
can't see anything wrong with it). This suspicion is due to what I see
in the kdc.log:

<snip>
Oct 01 21:21:14 surya.seekingfire.prv krb5kdc[4747](info): TGS_REQ (3 etypes {16 3 1}) 192.168.23.211: UNKNOWN_SERVER: authtim
e 1096684176,  tillman at SEEKINGFIRE.PRV for krbtgt/COM at SEEKINGFIRE.PRV, Server not found in Kerberos database
Oct 01 21:21:14 surya.seekingfire.prv krb5kdc[4747](info): TGS_REQ (3 etypes {16 3 1}) 192.168.23.211: UNKNOWN_SERVER: authtim
e 1096684176,  tillman at SEEKINGFIRE.PRV for krbtgt/COM at SEEKINGFIRE.PRV, Server not found in Kerberos database
Oct 01 21:21:14 surya.seekingfire.prv krb5kdc[4747](info): TGS_REQ (3 etypes {16 3 1}) 192.168.23.211: UNKNOWN_SERVER: authtim
e 1096684176,  tillman at SEEKINGFIRE.PRV for krbtgt/PRV at SEEKINGFIRE.PRV, Server not found in Kerberos database
Oct 01 21:21:14 surya.seekingfire.prv krb5kdc[4747](info): TGS_REQ (3 etypes {16 3 1}) 192.168.23.211: UNKNOWN_SERVER: authtim
e 1096684176,  tillman at SEEKINGFIRE.PRV for krbtgt/PRV at SEEKINGFIRE.PRV, Server not found in Kerberos database
Oct 01 21:21:14 surya.seekingfire.prv krb5kdc[4747](info): TGS_REQ (3 etypes {16 3 1}) 192.168.23.211: UNKNOWN_SERVER: authtim
<snip>

It's trying all kinds of things to get a cross-realm trust going, but
not the /right/ things. In other parts of the log it's trying
krbtgt/SEEKINGFIRE.COM at SEEKINGFIRE.PRV, and I have no idea how it's
getting the .COM version of the domain instead of the .PRV. It's
definitely not in /etc/krb5.conf on the two affected hosts and it's not
in my DNS zone file, which looks like this:

kerberos        CNAME   surya
_kerberos       TXT             "SEEKINGFIRE.PRV"
_kerberos._udp                  SRV     0       0       88      surya
_kerberos-master._udp   SRV     0       0       88      surya
_kerberos-adm._tcp              SRV     0       0       749     surya
_kerberos._udp                  SRV     0       0       464     surya

Steps I've taken so far: I've destroyed and recreated all tickets (via
kinit). I've confirmed that clocks are in sync. I've restarted the
relevant DNS services (to prevent caching from being a problem). I've
restarted the KDC. I've copied the /etc/krb5.conf over from athena to
the two problem hosts on the off chance that it had been changed and no
longer matched "the standard".

Any pointers on where I should be looking to further trouble-shoot an
error like this?

TIA,

-T


-- 
"So if you are wondering if you can just throw the tapes in the garbage,
the answer is no, they have data on them.  But if you're wondering if you
can restore your crashed disk contents from a tape, the answer is no, they
have no data on them." -- Alan J. Rosenthal, on the zen nature of backups