Skip Menu |
 

Subject: Anonymous kadmin does not work
Download (untitled) / with headers
text/plain 1.2KiB
When anonymous support was added, the intent was that kadmin -n would
work for authenticating anonymously to kadmind, and permissions could be
granted to the anonymous principal to do things like create new host
principals.

This (1) does not work at all on the admin server side, (2) has a bad
user experience on the admin client side, and (3) is awkward to use for
creating host principals.

Problem #1 is that server_stubs.c checks the name type returned by
gss_display_name() in two places, doing a pointer comparison (!) against
gss_nt_krb5_name. For the anonymous principal, gss_display_name()
returns a name type of GSS_C_NT_ANONYMOUS, so init_2_svc() rejects the
connection.

Problem #2 is that kadmin -n doesn't pick a client principal, so you
have to manually enter '-p @REALMNAME' or '-p
WELLKNOWN/ANONYMOUS@REALMNAME' or you get an obscure error. kadmin -n
should work as transparently as kinit -n.

Problem #3 is that we don't currently have a way to create a principal
and extract its random key at the same time. So you have to create the
host principal with a password, then use it (e.g. "kadmin -p
host/hostname -q 'xst host/hostname'") to randomize and extract. Within
a script, this would be pretty awkward as the script would have to
choose a secure temporary password.
I have also received a private report that, with problem #2 fixed and
problem #1 worked around, kadmin -n can occasionally fail, but then works
on the next try. We should try to reproduce and fix this problem.
I split this up into three other tickets: #7740 for kadmind accepting
anonymous names, #7741 for kadmin -n choosing an appropriate principal,
and #7743 for the ability to add a principal and extract its random key.

I was not able to reproduce any sporadic failures. If we get enough
information about such failures to have a hope of debugging it, we can
open a new issue about it.