2

この文書によると：

http://msdn.microsoft.com/en-us/library/ff647405.aspx

web.configで次を設定しました

<authentication mode="Windows" />
<identity impersonate="false" />

また、IIS Express 7.5 の applicationhost.config にもこれを設定しました。

<anonymousAuthentication enabled="false" userName="" />

<windowsAuthentication enabled="true">
  <providers>
    <add value="Negotiate" />
    <add value="NTLM" />
  </providers>
</windowsAuthentication>

ただし、System.Threading.Thread.CurrentPrincipal.Identity は常に、認証されたユーザーの Windows ID と等しくなります。つまり、IISExpress.exe が実行されているアカウント (開発者アカウント) ではありません。

明確にするために、私はアカウント A としてログインし、IIS Express はアカウント A として実行されますが、アカウント B (HttpWebRequest で資格情報を設定) を使用して Web サービスを呼び出しますが、サーバー側のコードはアカウント B として実行されます。スレッドにはこの ID があり、ネットワーク リソースにアクセスできます。

アカウント A (および製品サーバーではサービス アカウントとして) として実行し、必要な場合にのみ偽装したいと考えています。

私は何か間違ったことをしていますか、それともこの領域は IISX で完全に実装されていませんか?

ありがとう

ルーク

更新 1

それで、何が起こっているのか理解できたと思いました。以下の私の答えを見てください。問題は、逆に動作しているように見えることです!

string n1 = System.Security.Principal.WindowsIdentity.GetCurrent().Name;    // Runtime account.
string n2 = System.Threading.Thread.CurrentPrincipal.Identity.Name;         // Calling account.

var winId = (System.Security.Principal.WindowsIdentity)HttpContext.Current.User.Identity;
System.Security.Principal.WindowsImpersonationContext ctx = null;
try
{
    bool b = System.IO.File.Exists(@"d:\p\p.txt");    // true (!)

    using (ctx = winId.Impersonate())
    {
        // Now impersonating. Access (local) resources using the identity of the authenticated user.

        n1 = System.Security.Principal.WindowsIdentity.GetCurrent().Name;   // Calling account.
        n2 = System.Threading.Thread.CurrentPrincipal.Identity.Name;        // Calling account.

        b = System.IO.File.Exists(@"d:\p\p.txt");     // false (!)
    }
...

フォルダー d:\p は、呼び出し元のアカウント アクセスのみを許可するように設定されています。DOS でテストした場合は問題ありませんが、私の Web サービスからはアクセスできます。これは、スレッドに呼び出し元のセキュリティ コンテキストがあるためだと思います。なりすまし始めました！

さらに奇妙なことに、なりすましをすると、突然アクセスできなくなります。

適切な IIS 7.5 サーバーでテスト プロジェクトを作成し、これが IIS Express のバグであるかどうかを確認します。

更新 2

Exists テストの問題は半分解決されました。フォルダーへの権限を削除しましたが、ファイル自体にはまだいくつかの権限があり、.NET がフォルダーをトラバースせずにファイルにアクセスする方法は、引き続きアクセスできることを意味します。

今私は得る

b == false // as expected.
...
b == false // unexpected, after impersonation I should be able to see this file.

なりすましによってアクセスできると思っていましたが、そうではありません。

アップデート 3

私は断念しました。なりすましは機能せず、ネットワーク ポリシーまたは発見できない隠し設定であるとしか考えられません。

4

1 に答える 1

2

とった。ある種。

string n1 = System.Security.Principal.WindowsIdentity.GetCurrent().Name;
string n2 = System.Threading.Thread.CurrentPrincipal.Identity.Name;

n1=プロセスIDn2=呼び出し元のID

スレッドのセキュリティコンテキストには、私が予期していなかった呼び出し元のIDがあります。スレッドにはプロセスのコンテキストが流れていると思いましたが、これは明らかにそれがどのように機能するかではありません。

発信者のWindowsIdentityで.Impersonateを呼び出すと、呼び出し元のアカウントに許可されているローカルファイルにアクセスできないという興味深い状況になりましたが、それを解決して回答を更新します。

質問の更新を参照してください

于 2012-07-24T15:11:09.293 に答える