RODC (Read-Only Domain Controller)

Q1. RODC의 배치 목적은?
A. 지점(브랜치)에서 로그온 가용성을 높이되, 쓰기 작업과 민감 데이터를 본사 RWDC에 둬 보안을 강화하기 위함입니다. DC는 AD 데이터베이스 사본을 보유하고 인증·인가를 제공하는 역할을 하며(RODC는 읽기 전용), 쓰기 필요 시 RWDC로 참조(Write Referral) 합니다.

 

Q2. PRP(Password Replication Policy) 핵심 원리는?
A. 허용된 계정만 RODC에 암호 검증값(해시/키)을 선별 캐시합니다. 기본적으로 고권한/민감 계정은 캐시 금지(Denied)이며, WAN 장애 시 이미 캐시된 계정만 오프라인 로그온이 가능합니다.

 

Q3. RODC와 GC(Global Catalog)의 관계는?
A. GC는 포리스트 전체 개체의 부분(읽기 전용) 복제본을 보유하고 범용(Universal) 그룹 멤버십 계산을 담당합니다. RODC를 GC로 겸하면 지점에서 UPN 로그온/UG 토큰 계산 실패를 줄일 수 있습니다(“GC에 연결 실패 시 로그온 실패” 가능).

 

Q4. Universal 그룹 토큰 계산은 왜 GC 의존적인가?
A. 범용 그룹은 도메인 경계를 넘나드는 멤버십을 갖기 때문입니다. GC가 로그온 시점에 범용 그룹 멤버십을 빌드하므로, 지점은 GC 접근성이 성능과 가용성에 직결됩니다.

 

Q5. RODC 배치 전 필수 점검(기능 수준) 포인트는?
A. 도메인/포리스트 **기능 수준(DFL/FFL)**은 사용 가능한 AD 기능을 좌우합니다. 기능 수준은 각 DC/도메인의 상태를 기준으로 승급 가능 여부가 정해지므로(예: 2003→2008 R2 가능/불가 예시), RODC 도입과 병행해 업그레이드 로드맵을 확인합니다.

 

Q6. RODC에서 쓰기 작업(예: 사용자 비밀번호 변경)은 가능한가?
A. 불가합니다. RODC는 읽기 전용이므로, 비밀번호 변경/그룹 수정 등 쓰기는 RWDC가 처리하도록 참조됩니다. (DC가 쓰기/인증/인가를 제공하되, RODC는 쓰기를 위임)

 

Q7. RODC 분실/도난 시 표준 대응은?
A. 해당 RODC 개체 삭제 시 **“캐시된 암호 모두 재설정”**을 수행하고, 그 RODC 전용 KDC 계정(krbtgt_RODC)의 티켓 신뢰를 무효화합니다. 이후 필요한 계정만 선별 비밀번호 재설정으로 마무리합니다.

 

Q8. RODC와 DNS/동적 업데이트는 어떻게 연동되나?
A. AD 통합 DNS는 RODC에 읽기 전용 복제가 이뤄지고, 클라이언트의 보안 동적 업데이트 쓰기는 RWDC로 프록시됩니다(쓰기 권한은 RWDC).

 

Q9. SYSVOL/GPO와 RODC의 상호작용은?
A. RODC의 SYSVOL은 읽기 전용 복제본입니다. 클라이언트는 로컬 RODC의 SYSVOL에서 GPO를 읽어 적용하지만, 정책 편집/작성은 RWDC에서 수행해야 합니다.

 

Q10. RODC 제거 또는 강제 강등 후 “잔여 흔적” 처리는?
A. Metadata Cleanup이 필요합니다. 2008 이상은 **Active Directory Sites and Services(또는 DSA)**로 정리하고, 2003은 NTDSUTIL 절차를 따릅니다.

 

Q11. RODC 운영 도구는 무엇이 유용한가?
A. DcDiag, RepAdmin, LDP, ADSIEdit, PowerShell 등 표준 진단/관리 도구가 유용합니다. PRP 현황(Allowed/Denied/Revealed), 복제 지연, GC 광고/의존성 등을 정기 점검합니다.

 

Q12. 범용 그룹과 도메인 로컬/글로벌 그룹을 RODC 지점에서 어떻게 설계하나?
A. AGDLP/AGUDLP 원칙을 유지하되, 지점 권한은 도메인 로컬에 매핑하고, 계정은 글로벌로 유지해 토큰 팽창을 억제합니다. 범용 그룹 사용은 GC 의존성과 비용을 고려합니다.

 

Q13. RODC의 복제 특성은?
A. RODC는 인바운드(수신) 복제만 수행하고, 다른 DC의 원본이 되지 않습니다. 쓰기 충돌 위험을 구조적으로 제거해 지점 보안 모델을 단순화합니다.

 

Q14. FAS(RODC Filtered Attribute Set)를 쓰는 이유는?
A. 복제 자체를 RODC에서 제외해야 하는 민감 속성(키·복구정보 등)을 스키마 플래그로 표시해, 지점 서버에 민감 데이터가 남지 않도록 합니다.

 

Q15. 계정 잠금/정책 이벤트는 RODC에서 어떻게 다뤄지나?
A. 권위는 PDC 에뮬레이터에 있으며, RODC는 관련 이벤트를 상류로 전달합니다. WAN 품질이 나쁘면 잠금 판단·전파가 지연될 수 있습니다.

 

Q16. GC 장애가 지점 로그온에 미치는 영향과 완화책은?
A. GC 장애 시 범용 그룹 토큰 빌드 실패로 로그온 실패가 날 수 있습니다. RODC를 GC 겸용으로 두거나, 네트워크 경로·대체 GC를 설계합니다.

 

Q17. 사이트/서브넷 설계가 RODC에 중요한 이유는?
A. DC Locator가 가까운 DC/GC를 고르므로, 잘못된 매핑은 로그온 지연과 WAN 과부하를 유발합니다. RODC 배치 시 사이트 정의를 먼저 정합화합니다.

 

Q18. 기능 수준을 올리면 RODC 관련 이점이 있나?
A. 기능 수준은 AD DS의 사용 가능 기능을 결정합니다(예: 신규 KDC/보안 기능). RODC 자체 기능은 동일하지만, 상위 기능 수준의 보안/복제/정책 이점을 함께 누릴 수 있습니다.

 

Q19. 감사/권한 모델에서 무엇을 주로 본다면 좋은가?
A. 접근 토큰·권한(WhoAmI, 보안 설명자/ACL)·암호 정책을 주기 점검합니다. RODC는 읽기 전용 특성상 권한 위임 범위를 명확히 유지하기 쉽습니다.

 

Q20. 지점 운영 표준(SOP) 최소 항목은?
A. PRP(Allowed/Denied/Revealed) 정기 검토, GC 상태·광고 확인, 복제 상태, 메타데이터 정리 절차 리허설, 도구 세트(DcDiag/RepAdmin/LDP) 기본 점검 목록화입니다.

 

 

Q1. RODC 배치의 1차 목적은?
A. 지점(브랜치) 환경에서 로그온 가용성과 **보안(데이터 최소화)**을 동시에 달성하는 것. 암호 해시·민감 속성은 선별 복제/비복제로 제한하고, 쓰기 작업은 쓰기 가능 DC로 위임(Write referral)한다. WAN 품질 저하 시에도 캐시된 사용자/컴퓨터는 인증 가능.

 

Q2. Password Replication Policy(PRP)의 핵심은?
A. “누구의 암호를 RODC에 캐시할 것인가”를 제어한다.

• Allowed RODC Password Replication Group(허용 목록)
• Denied RODC Password Replication Group(거부·우선순위 ↑, 고권한/민감 계정 포함)
  Denied가 Allowed보다 항상 우선한다.

Q3. 특정 계정을 미리 캐시(Prepopulate)하려면?
A. 배포 전 대상 계정/컴퓨터를 허용 후 사전 캐시한다.

repadmin /rodcpwdrepl <RODCName> <sAMAccountName>

또는 ADUC에서 RODC 개체 속성 → Prepopulate Passwords.

 

Q4. 현재 RODC에 ‘실제로 캐시된’ 계정 확인?
A.repadmin /prp view <RODCName> revealed

Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity <RODCName> -Revealed

 

Q5. RODC가 허용하지 않은 계정 로그온 흐름은?
A. RODC는 인증을 쓰기 가능 DC로 프록시/참조한다(Write referral). 그 과정에서 암호는 RODC에 남지 않는다.

 

Q6. WAN 장애 시 누가 로그인 가능한가?
A. 이미 캐시된 사용자/컴퓨터만 가능. 그 외는 실패한다(계정 잠금/비번 변경 판정도 지연될 수 있음).

 

Q7. RODC 분실/도난 시 표준 대응?
A. ADUC에서 해당 RODC 제거 시 “캐시된 암호 모두 재설정” 옵션 사용 → 캐시되었던 계정들만 선별 비번 재설정. 해당 RODC의 krbtgt_####(RODC 전용 KDC 계정) 암호 재설정으로 그 RODC가 발급한 TGT를 무효화.

 

Q8. krbtgt_####(RODC 전용) 계정의 의미는?
A. 각 RODC에 1:1 매칭되는 로컬 KDC 신뢰 루트. 이 계정 암호를 바꾸면 그 RODC가 발급한 티켓 전체가 폐기된다(다른 DC에는 영향 없음).

 

Q9. RODC에서 쓰기 작업(예: 비번 변경) 가능?
A. 불가. RODC는 읽기 전용이며, 모든 쓰기는 쓰기 가능 DC로 참조된다.

 

Q10. 계정 잠금(Account Lockout)은 누가 결정?
A. 권위는 PDC 에뮬레이터. RODC는 잠금 이벤트를 상류로 전달한다. WAN 이슈가 있으면 판단/전파가 지연될 수 있음.

 

Q11. 스마트카드 로그온, EAP-TLS 등 인증서 기반은?
A. 가능. 단, CRL/OCSP 접근성, GC/UPN 확인 경로가 보장되어야 하며, 사이트 디자인에 따라 WAN 의존이 생길 수 있다.

 

Q12. 누가 RODC에 “인증 시도”했는지 감사하는 방법?
A.repadmin /prp view <RODCName> auth2

• 디렉터리 서비스 감사 정책 활성화로 이벤트 상관 분석.

Q13. RODC Filtered Attribute Set(FAS)은?
A. 민감 속성을 RODC로 아예 복제하지 않게 하는 스키마 플래그. 스키마에서 해당 attributeSchema의 **searchFlags 비트 0x200(RODC 필터링)**을 설정해 RODC 복제를 차단한다(변경 전 보안/앱 영향 평가 필수).

 

Q14. adprep /rodcprep의 역할은?
A. 포리스트/도메인에 RODC가 들어올 수 있도록 DNS 애플리케이션 파티션 권한 등 사전 준비를 자동화한다(배포 전 1회 수행).

 

Q15. IFM(Install From Media)로 RODC를 준비하는 이유?
A. 초기 복제를 WAN 없이 신속히 수행하고, RODC용 IFM은 비밀 데이터 제외로 보안성을 유지한다.

ntdsutil "activate instance ntds" ifm "create rodc C:\IFM"

 

Q16. RODC를 GC로 만들 필요가 있을까?
A. 지점에서 UPN 로그온/범용그룹 토큰 계산/Exchange 의존이 있으면 GC 겸용 권장. 아니면 UGMC로 대체하되 최초 로그온 지연 고려.

 

Q17. DNS 동적 업데이트와 RODC?
A. AD 통합 영역은 RODC에 읽기 전용 복제. 클라이언트의 보안 동적 업데이트는 RODC가 쓰기 가능 DC로 프록시한다. 프록시 실패 시 이벤트/네트워크 경로 점검.

 

Q18. SYSVOL/GPO는 RODC에서 어떻게?
A. DFS-R로 읽기 전용 복제. 편집은 금지, 클라이언트는 로컬 RODC의 SYSVOL에서 읽어 적용한다(편집·작성은 쓰기 가능 DC에서).

 

Q19. 사이트/서브넷 매핑 오류의 영향?
A. 클라이언트가 엉뚱한 DC/GC로 바인딩하며 로그온 지연·WAN 증가. 배포 직후 nltest /dsgetsite로 검증 필수.

 

Q20. 운영 점검 체크포인트는?
A. PRP(allowed/denied/revealed/auth2), 복제 지연, GC/UGMC 상태, DNS 프록시 실패 이벤트, krbtgt_#### 변경 이력, ARS(Administrator Role Separation) 위임 상태, 백업/재배치(이미지+IFM) 계획.