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@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.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
