誰でも以下の行の機能を説明できますか:
WindowsIdentity wId = (WindowsIdentity)HttpContext.Current.User.Identity;
WindowsImpersonationContext wIdCon = wId.Impersonate();
これは、IIS 基本認証を使用した POST メソッドで使用され、正常に機能します。ただし、IIS 認証が Windows に設定されている場合、上記は機能しなくなります。
例としてダンプするにはコードが多すぎます。
への呼び出しImpersonate()により、IIS はその時点から要求しているユーザーのふりをします。これは多くの理由で役立ちますが、主に、要求しているユーザーがアクセスを拒否されていない場合にのみ後続のコードが機能するためです。
ウェブサイトにはユーザー名とパスワードが与えられているため、ユーザーとしてログインできるため、これは基本的に機能します。kerberos を使用し、ユーザーのパスワードではなく、ユーザーを参照するチケットのみが与えられるため、Windows 認証は失敗します。
Windows 認証を機能させるには、Web サイト アカウント (アプリケーションのアプリ プール ID であるアカウント) がユーザーを偽装できるようにする必要があります。これは、Active Directory のアカウントの委任タブで行われます。
委任タブがない場合は、最初に SPN (サービス プリンシパル名) を追加する必要があります。SPN により、クライアントは Web サイトを実行しているアカウントを認識できるため、Web サイトがそれを開くことができるように kerberos チケットに暗号化する方法を知ることができます。これはすべて、クライアントとサーバーがサードパーティ (標準の MS 実装の AD サーバー) を信頼している限り、お互いにパスワードを伝え合うことなく会話できるようにする方法です。
これはすべて、kerberos ダブル ホップとして知られる一般的な問題の一部です。これはすべて、クライアントから Web サイトへの Kerberos が機能する (Web サイトはページを提供するためのクライアント ユーザーの資格情報について十分に認識している) という事実に起因していますが、Web サイトから Web ユーザーの資格情報を必要とするリソースへの 2 番目のホップが提供されていません。ウェブサイトのアカウントが許可されていないためです。詳細については、msdn の Understanding-kerberos-double-hop を参照してください
編集：
setspn /q http/machine_name_or_fqdnたとえば実行してみてください
setspn /q http/mywebbox
setspn /q http/mywebbox.my.domain.com
これらの spn はどのユーザーに対して設定されていますか? IIS には、SPN と同じユーザーとして実行されている Web サイト用の appPool が必要です。
それを確認したら、フィドラーツールを使用して、クライアントとサーバーの間で何が渡されているかを確認することをお勧めします。401 エラー応答が返されていることを確認し (つまり、認証が必要です)、すぐに要求を再試行します。有効な kerberos ヘッダー。
kerberos を介してクライアントからサーバーへの通信を確立したら、AD で appPool アカウントがユーザーに代わって委任できるように設定されていることを確認する必要があります。