Failed primary KDC - Can't login

Ken Raeburn raeburn at MIT.EDU
Fri Aug 9 16:04:12 EDT 2002


Turbo Fredriksson <turbo at bayour.com> writes:
> I've set up two KDC's (kerberos1/rmgztk and kerberos2/morwen) and a
> client (tuzjfi).

How do you pronounce "rmgztk"? :-)

> morwen:~# tail -f /var/log/kerberos/krb5kdc.log -n0
> Aug 07 11:16:37 morwen krb5kdc[2892](info): AS_REQ (3 etypes {16 1 3}) 192.168.1.4(88): NEEDED_PREAUTH: turbo at BAYOUR.COM for krbtgt/BAYOUR.COM at BAYOUR.COM, Additional pre-authentication required
> Aug 07 11:16:48 morwen krb5kdc[2892](info): AS_REQ (3 etypes {16 1 3}) 192.168.1.4(88): ISSUE: authtime 1028711808, etypes {rep=16 tkt=16 ses=16}, turbo at BAYOUR.COM for krbtgt/BAYOUR.COM at BAYOUR.COM
> ----- s n i p -----
>
> The second line comes just before I get 'login timed out ...', but it
> seems like it's succeeding!

Yes, it does.  I don't think this is a problem with timeouts in the
Kerberos code.

The retry loop in the krb5 library is kind of lame in some ways, but
in the situation you've described, it should only be delaying a second
or so waiting for a response from kerberos1 before contacting
kerberos2, both times.


> One thing that I thought of was that there's no KAdmin (krb524d) running
> on kerberos2. Do I really _HAVE_ to run one? Kerberos2 is 'never' going
> to be the master, it's just to authenticate users/services while kerberos1
> is down (hopfully a very short time :)...

Don't confuse kadmin and krb524d.  The latter is for converting krb5
tickets into krb4 tickets, and has nothing to do with a KDC being the
master.  If you're running it on kerberos1, you should run it on
kerberos2 as well.  If you weren't running it on kerberos1, and had no
problems, then you shouldn't need it on kerberos2.

I'm not familiar with the krb5 PAM module.  If it or other software is
trying to get krb4 tickets during the login process, and doing it via
krb524 (instead of a separate krb4 initial ticket request with
password), that could add a similar delay of probably around 22
seconds.  (Total 21 seconds waiting for responses from kerberos1 after
three attempts to reach it, plus however long it takes to get back
"port unreachable" messages from kerberos2.)

But you say the successful krb5 request is right before the timeout.
If the timeout is 60 seconds, that means the login program isn't
contacting the KDCs the first time until around 45 seconds have
passed, and then you presumably enter your password for the krb5
preauth, and after that you have only a few seconds for whatever login
is trying to do before the timeout (krb524 exchange or LDAP stuff or
something else).

> But I think the real problem is the timeout. Since I'm using LDAP (PAM/NSS),
> and it takes a while before the LDAP libs try the second LDAP server (which 
> is kerberos2), login times out.
>
> If indeed this is the problem, this is more of a OpenLDAP issue (hence the
> Cc)...

Yes, if it's doing the LDAP work first, that may be the place to look
for a timeout to fix.

Something else you might try is getting "port unreachable" errors sent
back from the address of kerberos1.  If your router can't do it
(packet filter settings?), bring up a machine on that address (or
configure an extra address on another box) that's not running any of
those services, so that you don't need to wait for the timeout.  Then
perhaps both Kerberos and LDAP can fall back to kerberos2 more
quickly.

Ken



More information about the Kerberos mailing list