Hello Phil, <br>thanx for your answer.I dont know really what the server offers because I dont get a valid response:<br><br><br><br>Frame 2475: 168 bytes on wire (1344 bits), 168 bytes captured (1344 bits)<br>Ethernet II, Src: xxxxxxxxxxxxxx, Dst: Vmware_xxxxxxxxxxxxxxxxx<br>
Internet Protocol, Src: xxxxxxxxxxxxxxxx, Dst: xxxxxxxxxxxxxxxx<br>Transmission Control Protocol, Src Port: domain (53), Dst Port: 60357 (60357), Seq: 1, Ack: 1390, Len: 114<br>Domain Name System (response)<br> [Request In: 2473]<br>
[Time: 0.001913000 seconds]<br> Length: 112<br> Transaction ID: 0x43cf<br> Flags: 0x8080 (Standard query response, No error)<br> 1... .... .... .... = Response: Message is a response<br> .000 0... .... .... = Opcode: Standard query (0)<br>
.... .0.. .... .... = Authoritative: Server is not an authority for domain<br> .... ..0. .... .... = Truncated: Message is not truncated<br> .... ...0 .... .... = Recursion desired: Don't do query recursively<br>
.... .... 1... .... = Recursion available: Server can do recursive queries<br> .... .... .0.. .... = Z: reserved (0)<br> .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server<br>
.... .... ...0 .... = Non-authenticated data: Unacceptable<br> .... .... .... 0000 = Reply code: No error (0)<br> Questions: 1<br> Answer RRs: 1<br> Authority RRs: 0<br> Additional RRs: 0<br> Queries<br>
788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d: type TKEY, class IN<br> Name: 788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d<br> Type: TKEY (Transaction Key)<br> Class: IN (0x0001)<br>
Answers<br> 788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d: type TKEY, class ANY<br> Name: 788-ms-7.78-fb5adae.7b80ec04-febd-11df-18a0-00505699419d<br> Type: TKEY (Transaction Key)<br>
Class: ANY (0x00ff)<br> Time to live: 0 time<br> Data length: 26<br> Algorithm name: gss-tsig<br> Signature inception: Jan 1, 1970 01:00:00.000000000 Mitteleuropäische Zeit <br>
Signature expiration: Jan 1, 1970 01:00:00.000000000 Mitteleuropäische Zeit <br> Mode: GSSAPI<br> Error: <b>Bad key</b><br> <br>The Log-File from the DNS-SUSE-Server tells me "wrong principal". Is there a way to find out what principal it expects?<br>
<br>thanx a lot,<br>cheers,<br>Juergen<br><br> <br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
GSS-API Generic Security Service Application Program Interface<br>
OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)<br>
Simple Protected Negotiation<br>
negTokenInit<br>
mechTypes: 3 items<br>
MechType: 1.2.840.48018.1.2.2 (MS KRB5 - Microsoft Kerberos 5)<br>
MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos 5)<br></div>
MechType: 1.2.840.113554.1.2.2.3 (KRB5 - Kerberos 5 - *User to User*)<br>
</blockquote><div class="im">
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Is this a wanted behavior?<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
_______________________________________________<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote>No. Your client is using SPNego and offering u2u as a *possible* mechanism to be negotiated.<br></div><br>