11

これが私がやろうとしてきたことです

フォーム認証と Active Directory メンバーシップを使用して ASP.NET MVC 3 アプリケーションを構築します。Web サーバーとデータベースは異なる物理サーバーであるため、ダブルホップです。

答えは、制約付き委任とプロトコル移行に関するこの古い記事だと思いましたか? これまでのところ、私はそのテクニックを機能させることができませんでした。

実稼働セットアップで Windows 2008 (IIS7) に展開する前に、Web サーバー用の DEV マシン (Windows 7、IIS7) からこれをテストしています。Windows 2008 は違いをもたらしますか?

何が機能し、何が失敗するか

フォーム認証と AD メンバーシップでログインできます。これはうまく機能しているようです。このコードを使用してデータベース呼び出しを実行しようとすると:

public void AsUser(Action action)
    {
        using (var id = new WindowsIdentity(User.Identity.Name + @"@example.com"))
        {
            WindowsImpersonationContext context = null;
            try
            {
                context = id.Impersonate();
                action.Invoke();
            }
            catch (Exception ex)
            {
                // ex.Message is The type initializer for System.Data.SqlClient.SqlConnection threw an exception
                // buried inner exeption is Requested registry access is not allowed
            }
            finally
            {
                if (context != null)
                {
                    context.Undo();
                }
            }
        }
    }

例外が発生し、ローカル DEV サーバーにセットアップの問題があると思い込んでしまいます。内部例外はRequested registry access is not allowed.

ブレークポイントを設定し、呼び出しWindowsIdentity後にを調べると、が に設定されていることがわかります。これは、正しくセットアップされていないという手がかりのようです。誰でも確認できますか？Impersonate()ImpersonationLevelIdentification

私は正しい軌道に乗っていますか?これはセットアップすることさえ可能ですか? 任意のポインタをいただければ幸いです。

4

5 に答える 5

5

あなたは正しい軌道に乗っていると思います。プロトコル移行のセットアップに関するトラブルシューティング作業がさらに必要です。

Active Directory メンバーシップ プロバイダーを正しく構成して、Active Directory のユーザー名とパスワードを使用して Web ページに正常にログオンできることを前提としています。そうでない場合は、私の回答の残りを無視してください:)

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

ドメイン内で 1 台のマシンにプロトコル遷移を許可することは、非常に高い特権であることを理解する必要があります。サーバーにプロトコル移行を許可するということは、そのサーバーがほとんどドメイン コントローラーのようであると信頼していることを意味します。サーバーにこの機能を持たせるには、AD でこの決定を意識的に行う必要があり、この変更を行うにはドメイン管理者である必要があります。これを行っていない場合は、おそらく適切に設定していません。

確認すべき点がいくつかあります。

最初に、[指定されたサービスへの委任に対してのみこのコンピューターを信頼する] を選択したことを確認し、サービス アカウントで [任意の認証プロトコルを使用する] を選択したことを確認します。ドメイン アカウントを作成することをお勧めします。 ASP.NET のサービス アカウントを作成する方法に関するリンクを次に示します。ドメイン アカウントが必要です。ドメイン サービス アカウントを作成したら、そのアカウントの [委任] タブに移動し、正しいオプションを選択したことを確認してください。

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

3 番目に、Kerberos 委任を無効にするものがないことを確認する必要があります。一部の重要な AD アカウントは、デフォルトで委任が許可されていません。たとえば、組み込みの管理者アカウントです。したがって、テスト目的で他の通常のユーザー アカウントを使用することをお勧めします。

アップデート

ASP.NET のプロトコル移行をセットアップする方法を説明する別の記事を見つけました。Impersonationタイプ WindowsIdentityを作成できることを確認するために、IIS サービス アカウントに TCB 権限を付与する必要があると記載されています。あなたはそれを試してみることができます。

于 2011-02-22T07:06:31.343 に答える
1

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

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

これは、匿名アクセスまたは偽装がオフの場合には発生しません。その場合、IIS が認証を処理し、ローカル アクセスまたはネットワーク アクセスに別のユーザーを使用するためです。これは、アプリ プール ID または匿名ユーザーが最初のホップとしてネットワーク呼び出しを行うことができることを意味します。

最初の接続以外に資格情報を渡すことができないことは明らかだと思います。

于 2011-02-22T17:57:01.483 に答える
1

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

于 2011-02-21T19:31:47.013 に答える
1

偽装が許可されているかどうかについても、AD 管理者に確認する必要があります。私の会社の AD ポリシーでは、なりすましは許可されません。

于 2011-02-21T19:49:07.657 に答える