LDAP 보안 프로세싱의 이해
원문주소 : Understanding LDAP Security Processing
http://blogs.technet.com/askds/archive/2009/09/21/understanding-ldap-security-processing.aspx
랜디(Randy)입니다. 오늘은 LDAP 보안을 다루도록 하겠습니다. LDAP(Lightweight Directory Access Protocol)은 Active Directory 데이터베이스를 읽고 쓰는데 사용하는 인터페이스입니다. 따라서 Active Directory 관리도구(AD 사용자 및 컴퓨터, AD 사이트 및 서비스 등)나 타사의 관리도구는 도메인을 관리하기 위해 데이터베이스에 연결하는데 LDAP을 사용합니다. 아시는 것처럼 이 중요한 데이터베이스에 접근할 때 사용자를 인증하는 것은 윈도우 보안에 의존합니다. 이 데이터베이스에 접근하는 것은 도메인 컨트롤러에서 Ntdsa.dll로 나타나는 DSA(Directory System Agent)를 통해 제어합니다. Ntdsa.dll은 Lsass.exe로 동작하는 LSA(Local Security Authority)의 일부분으로 동작합니다.
접근 권한을 얻는 과정은 두 단계로 진행됩니다. 바로 인증과 권한부여입니다. 이 글에서는 인증부분을 자세히 살펴볼 것입니다(사용자의 신원을 확인하는 부분). 인증 절차에 대해 더 알고 싶다면, 보안 토큰에 대한 글을 참조하세요. Active Directory 데이터베이스의 객체는 다른 윈도우 객체와 같이 동일한 규칙을 따릅니다. Active Directory 데이터베이스의 객체는 인증된 사용자가 할 수 있는 권한와 특권을 포함하고 있습니다.
이 글에서는 Windows 2008에 있는 LDP.EXE 유틸리티를 통해 설명하겠습니다. 이 도구는 Active Directory에 연결하고, 바인드하고, 관리를 도와주는 클라이언트 GUI 도구입니다. LDAP 문제를 트러블슈팅하거나 네트워크 추적을 원하면 네트워크 모니터(Network Monitor)를 다운로드할 수 있습니다. LDP를 열고 Connection 메뉴의 "Connect…"를 선택하고 매개변수는 넣지 마세요.
그리고 "bind as currently logged on user"를 선택하세요.
시작을 하면 잘 동작하는 것을 확인할 수 있습니다. DC Locator process를 통해 대상 DC를 지정하지 않고 현재 도메인 컨트롤러에서 실행했고 현재 로그온한 사용자로 연결해서 윈도우에 포함된 보안 패키지를 사용했습니다. 네트워크 추적에서는 무엇을 볼 수 있을까요? Network Monitor 3.3을 열고 LDAP을 필터링해서 볼 수 있습니다.
접속하기 전에 왜 LDP.exe에서 결과를 얻을까요?
처음으로 볼 수 있는 트래픽은 많은 LDAP Search Requests와 Search Responses입니다. 설명은 Description 필드에서 볼 수 있습니다.
그러면 왜 LDAP을 바인드하기 전에 LDAP search request이 나타날까요? 왜냐하면 Active Directory 데이터베이스의 "RootDSE" 파티션에 처음 접근할 때, 이 DSA에 바인드하고 인증하는 규칙에 대한 정보를 쿼리하기 위해 익명으로 연결하기 때문입니다. 이 루트에는 익명 접근을 허용하지만, Windows Server 2003과 이후 버전은 Active Directory의 모든 다른 파티션에 익명 접근을 차단합니다. DSHeuristics 값을 변경하여 이 설정을 바꿀수 있습니다. 그러면 포레스트 전체에 있는 모든 도메인 컨트롤러에 변경됩니다.
LDAP search request의 상세정보를 살펴보면 LDAP request parameters가 "BaseDN: NULL"으로 나타납니다. "LDAP: Search Request"를 확장하고, "Parser: Search Request"를 확장하고, "Search Request"를 확장합니다.
"BaseDN"은 LDAP 쿼리에서 검색을 시작하는 컨테이너입니다. NULL은 도메인 컨트롤러의 RootDSE가 됩니다. 이것이 바인드하기 전에 LDP 유틸리티의 오른쪽 창에서 그런 결과가 나타나는 이유입니다.
"LDAP: Search Result"는 "LDAP: Search Result"를 확장하고, "Parser: Search Result"를 확장하고, "SearchResultEntry" 확장할 때와 같은 데이터를 보여줍니다.
네트워크 추적의 결과는 LDP.exe 결과 창에 나타난 것과 일치합니다. 중요한 정보 중 하나는 "supportedSASLMechanisms"입니다. 이것은 LDAP 바인드에서 사용할 수 있는 보안 매커니즘입니다. 이것은 이 글의 뒷부분에서 다루겠습니다.
왜 자격증명 입력을 선택할 때 "Null"로 로그온 할까요?
바인드를 하고 현재 로그온한 사용자를 기본값으로 선택합니다. LDP 결과 창에서 'NULL'로 로그인한 것을 볼 수 있습니다.
저는 이것이 이 도구의 특징이고, 완벽하게 정확하지 않다고 생각합니다. 바인드를 할 때, 'NULL' 자격증명을 표시하지만, 인증 타입으로 SASL을 지정하기도 합니다. 이 부분에서, SASL 매커니즘으로 인증 절차가 이루어집니다. 네트워크 추적을 통해 그 증거를 볼 수 있습니다.
프레임 세부정보 창의 Bind Request를 살펴보면, LDAP 패킷을 확장할 때 흥미로운 정보를 볼 수 있습니다.
NULL 자격증명이 통과된 것을 볼 수 있지만, SASL 인증으로 협상합니다. SASL(Simple Authentication and Security Layer)은 연결기반 프로토콜에 인증을 추가하는 방법입니다. 기본적으로, LDAP은 NULL 자격증명으로 바인드되는데 SASL에 로그온 절차를 넘기고 모든 작업을 하도록 합니다. bind request에서 협상 프로세스의 세부내용을 볼 수 있고 GSS-SPEGNO SASL 매커니즘을 선택하면 Kerberos 세션 티켓이 나타납니다.
그러면 어떻게 SASL이 인증을 제공할까요?
자세한 정보는, SASL에 대한 IETF의 설명을 확인할 수 있습니다. SSPI(Security Support Provider Interface)가 보안 패키지를 사용하는 방법과 비슷하게, SASL은 인증 절차를 완료하기 위해 SASL 매커니즘 등록을 사용합니다. 앞서 기술한 supportedSASLMechanisms의 초기 LDAP 쿼리 동안입니다. 서버와 클라이언트가 선택할 수 있는 모든 매커니즘의 목록을 가져왔습니다. 다음은 Windows Server 2008의 기본 매커니즘입니다.
|
인증 프로토콜 |
설명 |
|
GSS-SPNEGO |
GSS-SPNEGO는 커버로스나 NTLM을 인증 프로토콜의 기초로 사용합니다. |
|
GSSAPI |
GSSAPI는 커버로스를 항상 인증 프로토콜의 기초로 사용합니다. |
|
EXTERNAL |
LDAP 통신 외부에서 제공되는 정보를 통해 클라이언트가 자체적으로 인증하는 것을 허용하는데 사용합니다. TLS나 IPSec을 통해 인증서를 제출하는데 사용합니다. |
|
DIGEST-MD5 |
Digest-MD5을 사용하여 인증을 암호화합니다. |
LDP 도구는 다양한 매커니즘을 선택할 수 있도록하고 다른 도구를 사용할 수 없을 때 연결을 테스트할 수 있는 훌륭한 도구입니다. 응용 프로그램이 무엇을 수행하는지 적절한 바인드 특성을 선택할 수 있습니다.
응용 프로그램은 어떤 기능을 사용하여 데이터베이스에 연결할지를 결정합니다. (예 : LDAP_Simple_bind, LDAP_Sasl_bind, 등)
LDAP 서명(signing)은 무엇일까요?
그룹 정책에서 보안 설정을 살펴본다면, LDAP에 많이 관련되어 있는 것을 알 수 있습니다.
Domain controller: LDAP server signing requirements
Network security: LDAP client signing requirements
둘 모두 컴퓨터 구성\윈도우 설정\보안 설정\로컬 정책\보안 옵션에 있습니다.
서명된 LDAP 트래픽은 man-in-the-middle 공격을 예방하는 방법입니다. LDAP 트래픽을 서명함으로써, 요청이 만들어진 DC로부터 만들어진 LDAP 응답을 보장합니다. 이 설정을 활성화하면, 컴퓨터는 트래픽을 가로챌 수 없고 유선상에서 데이터를 변경할 수 없습니다. 네트워크 추적에서 디지털 서명 값을 볼 수 있습니다. 이 값은 서명이 완료된 DC의 모든 LDAP 응답에 있습니다.
단순 바인드는 무엇일까요?
LDAP 단순 바인드는 LDAP 서버에 자격증명을 제공하기 위해 사용자이름과 비밀번호를 텍스트로 보냅니다. 이것은 안전하지 않기 때문에, 응용 프로그램에서 단순 바인드를 사용한다면 다시 구성하거나 업데이트 해야합니다. LDP.exe의 이 옵션을 사용하여 단순 바인드를 생성하거나 코드에 LDAP_Simple_bind 기능을 호출하여 만듭니다. 네트워크 추적에서 LDAP BIND 바인드 프레임에서 사용자이름과 비밀번호를 볼 수 있습니다.
도메인에 서명이 필요해서, LDP.exe를 통해 단순 바인드를 수행할 수 없었습니다. "LDAP_Simple_Bind failed: Strong Authentication Required"라는 오류를 받았습니다.
익명 바인드는 무엇일까요?
앞서 기술했듯이, 모든 LDAP 연결은 LDAP 서버의 RootDSE를 쿼리하기 위해 익명 바인드를 수행합니다. 또한 앞서 언급했듯이, AD 포레스트의 DSHueristics 값을 변경하면, 모든 AD 파티션에 대해서 익명 바인드 LDAP 검색을 허용할 수 있습니다. 익명 바인드는 디렉터리 객체의 권한에 의해 여전히 제한됩니다. 익명 바인드를 만들고 도메인의 모든 사용자 객체에 검색을 수행하였는데, 한명의 사용자에만 수동으로 권한을 주었기 때문에 한명의 사용자만 검색되었습니다.
또한 사용자를 포함하고 있는 OU에 권한을 주었는데, 익명 로그온은 권한이 없기 때문에 컨테이너를 검색할 수 없었습니다. 루트 도메인 네이밍 컨텍스트에 접근할 수 있는 권한을 주지 않았습니다. "AD 사용자 및 컴퓨터"에서 "고급 기능"을 통해 권한을 설정할 수 있습니다.
LDAPS은 무엇일까요?
LDAPS은 LDAP 서버와 클라이언트 사이에서 암호화된 터널을 만드는 SSL/TLS 기술을 사용합니다. 터널은 LDAP 서버의 PKI 인증으로 통해 암호화하고, LDAP서버와 클라이언트를 제외한 다른 사람은 이 트래픽을 읽을 수 없기 때문에 클라이언트는 단순 바인드를 수행할 수 있고 텍스트로 자격증명을 안전하게 전달할 수 있습니다. LDAPS는 다른 글로 쓸 수 있는 완전히 다른 주제입니다. 운좋게도 James Carr 가 그것에 대해 기술했습니다. 여기를 확인하세요.
개발자는 Active Directory 데이터베이스에 바인드할 수 있는 다양한 방법이 있습니다. LDAP 클라이언트의 다양한 성향을 지원하지만, AD 관리자가 일부 구성을 해주어야 합니다. 안녕히 계세요...
Randy “Baby Elvis, thank you verah muuuch” Turner
