[6917] in Kerberos
realm conversion question with v4 compatibility
daemon@ATHENA.MIT.EDU (Paul Pomes)
Tue Mar 19 15:54:37 1996
To: kerberos@MIT.EDU
Date: 19 Mar 1996 17:02:35 GMT
From: P-Pomes@Qualcomm.com (Paul Pomes)
In previous iterations with the v5 beta releases, I eliminated the realm
and principal conversion for "rcmd" requests in src/lib/krb5/krb/conv_princ.c .
I would then create two entries with kdb5_edit
ark host/hydra1.glab.globalstar.com (V5)
av4k rcmd/hydra1 (V4)
xst hydra1.glab.globalstar.com host (copied to hydra1:/etc/v5srvtab)
xst4 hydra1 rcmd (copied to hydra1:/etc/srvtab)
This worked fine for both the v4 clients, e.g, NCSA telnet from a Mac w.
KConfig, and for v5 clients.
With the latest release I'm trying to "go with the flow" and leave as much
as the system un-modified as possible. In /etc/krb5.conf I've arranged for
proper realm conversion with
[libdefaults]
ticket_lifetime = 600
default_realm = GLOBALSTAR.COM
[realms]
GLOBALSTAR.COM = {
kdc = draco1.glab.GLOBALSTAR.COM:88
admin_server = draco1.glab.GLOBALSTAR.COM
v4_instance_convert = {
hydra1 = hydra1.glab.globalstar.com
}
}
QUALCOMM.COM = {
kdc = KERBEROS.QUALCOMM.COM:750
admin_server = KERBEROS.QUALCOMM.COM
default_domain = QUALCOMM.COM
}
[domain_realm]
.glab.globalstar.com = GLOBALSTAR.COM
Now my understanding is that when processing a request for
rcmd.hydra1@GLOBALSTAR.COM, the KDC will look this up as
host/hydra1.glab.globalstar.com@GLOBALSTAR.COM . From the log files
I see that this is indeed the case. However when the client presents
his credentials to hydra1, login fails with "can't decode authenticator"
error. Obviously different keys are in hydra1:/etc/srvtab and what was
used by the KDC to encrypt the service ticket.
How do I bring these keys into sync?
/pbp