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/h...@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....@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
