4

Web クライアントから呼び出す ASMX Web サービス (ローカルホスト - WinXP IIS 5.1) があります。私の Web サービスは、別の ASMX Web サービスを使用する必要があります (Win 2003 サーバー IIS 6.0 上)。

「ハードコーディングされた」方法で Web サービス コードに資格情報を提供すると、次のようになります。

engineWSE.Credentials = new System.Net.NetworkCredential("myUser", "myPass", "myDomain");

...その後のリモート Web サービスの呼び出しは正常に機能します

今、私はいくつかの初期テストで自分自身になりすまそうとしています。これについての私の最初の読書は、これが大きな主題になる可能性があることを私に教えてくれますが、ここに私が手始めにやったことがあります:

  1. ローカルホストの WebClient サイトの仮想ディレクトリで、チェックされていない「匿名アクセス」

  2. 私の webclient サイトの web.config で、次のように設定しました: authentication mode="Windows" and identity impersonate="true"

  3. リモート サービスを呼び出す必要がある Web サービスの Web メソッドで、次のように変更しました。

    engineWSE.Credentials = System.Net.CredentialCache.DefaultCredentials;
    
  4. これらの DefaultCredentials でリモート Web サービスが呼び出されると、次のエラーが発生します。

    System.Web.Services System.Web.Services.Protocols.SoapException: サーバーは要求を処理できませんでした.--->

    System.Net.WebException: HTTP ステータス 401 で要求が失敗しました: 権限がありません。

    System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse (SoapClientMessage メッセージ、WebResponse 応答、ストリーム responseStream、ブール値の asyncCall) で

    System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke (メソッド名の文字列、オブジェクト [] パラメーター) で

私が誤解して「なりすまし」を過度に単純化しようとしたのか、それともリモート Web サービスが 3 つの引数 (つまり、ユーザー名、パスワード、ドメイン) を持つ資格情報のみを受け入れるように配線されているのかはわかりません。

4

5 に答える 5

3

@Michael Levy が言ったように、これはダブルホップの問題です。これが意味することは、Kerberos (ネゴシエート) を構成しない限り、NTLM はおそらく IIS を実行している Windows 環境で使用され、マシン A にブラウザーを搭載したクライアントがマシン B の Web サイトにアクセスしようとすると、サイトにアクセスできることになります。サイトはマシン C のサービスに接続しようとするため、代わりにプール資格情報を使用する必要があります。

Web サイト A がサービス B を呼び出し、サービス B がサービス C を呼び出す場合も同様です。

Web サイト用に Kerberos を構成する場合、複数のことを考慮する必要があります。1つ目は、農場かどうかを知ることです。そうである場合は、ファームのすべてのマシン部分のプールに共通のユーザーを定義する必要があります。これは、Kerberos がドメイン名を使用してセキュリティ トークンの暗号化に使用されるプリンシパルを識別するために必要です。同じエントリ。詳細については、Kerberos と負荷分散に関するこちらを参照してください。

たとえば、URL が myApp.intranet のサイトがあるとします。AD では、たとえばドメイン MyDomain の myUser に SPN を設定します (setspn -S MyDomain\myUser HTTP/myapp.intranet)。要求が KDN に送信されると (KDN の詳細については、最後の kerberos リンクを参照してください)、常に myUser で暗号化されたトークンが返されますが、IIS は別のユーザーでそれを復号化しようとします。同じサービス (HTTP/myapp.intranet) に対して複数の SPN を作成したくなるかもしれませんが、これにより KRB エラーが発生します。

また、IIS 7 以降を使用している場合、カーネル モード認証を有効にしておく場合は、ApplicationHost.config に少し詳細を設定する必要があります (これを強くお勧めします): useAppPoolCredentials =true. この値は、configuration\system.webServer\security\authentication\windowsAuthentication で設定する必要があります。これは、デフォルトで、カーネルモード認証がプール アカウントではなくコンピュータ アカウントを使用するためです。これにより、マルチユーザー シナリオに戻ることになります。

いずれの場合も、AD プリンシパルの[Delegation] タブの [Trust this user for ...]を有効にして、委任を機能させる必要があります。次に、一般委任と制約付き委任のどちらを使用するかを決定する必要があります。

前述したように、適切なユーザーと適切なサービスの SPN も設定する必要があります。ユーザーは、プールで定義したユーザーであるため、非常に簡単に識別できますが、構成によってはサービスが少し複雑になる場合があります。DNS、ブラウザ、およびおそらくその他の変数によって、使用すべきものが変わる可能性があります。私たちの試行錯誤は、次のことを示しています。

  • DNS エントリが A エントリの場合は、それを直接使用します
  • エントリが CName の場合、テストでは、それに関連付けられた A エントリが使用されました。
  • CName が使用されるケースがあり、ブラウザのバージョンに関連しているように見えました。

SPN が明確に設定されておらず、NetBIOS 名を介して Web サイトにアクセスする場合、HTTP/マシン サービスが要求され、デフォルトでHOST サービス (extra を検索)が HTTP の代わりに使用される可能性があるため、HOST/マシン使用されます。これは、小規模なネットワークで簡単に構成するのに役立ちます。

また、NTLM から Kerberos に移行する際のダウンタイムを制限したい場合は、最初に ApplicationHost を変更してから、SetSPN を使用する必要があることにも注意してください。アクションの前にネゴシエートを無効にして、すべてがセットアップされるまで NTLM のみを保持し、可能であれば、ネゴシエートのみを有効にすることもできます (NTLM なし)。これにより、クライアントは Web サイトへのアクセス方法を変更する必要があります。これを行わないと、キャッシュ メカニズムがしばらくの間 NTLM のままになりがちです。

これが役立つことを願っています。それでも Kerberos の構成に問題がある場合は、WireSharkが最も信頼できる友人です。次のページで Kerberos をデバッグする方法に関する情報を見つけることができます: - Web サイトの Kerberos をデバッグする - Kerberos に関するAD の問題をデバッグする(最大トークン サイズはそれらの 1 つです) - Kerberos ツールとその他のリンク -一般的なネットワーク キャプチャ Kerberos のデバッグ

于 2014-05-05T15:10:32.873 に答える
1

クレデンシャルが渡されていることを確認するためにnetmonまたはwiresharkを使用しましたか?サービスプロバイダーのログから何がわかりますか?また、web.config(または他の.config)に偽装タグが構成されていないことを確認してください。

編集:

HostingEnvironment.Impersonate()ブロックは、おそらく-デフォルトでアプリプールのID、または渡したユーザートークンのIDを利用します。

于 2009-04-07T22:47:09.850 に答える
1

これは典型的なダブル ホップの問題です。ドメインで Kerberos 委任が適切に構成されていない限り、なりすましによって取得したユーザー資格情報を使用して別のサーバーにアクセスすることはできません。この質問の複製

于 2011-12-19T12:47:19.760 に答える
0

@MichaelKniskern-HTTPで確かに可能です。偽装機能は、ASP.NetアプリからIISに資格情報を渡します。統合Windows認証を使用すると、デフォルトのASPNETアカウント(またはアプリプールに接続されているアカウント)の代わりに、エンドユーザーの資格情報が使用されます。そのMSDNの記事でのHTTPとFTPへの言及は、DefaultNetworkCredentialsに向けられたと私は信じています。

于 2009-04-17T17:29:14.683 に答える
0

次の MSDN の記事によると、HTTP および FTP プロトコルでは機能しません。リモート サーバーに接続するときは、資格情報を明示的に指定する必要があります。

于 2009-04-08T00:38:01.300 に答える