[tlyu - Mon Mar 21 15:54:15 2005]:
Show quoted text
> >>>>> "jd" == Public Submitter via RT <rt-comment@krbdev.mit.edu> writes:
>
> jd> [guest - Wed Mar 16 14:15:31 2005]:
> >>
> >> As I was saying (sorry about the previous "submit")...
> >>
> >> It seems like this fix breaks kadmin auth. with keytab. For example:
> >>
> >> # kadmin -p host/binky.foonon.com -k -t /etc/krb5.keytab
> >> Authenticating as principal host/binky.foonon.com with
> >> keytab /etc/krb5.keytab.
> >> kadmin: Cannot find KDC for requested realm while initializing kadmin
> >> interface
> >>
> >> jd
>
> jd> Also, this seems to not happen when the kadmin server is running on a
> jd> pre-1.4 KDC
>
> This seems like it may be a bug exposed due to a misconfigured
> domain_realm mapping. Are the pre-1.4 KDC and the 1.4 KDC running on
> the same host? Does the kadmin client without a keytab work correctly
> on the same host from which you attempt to use kadmin with the keytab?
>
> ---Tom
I had the sense of things messed up, sorry. What I *meant* to say is
that it *doesn't* happen when the kadmin server is using RPCSEC_GSS.
I'm working in two different Kerberos environments: one using a 1.28 MIT
KDC, the other using a Solaris 10 KDC.
With the 'kadmin classic' server (v1.28, patched), and the new (1.4
patched) kadmin client, "kadmin -k" would fail, but "kadmin -O -k" would
work just fine (while password and ccache auth would work without the
"-O"). On the same system, connecting to the same kadmind, a v1.35
kadmin would work just fine in all three cases.
I'll double-check the domain_realm mapping, but I'm fairly certain that
it's okay since everything else works.
jd
