On Tue 2007-08-07 19:48:59 -0400, Russ Allbery wrote: > 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.
Thank you, Russ! Adding a domain_realm entry does indeed restore the
etch behavior, independent of which libraries are used. Not only
that, but it restores what had looked like broken functionality in
iceweasel and svn (via libneon26). Sweet!
However, i've got dns_lookup_realm = true in [libdefaults] of
krb5.conf.
The server is x.example.org, and there is already a
_kerberos.example.org TXT record in DNS which reports "EXAMPLE.ORG"
for this domain [0].
Shouldn't the dns_lookup_realm have the same effect as adding the
explicit domain_realm mapping, given the presence of the DNS record?
Do i have the configuration wrong? Is my DNS entry misconfigured?
Lastly, i'm still confused as to why the client is trying to query the
KDC at all if it knows the domain/realm mapping. There's a ~40 second
delay in curl while the library tries to query an unresponsive KDC,
even if the domain_realm mapping is explicitly present and the
credentials cache has a valid, non-expired ticket. What is this query
doing? Why should the client need to wait like this?
To be fair, iceweasel and svn don't seem to have the same delay
issues, so maybe that angle of this bug belongs more in the libcurl
package?
Thanks again,
--dkg
[0] http://www3.ietf.org/proceedings/00jul/I-D/cat-krb-dns-locate-02.txt
pgpHh1Sns65Y5.pgp
Description: PGP signature
