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....@example.org -pass * -mapuser f...@example.org where "foo.keytab" is the filename for the new keytab, "DNS/foo.example....@example.org" is the principal name, and "f...@example.org" is the Active Directory user account. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
