tkey-gssapi-credential
Nicholas F Miller
Nicholas.Miller at Colorado.EDU
Fri Oct 1 13:05:40 UTC 2010
That is how I created my keytab as well.
It is interesting, when I try an update from a client all I get are denies. When I try an update using nsupdate -g from the DNS server I will get a REFUSED but I will also get a DNS/host at DOMAIN kerb ticket from the keytab.
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder
On Sep 30, 2010, at 4:00 PM, Rob Austein wrote:
> Sorry, I spent most of the last two weeks locked in a conference room
> and mostly off net, still catching up.
>
> At Mon, 27 Sep 2010 07:54:54 -0600, Nicholas F Miller wrote:
>>
>> DNS Standard query TKEY 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
>> Queries
>> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class IN
>> Additional records
>> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class ANY
>> Algorithm name: gss-tsig
>> Signature inception: Sep 27, 2010 07:26:04.000000000 Mountain Daylight Time
>> Signature expiration: Sep 28, 2010 07:26:04.000000000 Mountain Daylight Time
>> Mode: GSSAPI
>> GSS-API Generic Security Service Application Program Interface
>> OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)
>> Simple Protected Negotiation
>> negTokenInit
>> mechTypes: 3 items
>> MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)
>> MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
>> MechType: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - User to User)
>> krb5_blob:
>> KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)
>> Kerberos AP-REQ
>> Realm: <FQN of DOMAIN>
>> Server Name (Service and Instance): DNS/<fqn of the DNS server>
>>
>> DNS Standard query response TKEY
>> Queries
>> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class IN
>> Answers
>> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, class ANY
>> Algorithm name: gss-tsig
>> Signature inception: Dec 31, 1969 17:00:00.000000000 Mountain Standard Time
>> Signature expiration: Dec 31, 1969 17:00:00.000000000 Mountain Standard Time
>> Mode: GSSAPI
>> Error: Bad key
>
> The nameserver appears to be rejecting the GSSAPI negotiation due to
> some basic failure, there are too many possibilities (all of which the
> protocol lumps into "BADKEY", sigh) to guess which. In theory named
> should have logged something like "failed gss_accept_sec_context:
> blah" where "blah" is the output of gss_error_tostring(); if there
> really is no such message (ie, it's not just lost under all the
> noise), this may indicate that you're somehow getting an "impossible"
> GSSAPI failure, ie, something that we don't ever expect to fail, so
> we're handling it via a RETERR() wrapper around an API call, or
> something like that (in which case said error clearly is not
> "impossible" and probably needs to be handled differently).
>
> The timestamps in the response is just the Unix epoch. I don't recall
> offhand whether that's what TKEY is supposed to return in this mode if
> there's no signature, but if not this would be consistent with the
> theory that something is erroring out early in processing.
>
> FWIW, here's the ktpass incantation that's worked for me in the past:
>
> C:\> ktpass -out foo.keytab -princ DNS/foo.example.org at EXAMPLE.ORG -pass * -mapuser foo at example.org
>
> where "foo.keytab" is the filename for the new keytab,
> "DNS/foo.example.org at EXAMPLE.ORG" is the principal name, and
> "foo at example.org" is the Active Directory user account.
More information about the bind-users
mailing list