Re: tkey-gssapi-credential
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
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: >> Server Name (Service and Instance): >> DNS/ >> >> 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
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: >Server Name (Service and Instance): > DNS/ > > 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
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/@ >> -pass * -mapuser @ -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.603167DNS 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 >> 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: >> Server Name (Service and Instance): >> DNS/ >> Name-type: Service and
Re: tkey-gssapi-credential
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/@ > -pass * -mapuser @ -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.603167DNS 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 > 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: > Server Name (Service and Instance): > DNS/ > Name-type: Service and Instance (2) > Name: DNS > Name: > 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.605703DNS Standard query response > TKEY > ... > Queries > 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-00
Re: tkey-gssapi-credential
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/@ -pass * -mapuser @ -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.603167DNS 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 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: Server Name (Service and Instance): DNS/ Name-type: Service and Instance (2) Name: DNS Name: 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.605703DNS Standard query response TKEY ... 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
Re: tkey-gssapi-credential
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
Re: tkey-gssapi-credential
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
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
