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