원격 IIS 서버에 연결할 때 "액세스가 거부되었습니다"- C#

Question

IIS 5.1에서 실행중인 C# 응용 프로그램에서 원격 IIS 6 서버에 연결하려고하면 "액세스가 거부되었습니다"COMException이 발생합니다.

아이디어가 있으십니까? 나는 원래의 질문에 대해 똑같은 문제를 겪고있다.

업데이트 - 4/1/09

나는 시작하고 웹 사이트를 중지하는 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 서버에 관리자 그룹에 추가 된 활성 디렉터리 그룹의 구성원입니다.

이 문제가 발생하거나 해결 방법을 알고있는 사람이 있습니까?

UPDATE :

@Kev는 - 그것은 ASP.NET 응용 프로그램입니다. 또한 IIS6 관리자를 통해 원격 서버에 사용자 이름과 암호없이 연결할 수 있습니다.

@Chris - 가상 디렉터리 수를 표시하고 각 디렉터리의 .NET Framework 버전을 확인하기 위해 원격 서버에 연결하려고합니다. 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
로그 오프 : UNT : ASPNET
소스 워크 스테이션 :
오류 코드 : 0xC0000234

두 번째 이벤트 :

이벤트 범주 : 로그온/로그 오프
이벤트 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 응용 프로그램을 설정 한 다음 IIS5.1 웹 사이트의 system.web에서 impersonation을 사용하도록 web.config에 다음을 추가 할 수 있습니다.

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

Answer 6

이중 홉 문제 일 수 있습니다. NTLM을 사용하여 웹 사이트의 현재 사용자로 가장하는 경우 해당 서버 (이 경우 IIS 5.1 서버)에서만 해당 가장이 유효합니다. 웹 사이트를 사용하여 다른 서버에 연결하려고하면 토큰을 가장 (impersonation) 중에 사용 된 다른 서버로 전달할 수 없으므로 실제로 문제가 발생할 것입니다. 다른 컴퓨터로 이동하여 컴퓨터를 통해 사이트를 디버깅하는 경우에도 마찬가지입니다. 로컬 시스템이 사용자를 인증하지만 사용자를 다른 서버로 가장 할 수는 없습니다.

내가 과거에 사용한 모든 솔루션은 권한이있는 계정을 사용하도록 앱 풀을 하드 코딩해야합니다. 계정을 다른 컴퓨터에 대한 권한이있는 도메인 계정에 연결하거나 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를 사용 믿습니다. 이것은 당신이 묘사 한 행동과 일치하는 것 같습니다. 광고 작업을 위해, 우리는 이런 이유로 결코 사용하지 않습니다.