Problems with Bind-Kerberos-Windows-Linux

Jürgen Dietl juergen.dietl at
Mon Dec 6 14:20:22 UTC 2010


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: (SPNEGO - Simple Protected

                    Simple Protected Negotiation


                            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. (KRB5 -
Kerberos 5 - *User to User*) <---------



                                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


                                        Tkt-vno: 5

                                        Realm: TEST.LOC

                                        Server Name (Service and Instance):

                                            Name-type: Service and Instance

                                            Name: DNS

                                            Name: scdns14p.test.loc

                                        enc-part des-cbc-md5

                                            Encryption type: des-cbc-md5 (3)

                                            Kvno: 3


                                    Authenticator des-cbc-md5

                                        Encryption type: des-cbc-md5 (3)

                                        Authenticator data:

Is this a wanted behavior?

The client has an entry in the AD with DNS/test.loc at 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.loc at 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.loc at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the bind-users mailing list