2011-09-07 4 views
9

PrincipalContext.ValidateCredentials을 사용하여 이상한 행동을 보았습니다. 이 설정은 상위/하위 설정의 두 Active Directory 도메인입니다 (주 도메인이 company.com이고 하위 도메인이 development.company.com).ValidateCredentials는 알 수없는 사용자에게 true를 반환합니까?

기본 도메인에 대한 자격 증명의 유효성을 검사 할 때 ValidateCredentials은 예상대로 작동하고 올바른 사용자/전달 쌍에 대해 true를 반환하고 다른 것에 대해서는 false를 반환합니다.

그러나 하위 도메인에서 사용자의 유효성을 검사하면 좋은 사용자 이름/비밀번호와 유효하지 않은 사용자 모두에 대해 ValidateCredentials이 true를 반환합니다. 유효한 사용자에게 잘못된 암호를 제공하면 올바르게 false가 반환됩니다.

이제는 UserPrincipal.FindByIdentity()을 먼저 수행하고 사용자가있는 경우 ValidateCredentials을 호출합니다. 그러나 나는 무슨 일이 일어나는지 알고 싶습니다.

나는 MSDN entry for ValidateCredentials statesdomain\username로 이름을 통과하는 것입니다 검토 한 다른 해결 방법 :이 기능의 각 버전에서

, 사용자 이름 문자열은 중 하나에 서로 다른 다양한 형식이 될 수 있습니다 . 허용되는 형식 유형의 전체 목록을 보려면 ADS_NAME_TYPE_ENUM 설명서를 참조하십시오.

...이 형식의 사용자 이름이 나열됩니다. 그러나 이것은 ValidateCredentials는 관계없이 항상 내가 전달 사용자 이름과 암호의 어떤 조합, true를 반환하지됩니다

관련 코드는 다음과 같습니다

bool authenticated = false; 

// Various options tried for ContextOptions, [etc] inc. explicit username/password to bind to AD with -- no luck. 
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, domain, null, ContextOptions.Negotiate, null, null)) 
{ 
    log(pc.ConnectedServer + " => " + pc.UserName + " => " + pc.Name + " => " + pc.Container); 
    using (var user = UserPrincipal.FindByIdentity(pc, IdentityType.SamAccountName, username)) 
    { 
     if (user != null) 
     { 
      log(user.DistinguishedName + "; " + user.DisplayName); 
      authenticated = pc.ValidateCredentials(username, password); 
     } else { 
      log("User not found"); 
      // Debug only -- is FindByIdentity() needed. This should always return 
      // false, but doesn't. 
      authenticated = pc.ValidateCredentials(username, password); 
     } 
    } 
} 
return authenticated; 

모든 모든 (분별) 제안 환영 - 난. 그냥 내 모든 기대에 어긋나게 내 머리를 긁적.

내가 추가해야 할 사항 : 이것은 내 컴퓨터에서 실행되고 있으며 둘 다 기본 도메인의 구성원입니다. 그러나 나는 또한 정확히 동일한 결과를 가진 하위 도메인 (runas /user:subdomain\user cmd)의 사용자로 내 컴퓨터의 명령 프롬프트에서 실행 해 보았습니다.

+0

두 도메인이 있습니다. 내 도메인의 IP 주소를 사용하여 유효성 검사 자격 증명을 호출 할 수 있으며 두 도메인의 사용자 이름 또는 비밀번호를 전달하면 성공합니다. 나는이 여분의 정보를 제공 할 필요가 없다는 것에 놀라움을 금치 못합니다. 그리고 나서 올바른 도메인에서 올바른 사용자의 유효성을 확인하는 방법을 조금 혼란스럽게 생각합니다. (각각이 jsmith를 말할 수는 없습니까?) – Greg

답변

16

Google 검색 중 일부가 나중에 (이 검색 어쨌든 Google에서 하루 종일 검색 중이었던 것은 아니지만) found the answer입니다.

간단히 말해 도메인에서 Guest 계정을 사용하는 경우 ValidateCredentials는 알 수없는 사용자에 대해 TRUE를 반환합니다. development.company.com에서 게스트 사용자의 상태를 확인한 결과 계정이 사용 설정되어 있는지 확인했습니다. 게스트 계정을 사용하지 않도록 설정 한 경우 ValidateCredentials는 false를 올바르게 반환합니다.

이것은 상당히 근본적인 문제입니다.이 동작에 관심이 있는지는 확실하지 않습니다. 불행히도 MSDN에서는 명시 적으로 언급하지 않았습니다.

+0

와우 ... 큰 보안 구멍이 될 수있는 쉬운 실수입니다. 답변 해주셔서 감사합니다! –

+2

AD API는 왜 그렇게 뇌가 죽었습니까? –

+0

5 년이 지난 사례는 여전히 동일합니다. 'principalContext.ValidateCredentials ("blah", "blah", ContextOptions.Negotiate)'가'true '를 반환하는 것을 보면서 깜짝 놀랐습니다. – trailmax

0

은이 this과 관련이있을 수 :

있는 ValidateCredentials 방법은 생성자에 지정된 서버에 바인딩합니다. username 및 password 매개 변수가 null 인 경우 생성자에 지정된 자격 증명의 유효성이 검사됩니다. 자격 증명이 생성자에 지정되어 있고 사용자 이름과 암호 매개 변수가 null 인 경우이 메서드는 현재의 기본 자격 증명의 유효성을 검사합니다.

+0

아니요 ... 밝혀진대로 도메인 수준 게스트 계정이 활성화되었습니다. 사용하지 않으면 ValidateCrendentials이 올바른 작업을 수행합니다. (그리고 전형적으로, 응답을 찾으려고 노력하는 대부분의 날 이후, 나는 이것을 게시 한 후 20 분을 대답한다). –

+0

예, 항상 케이스 :) – TheCodeKing

관련 문제