Daniel Kahn Gillmor <[EMAIL PROTECTED]> writes:
> Package: libkrb53
> Version: 1.6.dfsg.1-6
> Severity: important
> This is a confusing one (for me, anyway):
> I have a GSSAPI-capable client (curl, using the --negotiate flag). It
> is linked against the MIT krb5 libraries. It is connecting to service
> "X". My credentials cache already has a (non-expired) ticket for X
> (in addition to having a TGT).
> My understanding of the krb5 protocol is that there is no need to
> contact the KDC until ticket expiry. In my test environment, the KDC
> is inaccessible after having granted the tickets.
> However, with the lenny version of libkrb53, not only does my client
> attempt to contact the KDC (both primary and secondary, repeatedly,
> for ~45 seconds); if neither KDC responds, the GSSAPI authentication
> fails.
> Trying the same experiment on a debian etch system with the same
> credentials cache shows the same repeated attempts to contact the
> KDCs, but then the GSSAPI authentication succeeds.
Since there's a change between etch and lenny, this smells like a referral
issue. The primary user-noticable difference between the etch libraries
and the lenny libraries is that the lenny libraries will query the KDC to
determine the appropriate realm for a service ticket rather than applying
a heuristic based on DNS names, which means that people without
domain_realm mappings are seeing different behavior.
Could you check your /etc/krb5.conf file on the client and make sure that
you have a domain_realm mapping set up for the system to which you're
trying to authenticate? For example, if your realm is EXAMPLE.ORG and the
system is webserver.example.org, a mapping like:
[domain_realm]
.example.org = EXAMPLE.ORG
should be sufficient.
My guess is that this is missing and that adding it will restore the etch
behavior.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
