Problems with Bind-Kerberos-Windows-Linux
Jürgen Dietl
Hello,
I am trying to allow the DNS-Client to do dynamic updates at the DNS-Server using BIND. I want to use Kerberos as the security protocol. For that I have a small test lab with a client, 3 Kerberos Server and one Suse Linux DNS-Server. The 3 Kerberos-Server are emulated with using VM-Ware.
The Kerberos-Client gets the TGT from the Kerberos-Server. As I understand it should use this TGT for requesting further services via an AP-Request.
Cached TGT:
ServiceName: krbtgt
TargetName: krbtgt
FullServiceName: xxxgsstsig
DomainName: TEST.LOC
TargetDomainName: TEST.LOC
AltTargetDomainName: TEST.LOC
TicketFlags: 0x40e00000
KeyExpirationTime: 1/1/1601 1:00:00
StartTime: 12/6/2010 4:18:37
EndTime: 12/6/2010 14:18:37
RenewUntil: 12/10/2010 17:18:37
TimeSkew: 1/1/1601 1:00:00
I have read that there is a special mode called User-To-User Mode. This mode enables the client to ask for a service direct without asking for a TGT before. I found out that my client use this special user-to-user mode. I don’t know why.
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: 6082047d06092a864886f71201020201006e82046c308204...
krb5_blob: 6082047d06092a864886f71201020201006e82046c308204...
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: TEST.LOC
Server Name (Service and Instance): DNS/scdns14p.test.loc
Name-type: Service and Instance (2)
Name: DNS
Name: scdns14p.test.loc
enc-part des-cbc-md5
Encryption type: des-cbc-md5 (3)
Kvno: 3
enc-part: bfd012cc83e2e0050400b56aa8dd50a2404896871830e9f0...
Authenticator des-cbc-md5
Encryption type: des-cbc-md5 (3)
Authenticator data: 249c7a63fd5d9c84137f9dbdfa78eeee10e04fe0d6a5b0cd...
Is this a wanted behavior?
The client has an entry in the AD with DNS/test...@TEST.LOC. The Client, DNS-Server, Kerberos-Server all have a copy of the krb5.keytab. If I do a kinit -k -t c:\krb5.keytab DNS/test...@TEST.LOC then all seem to be ok. I get this message from the DNSserver: 03-Dec-2010 10:42:00.451 general: debug 3: gss cred: "DNS/test...@TEST.LOC", GSS_C_ACCEPT, 4294962027. But when the client do it from its own I get this message from the DNS-Server: 03-Dec-2010 10:42:00.451 general: debug 3: failed gss_accept_sec_context: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Wrong principal in request.
I have installed Bind V 9.7.2 (so the newest) and all PCs are running NTP for time synchronisation.
Any help would be greatly appreciated
Cheers,
Juergen
Phil Mayers
> I have read that there is a special mode called User-To-User Mode. This
> mode enables the client to ask for a service direct without asking for a
That's not quite how u2u works.
> TGT before. I found out that my client use this special user-to-user
> mode. I don’t know why.
No. Your client is using SPNego and offering u2u as a *possible*
mechanism to be negotiated.
> 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*)
>
> Is this a wanted behavior?
Yes. That's how spnego works. I'm willing to bet the server does not
actually *pick* u2u - but the client can do it, so offers it during
negotiation.
I can't help you with your wider question I'm afraid; I don't really
understand what you're asking. But the user2user stuff is a red herring
and can be ignored.
Jürgen Dietl
thanx for your answer.I dont know really what the server offers because I dont get a valid response:
Frame 2475: 168 bytes on wire (1344 bits), 168 bytes captured (1344 bits)
Ethernet II, Src: xxxxxxxxxxxxxx, Dst: Vmware_xxxxxxxxxxxxxxxxx
Internet Protocol, Src: xxxxxxxxxxxxxxxx, Dst: xxxxxxxxxxxxxxxx
Transmission Control Protocol, Src Port: domain (53), Dst Port: 60357 (60357), Seq: 1, Ack: 1390, Len: 114
Domain Name System (response)
[Request In: 2473]
[Time: 0.001913000 seconds]
Length: 112
Transaction ID: 0x43cf
Flags: 0x8080 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
Queries
788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d: type TKEY, class IN
Name: 788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d
Type: TKEY (Transaction Key)
Class: IN (0x0001)
Answers
788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d: type TKEY, class ANY
Name: 788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d
Type: TKEY (Transaction Key)
Class: ANY (0x00ff)
Time to live: 0 time
Data length: 26
Algorithm name: gss-tsig
Signature inception: Jan 1, 1970 01:00:00.000000000 Mitteleuropäische Zeit
Signature expiration: Jan 1, 1970 01:00:00.000000000 Mitteleuropäische Zeit
Mode: GSSAPI
Error: Bad key
The Log-File from the DNS-SUSE-Server tells me "wrong principal". Is there a way to find out what principal it expects?
thanx a lot,
cheers,
Juergen
GSS-API Generic Security Service Application Program InterfaceMechType: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - *User to User*)
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)
Yes. That's how spnego works. I'm willing to bet the server does not actually *pick* u2u - but the client can do it, so offers it during negotiation.
Is this a wanted behavior?
I can't help you with your wider question I'm afraid; I don't really understand what you're asking. But the user2user stuff is a red herring and can be ignored.
_______________________________________________
bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Phil Mayers
> The Log-File from the DNS-SUSE-Server tells me "wrong principal". Is
> there a way to find out what principal it expects?
You can configure it:
tkey-domain "YOUR.DOMAIN";
tkey-gssapi-credential "DNS/hostname.your.domain";
(I've never managed to make this work under bind, FWIW. Even when I did
get the kerberos working, the ms-self ACL turns out to be useless in a
disjoint domain environment)
Jürgen Dietl
thanx again for your answer. So I read between the lines that even if there were bugfixes for GSSTSIG in Bind V. 9.7.2 - it dont work. So we have to wait until MS follow the standards? :-)
Forgive me but what is a disjoint domain environment?
thanx a lot,
cheers,
Juergen
Jürgen Dietl
grats for sending it from your iPhone :-) But is there any message missing?
thanx a lot and have a nice day
cheers,
Juergen
From: Nevarez, Noe (DNSLB-NETWORKS) <noe.n...@hp.com>
Date: 2010/12/6
Subject: Re: Problems with Bind-Kerberos-Windows-Linux
To: Jürgen Dietl <juerge...@googlemail.com>
Regards,
Noe N.
HP Hostmaster
Sent from my iPhone.
On Dec 6, 2010, at 10:02 AM, "Jürgen Dietl" <juerge...@googlemail.com<mailto:juerge...@googlemail.com>> wrote:
Hello Phil
thanx again for your answer. So I read between the lines that even if there were bugfixes for GSSTSIG in Bind V. 9.7.2 - it dont work. So we have to wait until MS follow the standards? :-)
Forgive me but what is a disjoint domain environment?
thanx a lot,
cheers,
Juergen
The Log-File from the DNS-SUSE-Server tells me "wrong principal". Is
there a way to find out what principal it expects?
You can configure it:
tkey-domain "YOUR.DOMAIN";
tkey-gssapi-credential "DNS/hostname.your.domain";
(I've never managed to make this work under bind, FWIW. Even when I did get the kerberos working, the ms-self ACL turns out to be useless in a disjoint domain environment)
_______________________________________________
bind-users mailing list
<https://lists.isc.org/mailman/listinfo/bind-users>https://lists.isc.org/mailman/listinfo/bind-users
<ATT00001..txt>
Sergiu Bivol
> DNS-Server, Kerberos-Server all have a copy of the krb5.keytab. If I do a
> kinit -k -t c:\krb5.keytab DNS/test...@TEST.LOC then all seem to be ok. I
> get this message from the DNSserver: 03-Dec-2010 10:42:00.451 general: debug
> 3: gss cred: "DNS/test...@TEST.LOC", GSS_C_ACCEPT, 4294962027. But when the
> client do it from its own I get this message from the DNS-Server:
> 03-Dec-2010 10:42:00.451 general: debug 3: failed gss_accept_sec_context:
> GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more
> information, Minor = Wrong principal in request.
Normally you need 2 kerberos principals, one for the DNS Server, one for the client.
If kinit above works on the DNS Server box, and you can see these messages at startup BIND is configured correctly.
27-Sep-2010 18:26:47.860 acquiring credentials for DNS/test.loc
27-Sep-2010 18:26:47.860 gss cred: "DNS/test...@TEST.LOC", GSS_C_ACCEPT, 4294967295
You still need to configure update-policy to allow your client to update DNS, but that is another issue.
A GSS-TSIG-enabled DNS client would request TGT (as a different Kerberos user/principal), then TGS to use the DNS Service identified by the DNS/test...@TEST.LOG service principal. With this it should be able to update the DNS server, as long as DNS Server validates the client's ticket and the policy allows the update.
I hope your understanding is the same, it just wasn't clear from your message.
Regards
Sergiu
Phil Mayers
> Hello Phil
> thanx again for your answer. So I read between the lines that even if
> there were bugfixes for GSSTSIG in Bind V. 9.7.2 - it dont work. So we
> have to wait until MS follow the standards? :-)
That's not what I said.
>
> Forgive me but what is a disjoint domain environment?
domain: EXAMPLE.COM
hostname: host.subdomain.example.com
Bind seems to have trouble in this case.
Jürgen Dietl
many thanx for your hint. This I was asking me too for some time. Because the TGT is for the client name (principal) that is logged in at the moment and the service should be always for the same principal name on any client. So yes I will need to define 2 principals.
You wrote:
You still need to configure update-policy to allow your client to update DNS, but that is another issue.
thanx a lot,
cheers,
Juergen
Chris Buxton
> Hello Serjiu,
> many thanx for your hint. This I was asking me too for some time. Because the TGT is for the client name (principal) that is logged in at the moment and the service should be always for the same principal name on any client. So yes I will need to define 2 principals.
>
> You wrote:
> You still need to configure update-policy to allow your client to update DNS, but that is another issue.
>
> Do you mean the policy in the active directory? Btw. did you try to do it your own and succeeded?
No, he meant the update-policy statement in named.conf, which sets who can update what in the zone.
Chris Buxton
BlueCat Networks
Jürgen Dietl
I tried to put in 2 credential Entries in the named.conf:
tkey-gssapi-credential "DNS/test.loc"; (that was in before)
tkey-gssapi-credential "USER/test.loc", (new entry)
tkey-domain "TEST.LOC";
The system didnt like the second entry for the user. So how can I put in 2 credentials, or maybe where to put them?
Another problem with 2 Principal name is that the User Principal is of course different on any pc.
Thanx a lot for your help,
cheers,
From: Sergiu Bivol <sbi...@bluecatnetworks.com>
Date: 2010/12/6
Subject: Re: Problems with Bind-Kerberos-Windows-Linux
> DNS-Server, Kerberos-Server all have a copy of the krb5.keytab. If I do a
> kinit -k -t c:\krb5.keytab DNS/test...@TEST.LOC then all seem to be ok. I
> get this message from the DNSserver: 03-Dec-2010 10:42:00.451 general: debug
> 3: gss cred: "DNS/test...@TEST.LOC", GSS_C_ACCEPT, 4294962027. But when the
> client do it from its own I get this message from the DNS-Server:
> 03-Dec-2010 10:42:00.451 general: debug 3: failed gss_accept_sec_context:
> GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more
> information, Minor = Wrong principal in request.
If kinit above works on the DNS Server box, and you can see these messages at startup BIND is configured correctly.
27-Sep-2010 18:26:47.860 acquiring credentials for DNS/test.loc
27-Sep-2010 18:26:47.860 gss cred: "DNS/test...@TEST.LOC", GSS_C_ACCEPT, 4294967295
Sergiu Bivol
> a lot of configuration and sniffering etc. I looked in google for hours but
> I could not find anyone that says - yes it works.
It does work, but setting it up is very-very painful. Even if you do get it working, and document every step, a slightest mistake is at least an hour or two spent in troubleshooting. When configured properly it works, with a few limitations (in 9.7.2 at least).
>Do you mean the policy in the active directory?
No, I meant the update-policy option in BIND. It allows you to grant/deny ddns update permission to kerberos principals.
>Btw. did you try to do it your own and succeeded?
Yes, we succeeded and got GSS-TSIG in BIND working with Windows clients, Windows DHCP, and implemented our own GSS-TSIG client.
Regards
Sergiu
Jürgen Dietl
thanx to all that helped me. Problem solved.
The main reason was this posted by phil
1. Ensure there is a prinicpal in your kerberos realm "DNS/hostname.domain.com", matching the hostname of your DNS server
This is why I always got a wrong principal name.
Have a nice weekend,
cheers,
Juergen