Re: tkey-gssapi-credential

2010-10-01 Thread Nicholas F Miller
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.0 Mountain 
 Daylight Time
   Signature expiration: Sep 28, 2010 07:26:04.0 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.0 Mountain 
 Standard Time
   Signature expiration: Dec 31, 1969 17:00:00.0 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


Re: tkey-gssapi-credential

2010-10-01 Thread Rob Austein
At Fri, 1 Oct 2010 07:05:40 -0600, Nicholas F Miller wrote:
 
 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.

It might be worth watching the Kerberos (UDP port 88) traffic during
both exchanges, to see if there are visible differences.

Basic capture of Kereberos can tell you a fair amount about
principals, realms, and algorithm negotiations.  tshark's -K option
lets you load keytabs, which in theory might let you peer deeper into
the packet, but I've never experimented with that option and don't
know if it's useful in this scenario.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: tkey-gssapi-credential

2010-09-30 Thread Rob Austein
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.0 Mountain 
 Daylight Time
Signature expiration: Sep 28, 2010 07:26:04.0 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.0 Mountain 
 Standard Time
Signature expiration: Dec 31, 1969 17:00:00.0 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


Re: tkey-gssapi-credential

2010-09-29 Thread Nicholas F Miller
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.0 Mountain 
 Daylight Time
  Signature expiration: Sep 28, 2010 07:26:04.0 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: 2000 (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
   

Re: tkey-gssapi-credential

2010-09-27 Thread Nicholas F Miller
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:

7341161.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.0 Mountain 
Daylight Time
   Signature expiration: Sep 28, 2010 07:26:04.0 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: 2000 (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

7344161.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 

Re: tkey-gssapi-credential

2010-09-27 Thread Nicholas F Miller
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.0 Mountain 
 Daylight Time
   Signature expiration: Sep 28, 2010 07:26:04.0 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: 2000 (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
   

Re: tkey-gssapi-credential

2010-09-17 Thread Rob Austein
At Fri, 17 Sep 2010 09:17:09 -0600, Nicholas F Miller wrote:
 
 I was wondering if it is possible to use the tkey-gssapi-credential
 and update-policy on a Windows install of bind. It strikes me that
 running bind on a Windows server, snapped into the AD it will serve
 DNS to, should be the easiest way of getting DDNS with update-policy
 control working.

It would be, except for one small problem: the Windows native Kerberos
doesn't support GSS-API (or didn't, when last I checked), instead it
supports some similar-but-different Microsoft proprietary API whose
name has temporarily escaped my memory.  So either we would have to
hack Windows-specific code here to use Microsoft's API, or we would
have to get a Unix-style Kerberos library working on Windows.

We spent an insane amount of time banging our head against the latter
approach, but never got it to work, for reasons that never made a lot
of sense (eg, linking against precompiled MIT Kerberos binaries
resulted in binaries that worked fine for everything but GSS-TSIG but
failed silently for that, attempting to build MIT Kerberos for Windows
from source resulted in Kerberos code that couldn't even kinit, and
nobody on the MIT Kerberos project could tell us why).  We eventually
gave up, because we had deadlines to meet and this configuration
(BIND9 running GSS-TSIG on Windows) wasn't on our critical feature
list.

 Am I nuts? Should I just install it on a Linux box and be done?

Yes, unless you (or some other brave soul) have the time and energy to
get this working on Windows, in which case please tell us what you did
(and i will stand you a beer if we ever meet...).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: tkey-gssapi-credential

2010-09-17 Thread Nicholas F Miller
Thanks, that will save me a bunch of time. Of course I spent my morning testing 
it out to no avail.

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.
_
Nicholas Miller, ITS, University of Colorado at Boulder



On Sep 17, 2010, at 12:54 PM, Rob Austein wrote:

 At Fri, 17 Sep 2010 09:17:09 -0600, Nicholas F Miller wrote:
 
 I was wondering if it is possible to use the tkey-gssapi-credential
 and update-policy on a Windows install of bind. It strikes me that
 running bind on a Windows server, snapped into the AD it will serve
 DNS to, should be the easiest way of getting DDNS with update-policy
 control working.
 
 It would be, except for one small problem: the Windows native Kerberos
 doesn't support GSS-API (or didn't, when last I checked), instead it
 supports some similar-but-different Microsoft proprietary API whose
 name has temporarily escaped my memory.  So either we would have to
 hack Windows-specific code here to use Microsoft's API, or we would
 have to get a Unix-style Kerberos library working on Windows.
 
 We spent an insane amount of time banging our head against the latter
 approach, but never got it to work, for reasons that never made a lot
 of sense (eg, linking against precompiled MIT Kerberos binaries
 resulted in binaries that worked fine for everything but GSS-TSIG but
 failed silently for that, attempting to build MIT Kerberos for Windows
 from source resulted in Kerberos code that couldn't even kinit, and
 nobody on the MIT Kerberos project could tell us why).  We eventually
 gave up, because we had deadlines to meet and this configuration
 (BIND9 running GSS-TSIG on Windows) wasn't on our critical feature
 list.
 
 Am I nuts? Should I just install it on a Linux box and be done?
 
 Yes, unless you (or some other brave soul) have the time and energy to
 get this working on Windows, in which case please tell us what you did
 (and i will stand you a beer if we ever meet...).
 ___
 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


Re: tkey-gssapi-credential

2010-09-17 Thread Rob Austein
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