tkey-gssapi-credential

[Nicholas F Miller]

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.