リモートIISサーバーに接続しようとすると「アクセスが拒否されました」 - C＃

Question

IIS 5.1で実行されているC＃アプリケーションからリモートIIS 6サーバーに接続しようとすると、「アクセスが拒否されました」COMExceptionが表示されます。

アイデア？私は元の質問と同じ問題をすべて経験しています。

アップデート - 4/1/09

私は、Webサイトを開始および停止するためにIISサーバーへの接続ウィンドウアプリケーションで構成され、この溶液（http://www.codeproject.com/KB/cs/Start_Stop_IIS_Website.aspx）を発見しました。ワークステーションで実行してIISサーバーに接続できます。

私はこのスタンドアロンアプリケーションを実行できますが、ASP.NETアプリケーションは実行できません。オリジナル

は、私はIISサーバーが有効であるかどうかを確認するためにDirectoryEntry.Existメソッドを使用してリモートマシンからIISに接続しようとすると、COMExceptionは、「アクセス拒否」を受信します。

string path = string.Format("IIS://{0}/W3SVC", server); 

if(DirectoryEntry.Exist(path)) 
{ 
    //do something is valid.... 
} 

私は、接続しようとしているIISサーバーに対してAdministratorsグループに追加されたアクティブなディレクトリグループのメンバです。

誰もこの問題を経験しており、解決方法を知っていますか？

UPDATE：

@Kev - それは、ASP.NETアプリケーションです。また、IIS6マネージャーを使用して、ユーザー名とパスワードなしでリモートサーバーに接続することもできます。

@Chris - リモートサーバーに接続して仮想ディレクトリの数を表示し、各ディレクトリの.NETフレームワークバージョンを確認しようとしています。 this SOの質問を参照してください。

@dautzenb - 私のASP.NETアプリケーションはIIS 5.1でIIS 6サーバーに接続しようとしています。リモートサーバー上のローカルASPNETアカウントのセキュリティログにフォルト監査が表示されます。アプリケーションをデバッグしようとすると、自分のドメインアカウントで実行されているにもかかわらず、アクセスが拒否されます。

public DirectoryEntry 
( 
    string path,  
    string username,  
    string password 
) 

しかし、すべてのプロパティが含まれている「例外を投げた：私は、次のオーバーロードを使用して、DirectoryEntryオブジェクトを作成するために確立することができました - @Kev

：UPDATE 2

タイプ 'System.Runtime.InteropServices.COMException'の "私は、アプリケーションをデバッグしている間。

また、AuthenticationTypeプロパティはSecureに設定されています。

UPDATE 3：

次の二つの失敗の監査エントリは、私が接続を確立しようとしたすべての時間をログに記録し、リモートIISサーバーのセキュリティイベントであった。

まずイベント：

イベントカテゴリ：アカウントログオン
イベントID：680
ログの書き込み元：MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
ログオンUNT：ASPNET
ソースワークステーション：
エラーコード：0xC0000234

2番目のイベント：

イベントカテゴリ：ログオン/ログオフ
イベントID：529
ログオン失敗：
理由：不明なユーザー名または悪いパスワード
ユーザー名：ASPNET
ドメイン：（MyDomain）
ログオンの種類：3
ログオンプロセス：NtLmSspこの
認証パッケージ：NTLM
ワークステーション名：（MyWorkstationId）
発信者ユーザー名： -
発信者ドメイン： -
呼び出し側ログオンID： -
呼び出し側プロセスID： -
移行されましたサービス： -
ソースネットワークアドレス：10.12.13.35
送信元ポート：1708

偽装がtrueに設定されており、ユーザー名とパスワードが空白です。リモートIISサーバー上のASPNETアカウントを使用しています。

Answer 1

正確にあなたも読もうとしていますか？あなたのアプリケーションと同じパスの下にありますか？

Answer 2

これはASP.NETアプリケーションなので、IISのアプリケーションプールで実行されます。このアプリケーションプールは、特定のユーザー（「ローカルシステム」、「ネットワークサービス」または別のユーザー）を使用して実行されます。

このユーザーは、リモートサーバーに接続するのに十分な権限を持っていますか？

See MSDN for more info.

Answer 3

私は一種のあなたは、この作業を取得することができない理由として、現時点では困惑。あなたの周りに一時的な試みがあります。 DirectoryEntryオブジェクトをインスタンス化するときは、次のコンストラクタのオーバーロードのいずれかを使用できます。

public DirectoryEntry(
    string path, 
    string username, 
    string password 
) 

はで文書化： MSDN: DirectoryEntry Constructor (String, String, String)

...か...私が同様のものを行うために、新しいプロジェクトのために私の仮想サーバーボックスのテストAD環境を構築しています偶然にもMSDN: DirectoryEntry Constructor (String, String, String, AuthenticationTypes)

：

public DirectoryEntry(
    string path, 
    string username, 
    string password, 
    AuthenticationTypes authenticationType 
) 

はで文書化。私がそれを立ち上げて走っているとき、あなたが直面している問題を再現できるかどうかを知るために遊びに行くでしょう。その間に、上で参照されたこれらのコンストラクタのオーバーロードを試すとどうなるかをお知らせください。 （マイケルズコメントへの答えで）

更新：

ちょうど今私を避ける理由から、我々は特定のシナリオでDirectoryEntry.Exists()を使用することができなかった、今、もう一度呼び出されるコードのこのスニペットがあります私たちのアプリの一つで：

public static bool MetabasePathExists(string metabasePath) 
{ 
    try 
    { 
    using(DirectoryEntry site = new DirectoryEntry(metabasePath)) 
    { 
     if(site.Name != String.Empty) 
     { 
     return true; 
     } 
     return false; 
    } 
    } 
    catch(COMException ex) 
    { 
    if(ex.Message.StartsWith("The system cannot find the path specified")) 
    { 
     return false; 
    } 
    LogError(ex, String.Format("metabasePath={0}", metabasePath)); 
    throw; 
    } 
    catch(Exception ex) 
    { 
    LogError(ex, String.Format("metabasePath={0}", metabasePath)); 
    throw; 
    } 
} 

あなたは上記のいずれかでコンストラクタを置き換えることができます。確かにそれは暗闇の中で刺すようです:)。

Answer 4

この問題が発生したとき、Windowsファイル共有で自分自身を認証するだけで問題が解決されたことがわかりました。経験から、私はWMI/ADSI/COMは認証されていないユーザーに対して大きなサポートをしていないと思います。この問題は、Windowsドメインに関連付けられていない場合に発生すると考えられます。

Answer 5

IDの問題が発生した場合は、Integrated Windows Authenticationを使用するようにIIS 5.1アプリケーションを設定してから、system.webのIIS5.1 Webサイトのweb.configに次のように追加してimpersonationを有効にすることができます。

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

Answer 6

これはダブルホップの問題のようです。 NTLMを使用してWebサイトの現在のユーザーを偽装している場合、その偽装はそのサーバー（この場合はIIS 5.1サーバー）でのみ有効です。 Webサイトを使用して別のサーバーに接続しようとすると、偽装中に使用された別のサーバーにトークンを渡すことができないため、実際に問題が発生します。別のボックスに移動して、マシンからサイトをデバッグしている場合も同様です。あなたのローカルマシンはあなたを認証していますが、あなたを別のサーバーに偽装することはできません。

私がこれまで使用してきたソリューションのすべてでは、アクセス許可を持つアカウントを使用するようにアプリケーションプールをハードコードする必要があります。アカウントを他のマシンのアクセス許可を持つドメインアカウントに追加するか、ドメインアカウントの下にあるIIS 5.1マシン上で実行されているWindowsサービスを使用して、別のサーバーに接続します。

Kerberosを使用している場合、これは適用されませんが、ADはデフォルトでNTLMを使用します。

Answer 7

実際にNTLMダブル・ホップの問題の場合は、SETSPNユーティリティを使用して、ターゲットIISサーバー用のサービス・プリンシパル・インスタンス・インスタンスを作成できます。

次に、Active Directoryに入り、コンピュータオブジェクト（基本的にはNETWORK SERVICEまたはLOCAL SERVICEプリンシパル）が、資格情報を正しく登録されたSPNに委任できるようにすることができます。

あなたはどこにでもホップホップすることができます！しかし、警告してください！あなたはダブルホップを有効にすると、人々は鋭い尖ったもので自分自身を傷つける可能性があります！読んで

グッドKB記事：

http://support.microsoft.com/kb/929650

Answer 8

私はDirectoryEntry.Existsは黙っ供給任意の資格情報を無視し、認証されたユーザのcredsをを使用していることを信じています。これはあなたが記述した動作と一致するようです。 ADの仕事のために、我々はこの理由のために決してそれを使用しません。