A small correction:
The packets captured below were between one of the DCs and the DNS server not a
client.
Also, I am getting this as well when I run nsupdate -g and try to add an A
record:
dns_tkey_negotiategss: TKEY is unacceptable
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder
On Sep 27, 2010, at 7:54 AM, Nicholas F Miller wrote:
> Are you sure? ;-P
>
> I can't seem to get things working. It looks like the Windows machines are
> not happy with the TKEY the DCs are giving them. I can kinit a user account
> from the AD on the DNS server so our krb5.conf appears correct. I am getting
> errors when I run kinit -k -t /etc/krb5.keytab saying the client is not found
> in the database. I'm not sure if it should work since the keytab only has a
> reference to the DNS service principle.
>
> I created the keytab using various different flags. Below is the current
> keytab:
>
> ktpass -out new.keytab -princ DNS/<fqn of the DNS server>@<FQN of DOMAIN>
> -pass * -mapuser <ADuser>@<fqn of domain> -ptype KRB5_NT_PRINCIPAL -crypto
> DES-CBC-CRC
>
>> From the AD client I am getting some DNS TKEY transactions like this after
>> the update fails. Notice the second transaction's Signature inception and
>> expiration have a null date:
>
> 7341 161.603167 <DC IP> <client IP> DNS Standard query TKEY
> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
> ...<snip>
> Queries
> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY,
> class IN
> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
> Type: TKEY (Transaction Key)
> Class: IN (0x0001)
> Additional records
> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY,
> class ANY
> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
> Type: TKEY (Transaction Key)
> Class: ANY (0x00ff)
> Time to live: 0 time
> Data length: 1712
> 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
> Error: No error
> Key Size: 1686
> Key Data
> 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)
> mechToken:
> 6082065006092a864886f71201020201006e82063f308206...
> krb5_blob:
> 6082065006092a864886f71201020201006e82063f308206...
> KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos
> 5)
> krb5_tok_id: KRB5_AP_REQ (0x0001)
> Kerberos AP-REQ
> Pvno: 5
> MSG Type: AP-REQ (14)
> Padding: 0
> APOptions: 20000000 (Mutual required)
> 0... .... .... .... .... .... .... ....
> = reserved: RESERVED bit off
> .0.. .... .... .... .... .... .... ....
> = Use Session Key: Do NOT use the session key to encrypt the ticket
> ..1. .... .... .... .... .... .... ....
> = Mutual required: MUTUAL authentication is REQUIRED
> Ticket
> Tkt-vno: 5
> Realm: <FQN of DOMAIN>
> Server Name (Service and Instance):
> DNS/<fqn of the DNS server>
> Name-type: Service and Instance (2)
> Name: DNS
> Name: <fqn of the DNS server>
> enc-part rc4-hmac
> Encryption type: rc4-hmac (23)
> Kvno: 3
> enc-part:
> 29653f6457b51106240db14316c9ffef0f40e58852cf7a59...
> Authenticator rc4-hmac
> Encryption type: rc4-hmac (23)
> Authenticator data:
> 6b4d26e823ca79be98fa558115020ef589b859088566b9a3...
> Other Size: 0
>
> 7344 161.605703 <client IP> <DC IP> DNS Standard query response
> TKEY
> ...<snip>
> Queries
> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY,
> class IN
> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
> Type: TKEY (Transaction Key)
> Class: IN (0x0001)
> Answers
> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY,
> class ANY
> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e
> Type: TKEY (Transaction Key)
> Class: ANY (0x00ff)
> Time to live: 0 time
> Data length: 26
> 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
> Key Size: 0
> Other Size: 0
>
> The named.conf contains an update-policy like this:
>
> options {
> ...<snip>
> tkey-gssapi-credential "DNS/<fqn of the DNS server>";
> tkey-domain "<FQN of DOMAIN>";
> }
>
> update-policy {
> grant <FQN of DOMAIN> ms-self * A;
> };
>
> Any ideas? Have I missed something obvious?
> _________________________________________________________
> Nicholas Miller, ITS, University of Colorado at Boulder
>
>
>
> On Sep 17, 2010, at 11:08 PM, Rob Austein wrote:
>
>> At Fri, 17 Sep 2010 13:18:42 -0600, Nicholas F Miller wrote:
>>>
>>> Does anyone have instructions on how to setup a Linux bind server to
>>> use GSS-TSIG against an AD? I have found many articles from people
>>> having issues with it but none that had good instructions on how to
>>> get it working. Last year we played around with it but were having
>>> issues getting it to work. kinit would work against the AD on our
>>> RHEL bind server but our clients couldn't update their records.
>>
>> Beyond what's already been posted here? Not really. I can perhaps
>> tell you two things that might be useful.
>>
>> 1) The code really does work, honest. I have personally seen it work
>> (in the lab -- my last stint as an operator supporting anything on
>> Windows predated AD) with Windows 2000, Windows 2003 Server, and
>> Windows XP. I have not (yet) personally tested it with anything
>> more recent than that, but unless Microsoft has done something
>> weird (nah) it still should.
>>
>> 2) If you run into problems, the best debugging tools I can recommend
>> are:
>>
>> a) Running named with full debugging ("named -g" and capture the
>> stderr output somewhere, or do the equivalent with logging
>> options in named.conf); and
>>
>> b) A good packet sniffer watching both DNS and Kerberos traffic.
>>
>> For (b) I recommend Wireshark (or tshark, same difference). You
>> can use some other tool (eg, tcpdump) to capture the dump, but
>> understanding what happened requires an analyzer that do deep
>> insepction of both DNS and Kerberos. Make sure you capture full
>> packets for both Kerberos and DNS, ie, UDP ports 88 and 53 as well
>> as TCP port 53 (Yes, Windows uses all three).
>> _______________________________________________
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
> _______________________________________________
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
