フォーム認証で認証されたクライアントを偽装し、SQL Serverへの信頼できる接続を確立することはできますか？ここで

Question

私は、フォーム認証とActive Directoryのメンバーシップを持つASP.NET MVC 3アプリケーションをビルド

をやろうとしていたものです。 Webサーバーとデータベースは異なる物理サーバーなので、ダブルホップです。

答えは、この古い記事constrained delegation and protocol transitionでしたと思いましたか？これまでのところ、私は技術を働かせることができませんでした。

プロダクションセットアップでWindows 2008（IIS7）にデプロイする前に、WebサーバーのDEVマシン（Windows 7、IIS7）からテストしています。窓2008は違いをもたらすだろうか？

何動作し、私は、フォーム認証とADのメンバーシップでログインすることができるよ

を失敗しました。これは正常に動作しているようです。このコードを使用してデータベース・コールを作成しようとすると、次のような例外が発生します。内部例外はRequested registry access is not allowedです。

私がブレークポイントを設定し、Impersonate()コール後にWindowsIdentityを調べると、ImpersonationLevelがIdentificationに設定されていることがわかります。これは正しく設定されていないという手がかりのようです。誰でも確認できますか？

私は正しい軌道に乗っていますが、セットアップすることも可能ですか？すべてのポインターをいただければ幸いです。

Answer 1

あなたは正しい方向にいると思います。プロトコル移行セットアップでは、さらに多くのトラブルシューティング作業が必要です。

アクティブディレクトリのメンバー名とパスワードを使用してWebページに正常にログオンできるように、Active Directoryメンバーシッププロバイダを正しく設定したと仮定します。そうでない場合は、私の答えの残りの部分を無視してください:)

私はあなたの質問で見たものから、あなたはWindowsIdentityによってS4USelfを使用してユーザーのトークンを取得しました。次に、S4UProxyを使用して、偽装されたトークンをSQLサーバーに渡します。あなたはImpersonationLevel.Identificationしか持っていないと言っていたので、あなたはプロトコルの移行に失敗したことになります。

ドメイン内で1つのマシンでプロトコルを変更できるようにするには、非常に高い特権が必要です。サーバーにプロトコルの移行を許可するということは、ほとんどの場合、そのサーバーをドメインコントローラーのように信頼することを意味します。あなたは意識してこの能力を持つようにサーバーを回すために、この決定をADで行う必要があり、この変更を行うにはドミニオンの管理者でなければなりません。あなたがこれをやっていないなら、あなたはおそらくあなたのものを適切にセットアップしていないでしょう。

いくつか確認する必要があります。

まず、「指定したサービスのみに委任するようにこのコンピュータを信頼する」を選択してから、サービスアカウントで「任意の認証プロトコルを使用」を選択したことを確認してください。ドメインアカウントを作成することができます。 Hereは、ASP.NETのサービスアカウントを作成する方法に関するリンクです。ドメインアカウントが必要です。ドメインサービスアカウントを作成したら、そのアカウントの委任タブに移動し、正しいオプションを選択してください。

第2に、SPNが正しく設定されていることを確認する必要があります。あなたが投稿したリンクには、ASP.NETサービスアカウントのSPNのみが記載されています。実際には、SQLサーバーのサービスアカウントも正しく設定されていることを確認する必要があります。その他、WindowsではKerberos認証をまったく使用しません。それはNTLMを使用するために使用されます。 SQLサーバーにSPNを正しく設定するには、多くの詳細があります。最初にhereをチェックして運があるかどうか確認することができます。私の経験から、DBAの大半は正しく設定する方法を知らない。 NTLMではほとんどのアプリケーションが正常に動作するため、認識していません。使用しているSQLサーバーサービスアカウントとポート番号に注意する必要があります。

第3に、Kerberos委任を無効にすることがないことを確認する必要があります。機密性の高い一部のADアカウントは、デフォルトで委任されません。たとえば、組み込みの管理者アカウントです。だから、テスト目的のために他のいくつかの普通のユーザーアカウントを使うのが良いでしょう。

UPDATE

私はどのようにセットアップASP.NETのためのプロトコル遷移をするあなたを教えanother articleを見つけました。 ImpersonationタイプのWindowsIdentityを作成できるようにするには、IISサービスアカウントにTCB権限を与える必要があると述べました。あなたはそれを撃つことができます。

Answer 2

Windows 7またはWindows 2008マシンで偽装を有効にしましたか？この記事では、この設定方法について説明します。 http://technet.microsoft.com/en-us/library/cc730708(WS.10).aspx。また、32ビットまたは64ビットを実行していますか？

Answer 3

また、偽装が許可されているかどうかを広告管理に確認する必要があります。私の会社の広告ポリシーは偽装を許可しません。

Answer 4

ここではクラスを使用します。また、AppPoolが実行されているプロセスが、そのような特権アクティビティであるため、偽装を実行するための十分な権限を持っているかどうかを確認して確認する必要があります。私は、アプリケーションプールが一時的な管理者特権（もちろん、devボックスのみ）の下で実行されていることをユーザーアカウントに伝え、それが動作するかどうかを確認して、アクセス権の問題であるかどうかを確認します。

public class ImpersonationHelper : IDisposable 
    { 
     private const int LOGON32_LOGON_INTERACTIVE = 2; 
     private const int LOGON32_PROVIDER_DEFAULT = 0; 
     private WindowsImpersonationContext _impersonationContext; 
     private string _userName; 
     private string _domain; 
     private string _password; 

     [DllImport("advapi32.dll")] 
     public static extern int LogonUserA(String lpszUserName, 
      String lpszDomain, 
      String lpszPassword, 
      int dwLogonType, 
      int dwLogonProvider, 
      ref IntPtr phToken); 
     [DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)] 
     public static extern int DuplicateToken(IntPtr hToken, 
      int impersonationLevel, 
      ref IntPtr hNewToken); 

     [DllImport("advapi32.dll", CharSet = CharSet.Auto, SetLastError = true)] 
     public static extern bool RevertToSelf(); 

     [DllImport("kernel32.dll", CharSet = CharSet.Auto)] 
     public static extern bool CloseHandle(IntPtr handle); 

     public ImpersonationHelper(string domain, string userName, string password) 
     { 
      _userName = userName; 
      _domain = domain; 
      _password = password; 
     } 

     public void Start() 
     { 
      WindowsIdentity tempWindowsIdentity; 
      IntPtr token = IntPtr.Zero; 
      IntPtr tokenDuplicate = IntPtr.Zero; 

      if (RevertToSelf()) 
      { 
       if (LogonUserA(_userName, _domain, _password, LOGON32_LOGON_INTERACTIVE, 
        LOGON32_PROVIDER_DEFAULT, ref token) != 0) 
       { 
        if (DuplicateToken(token, 2, ref tokenDuplicate) != 0) 
        { 
         tempWindowsIdentity = new WindowsIdentity(tokenDuplicate); 
         _impersonationContext = tempWindowsIdentity.Impersonate(); 
         if (_impersonationContext != null) 
         { 
          CloseHandle(token); 
          CloseHandle(tokenDuplicate); 
         } 
        } 
       } 
      } 
      if (token != IntPtr.Zero) 
       CloseHandle(token); 
      if (tokenDuplicate != IntPtr.Zero) 
       CloseHandle(tokenDuplicate); 
     } 

     #region IDisposable Members 

     void IDisposable.Dispose() 
     { 
      if (_impersonationContext != null) 
      { 
       _impersonationContext.Undo(); 
      } 
     } 

     #endregion 
    } 

Answer 5

あなたは問題を特定したと思いますが、誰もそれを言及していないと思います。 「ダブルホップ」の問題では、これを行うことはできません。不可能です。 Scott Forsythのようにそれについて書いた人がたくさんいます。あなたが 最初の「ホップ」をアップし使用しています統合 認証を使用してIIS サーバに認証

。 IISが ネットワークデバイスにアクセスしようとすると、 が許可されていない ダブルまたはセカンドホップになります。 IISはこれらの資格情報を の資格情報を次のネットワーク デバイスに渡すことはできません。そうしないと、開発者または 管理者が 資格情報を悪用し、 サイト訪問者が予期しなかった方法で使用できます。

その場合にはIISがあなたを認証する の世話をし、それがローカルまたはネットワーク アクセスのための 別のユーザーを使用していますので、これは匿名 アクセスまたは オフ偽装では発生しません。これは、アプリケーションプール 身元または匿名ユーザーが最初のホップとして ネットワークコールを行うことができることを意味します。

私は、最初の接続よりもあなたの資格情報を引き継ぐことができないことは明らかです。