06Identity Source — AD QueryIdentity Source — AD Query
AD Query 는 Active Directory에서 클라이언트 없이 신원을 매끄럽게 취득 하는 소스입니다. 엔드포인트에 아무것도 설치하지 않고 AD가 기록하는 보안 이벤트 로그를 읽어 사용자·컴퓨터를 식별하므로, 신원 기반 감사·로깅과 데스크톱 사용자 에 특히 잘 맞습니다. 이 장은 AD Query를 켜고, Single User Assumption과 서비스 계정 제외를 다루고, NTLMv2 인증으로 맞추고, LDAP 그룹 자동 갱신·도메인 컨트롤러 선택·상태 점검·문제 해결까지 AD Query 구성의 전 과정을 빠짐없이 정리합니다. 마지막에는 WMI가 도메인 컨트롤러에 주는 성능 영향도 다룹니다.
동작과 전제
AD Query는 AD의 Security Event Log를 WMI로 읽어 누가 어느 IP에서 로그인했는지 알아냅니다. 그래서 AD 사용자·컴퓨터만 탐지 한다는 한계가 있습니다. Microsoft Active Directory를 쓰는 조직이라면 AD Query만으로 모든 AD 사용자에게 클라이언트 없는 직원 접속(clientless employee access) 을 줄 수 있습니다. 접근 통제는 방화벽 규칙에 Access Role 객체를 넣어 적용하는데, Access Role은 사용자·컴퓨터·네트워크 위치를 하나의 객체 로 묶은 것입니다. 로그인해 인증된 AD 사용자는 그 방화벽 규칙에 따라 자원에 매끄럽게 접근합니다.
설정은 AD 관리자 자격 증명이 필요 할 만큼 간단하지만, 관리자 계정을 서드파티 장비의 서비스 계정으로 쓰기 꺼려진다면 관리자 권한 없이 AD Query를 구성 하는 방법(sk43874)도 있습니다.
인증 모드 — NTLMv1과 NTLMv2
| 게이트웨이 버전·상황 | 업그레이드 전 구성 | 기본 인증 모드 |
|---|---|---|
| R82 — 클린 설치 | 해당 없음 (R81.20부터 기본은 NTLMv2) | NTLMv2 |
| R82 — 하위 버전에서 업그레이드 | adlogconfig 명령으로 인증 모드를 바꾸지 않음 (R81.10 이하의 기본은 NTLMv1) | NTLMv2 |
| R82 — 하위 버전에서 업그레이드 | adlogconfig 명령으로 인증 모드를 NTLMv1으로 변경함 (예: R81.10에서 NTLMv1→NTLMv2→다시 NTLMv1로 바꾼 경우) | NTLMv1 |
즉 클린 설치이거나 인증 모드를 손대지 않았다면 NTLMv2 가 되고, 과거에 NTLMv1으로 명시적으로 돌려놓았다면 그 설정이 유지 됩니다.
AD Query 구성 절차
1. 게이트웨이에서 AD Query 켜기
- 왼쪽 탐색 패널에서 Gateways & Servers 를 클릭합니다.
- Security Gateway 또는 Cluster 객체를 엽니다.
- General Properties 페이지에서 (아직 안 했다면) Identity Awareness Software Blade를 선택합니다.
- Identity Awareness 페이지에서 Active Directory Query 를 선택합니다.
- Settings 버튼을 클릭하면 Active Directory Query 창이 열립니다.
- Active Directory Domains 섹션에서 LDAP Account Unit을 다룹니다.
- 초록색 더하기
[+]를 클릭하고 기존 LDAP Account Unit 객체를 골라 목록에 추가 합니다. - 목록의 LDAP Account Unit을 선택하고 빨간색 빼기
[-]를 클릭하면 목록에서 제거 합니다.
- 초록색 더하기
2. (선택) Single User Assumption 구성
AD Query를 IP 주소당 활성 계정을 하나만 허용 하도록 설정할 수 있습니다. 이것을 Single User Assumption 이라고 합니다. 사용자 A가 timeout 전에 로그아웃하고 사용자 B가 로그인하면, A의 세션은 자동으로 닫히고 권한이 취소 되며 B만 유일한 활성 계정으로 그의 권한만 유효 해집니다.
a. Service Account(사용자·컴퓨터·네트워크) 제외하기
서비스 계정(사용자·컴퓨터·네트워크)은 AD Query 스캔에서 수동으로 제외 할 수도 있고, 의심되는 서비스 계정을 자동으로 탐지·제외 하도록 설정할 수도 있습니다. Identity Awareness는 동시에 지정한 수보다 많은 컴퓨터에 로그인한 사용자 계정 을 서비스 계정으로 식별합니다.
- Identity Awareness 페이지에서 Active Directory Query 를 선택하고 Settings 를 클릭합니다.
- Advanced 버튼을 클릭하면 Active Directory Query Advanced 창이 열립니다.
- Excluded Users / Computers 섹션에서 제외할 사용자·컴퓨터 계정 이름을 입력하고 Add 를 클릭합니다.
*와?와일드카드, 또는 정규 표현식 을 써서 여러 계정을 한 번에 지정할 수 있습니다(정규 표현식은 부록 "Regular Expressions" 참고).- 정규 표현식 구문은 다음과 같습니다.
regexp:<Regular Expression>
- (선택) Automatically exclude users which are logged into more than [ ] machines simultaneously(동시에 [ ]대보다 많은 컴퓨터에 로그인한 사용자를 자동 제외) 옵션을 선택하고, 관련 필드에 기준이 되는 컴퓨터 대수(threshold) 를 입력합니다.
- Excluded Networks 섹션에서 네트워크를 다룹니다.
- 초록색 더하기
[+]를 클릭해 기존 Network 객체를 고르거나(또는 New로 새로 만들어) 목록에 추가합니다. - Network 객체를 선택하고 빨간색 빼기
[-]를 클릭하면 목록에서 제거합니다.
- 초록색 더하기
- OK 를 클릭해 Active Directory Query Advanced 창을 닫습니다.
b~e. Single User Assumption 마무리
- Active Directory Query 창에서 Assume that only one user is connected per computer(컴퓨터당 한 사용자만 연결된다고 가정) 를 선택합니다. > 참고 — Single User Assumption을 끄려면 이 옵션을 해제하면 됩니다.
- OK 를 클릭해 Active Directory Query 창을 닫습니다.
- OK 를 클릭해 Security Gateway/Cluster 객체를 닫습니다.
- Security Gateway/Cluster 객체에 Access Control Policy를 설치 합니다.
3. (선택) 의심 서비스 계정 목록 관리
자동 제외가 켜져 있으면 Identity Awareness는 10분마다 의심 서비스 계정을 탐색 합니다. 의심 서비스 계정은 재부팅해도 살아남는 영구 데이터베이스에 저장 되고, 새 서비스 계정이 탐지되면 SmartConsole > Logs & Events view > Logs 탭에 로그가 뜹니다.
| 동작 | 명령 |
|---|---|
| 의심 서비스 계정 전체 보기 | ``adlog a control srv_accounts show`` |
| 서비스 계정 스캔 즉시 실행 (Assume that only one user is connected 옵션을 켜기 전에 유용) | ``adlog a control srv_accounts find`` |
| 특정 계정을 서비스 계정 DB에서 제거 | ``adlog a control srv_accounts unmark <account name>`` |
| 의심 서비스 계정 DB 전체 비우기 | ``adlog a control srv_accounts clear`` |
자세한 내용은 "adlog control"(248쪽 상당) 항목을 참고하세요.
4. (권장) 인증 모드를 NTLMv2로 맞추기
인증 모드가 NTLMv2를 쓰도록 확인하는 절차입니다. Security Management Server 와 Security Gateway 양쪽에서 똑같이 진행합니다.
a. Security Management Server에서
- 명령줄에 접속해 Expert mode 로 로그인합니다.
- 다음을 실행합니다.
adlogconfig a
- Authentication mode 섹션을 살핍니다.
- [x] Use NTLMv2 옆에
[x]가 있으면 — 다음 단계("Use Automatic LDAP Group Update")로 건너뜁니다. - [x] Use NTLMv1 옆에
[x]가 있으면 — 다음 옵션의 번호를 입력합니다.
- [x] Use NTLMv2 옆에
Change authentication mode NTLMv1/NTLMv2
그리고 Use NTLMv2 옆에 [x] 가 표시되는지 확인합니다.
4. 다음 옵션의 번호를 입력해 저장하고 빠져나옵니다.
Exit and save
b. Security Gateway에서
위 a와 동일하게 진행합니다 — Expert mode 로그인 → adlogconfig a 실행 → Authentication mode 확인 → NTLMv1이면 Change authentication mode NTLMv1/NTLMv2 옵션으로 NTLMv2로 변경 → Exit and save.
c. SmartConsole에서 Identity Awareness 마법사 다시 실행
- 왼쪽 탐색 패널에서 Gateways & Servers 를 클릭합니다.
- Security Gateway/Cluster 객체를 엽니다.
- General Properties 창에서 Identity Awareness 를 해제 합니다. 단, OK는 누르지 마세요.
- General Properties 창에서 다시 Identity Awareness 를 선택하면 Identity Awareness Configuration 창이 열립니다.
- Identity Awareness 마법사를 따라 진행합니다.
- OK 를 클릭해 객체를 닫습니다.
- Security Gateway/Cluster 객체에 Access Control Policy를 설치합니다.
5. 자동 LDAP 그룹 갱신(Automatic LDAP Group Update)
Identity Awareness는 LDAP 그룹 멤버십의 변경을 자동으로 인식 하고 신원 정보(Access Role 포함)를 갱신합니다.
LDAP Group Update는 기본적으로 활성화 되어 있으며, 끌 수도 있습니다.
자동 LDAP 그룹 갱신 끄기
- Security Gateway/각 Cluster Member의 명령줄에 접속해 Expert mode 로 로그인합니다.
- 다음을 실행합니다.
adlogconfig a
- 다음 옵션의 번호를 입력합니다.
Turn LDAP groups update on/off
그러면 LDAP groups update 알림 상태가 [ ](비활성)로 바뀝니다. 이미 비활성인 상태에서 이 옵션을 다시 고르면 [X](활성)으로 토글됩니다.
4. Exit and save 옵션 번호를 입력해 저장·종료합니다.
5. SmartConsole에서 Access Control Policy를 설치합니다.
LDAP 그룹 알림 옵션 구성하기
- 명령줄에서 Expert mode 로 로그인합니다.
adlogconfig a를 실행합니다.- 다음 옵션의 번호를 입력합니다.
Notifications accumulation time
- 알림 사이의 시간을 초 단위로 입력합니다(기본값 10초).
- 사용자 관련 변경만 알림을 보낼지 정하는 다음 옵션의 번호를 입력합니다.
Update only user-related LDAP changes
LDAP 캐시와 즉시 반영
자동 LDAP 그룹 갱신은 즉시 일어나지 않 습니다. Identity Awareness가 사용자·그룹을 먼저 LDAP 캐시에서 찾는데, 캐시에는 갱신된 그룹 정보가 들어 있지 않기 때문입니다. 기본적으로 캐시에는 1,000명의 사용자 가 담기고, 캐시된 사용자 정보는 15분마다 갱신 됩니다.
자동 그룹 갱신을 즉시 반영받으려면 LDAP 캐시를 꺼야 합니다. 다만 이렇게 하면 Identity Awareness가 예상보다 느리게 동작할 수 있습니다.
LDAP 캐시 끄기:
- SmartConsole에서 Menu > Global properties 로 갑니다.
- 왼쪽 탐색 트리에서 User Directory 를 클릭합니다.
- Timeout on cached users 를 0 으로 바꿉니다.
- Cache size 를 0 으로 바꿉니다.
- OK 를 클릭합니다.
- Security Gateway/Cluster 객체에 Access Control Policy를 설치합니다.
6. 게이트웨이별 도메인 컨트롤러 지정
조직의 Active Directory는 여러 사이트로 나뉘고, 각 사이트마다 자체 도메인 컨트롤러 를 두고 그것을 Security Gateway가 보호할 수 있습니다. 모든 도메인 컨트롤러가 같은 Active Directory에 속하면, SmartConsole에는 LDAP Account Unit 하나만 생깁니다.
게이트웨이에서 AD Query가 켜져 있을 때, 게이트웨이가 일부 도메인 컨트롤러하고만 통신 하도록 설정할 수 있습니다. AD Query가 무시해야 할 도메인 컨트롤러는, Account Unit의 기본 우선순위(priority)를 1000보다 큰 값 으로 둡니다.
도메인 컨트롤러 지정 절차(위 예시 기준):
- 왼쪽 탐색 패널에서 Gateways & Servers 를 클릭합니다.
- Security Gateway/Cluster 객체를 엽니다.
- 왼쪽 트리에서 Other 옆
[+]를 클릭하고 User Directory 를 클릭합니다. - Selected Account Units list 옵션을 선택합니다.
- Add 를 클릭합니다.
- 해당 Account Unit 객체를 선택합니다. > 중요 — Active Directory에 접속하는 계정은 개인 사용자 계정이 아니라 서비스 계정(service account) 이어야 합니다.
- OK 를 클릭합니다.
- Use default priorities 옵션을 해제합니다.
- dc1, dc4, dc5에 우선순위 1001 을 설정합니다.
- 도메인 컨트롤러를 선택합니다.
- Priority 필드에
1001을 입력합니다. - Set 을 클릭합니다.
- OK 를 클릭합니다.
- Security Gateway/Cluster 객체에 Access Control Policy를 설치합니다.
7. 도메인 컨트롤러 상태 확인
도메인 컨트롤러가 올바로 구성됐는지 확인합니다. 게이트웨이가 어떤 도메인 컨트롤러와 통신하고 어떤 것을 무시하는지 점검하려면 다음을 실행합니다.
- Security Gateway/각 Cluster Member의 명령줄에 접속해 Expert mode 로 로그인합니다.
- 다음을 실행합니다.
adlog a dc
자세한 내용은 "adlog dc"(250쪽 상당) 항목을 참고하세요.
AD Query 문제 해결
도메인 컨트롤러와 Identity Awareness 게이트웨이/Log Server 사이에 연결 문제가 있을 때 따라가는 절차입니다.
1. 연결 문제 해결
- Identity Awareness 게이트웨이와 Log Server에서 도메인 컨트롤러로 ping 합니다.
- 도메인 컨트롤러에서 게이트웨이와 Log Server로 ping 합니다.
- 필요에 따라 표준 네트워크 진단을 수행합니다.
- Logs & Events > Logs 탭에서 AD Query가 설정된 게이트웨이(Source)와 도메인 컨트롤러(Destination) 사이에 drop이 있는지 확인합니다. drop이 있으면 "Configuring the Firewall"(방화벽 구성)과 sk58881을 참고합니다.
2. WBEMTEST로 WMI 동작·접근성 확인
Microsoft WBEMTEST 유틸리티로 WMI가 동작하고 접근 가능한지 검증합니다.
a. 유틸리티에 연결:
- Start > Run 을 클릭합니다.
- Run 창에
wbemtest.exe를 입력합니다. - Windows Management Instrumentation Tester 창에서 Connect 를 클릭합니다.
- Connect 창의 첫 필드에 도메인 컨트롤러를 다음 형식으로 입력합니다.
\\<IP address>\root\cimv2
- Credentials > User 필드에 정규화된 AD 사용자 이름(fully qualified) 을 입력합니다. 예:
ad.company.com\admin - 그 사용자의 암호를 입력합니다.
- Connect 를 클릭합니다.
- Tester 창이 버튼이 활성화된 채로 다시 나타나면 WMI가 완전히 동작 하는 것입니다.
연결이 실패하거나 오류가 나면 다음을 확인합니다.
- 연결 문제 ("연결 문제 해결" 참고)
- 잘못된 도메인 관리자 자격 증명 ("도메인 관리자 자격 증명 확인" 참고)
- WMI 서비스가 실행 중이 아님 ("도메인 컨트롤러의 WMI 서비스 확인" 참고)
- 게이트웨이/Log Server와 도메인 컨트롤러 사이를 방화벽이 막고 있음 ("Configuring the Firewall" 참고)
b. 도메인 관리자 자격 증명 확인:
- Start > Run 을 클릭합니다.
- Run 창에 다음을 입력합니다.
\\<domain controller IP address>\c$
예: \\11.22.33.44\c$
3. Logon 창에 도메인 관리자 사용자 이름·암호를 입력합니다.
4. 도메인 컨트롤러의 루트 디렉터리가 보이면 계정 권한이 충분 하다는 뜻입니다. 오류가 뜨면 다음 중 하나입니다.
- 권한 부족 → 도메인 관리자로 정의되지 않은 것이니, 도메인 관리자 자격 증명을 확보 합니다.
- 사용자 이름·암호 오류 → 확인 후 재시도합니다.
- 도메인 컨트롤러 IP가 틀렸거나 연결 문제가 있습니다.
c. 도메인 컨트롤러의 WMI 서비스 확인:
- Start > Run 을 클릭합니다.
- Run 창에
services.msc를 입력합니다. - Windows Management Instrumentation 서비스를 찾아 서비스가 시작됐는지 확인합니다. 시작 안 됐으면 오른쪽 클릭해 Start 를 선택합니다.
활용 시나리오 — 노트북 접속
James Wilson 은 ACME의 HR 파트너입니다. ACME IT는 악성코드 감염과 무단 접근 위험을 줄이려고 HR 서버 접근을 지정된 IP로만 제한 하고 싶어 합니다. 그래서 정책은 James의 데스크톱(고정 IP 10.0.0.19)에서만 접근을 허용합니다. 기존 Rule Base에는 다음과 같은 규칙이 있습니다.
| Name | Source | Destination | VPN | Service | Action | Track |
|---|---|---|---|---|---|---|
| Jwilson to HR Server | Jwilson | HR_Web_Server | Any Traffic | Any | accept | Log |
그런데 James가 노트북을 받았고, 조직 어디에서든 HR Web Server에 접근 하고 싶어 합니다. IT가 노트북에 고정 IP를 줬지만 그러면 책상에서만 쓸 수 있어 이동성이 사라집니다. 이 시나리오를 풀려면 IT 관리자가 다음을 합니다.
- Security Gateway에서 Identity Awareness 를 켜고, Identity Source 중 하나로 AD Query 를 선택한 뒤 정책을 설치합니다.
(고정 IP 규칙 대신 James의 신원으로 접근을 허용하도록 Access Role 기반 규칙으로 바꾸면, James가 어느 IP에서 접속하든 HR Web Server에 접근할 수 있게 됩니다.)
데이터베이스 설치
AD Query 마법사를 끝낸 뒤 데이터베이스를 설치하는 과정입니다.
- 마법사 마지막의 Identity Awareness is Now Active 페이지에 취득 방법 요약이 나오면 Finish 를 클릭합니다.
- (선택) Log Server 객체의 Identity Awareness 페이지에서 해당 설정을 구성합니다.
- OK 를 클릭합니다.
데이터베이스 설치:
- SmartConsole에서 Menu > Install database 로 가면 Install Database 창이 열립니다.
- 데이터베이스를 설치할 모든 Check Point 객체를 선택 합니다.
- Install database 창에서 Install 을 클릭합니다.
- SmartConsole 창에서 Publish & Install 을 클릭합니다.
- 작업 끝에
Install Database on XXX Succeeded메시지가 뜰 때까지 기다립니다.
WMI 성능 영향
AD Query가 WMI로 도메인 컨트롤러를 읽을 때 생기는 부하는 다음과 같습니다.
Log Server와 도메인 컨트롤러 사이의 대역폭
Log Server와 도메인 컨트롤러 사이에 오가는 데이터양은 생성되는 이벤트의 양에 달려 있습니다. 이벤트에는 event log와 authentication event가 포함되며, 그 양은 네트워크에서 도는 애플리케이션에 따라 달라 집니다 — 인증 요청이 많은 프로그램일수록 로그가 많아 집니다. 관찰된 대역폭은 사용자 1,000명당 0.1 ~ 0.25 Mbps 범위입니다.
CPU 영향
AD Query를 쓸 때 도메인 컨트롤러 CPU에 주는 영향은 3% 미만 입니다.