問題タブ [spn]

この質問により、noidentity が指定された場合のデフォルトの動作は ですhost/myhostname。

しかし、これは完全に真実ではないようです。

ID を指定しないと機能しない SOAP WCF サービス (Dynamics NAV Web サービスですが、質問は完全にクライアントの視点に関するものであるため、これは次の場合は問題になりません) があります。

サーバーは実際にはドメイン ユーザー アカウントで実行されています。 host/myhostnameが指定されていますが、このユーザー アカウントではなく、マシン アカウントに対してのみ指定されています。 http/myhostnameがこのドメイン ユーザー アカウントに指定されています。

3 つのシナリオを見てみましょう。

ID が指定されていません

EndpointAddress次のコードで作成します。

このシナリオでは、次のことが起こっています。

• ヘッダーなしの HTTP POST Authorization 。
• で応答しWWW-Authenticate: Negotiateます。
• ヘッダー付きの HTTP POST Authorization: Negotiate XXX。XXXで始まる 1584 の BASE64 エンコード バイト96 130 6です。その中に読み取り可能なASCIIが見つかりません。
• Authorization: Negotiate XXXヘッダー付きの応答。XXX126 BASE64 でエンコードされたバイトです。その中に読み取り可能なASCIIが見つかりません。
• ヘッダー付きの HTTP POST Authorization: Negotiate XXX。XXX1527 BASE64 でエンコードされたバイトです。その中に読み取り可能なASCIIが見つかりません。
• WWW-Authenticate: Negotiate XXXヘッダー付きの応答。XXX113 BASE64 でエンコードされたバイトです。その中に読み取り可能なASCIIが見つかりません。
• この時点で、クライアントは例外をスローします。内部例外メッセージはThe target principal name is incorrect.

ID を手動でhost/myhostnameまたは間違った文字列に設定します。

次のコードで EndpointAddress を作成します。

がデフォルト設定である場合host/myhostname、上記のコードはこのデフォルト設定を明示的に指定するだけです。したがって、同じ動作が期待されます。しかし、これは機能します。NTLMにフォールバックしているようです。だから違いがあるに違いない。

これが起こっていることです：

• ヘッダーなしの HTTP POST Authorization 。
• で応答しWWW-Authenticate: Negotiateます。
• Authorization: Negotiate XXXXXX が 40 BASE64 でエンコードされたバイトであるHTTP POST 。最初のバイトは ASCII 文字NTLMSSPです。
• WWW-Authenticate: Negotiate XXXXXX が 270 BASE64 でエンコードされたバイトである場合の応答。最初のバイトは ASCII 文字NTLMSSPです。また、FQDN は ASCII としてエンコードされているようです。
• を含む HTTP POST。XXX はAuthorization: Negotiate XXX、BASE64 でエンコードされた 590 バイトです。今回はASCII文字はありません。
• ペイロードでの応答。

興味深い事実: ID を間違った文字列に指定すると、まったく同じ動作になります。たとえば、次のEndpointAddressコードで を指定すると、次のようになります。

NTLM へのフォールバックでも上記の動作が得られます。

IDを正しく設定しましたhttp/myhostname

設定されている SPN を指定すると、 RFC 4559http/myhostnameにより正しい選択と思われます。これは構成です:

そして、これが起こっていることです：

• ヘッダーなしの HTTP POST Authorization 。
• で応答しWWW-Authenticate: Negotiateます。
• ヘッダー付きの HTTP POST Authorization: Negotiate XXX。XXX は 1580 BASE64 でエンコードされたバイトです。ASCI サインはありません。
• ペイロードでの応答。

この質問は、それを機能させるための熱意ではなく、理解に関するものです。私を混乱させているのは、最初の例と2番目の例の違いです。私の考えは次のとおりです。

1. デフォルトの ID が の場合host/myhostname、
2. に ID を手動で指定しても違いはありませんhost/myhostname。
3. しかし、違いがあります
4. したがって、これをデフォルトの ID にすることはできません。

だから私の質問は

1. 実際のデフォルトの動作は何ですか。
2. http/myhostnameRFC4559 が原因で、デフォルトの SPN として選択されないのはなぜですか?

そして/または私は何か完全に間違っていることを理解しましたか?

SSO プロジェクトに Kerberos 認証を統合しています。奇妙なシナリオに出くわしました。

新しいユーザーを作成し、SPN をアタッチしました。この質問の手順に従い、すべてが機能しました。私が意味するすべてによって:-

1. kinit ユーザー名 - 次にパスワードを入力すると、チケットが保存されたというメッセージが表示されました。
2. kinit spn(int 形式の HTTP/FQDN) - 次にパスワードを入力すると、チェックが保存されたというメッセージが表示されました。

しばらくして、これをもう一度やり直すことにしたので、コマンドを使用しました

ユーザー名から spn を切り離します。次に、このユーザー (ユーザー名) を AD から削除しました。

次に、username1 という新しいユーザーを作成し、この質問に従って、この新しいユーザーに対して上記の手順と同じ spn を登録しました。

kinit username1 - パスワードを入力するとチケットが保存されたというメッセージが表示されましたが、kinit spn - パスワードを入力するとエラーが発生しました

別の（新しい）spnを使用すると、すべてが正常に機能することに注意してください。

問題は、Windows サーバーに特定のキャッシュがあり、このキャッシュが原因でこの spn を再度使用できないリンクがまだ存在するかどうかです。または、spn をユーザーから切り離す際に間違いを犯しましたか?

ありがとう、ニキル