IIS 7.5のWebサイトの[基本設定]セクションには、Connect As...
を介してユーザーアカウントを指定するオプションがあります。これをオフにすると、パススルー認証が使用されます。
アプリケーションプールのIDを使用すると想定しましたが、そうではありませんでした。私のWebサイトが正しいユーザーアカウントでMSSQLに接続できるようにするには、Connect As...
画面でユーザーを指定する必要がありました。
では、Connect As...
とアプリケーションプールIDの違いは何ですか?
これは推測するこれは、ネットワークを介してアプリケーションプールIDを偽装するコンピューターの機能に関連している可能性があります。 「接続」には資格情報が保存(および暗号化)されているため、完全なプライマリトークンを作成し、そのユーザーIDとしてリソースにアクセスできます。 「アプリケーションユーザー(認証のパススルー)」では、それは既存のトークンであり、なりすましにそのトークンを使用しようとします。そのシナリオでは、偽装を実行しているコンピューターが委任に対して信頼されていない場合、成功しません。
これはテストと検証が簡単にできるはずです。
コンピューターは委任に対して信頼されていますか? [Active Directoryユーザーとコンピューター]> [コンピューター]> [プロパティ]> [委任]タブで。 [このコンピュータを委任に対してすべてのサービスに信頼する(Kerberosのみ)]を選択します。
IIS7構成設定 "useAppPoolCredentials"を設定する必要がある場合もあります。これは、次のコマンドで設定できます。
appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication -useAppPoolCredentials:true
useAppPoolCredentials = True、2008年にKerberos委任を使用
https://blogs.technet.com/b/proclarity/archive/2011/03/08/useapppoolcredentials-true-with-kerberos-delegation-on-2008.aspx
おそらく関連しています:
https://stackoverflow.com/questions/3775569/help-with-kerberos-authentication-in-iis-7
アプリケーションプールIDを、基本設定でログインしてパススルー認証を有効にできるユーザーアカウントに設定しているにもかかわらず、MSSSQLサーバー接続文字列に統合セキュリティを使用しているときに次のエラーが発生する理由を発見しましたウェブサイトの:
Microsoft SQL Server Native Client 10.0エラー '80040e4d'
ユーザー「NT AUTHORITY\ANONYMOUS LOGON」のログインに失敗しました。
[認証]に移動し、匿名ユーザーを編集します-デフォルトのIUSRアカウントの使用からアプリケーションプールIDの使用に変更します。