AD

Active Directory

조직 안의 사용자, 컴퓨터, 그룹, 정책 같은 자원을 한곳에서 중앙 집중식으로 인증하고 관리하는 시스템이다. 쉽게 말해 "네트워크용 전화번호부 + 신원 관리소"다. 누가(사용자), 어떤 장비(컴퓨터)가, 어떤 권한으로 무엇에 접근할 수 있는지를 하나의 데이터베이스에 담아두고, 로그인, 권한 검사, 정책 배포를 이 데이터베이스 기준으로 처리한다.

AD가 없다면 서버와 PC마다 계정을 따로 만들고 비밀번호를 각각 관리해야 한다. AD는 이를 단일 신원(single identity) 으로 묶는다. PC에 한 번 로그인하면 파일 서버, 프린터, 인트라넷 같은 도메인 자원에 다시 인증하지 않고 접근할 수 있고, 관리자는 정책을 한 번만 정의해 전체에 배포한다.

SSO(Single Sign-On) 는 한 번 인증하면 이후 여러 서비스에 다시 로그인하지 않는 방식이다. 중앙 인증 서버가 신원을 확인해 서명된 증표를 발급하고, 각 서비스는 비밀번호를 직접 확인하지 않고 그 증표만 검증한다. AD의 도메인 로그인이 이 구조이며, 증표에 해당하는 것이 Kerberos 티켓이다. SSO는 사내망(또는 VPN)에서 같은 AD에 연결된 서비스에만 통하는데, Slack 같은 외부 SaaS는 Kerberos 티켓을 받지 않으므로, 온프레미스의 AD FS나 클라드의 Entra ID 같은 서비스가 필요하다.

왜 필요한가

계정과 권한을 장비마다 개별 관리하면 조직이 커질수록 다음 문제가 생긴다.

사용자가 입사/퇴사할 때마다 수십 대의 서버와 PC에서 계정을 만들거나 지워야 한다
비밀번호 정책, 화면 잠금, 소프트웨어 설치 제한 같은 규칙을 장비마다 손으로 설정해야 한다
"이 사람이 어디에 접근 가능한가"를 한눈에 볼 방법이 없다

AD는 이를 중앙 집중 관리로 해결한다.

계정을 한 번 만들면 도메인 전체에서 유효하다 (입사와 퇴사 처리가 한 곳)
그룹 정책(GPO)으로 수천 대의 PC에 동일한 보안 설정을 일괄 적용한다
인증과 권한 정보가 한 데이터베이스에 있어 감사(audit)와 통제가 쉽다

네트워크 관점에서도 중요하다. 802.1X 인증, VPN 접속, 무선 로그인, 스위치, 라우터 관리자 로그인(TACACS+ 연동) 등 다양한 접근 통제의 identity source 로 AD가 자주 사용된다.

구성 요소

논리 구조

AD는 자원을 계층적으로 조직한다.

단위	설명
Domain	관리와 보안 경계의 기본 단위. 하나의 계정과 정책 데이터베이스를 공유한다 (예: `corp.example.com`)
Tree	같은 namespace을 공유하는 도메인들의 계층 (부모–자식 도메인)
Forest	AD의 최상위 보안 경계. 하나 이상의 트리를 묶은 전체
OU (Organizational Unit)	도메인 내부에서 사용자와 컴퓨터를 부서별로 나누는 폴더 같은 컨테이너. GPO 적용 단위

같은 Forest에 속한 도메인들은 자동으로 양방향 신뢰 관계(Trust)를 맺기 때문에, 추가 설정 없이 서로의 자원에 접근할 수 있다. Forest가 다르면 기본 신뢰가 없어 관리자가 Trust를 명시적으로 만들어야 한다. 그래서 보안 격리가 필요할 때는 도메인을 나누는 것으로 부족하고 Forest를 나눠야 한다. 한 도메인의 DC(Domain Controller)가 침해되면 같은 Forest의 다른 도메인까지 권한이 확장될 수 있다.

물리 구조

Domain Controller (DC): AD 데이터베이스를 실제로 보관하고 인증을 처리하는 서버. 여러 대를 두어 이중화하며, DC끼리 데이터를 복제(replication)한다
Global Catalog (GC): Forest 전체 객체의 부분 정보를 담아 도메인 간 검색과 로그인을 빠르게 해주는 특수 DC
Site: 물리적 네트워크 위치(대개 IP 서브넷 기준). DC 복제 트래픽을 지역 간에 효율적으로 흐르게 하려고 정의한다

동작 원리

AD 로그인의 핵심 인증 프로토콜은 Kerberos다. (구형 호환용으로 NTLM도 있지만 신규 사용은 지양된다.)

아래 그림의 DC(Domain Controller)는 AD 데이터베이스를 보관하고 인증을 처리하는 서버이며, Kerberos에서 티켓을 발급하는 KDC(Key Distribution Center) 역할을 함께 맡는다.

[사용자 PC]                    [DC (KDC 역할)]                 [파일 서버]
    │                              │                              │
    │ 1. 로그인 (ID/비번)             │                              │
    │ ───────────────────────────▶ │                              │
    │                              │ 신원 확인 후 TGT 발급            │
    │ 2. TGT 수신 ◀──────────────── │                              │
    │                              │                              │
    │ 3. "파일서버 쓸 티켓 줘"         │                              │
    │    (TGT 제시)                 │                              │
    │ ──────────────────────────▶  │                              │
    │ 4. 서비스 티켓 수신 ◀──────────  │                              │
    │                              │                              │
    │ 5. 서비스 티켓 제시                                             │
    │ ──────────────────────────────────────────────────────────▶ │
    │                                            접근 허용 ◀────────│

핵심은 비밀번호를 매번 서버에 보내지 않는다는 점이다. DC(KDC, Key Distribution Center 역할)가 처음에 한 번 신원을 확인해 TGT(Ticket Granting Ticket) 를 주고, 이후에는 이 티켓으로 각 서비스용 티켓을 받아 접근한다. 티켓 기반이라 비밀번호가 네트워크에 반복 노출되지 않고, 서비스에 접근할 때마다 다시 로그인할 필요도 없다.

내부적으로 AD가 의존하는 프로토콜은 다음과 같다.

프로토콜	포트	역할
DNS	53	클라이언트가 DC를 찾는 데 필수 (SRV 레코드). AD는 DNS 없이는 동작하지 않는다
Kerberos	88	기본 인증
LDAP	389 / 636(LDAPS)	디렉터리 조회, 수정
Global Catalog	3268 / 3269	Forest 전역 검색
SMB / RPC	445 등	GPO 배포, 파일 공유, 복제

LDAP와의 관계

AD를 이야기할 때 LDAP(Lightweight Directory Access Protocol) 이 자주 함께 언급된다.

LDAP은 디렉터리 서비스(사용자·그룹·컴퓨터 등의 개체 정보를 계층 구조로 저장하는 데이터베이스)에 질의하고 인증하기 위한 표준 프로토콜이다.
AD는 마이크로소프트가 만든 디렉터리 서비스 제품으로, 디렉터리 데이터를 조회·수정하는 프로토콜로 LDAP(TCP 389, LDAPS는 TCP 636)을 지원한다.

즉 리눅스 서버나 애플리케이션이 AD의 사용자 정보를 조회할 때 흔히 LDAP(또는 LDAPS)으로 붙는다. AD는 LDAP 외에도 Kerberos(인증), DNS(도메인 컨트롤러 탐색), 그룹 정책(GPO, 설정 배포)을 하나의 도메인 서비스로 통합한다.

그룹 정책 (GPO)

Group Policy Object는 AD의 강력한 관리 도구다. 사용자와 컴퓨터에 적용할 설정(비밀번호 규칙, 화면 잠금 시간, 소프트웨어 배포, USB 차단 등)을 정의해 OU/도메인/사이트 단위로 배포한다.

관리자가 정책을 한 번 정의하면 대상 PC들이 부팅하거나 로그인할 때 자동으로 적용받는다
부서(OU)별로 다른 정책을 줄 수 있어 세밀한 통제가 가능하다
수천 대 규모에서도 일괄 관리가 되어 운영 비용을 크게 줄인다

Entra ID

전통적인 AD(정식 명칭 AD DS, Active Directory Domain Services)는 사내 서버(온프레미스)에 DC를 두는 모델이다. 클라우드와 SaaS가 늘면서 마이크로소프트는 클라우드 기반 신원 서비스 Microsoft Entra ID(구 Azure Active Directory)를 별도로 제공한다.

구분	AD DS (온프레미스)	Entra ID (클라우드)
위치	사내 DC 서버	마이크로소프트 클라우드
주 대상	도메인 가입 PC와 서버, 파일 공유	SaaS, 웹앱(Microsoft 365 등) SSO
인증	Kerberos, NTLM, LDAP	OAuth 2.0, OpenID Connect, SAML
구조	Domain / Forest / OU / GPO	플랫한 테넌트, OU/GPO 없음

이름은 비슷하지만 프로토콜과 구조가 다르다. 많은 조직이 둘을 하이브리드로 연동(Entra Connect)해 온프레미스 계정을 클라우드로 동기화한다.

네트워크 관점의 고려사항

DNS 의존: AD는 DNS에 완전히 의존한다. 클라이언트는 DNS SRV 레코드로 DC를 찾으므로, DNS 설정이 틀어지면 로그인과 인증이 전부 실패한다
방화벽 정책: DC와 클라이언트 사이에 위 표의 포트들(53, 88, 389, 445 등)이 열려 있어야 한다. 세그멘테이션 설계 시 AD 트래픽 경로를 반드시 고려한다
인증 연동의 원천: 802.1X, VPN, 무선(WPA-Enterprise), 네트워크 장비 관리자 로그인(TACACS+/RADIUS) 등이 AD를 백엔드 신원 저장소로 사용하는 경우가 많다
DC 이중화와 사이트: DC는 여러 대로 이중화하고, 지사가 여러 곳이면 Site를 정의해 복제 트래픽이 WAN을 비효율적으로 오가지 않게 한다
보안 표적: AD는 조직 신원의 중심이라 공격의 핵심 표적이다. DC가 침해되면 도메인 전체 계정이 함께 노출되므로, 관리자 계정 보호, 티어링, 모니터링이 중요하다