tkey-gssapi-credential
Nicholas F Miller
Am I nuts? Should I just install it on a Linux box and be done?
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder
Rob Austein
>
> 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...).
Nicholas F Miller
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
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
Rob Austein
>
> 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).
Nicholas F Miller
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
Nicholas F Miller
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
Nicholas F Miller
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
Nicholas F Miller
Tony Finch
> Does anyone actually have GSS-TSIG working with an Active Directory?
There are some GSS-TSIG interop fixes in 9.7.2.
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
Dave Knight
On 2010-09-30, at 11:24 AM, Nicholas F Miller wrote:
> Does anyone actually have GSS-TSIG working with an Active Directory? I see plenty of posts from people trying to get it to work. I have yet to see anyone who claims to actually have it working. Did MS change something in 2008r2 since GSS-TSIG was implemented in bind to make it inoperable?
Right after GSS-TSIG appeared I built a lab for the purpose of demonstrating and documenting a working setup.
That lab contained a couple of W2k3 servers, XP clients and BIND servers running on FreeBSD. I went from bare iron to a working W2k domain using BIND+GSS-TSIG exclusively for name service.
As I recall I did the initial population of the zone used for the W2k domain without security enabled, ie: I informed the Windows machine that the BIND server was to be used and configured the BIND server to allow updates from the Windows server on the basis of its IP address, then ran dcpromo.exe to create the domain, then did the necessary Kerberos bits, then locked down the BIND server to henceforth accept only GSS-TSIG authenticated updates.
I haven't touched this stuff since though, so I have nothing to say about how it might work with contemporary Windows and BIND versions.
dave
Rob Austein
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.000000000 Mountain Daylight Time
> Signature expiration: Sep 28, 2010 07:26:04.000000000 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.000000000 Mountain Standard Time
> Signature expiration: Dec 31, 1969 17:00:00.000000000 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.exa...@EXAMPLE.ORG -pass * -mapuser f...@example.org
where "foo.keytab" is the filename for the new keytab,
"DNS/foo.exa...@EXAMPLE.ORG" is the principal name, and
"f...@example.org" is the Active Directory user account.
Nicholas F Miller
Nicholas Miller, ITS, University of Colorado at Boulder
On Sep 30, 2010, at 10:15 AM, Tony Finch wrote:
> On Thu, 30 Sep 2010, Nicholas F Miller wrote:
>
>> Does anyone actually have GSS-TSIG working with an Active Directory?
>
Nicholas F Miller
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder
Nicholas F Miller
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/host@DOMAIN kerb ticket from the keytab.
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder
Rob Austein
>
> 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/host@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.
Nicholas F Miller
deny <DOMAIN> ms-self * SRV AAAA;
grant <DOMAIN> ms-self * ANY;
Nothing will update. When we set it like this:
deny <DOMAIN> ms-self * SRV;
grant <DOMAIN> ms-self * ANY;
Things seem to work when a client reboots.
When we try to add grants for the DCs like this:
grant <fqn of dc> ms-self * ANY;
grant <fqn of dc> ms-subdomain * ANY;
deny <DOMAIN> ms-self * SRV;
grant <DOMAIN> ms-self * ANY;
The DCs cannot update their SRV records.
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder
On Oct 1, 2010, at 7:00 AM, Nicholas F Miller wrote:
> Thanks, I'll give it a try and see if things begin to work.
> _________________________________________________________
> Nicholas Miller, ITS, University of Colorado at Boulder
>
>
>
> On Sep 30, 2010, at 10:15 AM, Tony Finch wrote:
>
>> On Thu, 30 Sep 2010, Nicholas F Miller wrote:
>>
>>> Does anyone actually have GSS-TSIG working with an Active Directory?
>>
>> There are some GSS-TSIG interop fixes in 9.7.2.
>>
>> Tony.
>> --
>> f.anthony.n.finch <d...@dotat.at> http://dotat.at/
>> HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
>> DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
>> ROUGH. RAIN THEN FAIR. GOOD.
>
Rob Austein
than every machine in the realm), something like:
grant dc$@REALM. subdomain dnsname.;
might work better, where "dc$@REALM" is (eg) the Kerberos principle
corresponding to your DC and "dnsname" is the tree to which you want
to grant rights. The "$" is a Microsoft-ism.
Nicholas F Miller
I think it is working now. I have the update-policy setup as follows:
grant dc1$@REALM wildcard * ANY;
grant dc2$@REALM wildcard * ANY;
grant dns_server$@REALM wildcard * ANY;
deny REALM ms-self * SRV;
grant REALM ms-self * ANY;
If I understand things correctly I am allowing the DCs and DNS server to update any record type in the domain and any subdomains. The clients are allowed to update any of their own records except SRV, MX and NS. Do I even need to deny NS for ms-self?
If it is truly working correctly, I wonder why I can't deny AAAA records. When I add AAAA to the deny statement it blocks A records as well. If try A6 it still allows AAAA records to be set by client machines.
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder
Nicholas F Miller
If wanted to only allow machines in an Active Directory the ability to update their 'A' records shouldn't I be able to use a statement like this:
update-policy {
grant <REALM> ms-self * A;
}
For some reason the only thing that works is setting a grant ANY and then restricting records with a deny before the grant statement. This seems like overkill if all I want to allow is 'A' records.
Also, it appears that you cannot deny 'AAAA' and allow 'A'. Any time I set a deny for 'AAAA' it also blocks 'A' records.
Are these bugs or by design?
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder
Nicholas F Miller
>
Is there a bug in the implementation of the update-policy or do I not have a grasp on how it should work?
If wanted to only allow machines in an Active Directory the ability to update their 'A' records shouldn't I be able to use a statement like this:
update-policy {
grant <REALM> ms-self * A;
}
For some reason the only thing that works is setting a grant ANY and then restricting records with a deny before the grant statement. This seems like overkill if all I want to allow is 'A' records.
Also, it appears that you cannot deny 'AAAA' and allow 'A'. Any time I set a deny for 'AAAA' it also blocks 'A' records.
Are these bugs or by design?
>
_________________________________________________________
Nicholas Miller, ITS, University of Colorado at Boulder