Problems with Bind-Kerberos-Windows-Linux

[Jürgen Dietl]

Hello Phil,
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 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.
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
No. Your client is using SPNego and offering u2u as a *possible* mechanism
to be negotiated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20101206/e7bffc73/attachment.html>