Anonymous kerberos and bootstrapping new hosts - how to?

James Croall jcroall at coverity.com
Sat Sep 7 12:40:08 EDT 2013


(Follow up to my own email)

Nevermind - I am a little rusty at this, I see the documentation is clear
about ktadd randomizing the key and it's coming back to me now.

Thanks again!

- 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.
>
>





More information about the Kerberos mailing list