Active Directory: Understanding Proxy Authentication in AD LDS

아티클
08/24/2016

Active Directory

AD LDS의 프록시 인증 이해

Ken St. Cyr

한 눈에 보기:

프록시 인증 정의
프록시 인증이 유용한 이유
프록시 개체
인증 과정

프록시 인증이란?
프록시 인증의 이점
프록시 개체
인증이 실제로 수행되는 방식
프록시 인증 테스트 환경 설정
결론

다른 LDAP 사용 디렉터리 서비스와 마찬가지로 Microsoft Active Directory Lightweight Directory Services(AD LDS, 이전의 ADAM)에서도 디렉터리에 대해 LDAP 작업을 실행하려면 먼저 바인딩을 수행해야 합니다. 이 바인딩은 단순 LDAP 바인딩, SASL(Simple Authentication and Security Layer) 바인딩 또는 바인딩 리디렉션을 비롯한 몇 가지 방법으로 수행할 수 있습니다. 익명 바인딩도 가능하며, 이 경우 사용자는 암호를 입력하지 않습니다. 이 글에서는 그 중 한 방법인 바인딩 리디렉션, 즉 프록시 인증에 대해 구체적으로 살펴보겠습니다.

프록시 인증 소개

프록시 인증에서는 사용자가 Active Directory 계정과의 연결을 계속 유지하면서 AD LDS 인스턴스에 대해 단순 바인딩을 수행할 수 있습니다. 이 트랜잭션에서는 두 개의 계정이 사용됩니다. 첫 번째는 AD LDS의 특수 개체인 userProxy 개체입니다. 두 번째는 Active Directory의 사용자 계정입니다.

AD LDS userProxy 개체는 Active Directory 계정을 표현합니다. 프록시 개체는 Active Directory 계정의 보안 식별자(SID)를 통해 그 계정과 연결됩니다. 실제 프록시 개체 자체에는 암호가 저장되지 않습니다.

사용자가 프록시 개체를 사용하여 LDS 인스턴스에 대한 단순 바인딩을 수행하면 이 바인딩은 도메인 컨트롤러에 SID와 암호를 전달하는 방법으로 Active Directory에 리디렉션됩니다. AD LDS 서버는 인증을 수행하며 이러한 모든 프로세스가 최종 사용자 모르게 수행됩니다. 그림 1은 이러한 프로세스를 보여주며, Lucy가 "CN=AppDir,DC=contoso,DC=com"이라는 AD LDS 인스턴스에 자신의 AD LDS 사용자 계정으로 연결되어 있습니다.

그림 1 AD LDS 연결(더 크게 보려면 이미지를 클릭하십시오.)

인증을 위해 Lucy는 단순 바인딩을 사용하는 중이며, 일반 LDAP 바인딩처럼 DN(고유 이름)과 암호를 제공합니다. Lucy가 일반 LDS 사용자 계정에 연결된 것처럼 보이지만 실제로는 프록시 개체를 사용하고 있는 것입니다. Active Directory에 대한 인증은 사용자가 모르게 이루어지므로, Lucy는 자신이 바인딩에 Active Directory 계정을 사용하고 있음을 전혀 알지 못합니다.

프록시 인증의 이점

프록시 인증의 이점은 응용 프로그램 개발자가 Active Directory 계정에 대한 액세스 권한 없이 사용자 개체에 액세스할 수 있다는 것입니다. 디렉터리를 지원하는 새로운 응용 프로그램을 개발할 경우 이 응용 프로그램이 일부 데이터를 Active Directory에 저장해야 한다면 어떻게 될지 생각해 봅시다 응용 프로그램은 기존의 특성을 사용하거나 새 특성을 만들 수 있습니다.

사용되지 않은 기존의 특성을 사용할 경우 다른 용도를 위한 특성일 수 있다는 위험이 있습니다. 지금은 사용되지 않더라도 나중에 사용될 수 있습니다. 다른 용도로 사용되는 경우 Active Directory 관리자는 그 사용 현황을 추적해야 합니다. 응용 프로그램 개발자가 둘 이상의 특성을 필요로 한다면 어떻게 되겠습니까?

프록시 인증에서는 Active Directory 사용자 개체가 AD LDS 디렉터리에 나타납니다. 응용 프로그램 전용 디렉터리를 사용하면 응용 프로그램 개발자가 AD LDS의 컨텍스트에서 원하는 방식으로 스키마를 수정할 수 있습니다. 개발자가 선택하는 대로 특성을 추가, 변경하거나 기능을 바꿀 수 있으므로 Active Directory 관리자는 스키마를 여러 번 변경하거나 특성 사용 현황을 추적하지 않아도 됩니다. 다른 응용 프로그램이 온라인 상태로 되어 동일한 특성을 사용하려는 경우 별도의 AD LDS 인스턴스가 될 수 있으므로 특성 충돌이 발생하는 문제가 없습니다.

프록시 인증은 X.500 형식이 필요한 상황에서도 유용할 수 있습니다. Active Directory에서는 DN에 일반 X.500 명명법을 사용하지 않습니다. 예를 들어, Active Directory에서 사용자 개체의 DN은 "CN=Lucy D. Smith,CN=Users,DC=contoso,DC=com"이지만, AD LDS에서 사용자의 DN은 "CN=Lucy D. Smith,CN=Users,O=Contoso,C=US"가 될 수 있으며, 이는 X.500과 호환됩니다.

이는 타사 LDAP 클라이언트를 사용하거나 X.500 형식이 필요한 타사 디렉터리와 통합하려고 할 때 유용합니다. 이와 같이 LDS는 타사 디렉터리와 Active Directory 간을 중개하는 디렉터리가 될 수 있습니다. 프록시 인증을 사용할 경우 타사 디렉터리에서 LDS 인스턴스와의 바인딩에 사용할 서비스 계정은 LDS 자체가 아니라 Active Directory에 저장할 수 있습니다.

프록시 개체 내부

지금까지 LDS 프록시 개체가 Active Directory 사용자 계정에 어떻게 연결되는지를 간략하게 살펴봤습니다. 이제는 좀 더 자세하게 배후에서 실제로 어떤 작업이 이루어지는지 개체 클래스부터 살펴보겠습니다.

Windows Server 2008에서 %SYSTEMROOT%\ADAM 디렉터리에는 프록시 개체를 나타내는 2개의 LDF 파일이 있습니다.

MS-UserProxy.LDF
MS-UserProxyFull.LDF

MS-UserProxy.LDF에는 기본 특성을 가지며 msDS-BindProxy 보조 클래스를 포함하는 단순 userProxy 클래스에 대한 정의가 들어 있습니다. MS-UserProxyFull.LDF 역시 msDS-BindProxy 보조 클래스를 포함하지만, 이 클래스의 mayContain 특성에 추가 사용자 특성을 미리 채워 넣습니다. 따라서 특성 클래스가 먼저 존재해야 하므로 userProxyFull 클래스를 가져올 때 사용자 또는 inetOrgPerson 클래스를 먼저 가져와야 합니다. 사용자와 inetOrgPerson 모두 userProxyFull이 사용하는 특성에 대한 특성 클래스 정의를 포함합니다. 그림 2에서는 userProxy 클래스와 userProxyFull 클래스의 차이점을 보여 줍니다.

그림 2 userProxy와 userProxyFull 클래스(더 크게 보려면 이미지를 클릭하십시오.)

두 클래스 모두 msDS-BindProxy를 보조 클래스로 포함한다는 사실이 중요합니다. 보조 클래스는 구조 클래스에 추가 데이터를 제공할 수 있는 클래스입니다. 예를 들어, LDS에서 User 클래스는 Organizational-Person 클래스에서 상속되는 구조 클래스입니다. 즉 User 클래스는 Organizational-Person 클래스의 모든 특성을 갖습니다. 그러나 User 클래스는 msDS-BindableObject라는 보조 클래스도 포함합니다. 즉 User는 Organizational-Person 클래스의 특성 외에도 msDS-BindableObject의 모든 필수 및 선택적 특성을 갖습니다. 이 경우 msDS-BindableObject를 보조 클래스로 사용하면 User 클래스를 바인딩할 수 있습니다.

userProxy 클래스에는 msDS-BindProxy라는 보조 클래스가 있으므로(그림 3 참조) msDS-BindProxy의 필수 및 선택적 특성도 모두 포함하고 있습니다. msDS-BindProxy 보조 클래스는 개체를 프록시 개체로 바꾸는 역할을 합니다. 따라서 사용자 지정 클래스가 있더라도 msDS-BindProxy 보조 클래스를 추가하고 사용자 지정 개체를 프록시 인증에 사용할 수 있습니다.

그림 3 프록시 개체 만들기(더 크게 보려면 이미지를 클릭하십시오.)

msDS-BindProxy 클래스를 살펴보면 단 하나의 필수 특성인 objectSID가 정의되어 있음을 알 수 있습니다. 이 특성에는 LDS의 프록시 개체와 Active Directory의 사용자 개체 간의 연결을 만들기 위해 Active Directory 사용자 계정의 SID가 지정됩니다. 이 특성은 개체를 만들 때에만 지정할 수 있습니다. 이 특성을 변경하려면 개체를 삭제하고 다시 만들어야 합니다.

실제로 인증이 수행되는 방식

배후에서 진행되는 작업을 제대로 이해하려면 인증이 어떻게 수행되는지를 자세히 알아볼 필요가 있습니다. 프록시 인증이 어떻게 이루어지는지에 대한 이해를 돕고자 두 개의 네트워크 추적을 살펴보겠습니다. 첫 번째 추적은 프록시 사용자의 Windows XP 워크스테이션에서 Windows Server 2008 LDS 인스턴스로의 단순 바인딩에 대한 네트워크 캡처입니다. 이 캡처에서 Lucy는 자신의 워크스테이션에서 LDP.EXE를 사용하여 프록시 사용자 개체에 바인딩합니다.

그림 4에 나와 있는 캡처에서 3개의 패킷에 주목할 필요가 있습니다. 패킷 1은 워크스테이션(10.0.0.107)에서 Active Directory LDS 서버(10.0.0.201)로의 바인딩 요청입니다. 바인딩 요청은 Lucy의 DN, 즉 "cn=lucy,cn=people,cn=appdir,dc=contoso,dc=com"을 포함합니다. 패킷 2는 Active Directory LDS 서버에서 워크스테이션으로 보내는 응답으로 바인딩 성공을 나타냅니다. 패킷 3은 워크스테이션에서 바인딩 응답을 받았다고 Active Directory LDS 서버로 알려 주는 승인입니다.

그림 4 바인딩 요청 및 응답(더 크게 보려면 이미지를 클릭하십시오.)

패킷 2를 자세히 살펴보면(그림 5 참조) 놀라운 사실을 알 수 있습니다. Lucy가 제공한 암호(P@ssw0rd)가 캡처에 일반 텍스트로 표시됩니다. 이것이 인증에 단순 LDAP 바인딩을 사용할 때의 결점 중 하나입니다. 바인딩이 SSL 암호화로 래핑되지 않는 한 사용자의 암호가 네트워크에서 데이터를 수신하는 모든 사용자가 암호를 볼 수 있는 것입니다.

그림 5 SSL을 해제한 단순 바인딩(더 크게 보려면 이미지를 클릭하십시오.)

그러나 Active Directory LDS는 기본적으로 SSL을 사용합니다. SSL을 해제하려면 제가 이 작업에서 네트워크 추적을 읽을 수 있게 했던 것처럼 몇 가지 작업을 수행해야 합니다. 저는 Active Directory LDS 서버에 인증서를 지정하지 않았지만, 실제 구현에서는 SSL에서 사용 가능한 유효한 인증서가 Active Directory LDS 서버에 있어야 할 것입니다.

두 번째 추적은 Active Directory LDS 서버에서 도메인 컨트롤러(DC)로의 네트워크 캡처입니다. 이 추적은 첫 번째 추적보다 약간 더 크므로 몇 개의 부분으로 나누겠습니다. 이 추적의 처음 9개 패킷이 그림 6에 나와 있습니다.

그림 6 도메인 컨트롤러에 연결된 AD LDS(더 크게 보려면 이미지를 클릭하십시오.)

첫 번째 패킷은 익숙할 것입니다. 워크스테이션으로부터 수신된 바인딩 요청에 있는 패킷입니다. 역시 이 패킷도 Lucy의 DN과 암호를 일반 텍스트 형태로 포함합니다. 패킷 2부터 패킷 9까지는 도메인 컨트롤러(10.0.0.200)에 연결된 AD LDS 서버(10.0.0.201)를 표시합니다. 이는 ARP(Address Resolution Protocol) 메시지 다음에 DC와의 RPC(원격 프로시저 호출) 연결이 오는 식으로 구성됩니다.

그림 7에서 패킷 10과 11은 LsarLookupSids3이라는 메서드를 호출하는데, 이는 DC에게 SID의 배치를 가져와 그 이름을 반환하도록 지시하는 RPC 호출입니다. AD LDS 서버는 패킷 10에서 요청을 보내며 패킷 11에서 DC로부터의 응답을 수신합니다.

그림 7 Kerberos 인증 시도(더 크게 보려면 이미지를 클릭하십시오.)

그런 다음 Kerberos 세션을 시작하기 위한 짧은 TCP 핸드셰이크(패킷 12–14) 후에 패킷 15에서 AD LDS 서버는 KDC(키 배포 센터)로부터 인증 서비스 티켓(AS-REQ)을 받으려고 시도합니다. DC는 AD LDS 서버가 제공하지 않은 사전 인증 데이터가 필요하기 때문에 패킷 16에서 인증 서비스 티켓 요청이 거부됩니다. 입니다. 여기서는 DC가 신원 확인에 사용할 수 있는 타임스탬프를 원하고 있습니다. Kerberos 세션이 끝나며 재설정이 요청됩니다(패킷 17–19).

그림 8에서는 캡처의 나머지 부분을 보여 줍니다. 패킷 20–22는 새로운 Kerberos 세션을 설정하며, 패킷 23에서는 새로운 인증 서비스 요청이 AD LDS 서버에서 DC로 전송됩니다. 이 새 요청은 필요한 사전 인증 데이터를 포함하며, 패킷 25에서 DC로부터의 회신 성공으로 나타납니다. 이제 AD LDS 서버는 인증 서비스 티켓을 가지므로, TGS(Ticket Granting Service)에 Lucy의 자격 증명을 인증하라는 요청을 보낼 수 있습니다.

그림 8 인증 성공(더 크게 보려면 이미지를 클릭하십시오.)

TGS 요청 및 응답은 패킷33과 34에서 캡처합니다. 패킷 34에서의 KRB_TGS_REP 수신은 Lucy가 성공적으로 인증되었음을 나타냅니다. 마지막으로, 패킷 38에서는 AD LDS 서버가 워크스테이션에 바인딩 응답을 다시 전달하여 Lucy에게 AD LDS 인스턴스에 성공적으로 바인딩되었음을 알립니다. 이 프로세스는 몇 단계로 구성되지만 전체 트랜잭션에 걸리는 시간은 약 1/10초에 불과합니다.

Lucy가 잘못된 암호를 입력한 경우 어떻게 됩니까? 이번 예제에서는 인증 서비스 요청이 패킷 25에서 실패합니다. 인증 서비스 요청이 실패하면 AD LDS 서버에게 Lucy의 자격 증명이 잘못된 것이었음을 알리는 정보가 전송됩니다. AD LDS 서버는 TGS에 요청을 보내지 않고 대신 워크스테이션에 바인딩 요청을 돌려보내서 자격 증명이 잘못되었음을 알립니다.

다음은 성공적으로 교환한 경우를 다시 캡처한 것입니다.

워크스테이션이 AD LDS 서버에 바인딩 요청을 보냅니다.
AD LDS 서버가 DC와의 연결을 설정합니다.
AD LDS 서버는 DC에게 Lucy의 SID를 인증에 사용 가능한 식별자로 변환할 것을 요청합니다.
DC는 AD LDS 서버에게 Lucy의 ID를 제공합니다.
AD LDS 서버는 DC로부터 Lucy의 ID와 함께 TGT(Ticket Granting Ticket)를 받습니다.
AD LDS 서버는 Lucy의 TGT를 사용하여 세션 티켓을 가져옵니다.
AD LDS 서버가 워크스테이션에 바인딩 응답을 성공적으로 보냅니다.

이 프로세스는 워크스테이션에서 AD LDS 서버로의 연결이 표준 LDAP 바인딩 트랜잭션임을 보여 줍니다. 그런 다음 AD LDS 서버에서 DC로 Kerberos를 사용하여 안전하게 사용자를 인증합니다.

프록시 인증 테스트 환경 설정

프록시 인증이 어떻게 이루어지는지를 알아봤으므로 이번에는 테스트 환경에서 이를 설정하는 방법을 살펴보겠습니다. 이번 예제에서는 프록시 인증에서 SSL 요구사항을 해제하겠습니다. 그러나 앞서 언급했듯이, 실제 구현에서는 이 요구사항을 해제해서는 안 됩니다.

먼저 Windows Server 2008 구성원 서버가 설치된 정식 도메인과 여기에 연결된 워크스테이션이 필요합니다. Windows Server 2008 구성원 서버는 AD LDS를 실행하며 워크스테이션은 클라이언트 끝점이 됩니다. 이렇게 컴퓨터를 분리하면 상호 작용에 대한 네트워크 캡처를 얻을 수 있다는 장점이 있습니다. 테스트 환경을 설정하기 위해 다음과 같이 합니다.

구성원 서버에 AD LDS를 설치합니다.
프록시 인증의 SSL 요구사항을 해제합니다.
userProxy 클래스를 AD LDS 스키마로 가져옵니다.
프록시 개체를 만들고 권한을 지정합니다.
프록시 개체를 사용하여 AD LDS 디렉터리에 바인딩합니다.

첫 번째 단계는 Windows Server 2008 구성원 서버에 AD LDS를 설치하기 위한 단계입니다. 서버 관리자의 "역할 추가" 마법사에 LDS를 설치하는 옵션이 제공됩니다. 역할이 설치되면 관리 도구 메뉴에 Active Directory Lightweight Directory Services 설정 마법사라는 새 옵션이 나타납니다. 새 LDS 인스턴스를 만들려면 이 마법사를 사용합니다.

응용 프로그램 파티션 이름을 물으면 원하는 DN을 입력합니다. LDS는 X.500 명명을 지원하므로, 반드시 "DC=" 형식의 이름만 사용할 필요는 없습니다. 여기서는 "cn=appdir,dc=contoso,dc=com"을 사용했으나 "cn=appdir,o=contoso,c=us"라는 이름도 사용할 수 있습니다.

AD LDS 인스턴스가 설치된 후 다음 단계는 프록시 인증을 위한 SSL 요구사항을 해제하는 것입니다. ADSI Edit 스냅인(adsiedit.msc)에서는 설치 중에 지정한 관리자 계정을 사용하여 AD LDS 인스턴스의 구성 파티션에 연결해야 합니다. 구성 파티션의 DN을 모르는 경우 ADSI Edit의 연결 설정 대화 상자에서 "Select a well known naming context" 드롭다운 목록에서 "Configuration"을 선택할 수 있습니다.

"CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={guid}" 컨테이너를 찾아 "CN=Directory Service" 컨테이너의 속성 대화 상자를 엽니다. 특성 목록에는 msDS-Other-Settings라는 다중값 문자열 특성이 있습니다. 이 특성은 여러 문자열을 나열하며, 각 문자열은 AD LDS 인스턴스의 각기 다른 설정을 나타냅니다. 이 특성을 편집하고 "RequireSecureProxyBind" 문자열을 값 0으로 변경합니다.

다음 단계는 userProxy 클래스의 스키마 클래스 정의를 가져오는 것입니다. AD LDS 마법사의 절차에 따라 이미 가져왔을 수도 있습니다. 이미 가져온 경우 이 단계를 생략해도 됩니다. 아직 가져오지 않은 경우에는 다음 LDIFDE.EXE 명령을 사용하여 가져옵니다. 명령에 AD LDS 서버의 이름과 올바른 포트를 지정해야 합니다.

C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c 
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext

개체 클래스를 가져왔으므로 프록시 개체를 만들 수 있습니다. 여기서는 LDP.EXE를 사용하겠지만, 다른 도구나 프로그래밍 방법을 사용할 수도 있습니다. LDP를 사용하여 AD LDS 인스턴스에 연결하고 관리자 자격 증명으로 바인딩합니다. AD LDS 인스턴스의 DN을 찾은 다음 프록시 개체를 만들 컨테이너를 선택합니다. 컨테이너를 마우스 오른쪽 단추로 클릭하고 드롭다운 목록에서 자식 추가를 선택합니다. 추가 대화 상자의 DN 필드에 새 프록시 개체의 DN을 입력해야 합니다. 예를 들어, "cn=lucy,cn=appdir,o=contoso,c=us"를 사용할 수 있습니다.

또한 이 개체로 두 개의 특성을 만들어야 합니다. 첫 번째는 만들려는 개체의 종류를 나타내는 objectClass입니다. 이 예제에서는 userProxy가 되어야 합니다. 이 정보를 대화 상자의 Edit Entry 섹션에 입력하고 Enter 단추를 클릭합니다.

두 번째로 추가할 특성은 objectSID로서 이 프록시 개체가 연결된 Active Directory 사용자 계정의 SID를 포함합니다. 다양한 방법으로 이 SID를 얻을 수 있으나 여기서는 별도의 LDP 인스턴스에서 Active Directory에 연결하여 그곳의 사용자 계정으로부터 objectSID 특성을 복사했습니다. 이 정보를 입력한 후 Add 대화 상자가 그림 9와 비슷해야 합니다. 마지막으로 Run 단추를 클릭하여 변경을 적용합니다.

그림 9 프록시 개체 만들기

방금 만든 프록시 개체를 사용하려면 몇 가지 권한을 부여해야 합니다. LDP에서 "CN=Roles" 컨테이너 아래의 "CN=Readers" 개체를 선택하면 이 작업을 손쉽게 할 수 있습니다. 마우스 오른쪽 단추로 클릭한 후 드롭다운 목록에서 수정을 선택합니다. member라는 특성을 추가하고, 방금 만든 userProxy 개체의 DN을 값으로 입력합니다. Run을 클릭하기 전에 반드시 Enter 단추를 클릭해야 합니다. userProxy 개체는 LDS 인스턴스에서 Readers 그룹의 구성원이어야 합니다.

모든 설정이 끝났으므로 이제 프록시 인증을 테스트할 수 있습니다. 새 LDP 인스턴스를 열고 이를 AD LDS 서버에 연결합니다. 그러나 이번에는 인스턴스에 바인딩할 때 단순 바인딩을 선택하고 사용자 이름 필드에 프록시 개체의 DN을 입력합니다. 암호에는 이 프록시 개체를 연결한 Active Directory 계정의 암호를 입력합니다. OK를 클릭하면 읽기 전용 모드에서 인스턴스에 바인딩되어야 합니다.

네트워크 추적을 수집하여 다양한 바인딩 방법을 시도해 보십시오. 한 예로 SSL을 다시 켜고 LDAP 바인딩 프로세스를 캡처할 수 있습니다. 일부러 사용자 이름이나 암호를 틀리게 입력하면 어떻게 되는지를 확인할 수도 있습니다.

결론

프록시 인증 사용이 어렵다고 놀라지 마십시오. 여기서는 배후에서 이루어지는 작업을 자세히 살펴보기 위해 LDP 및 ANSI Edit에서 이 프로세스를 진행했습니다. 즉, 이 예제에서는 실습 위주로 프록시 인증 단계를 수행했습니다.

실제로는 ID 관리 시스템이나 계정을 만드는 데 사용하는 사용자 개발 프런트 엔드를 통해 userProxy 개체를 만들고 이를 조작하는 긴 프로세스를 수행해야 합니다. LDS 테스트 환경을 직접 구축하고 타사 디렉터리와 응용 프로그램을 통합하는 데 프록시 인증을 어떻게 사용할 수 있는지 직접 확인해 보도록 하십시오.

Ken St. Cyr은 Microsoft에서 컨설턴트로 일하고 있으며, Active Directory의 초창기부터 Active Directory 기반의 디렉터리 솔루션을 설계하고 구현해 왔습니다. 최근 그는 디렉터리 서비스에 대한 Microsoft Certified Master의 최초 취득자가 되기도 했습니다. 문의 사항이 있으면 ken.stcyr@microsoft.com으로 연락하시기 바랍니다.

추가 리소스