안전한 LDAP 인증 문제

Question

Server1 및 Server2의 ASP.NET 4 (4.0.30319) 응용 프로그램 풀에 배포 된 웹 폼의 코드에서 다음 C# 코드를 사용하고 있습니다.

PrincipalContext pc = new PrincipalContext(ContextType.Domain, "testnet.testad.org:636", "dc=testnet,dc=testad,dc=org"); 
bool validated = pc.ValidateCredentials(username, password, ContextOptions.Negotiate); 

서버 1이 실행되는 : 윈도우 서버 2003 SP2
는 ASP.NET 버전 4.0.30319

그것은 옵션에 따라 인증 30 ~ 60 초까지 걸리는 6.0
IIS.
는 (참고 : 지연없이 즉시 인증 일반 LDAP 사용)

서버 2가 실행 : 윈도우 서버 2008 SP2
은 IIS 7.0
ASP.NET 버전 4.0.30319

동일한 실행 코드는 Server1로, Server2는 거의 즉시 인증합니다.
(동일한 결과를 가진 다른 IIS 7.0 서버에 대한 코드도 시도했습니다.)

누구든지이 문제를 전에 경험해 봤습니까?
IIS 7.0 서버 대 IIS 7.0 서버에서 인증하는 다른 방법이 있습니까?
구성, 추가, 제거 등의 작업이 필요합니까?

감사합니다.

.............................................. .................................................. ..............................................

[업데이트]

ldaps 인증 요청을하는 동안 wireshark를 사용하도록 설정했습니다.
나는 636
을 통해 모든 요청을 포함하는 파일을 만든 그것은 여기 볼 수 있습니다 : Server1 636 traffic

가장 큰 차이는 사이에 발견된다 :

번호 1949 1.115583 초에서 - 제 06788 14.501754 초에 14.64297 초에서
및
호 6803-27.921379 초

해당 포트에서 다른 모든 트래픽을 11742 호 동일한 초 내에 발생한다.

참고 : Server2에는 대략 동일한 양의 트래픽이 있지만 모두 2 ~ 3 초 사이에 발생합니다.
은 여기에서 볼 수 있습니다 :

프로토 로컬 주소 외국인 주소 상태 PID
TCP 10.1.72.74:1761을 : 내가 로그인 할 때 Server2 636 traffic

내가 LDAPS에 대해 다음 연결에서 netstat -ano "명령을 실행 발견 10.1.72.54:636 설립 3688
TCP 10.1.72.74:1800 10.1.72.54:636 확정 3688
TCP 10.1.72.74:1825 10.1.72.54 : 636 ESTABLISHED 3688

Answer 1

ServerFault에서 내 대답 좀보세요 ...

C : \ 문서 및 설정 \ 모든 사용자 \ 응용 프로그램 데이터 \ 마이크로 소프트 \ 암호화 \ RSA \ MachineKeys

멘션 :

이 서비스에 액세스하지 못할 수 있습니다

날짜 : 3/25/2013 시간 : 10:11:06 AM 출처 : Schannel "SSL 클라이언트 자격 증명에 액세스 할 때 치명적인 오류 이 (가) 발생했습니다. 키.

가능성이 있습니다.

Answer 2

지원되는 SSL/TLS 버전을 확인하려면 레지스트리 키 항목을 확인하십시오. 핸드 셰이크 문제가 발생할 수있는 문제는 ... 몇 가지 관련 시나리오 컨트롤 \ SecurityProviders \ SCHANNEL \ 프로토콜

\

HKEY_LOCAL_MACHINE을 \ 시스템 \ CURRENTCONTROLSET (아래 링크에서 시나리오 5 참조)과 해상도가 읽기의 troubleshooting ssl related issues server certificate

Answer 3

PrincipalContext의 방법 ValidateCredentials 방법은 기본적으로 LDAP 바인딩 작업에 대한 래퍼입니다. 이 두 가지 핵심 기사는 IADsOpenDSObject::OpenDSObject과 LDAP ADsPath입니다.

SSL을 사용하고 있으므로 최대한 효율적으로 사용하려면 SSL을 사용하고 있어야합니다.

이

하나 이상의 ContextOptions 열거의 조합이 서버에 바인딩하는 데 사용되는 옵션 값 :이이 기능을 지원하지 않습니다처럼 ValidateCredentials 방법의 ContextOptions 인수에 대한 문서는 실제로 소리가 난다. 이 매개 변수는 SSL이 있거나없는 단순 바인딩 또는 바인딩 협상 만 지정할 수 있습니다.

제가 설명서를 잘못 해석하고있어 및 ValidateCredentials 방법은 정말 지원이 Negotiate | SecureSocketLayer 지정 않는다고 가정 할 때, 당신은 당신이 이름을 보내는 방법에 대해 살펴해야합니다. OpenDSObject 기사에서는 사용자 이름의 형식에 대한이 조언을 제공 :

1. 사용자 계정의 이름과 같은 "jeffsmith : 다음 문자열 중 하나로서 lpszUserName에 통과 할 수

   ". 사용자 이름을 단독으로 사용하려면 lnReserved 매개 변수에 ADS_SECURE_AUTHENTICATION 플래그 만 설정해야합니다.

2. "Fabrikam \ jeffsmith"와 같은 이전 버전의 Windows NT에서 사용자 경로.

3. "CN = Jeff Smith, OU = Sales, DC = Fabrikam, DC = Com"과 같은 고유 이름. DN을 사용하려면 lnReserved 매개 변수가 0이어야합니다. 그렇지 않으면 ADS_USE_SSL 플래그가 포함되어야합니다.

4. "jeffsmith@Fabrikam.com"과 같은 UPN (User Principal Name). UPN을 사용하려면 대상 사용자 개체의 userPrincipalName 특성에 적절한 UPN 값을 할당해야합니다. 당신이 2, 3 또는 4

   P.S.를 사용하는 그래서

당신은 SSL 플래그를 설정하는 예제 코드에서는 생성자에서 도메인의 DNS 이름을 지정합니다. 실제 코드로 서버를 지정하려면 ServerBind 플래그를 추가해야합니다.