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

Reply via email to