Do you need anything other than libgssapi installed for GSS-TSIG to work. Are
any of these required as well:
cyrus-sasl-gssapi.i386 2.1.22-5.el5_4.3 rhel-x86_64-client-5
cyrus-sasl-gssapi.x86_64 2.1.22-5.el5_4.3 rhel-x86_64-client-5
libgssapi.i386 0.10-2 rhel-x86_64-client-5
libgssapi-devel.i386 0.10-2 rhel-x86_64-client-workstation-5
libgssapi-devel.x86_64 0.10-2 rhel-x86_64-client-workstation-5
rsyslog-gssapi.x86_64 3.22.1-3.el5 rhel-x86_64-client-5
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder
On Sep 27, 2010, at 10:23 AM, Nicholas F Miller wrote:
> 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
