Windows Server 2008 R2 Domain Controllers: 신중한 RODC 계획

  • 아티클

Paul Yu

물리적 보안이 부족하다면 당연히 데이터 보안에 더욱 신경을 써야 합니다. Windows Server 2008 및 R2는 이를 위한 몇 가지 새로운 방법을 제공하는데, 이러한 방법들은 물리적 보안이 견고하지 못할 수 있는 원격 사무실과 같은 환경에 적합합니다. RODC(읽기 전용 도메인 컨트롤러)는 Windows Server 시스템 AD DS(Active Directory 도메인 서비스)의 새로운 기능으로, DC(도메인 컨트롤러) 사용 방법에 대한 근본적인 변화를 반영합니다.

RODC의 새로운 기능 중 다수가 디자인 및 배포 프로세스의 중요한 측면들에 영향을 미치므로 여러분의 엔터프라이즈에서 이것을 활용하는 방법을 파악해 두어야 합니다. 또한 RODC를 환경에 도입하기 전에 고려해야 하는 중요한 디자인 및 계획 관련 사항들도 있습니다. RODC는 Active Directory 데이터베이스의 읽기 전용 전체 복사본, SYSVOL의 읽기 전용 복사본, 그리고 쓰기 가능한 DC에서 특정 응용 프로그램 데이터의 인바운드 복제를 제한하는 FAS(복제가 제한된 특성 집합)를 호스팅하는 DC입니다.

기본적으로 RODC는 사용자 및 컴퓨터 계정 자격 증명을 선택적으로 저장하지는 않지만 그렇게 하도록 구성할 수 있습니다. 데이터 센터 인트라넷에서 사용되는 것과 같은 물리적 보안이 없는 원격 지점이나 경계 네트워크에서 RODC를 사용할 이유는 이것만으로도 충분합니다. 또한 RODC는 RODC 자체의 손상과 관련된 티켓 기반 공격에 대처하는 특수한 Kerberos 티켓 부여 계정과 같이 잘 알려지지 않은 다른 보안 기능도 제공합니다.

RODC를 배포하는 가장 일반적인 이유는 보안에 대한 우려지만 엔터프라이즈 관리 효율성 및 확장성과 같은 다른 여러 이점도 제공합니다. 일반적으로 RODC의 주 사용처는 로컬 인증 및 권한 부여가 필요하지만 쓰기 가능한 DC를 안전하게 사용하기 위한 물리적 보안이 부족한 환경입니다. 따라서 RODC는 데이터 센터 경계 네트워크 또는 지점에서 가장 많이 사용됩니다.

RODC의 좋은 사용 예 중 하나는 AD DS가 필요하지만 보안 제약으로 인해 경계 네트워크에서 회사 AD DS 포리스트를 활용할 수 없는 데이터 센터입니다. 이 경우 RODC가 관련된 보안 요구 사항을 충족하고, 따라서 회사 AD DS 구현의 인프라 범위를 변경할 수 있습니다. 이러한 유형의 시나리오는 앞으로 더 자주 볼 수 있을 것입니다. 이는 확장된 회사 포리스트 모델과 같은 현재의 경계 네트워크용 AD DS 모델 모범 사례도 반영합니다.

RODC를 통해 확장

AD DS를 사용하는 RODC의 가장 일반적인 환경은 여전히 지점입니다. 이러한 유형의 환경은 일반적으로 허브 및 스포크 네트워크 토폴로지에서 끝점입니다. 지리적으로 넓게, 많은 수가 분산되며 각각 적은 수의 사용자를 호스팅하고, 느리고 불안정한 네트워크 링크를 통해 허브 사이트에 연결되며 숙련된 지역 관리자가 없는 경우가 많습니다.

이미 쓰기 가능한 DC를 호스팅 중인 지점의 경우 RODC를 배포할 필요가 없을 수도 있습니다. 그러나 이 시나리오에서 RODC는 기존 AD DS 관련 요구 사항을 충족할 뿐만 아니라, 더 견고한 보안, 향상된 관리 기능, 간소화된 아키텍처 및 낮은 TCO(총 소유 비용)와 관련된 요구 사항을 초과 충족할 수 있습니다. 보안 또는 관리 효율성 요구 사항으로 인해 DC를 사용할 수 없는 곳에서 RODC는 DC를 환경에 도입하고 여러 가지 유용한 로컬 서비스를 제공하는 데 도움이 됩니다.

새로운 기능과 이점을 보면 RODC를 긍정적으로 평가하게 되지만 응용 프로그램 호환성 문제, 서비스 영향 조건과 같이 추가로 고려해야 할 점도 있습니다. 이러한 점을 고려할 경우 특정 환경에서는 RODC를 도입하지 못할 수 있습니다.

예를 들어 많은 디렉터리 지원 응용 프로그램 및 서비스는 AD DS에서 데이터를 읽으므로 RODC에서도 계속 작동할 것입니다. 그러나 특정 응용 프로그램에 항상 쓰기 가능한 액세스가 필요하다면 RODC를 수용할 수 없습니다. RODC는 쓰기 작업을 위해 쓰기 가능한 DC로의 네트워크 연결을 사용합니다. 실패한 쓰기 작업은 대부분의 잘 알려진 응용 프로그램 관련 문제를 일으키는 원인이지만, 비효율적이거나 실패한 읽기 작업, 실패한 쓰기-읽기-돌아가기 작업, 그리고 RODC 자체와 관련된 일반적인 응용 프로그램 오류 등 고려해야 할 다른 문제도 있습니다

응용 프로그램 문제 외에, 쓰기 가능한 DC로의 연결이 불안정하거나 끊어지는 경우 기본적인 사용자 및 컴퓨터 작업에 지장이 발생할 수 있습니다. 예를 들어 계정 암호를 캐시할 수 없고 RODC에 로컬로 캐시할 수도 없는 경우 기본 인증 서비스가 실패할 수 있습니다. RODC의 PRP(암호 복제 정책)를 통해 계정을 캐시할 수 있도록 한 다음 미리 채우기를 통해 암호를 캐시하면 이 문제를 쉽게 해결할 수 있습니다. 이러한 단계들을 수행하려면 쓰기 가능한 DC에 대한 연결도 필요합니다.

쓰기 가능한 DC에 연결할 수 없는 경우 다른 인증 문제와 함께 암호 만료 및 계정 잠김과 관련된 중대한 문제가 발생합니다. 쓰기 가능한 DC로의 연결이 복원될 때까지 암호 변경 요청과 잠긴 계정을 수동으로 해제하려는 시도는 계속 실패하게 됩니다. 이러한 종속성과 운영 측면에서 이후의 변화를 이해하는 것은 요구 사항과 SLA(서비스 수준 계약)를 확실해 해두는 데 있어 중요합니다.

RODC를 배포할 수 있는 일반적인 시나리오는 여러 가지입니다. RODC는 기존 DC가 없는 곳, 또는 현재 새로운 버전의 Windows로 교체 또는 업그레이드될 예정인 DC를 호스팅하고 있는 곳에 유용합니다. 각 시나리오에 따라 특정적인 광범위한 고려 사항이 있지만 여기서는 특정적이지 않은 접근 방식에 초점을 두겠습니다. 그러나 이러한 접근 방식은 기존의 쓰기 가능한 DC보다 RODC에 특정적입니다.

사전 계획

공식적인 RODC 계획을 시작하기 전에, 적절한 수준의 심사와 기본적인 AD DS 사전 계획을 수행해야 합니다. 여기에는 기존 AD DS 논리 구조의 유효성을 검사하고, 관리 모델과 AD DS 물리 구조가 기존 비즈니스 및 기술 요구 사항을 지원하는지 확인하는 것과 같은 중요한 작업이 포함되어야 합니다. 또한 하드웨어 요구 사항, 소프트웨어 업그레이드 전략 및 해당되는 운영 체제의 알려진 문제를 고려하고 RODC AD DS 필수 구성 요소도 평가해야 합니다. 이 정보는 계획 및 배포 프로세스에서 중요하게 사용됩니다. 이 정보는 세부적인 배포 확인 목록에 잘 문서화됩니다.

설치 및 관리

RODC에는 ARS(관리자 역할 구분)라고 하는 중요한 관리 기능이 있습니다. ARS는 Active Directory 권한을 부여하지 않고 비서비스 관리자에게 RODC 서버를 설치 및 관리할 수 있는 기능을 위임합니다. 이는 DC 서버 디자인, 관리 위임 및 배포 절차와 관련하여 기존 고려 사항에서 중요한 변경 사항입니다. 이 역할 구분의 중요성은 DC에 직접 설치해야 하는 핵심 응용 프로그램, 또는 하나의 다목적 서버를 호스팅하는 곳에서 더 커집니다.

추가 서버 역할

일반적으로 RODC가 작동하는 데 필요 없는 역할은 서버에서 모두 제거해야 합니다. 따라서 RODC에 추가해야 하는 역할은 DNS와 글로벌 카탈로그 서버 역할이 전부입니다. 쓰기 가능한 DC로 네트워크 연결이 되지 않는 경우 로컬 DNS 클라이언트가 DNS 확인을 수행할 수 있도록 각 RODC에 DNS 서버를 설치해야 합니다. 단, Dcpromo.exe를 통해 DNS 서버 역할을 설치하지 않는 경우 나중에 설치해야 합니다. Dnscmd.exe를 사용하여 Active Directory 통합 영역을 호스팅하는 DNS 응용 프로그램 디렉터리 파티션에 RODC를 넣어야 합니다. 또한 RODC를 글로벌 카탈로그 서버로 구성하여 RODC만 사용하여 인증 및 글로벌 카탈로그 쿼리를 수행할 수 있도록 해야 합니다. 인증 관점에서, 글로벌 카탈로그 역할을 사용할 수 없다면 유니버설 그룹 캐싱을 사용할 수 있습니다. RODC에 대한 성공적인 인증은 궁극적으로 RODC의 PRP 구성에 따라 좌우될 수 있습니다.

RODC 배치

RODC PRP가 등장한 이후 DC 배치의 많은 부분이 변경되었습니다. RODC는 동일한 도메인에서 Windows Server 2008 또는 Windows Server 2008 R2를 실행하는 쓰기 가능한 DC의 도메인 파티션을 복제할 수 있어야 합니다. 이러한 DC만이 RODC에 대한 PRP를 적용할 수 있기 때문입니다. 복제가 제대로 이루어지려면 RODC가 포함된 사이트에 대한 가장 비용이 낮은 사이트 링크를 가진 AD DS 사이트에 쓰기 가능한 DC가 위치해야 합니다.

이 구성을 설정할 수 없는 경우 RODC 복제는 모든 사이트 링크를 브리지로 연결 옵션(사이트 링크 추이성을 의미), 또는 RODC 사이트와 쓰기 가능한 DC 사이트가 포함된 사이트 링크 간의 사이트 링크 브리지에 의존해야 합니다. 사이트 추이성 또는 사이트 링크 브리지를 사용할 수 없는 경우 새 사이트 링크를 만들어 RODC 사이트와 쓰기 가능한 DC 사이트를 직접 연결할 수 있습니다.

일반적인 최선의 방법에 따르면, RODC와 동일한 AD DS 사이트에 다른 DC를 두면 안 됩니다. 이 경우 클라이언트 작동의 일관성이 훼손되어 클라이언트 작동을 예측할 수 없게 되기 때문입니다. 인증, LDAP 읽기 및 쓰기, 암호 변경과 같은 기본적인 작업은 서로 다른 RODC 구성, 쓰기 가능한 DC의 Windows 버전, 다른 쓰기 가능한 DC로의 네트워크 연결 가용 여부에 따라 다르게 작동할 수 있습니다. 또한 같은 도메인의 모든 사용자와 리소스를 하나의 RODC 사이트에 유지해야 합니다. RODC는 트러스트 암호를 저장하지 않으며, 인증 요청을 다른 쓰기 가능한 DC로 전달하기 위해 도메인 간 권한 부여를 요구합니다. 쓰기 가능한 DC가 별도의 사이트에 있다고 가정하면 모든 도메인 간 권한 부여 요청은 네트워크 연결에 의존하며, 따라서 네트워크 연결이 실패하는 경우 작동하지 않을 것입니다.

확장성과 복제

또한 RODC는 규모가 크거나 더 복잡한 AD DS 구현에 유용한 확장성 이점을 제공합니다. 예를 들어 RODC는 단방향 복제를 제공합니다. 따라서 지점에 RODC를 배포하면 일반적으로 지점 DC에 대한 인바운드 복제를 처리하는 허브 사이트 브리지헤드 서버의 성능 부하가 낮아집니다. TCO 관점에서 이는 만들고 관리해야 하는 연결 개체의 수를 줄여 줍니다. 또한 필요한 허브 사이트 DC의 수도 줄어들 수 있습니다.

RODC는 아웃바운드 연결 개체를 허브 사이트 브리지헤드 서버 간에 자동으로 균등하게 분산하는 데 도움이 되는 부하 분산 측면의 개선도 제공합니다. 이전 버전의 Windows에서는 이를 위해 정기적인 수동 작업이 필요했습니다. 이제는 RODC의 KCC(정보 일관성 검사기)가 허브 사이트에서 브리지헤드 서버의 추가 또는 제거를 감지하고 새 브리지헤드로 복제 파트너를 전환할지 여부를 결정합니다. 이를 위해 알고리즘과 가능성에 근거한 부하 분산을 실행합니다. RODC가 지점 위치에 추가되면 KCC는 인바운드 연결도 기존 허브 사이트 브리지헤드 서버로 고르게 분산합니다.

자격 증명 캐싱

RODC의 PRP는 해당 RODC에서 계정을 캐시할 수 있는지 여부를 결정합니다. 기본적으로 PRP의 “허용” 목록은 계정 암호를 캐시할 수 없도록 지정하고 특정 계정의 캐시를 명시적으로 거부합니다. 이는 수동으로 구성된 “허용” 구성에 우선합니다. 앞서 언급했듯이, 각 RODC에서 계정 암호의 캐시를 허용하도록 PRP를 구성해야 할 수 있습니다.

PRP 수정은 보안과 서비스 가용성에 모두 영향을 미치므로 이 단계는 주의를 기울여 수행하십시오. 예를 들어 계정을 캐시할 수 없는 기본 시나리오는 보안도 그만큼 강력하지만, 쓰기 가능한 DC에 대한 네트워크 연결을 사용할 수 없게 되면 오프라인 액세스가 불가능합니다. 반대로, 다수의 계정이 캐시 가능한 계정인 경우(예: 도메인 사용자 그룹) RODC가 손상되면 보안이 훨씬 더 약해지지만 캐시 가능한 계정에 대한 서비스 가용성 수준은 더 높습니다. 다양한 인프라 환경에 걸친 고유한 비즈니스 및 기술 요구 사항으로 인해 PRP 디자인은 조직별로 달라지게 됩니다.

PRP 모델을 설정하고 나면 각 RODC에서 PRP를 구성하여 적절한 계정을 캐시할 수 있도록 해야 합니다. 최상의 방법은 명시적 허용을 사용하여 PRP를 구성하고 기본 거부 목록은 수정하지 않는 것입니다. 거부 목록은 AD DS 서비스 관리자와 같은 중요한 계정 자격 증명이 RODC에 캐시되는 것을 차단하므로 중요합니다.

PRP 디자인의 또 다른 중요한 측면은 캐시 가능한 계정에 암호를 미리 입력할 것인지 여부를 결정하는 것입니다. 기본적으로 캐시 가능한 계정의 자격 증명은 RODC에 대한 첫 로그온, 즉 Windows Server 2008 또는 Windows Server 2008 R2 쓰기 가능한 DC로 인증 요청이 전달되고 자격 증명이 RODC에 복제될 때까지는 실제로 캐시되지 않습니다. 이는 캐시 가능한 계정이 RODC에 대해 인증되기 전에 쓰기 가능한 DC에 대한 네트워크 연결을 사용할 수 없게 되는 경우, 계정이 캐시 가능하도록 구성되었더라도 성공적으로 로그온할 수 없음을 의미합니다.

이 문제를 해결하는 방법은 PRP가 구성되고 계정이 캐시 가능한 것으로 표시되면 바로 암호를 수동으로 미리 입력하는 것입니다. 이 작업에는 Windows Server 2008 또는 Windows Server 2008 R2 쓰기 가능한 DC와 RODC 간의 네트워크 연결이 필요합니다. 이는 캐시 가능한 사용자가 처음 로그인하기 전, 배포 프로세스 중에 미리 할 수 있습니다.

이 기본 아키텍처 디자인 지침을 RODC 계획의 기반으로 사용할 수 있습니다. 이 기사에서는 핵심적인 디자인 고려 사항을 살펴봄으로써 세부적이고 포괄적인 RODC 솔루션을 디자인하기 위한 효과적인 시작 지점을 제공합니다. 이것은 간단한 프로세스가 아니고, 새로운 기능과 디자인 고려 사항을 조직 고유의 환경 및 요구 사항에 융화시키기 위해서는 많은 시간이 필요합니다.

Paul Yu*(Paul.Yu@microsoft.com)는 Microsoft Consulting Services 내의 선임 컨설턴트이며, 10년째 Microsoft에서 근무하면서 민간 기업과 공공 기관에 엔터프라이즈 인프라 솔루션을 제공하고 있습니다.*

관련 콘텐츠