2

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

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

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

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

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

ID が指定されていません

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

new EndpointAddress(new Uri(endpoint))

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

  • ヘッダーなしの 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 を作成します。

var identity = EndpointIdentity.CreateSpnIdentity(@"host/myhostname");
var endpointAddress = new EndpointAddress(new Uri(endpoint), identity);

がデフォルト設定である場合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コードで を指定すると、次のようになります。

var identity = EndpointIdentity.CreateSpnIdentity(@"thisIsTotallyWrongLoremIpsum");
var endpointAddress = new EndpointAddress(new Uri(endpoint), identity);

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

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

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

var identity = EndpointIdentity.CreateSpnIdentity(@"http/myhostname");
var endpointAddress = new EndpointAddress(new Uri(endpoint), identity);

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

  • ヘッダーなしの 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 として選択されないのはなぜですか?

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

4

1 に答える 1

4

問題文の最後に 2 つの質問がありました。それらを以下にリストします。

Q. 1) 実際のデフォルトの動作は何ですか?

A. ID が指定されておらず、クライアント資格情報の種類が Windows の場合、デフォルトは SPN で、サービス エンドポイント アドレスのホスト名部分に "host/" リテラルがプレフィックスとして付けられた値が設定されます。この設定は、サービスがいずれかのシステム アカウントまたは関連付けられた SPN 名を持つドメイン アカウントで実行されており、コンピューターが Active Directory 環境内のドメインのメンバーである場合に、Windows Kerberos セキュリティを利用します。

Q. 2) RFC4559 により、http/myhostname がデフォルトの SPN として選択されないのはなぜですか?

A. Web ブラウザでは、http/myhostname として接続します。ただし、WCF クライアントの場合、既定では、上記のように host/myhostname として接続します。ID を host/myhostname に設定するシナリオ #2 では、間違いなく host/myhostname に接続します。

上記の Q1 と Q2 の参照:サービス ID と認証

コメント: NTLM へのフォールバックは、さまざまな理由で発生します。それを理解する方法は、Kerberos が失敗した理由を理解することです。SPN の問題が主な原因です。SPN の問題を診断するための優れたリファレンスは、Brian Murphy-Booth のブログ - 最大の間違い: ServicePrincipalNameです。

Brian Murphy のブログを調べたところ、最初の質問者は、問題のシナリオ内でポートが使用されていることを発見しました。「SPNが自動的に決定される場合、ポートは使用されません。したがって、http: //foo.example.com:1234はSPNとしてhost/foo.example.comにつながります。SPNが存在しない場合、NTLMにフォールバックしますSPN が存在するが適切なユーザーのものではない場合、The target principal name is illegal 例外がスローされます。"

于 2016-12-08T12:44:04.067 に答える