2

クライアントが統合 Windows 認証を必要とするシステムがあります。これは、Sql Server 2005 に接続する ASP.NET 3.5 アプリケーションです。Web サーバーは Server 2003 R2 SP2 です。db サーバーは Server 2003 SP2 (R2 ではありません) です。

dbサーバーで、次のスクリプトを実行しました

exec sp_grantlogin 'myDomain\myUserGroup'
USE myDbName
exec sp_grantdbaccess 'myDomain\myUserGroup'

現在、Windows ユーザー グループ「myDomain\myUserGroup」に 3 人のユーザーがいます。3 人のユーザーのアカウントはすべて、委任に対して信頼済みとしてマークされています。AD の Web サーバー アカウントは、委任に対して信頼できるとマークされています。

Web アプリケーションは、Windows 認証を使用するようにマークされています (その他はすべてオフになっています)。web.config には次の行があります。

<authentication mode="Windows" ></authentication>
<identity impersonate="true" />
<authorization>
    <deny users="?"/>
</authorization>

しかし、ユーザー グループに属するユーザーで Web アプリケーションに接続しようとすると、次のエラーが表示されます。

System.Data.SqlClient.SqlException: 
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

私の接続文字列は、次のように構築された Sql ConnectionStringBuilder から構築されています。

ConnectionStringBuilder.DataSource = "MYDBSERVER"
ConnectionStringBuilder.InitialCatalog = "MYDBCATALOG"
ConnectionStringBuilder.IntegratedSecurity = True

許可されたアカウントの1つをweb.config <identity />行で偽装するようにハードコードすると、機能します。しかし、ハード コードされたアカウントを削除して、クライアントのマシンから ID を渡そうとすると、. エラーが発生します。

そのため、マルチホップ統合ログイン シナリオ用に何かが正しく構成されていないようですが、何がわかりません。

前もって感謝します！

4

2 に答える 2

3

ASP マシンは、NTLM/Kerberos 経由で IIS に接続するユーザーを認証しました。認証は、元のユーザー プロセス (IE) に、彼の身元を保証するシークレット (ボックスにログインしたときに入力したパスワード) を提示するよう要求したドメイン コントローラーによって保証されます。認証は、実際には関係するプロセスではなく、関係する各マシンのローカル セキュリティ機関 (LSA、別名 lsass.exe) によって行われます。ASP マシン上の LSA は認証が OK であることを認識しているため、リモート ユーザーのなりすましが、その LSA の制御下でアクセス権を持つすべてのもの (つまり、ローカル ASP マシン上のすべてのもの) にアクセスすることを許可します。 ）。

ユーザーを偽装する ASP プロセスが新しいマシンに別のホップを行うとすぐに、ASP マシン上の LSA によって制御される領域を離れます。SQL マシン上の LSA には、ASP マシン上の LSA を信頼する理由はありません。そのため、偽装されたユーザーであるという証拠を提示するように求めます。残念ながら、ASP マシンはユーザー シークレット (パスワード) を持っていないため、そのような証明を提示できません。

回避策は、「制約付き委任」と呼ばれるものです。制約付きの委任を通じて、ドメイン コントローラは SQL のマシン LSA と ASP マシンの LSA の間のネゴシエーションに介入し、「ASP マシンは問題ありません。彼を保証します」と言います。そのため、SQL のマシン LSA は認証を信頼し、元の偽装ユーザーを認証します。

制約付き委任を設定する方法の技術的な詳細については、「方法: ASP.NET 2.0 でプロトコル遷移と制約付き委任を使用する」を参照してください。

これは、関係するリソースの種類 (SQL サーバー、ファイル共有、新しいバックエンド ASP サービスなど) に関係なく、'ダブル ホップ' と偽装が関係する場合に常に当てはまることに注意してください。

于 2009-07-13T22:18:38.887 に答える
2

Windows 認証を使用している場合、偽装は ASP.NET プロセス自体を通過しません。ここには 2 つのオプションがあります。ID が流れる基本認証に切り替えるか、Win2003 以降で実行している場合は、Kerberos といくつかのハッカーを使用して、接続時に偽装することができます。

于 2009-07-13T21:25:42.783 に答える