Anonymous kerberos and bootstrapping new hosts - how to?

[James Croall]

Hi Greg,

Thanks for the detailed response! Indeed I am in a position to rebuild my
kerberos binaries, and the patch you suggested did the trick. I can
authenticate into kadmin with the anonymous principal.

And I was puzzled about how in the world to extract the key with only
"add" privileges -- your suggestion of starting with a password and then
authenticating in with that password to extract does the trick!

However one last bit of confusion -- what option in there randomizes the
key? Is that implicit in the extract?

Thanks!! Perhaps we will be one of the first users of this capability, I
wasn't too keen on setting up an ssh back-channel into my hosts.

- James



James Croall | Senior Product Manager
Coverity | 185 Berry Street | Suite 6500, Lobby 3 | San Francisco, CA
94107 
Office: 415.694.5354 | Mobile: 202.246.6613 | jcroall at coverity.com
The Leader in Development Testing





On 9/6/13 9:41 PM, "Greg Hudson" <ghudson at MIT.EDU> wrote:

>On 09/06/2013 07:22 PM, James Croall wrote:
>> What I can't figure out what to do is automatically bootstrap a keytab
>>for a new host using anonymous Kerberos. The documentation is a bit
>>fuzzy, and most forum posts I read on the topic suggest using custom
>>scripts and back-channels to accomplish this.
>
>I believe I was told that this scenario was tested manually at some
>point during the development of anonymous PKINIT support, but it doesn't
>seem to work as of when work on that feature was completed.  I see three
>issues with it in my own tests, one of which is fatal:
>
>1. kadmin -n doesn't do a good job of picking a client principal name.
>This can be worked around with "kadmin -n -p @REALMNAME', but there's no
>reason the -p option should be required.
>
>2. kadmind rejects incoming anonymous connections, because
>gss_display_name() reports the name type as GSS_C_NT_ANONYMOUS, and
>kadmind checks (by pointer comparison!) that the name type is
>gss_nt_krb5_name.  This requires code changes to fix.  (I can send you a
>quick and dirty patch if you'd like; the permanent fix will take some
>more thought.)
>
>3. It looks like the way the ACL permissions and kadmin RPCs work out,
>you have to create the server principal with a password initially, then
>randomize the key with "kadmin -p host/hostname -q 'xst host/hostname'"
>and the password.  Workable but awkward.
>
>So, with apologies, it looks like we have more work to do on this
>secnario--including automated tests and documentation--before we
>actually support it.
>
>