PDC 에뮬레이터의 이벤트 ID 4740과 PowerShell 한 줄 명령으로 Active Directory 계정 잠금 원인 컴퓨터를 즉시 식별하고, 반복 잠금의 근본 원인까지 추적하는 2026년 헬프데스크 실전 가이드.
업데이트: 2026년 6월 4일
Active Directory 계정 잠금 원인을 찾는 가장 빠른 방법은 PDC 에뮬레이터 도메인 컨트롤러의 보안 로그에서 이벤트 ID 4740을 검색하여 "Caller Computer Name" 필드를 확인하는 것입니다. 솔직히 말해서, 이 한 가지 사실만 알아도 헬프데스크 티켓의 절반은 5분 안에 끝낼 수 있습니다. 이 글에서는 PowerShell 한 줄 명령으로 잠금 원인 장치를 즉시 식별하고, Search-ADAccount로 잠긴 계정 목록을 추출하며, 모바일 기기에 캐시된 만료된 비밀번호 같은 반복적인 잠금 패턴까지 근본 원인을 추적하는 2026년 최신 절차를 정리합니다.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} 한 줄로 최근 잠금 이벤트와 잠금을 유발한 원본 컴퓨터(Caller Computer Name)를 즉시 확인할 수 있습니다.LockoutStatus.exe는 도메인 전체에서 사용자의 badPwdCount를 실시간으로 비교할 수 있는 표준 도구입니다.repadmin /showrepl로 점검해야 잘못된 잠금 정책 평가를 방지할 수 있습니다.Active Directory 계정 잠금은 사용자가 도메인 정책에 정의된 임계값(보통 5~10회) 이상 잘못된 비밀번호를 입력했을 때 자동으로 발생하는 보안 보호 메커니즘입니다. 그러나 헬프데스크 현장에서 실제로 잠긴 계정을 분석해 보면, 사용자가 직접 키보드로 비밀번호를 잘못 친 경우는 30%에 불과합니다. 나머지 대부분은 어딘가에 저장된 만료된 자격 증명이 백그라운드에서 반복적으로 인증을 시도하면서 발생합니다.
제가 지난 분기에 처리한 50건 이상의 반복 잠금 티켓을 분석해 본 결과, 가장 흔한 원인은 다음과 같았습니다. 첫째, 사용자가 비밀번호를 변경했지만 모바일 기기의 Outlook 또는 ActiveSync 클라이언트가 여전히 옛 비밀번호로 동기화를 시도하는 경우입니다(이게 진짜 1위입니다). 둘째, Windows 자격 증명 관리자(Credential Manager)에 저장된 자격 증명이 변경되지 않은 경우. 셋째, 예약된 작업(Scheduled Task)이 특정 서비스 계정의 옛 비밀번호로 실행되도록 구성되어 있는 경우. 넷째, 매핑된 네트워크 드라이브가 만료된 자격 증명을 캐시한 채 재연결을 시도하는 경우. 다섯째, 도메인 컨트롤러 간 복제 지연으로 인해 한 DC에서는 비밀번호가 변경되었지만 다른 DC가 이를 늦게 받아 잘못된 인증으로 판단하는 경우입니다.
이런 원인을 무작정 찾으려고 사용자 PC를 뒤지는 건 시간 낭비입니다. 다행히 Windows Server는 모든 잠금 이벤트를 보안 로그에 명확히 기록하고, 잠금을 유발한 정확한 컴퓨터 이름까지 캡처해 줍니다. 잘 활용하면 30초면 원인 장치를 특정할 수 있죠.
이벤트 ID 4740은 Windows 보안 감사 로그에서 사용자 계정이 잠겼음을 알리는 표준 이벤트입니다. 이 이벤트는 "A user account was locked out" 메시지와 함께 다음 핵심 필드를 포함합니다: Subject(잠금을 처리한 DC), Account That Was Locked Out(잠긴 사용자), Caller Computer Name(잘못된 비밀번호 시도가 시작된 원본 컴퓨터). 이 중 마지막 필드가 헬프데스크에서 가장 중요합니다.
중요한 점은 4740 이벤트가 임의의 도메인 컨트롤러에 기록되는 것이 아니라는 사실입니다. Windows Server는 계정 잠금이 발생한 DC에서 즉시 이를 PDC 에뮬레이터 역할을 보유한 DC로 전달합니다. 따라서 잠금 원인을 추적할 때는 반드시 PDC 에뮬레이터의 보안 로그를 살펴야 합니다. 다른 DC의 로그만 보면 이벤트가 누락된 것처럼 보일 수 있습니다(제가 처음 이 작업을 할 때 정확히 이 함정에 빠졌습니다).
또한 4740 이벤트는 기본적으로 활성화되어 있지만, 일부 환경에서는 "계정 관리 감사 정책"이 강제되지 않은 경우 기록되지 않을 수 있습니다. 정책을 확인하려면 그룹 정책 관리 콘솔에서 컴퓨터 구성 → Windows 설정 → 보안 설정 → 고급 감사 정책 구성 → 계정 관리 → 사용자 계정 관리 감사를 "성공" 및 "실패"로 설정해야 합니다. Microsoft Learn의 4740 이벤트 공식 문서에서 모든 필드의 의미와 감사 정책 구성 방법을 확인할 수 있습니다.
잠금 추적의 첫 단계는 도메인의 PDC 에뮬레이터 역할을 보유한 도메인 컨트롤러를 식별하는 것입니다. PowerShell을 도메인 가입된 워크스테이션이나 다른 DC에서 관리자 권한으로 실행한 후 다음 명령을 입력하세요.
# 현재 도메인의 PDC 에뮬레이터 호스트명 가져오기
$pdc = (Get-ADDomain).PDCEmulator
Write-Host "PDC 에뮬레이터: $pdc" -ForegroundColor Cyan
# PDC 에뮬레이터의 OS 버전과 가용성 확인
Test-Connection -ComputerName $pdc -Count 2 -Quiet
Get-ADDomainController -Identity $pdc | Select-Object Name, OperatingSystem, Site, IPv4Address위 명령은 RSAT(Remote Server Administration Tools)에 포함된 ActiveDirectory 모듈이 필요합니다. Windows 10/11 클라이언트에서는 Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 명령으로 설치할 수 있습니다.
PDC 에뮬레이터를 확인했다면, 이제 해당 서버의 보안 이벤트 로그에 원격으로 접근할 수 있는 권한이 필요합니다. 일반적으로 도메인 관리자(Domain Admins) 그룹 멤버이거나 이벤트 로그 판독기(Event Log Readers) 그룹에 속해 있어야 합니다. 권한이 없다면 다음 절차도 모두 실패하므로 먼저 권한부터 확인하세요.
잠금 원인을 찾는 가장 빠른 방법은 PDC 에뮬레이터의 보안 로그에서 4740 이벤트를 PowerShell로 직접 쿼리하는 것입니다. 다음 스크립트는 특정 사용자에 대한 최근 잠금 이벤트와 원본 컴퓨터를 즉시 반환합니다.
# 잠금 원인을 추적할 사용자 SamAccountName 지정
$user = "kim.jihoon"
$pdc = (Get-ADDomain).PDCEmulator
# 최근 7일간 4740 이벤트 조회
$filter = @{
LogName = 'Security'
Id = 4740
StartTime = (Get-Date).AddDays(-7)
}
Get-WinEvent -ComputerName $pdc -FilterHashtable $filter |
Where-Object { $_.Properties[0].Value -eq $user } |
Select-Object @{
Name='시간'; Expression={ $_.TimeCreated }
}, @{
Name='잠긴계정'; Expression={ $_.Properties[0].Value }
}, @{
Name='원본컴퓨터'; Expression={ $_.Properties[1].Value }
}, @{
Name='호출DC'; Expression={ $_.Properties[4].Value }
} | Format-Table -AutoSize이 스크립트는 사용자별로 잠금이 언제, 어느 컴퓨터에서, 어느 DC를 통해 발생했는지를 한눈에 보여줍니다. "원본컴퓨터" 열에 나타난 호스트명이 바로 잘못된 자격 증명을 보내는 장치입니다. 만약 이 필드가 비어 있거나 사용자의 휴대폰 호스트명이 나타난다면, 모바일 기기의 Exchange/ActiveSync 동기화 문제일 가능성이 높습니다.
특정 사용자가 아니라 도메인 전체에서 잠긴 모든 계정을 한 번에 찾으려면 다음 명령이 유용합니다. 이는 공식 Search-ADAccount cmdlet 문서에 설명된 표준 방식입니다.
# 현재 잠긴 모든 사용자 계정 조회
Search-ADAccount -LockedOut -UsersOnly |
Select-Object Name, SamAccountName, LastLogonDate, LockedOut |
Sort-Object LastLogonDate -Descending |
Format-Table -AutoSize
# 결과를 CSV로 내보내 보고용으로 저장
Search-ADAccount -LockedOut -UsersOnly |
Export-Csv -Path "C:\Temp\locked_accounts_$(Get-Date -Format yyyyMMdd).csv" `
-NoTypeInformation -Encoding UTF8이 명령들은 헬프데스크 1차 응대 시 빠른 진단 도구로 활용할 수 있습니다. 비슷한 진단 패턴은 Windows 11 원격 데스크톱 연결 오류 해결 가이드에서 다룬 이벤트 로그 분석 흐름과도 잘 맞습니다.
잠금 원인을 식별한 후에는 사용자가 다시 로그인할 수 있도록 계정을 해제해야 합니다. PowerShell에서 가장 간단한 방법은 Unlock-ADAccount cmdlet을 사용하는 것이죠.
# 단일 계정 해제
Unlock-ADAccount -Identity "kim.jihoon" -Confirm
# 잠긴 모든 계정을 한 번에 해제(주의: 보안 검토 후 사용)
Search-ADAccount -LockedOut -UsersOnly |
ForEach-Object {
Write-Host "잠금 해제 중: $($_.SamAccountName)" -ForegroundColor Yellow
Unlock-ADAccount -Identity $_.SamAccountName
}
# 해제 후 잠금 카운터가 0인지 검증
Get-ADUser -Identity "kim.jihoon" -Properties LockedOut, badPwdCount, lastBadPasswordAttempt |
Select-Object SamAccountName, LockedOut, badPwdCount, lastBadPasswordAttempt일부 환경에서는 보안 정책상 자동 잠금 해제를 금지하고 헬프데스크가 사용자 신원을 음성으로 검증한 후에만 해제하도록 요구합니다. 이 경우 위 일괄 해제 스크립트는 사용하지 말고, 단일 사용자 해제와 함께 잠금 발생 시점, 원본 컴퓨터, 처리 담당자를 티켓 시스템에 자동으로 기록하는 워크플로를 구성하는 편이 안전합니다.
Microsoft가 공식 제공하는 Account Lockout and Management Tools(ALTools)에 포함된 LockoutStatus.exe는 GUI 기반으로 특정 사용자의 잠금 상태를 도메인 내 모든 DC에서 동시에 비교할 수 있는 가장 직관적인 도구입니다. 도구는 Microsoft 다운로드 센터에서 무료로 제공되며, 단일 실행 파일로 배포 가능합니다.
실행 시 사용자 SamAccountName을 입력하면 도구는 도메인 내 모든 DC에 쿼리를 보내 다음 정보를 표 형식으로 표시합니다.
각 DC의 값이 일치하지 않으면 복제 지연을 의심해야 합니다. 이때 다음 명령으로 복제 상태를 점검하세요.
# 모든 DC의 복제 상태 요약
repadmin /replsummary
# 특정 DC의 상세 복제 파트너 상태
repadmin /showrepl <DC호스트명>
# 비밀번호 변경 즉시 복제 강제
repadmin /syncall /AdeP4740 이벤트로 원본 컴퓨터를 식별했다면, 이제 해당 컴퓨터에서 다음 6가지 항목을 순서대로 점검해 잘못된 자격 증명 소스를 제거해야 합니다. 이 체크리스트는 제가 실제 IT 운영 환경에서 90% 이상의 반복 잠금 사례를 해결한 경험을 토대로 정리한 것입니다.
cmdkey /list로 저장된 자격 증명을 모두 나열하고, 만료된 항목을 cmdkey /delete로 삭제합니다. 특히 Outlook과 SharePoint 자격 증명을 꼭 확인하세요.net use로 모든 매핑을 확인하고, 잘못된 자격 증명으로 연결된 드라이브를 net use <letter>: /delete로 제거한 후 재연결합니다.Get-ScheduledTask | Where-Object { $_.Principal.UserId -eq "DOMAIN\\user" }로 해당 사용자 자격 증명으로 실행되는 작업을 찾아 새 비밀번호로 업데이트합니다.Get-WmiObject Win32_Service -Filter "StartName LIKE '%user%'"로 도메인 계정으로 실행되는 서비스를 확인합니다.각 항목을 처리한 후에는 klist purge로 Kerberos 티켓 캐시를 정리한 다음 사용자를 다시 로그인시켜야 변경이 즉시 반영됩니다. 헬프데스크 처리 모범 사례에 관한 추가 가이드는 Windows 업데이트 후 Outlook 멈춤 해결 가이드에서 캐시 정리 패턴과 함께 다루었습니다.
2026년 현재 엔터프라이즈 환경에서는 단일 잠금을 수동으로 추적하는 대신 SIEM 플랫폼과 통합해 패턴을 자동으로 감지하는 것이 표준입니다. Microsoft Sentinel은 4740 이벤트를 신원 위협 신호로 자동 수집하며, KQL(Kusto Query Language)로 다음과 같은 분석 규칙을 만들 수 있습니다.
// 최근 1시간 동안 3회 이상 잠긴 계정 탐지 (자격 증명 스프레이 의심)
SecurityEvent
| where EventID == 4740
| where TimeGenerated > ago(1h)
| summarize LockoutCount = count(),
SourceComputers = make_set(WorkstationName)
by TargetUserName
| where LockoutCount >= 3
| project TargetUserName, LockoutCount, SourceComputers이 규칙은 단일 사용자 계정이 짧은 시간 안에 여러 DC에서 잠기는 경우(자격 증명 무차별 공격이나 패스워드 스프레이 공격의 전형적 패턴)를 자동으로 식별합니다. Microsoft Defender for Identity는 추가로 비정상적인 인증 위치, 황금 티켓 공격, Pass-the-Hash 시도까지 상관 분석합니다. 운영 환경에서는 4740 이벤트가 단순 운영 이슈인지 실제 보안 사고인지 자동으로 분류하는 워크플로를 갖추는 것이 사실상 필수입니다.
소규모 환경이라면 Sentinel 대신 PowerShell 스크립트를 작업 스케줄러에 등록해 매시간 잠긴 계정을 Teams 채널 웹훅으로 전송하는 가벼운 자동화도 충분합니다. 핵심은 잠금이 발생하면 사람이 일일이 로그를 뒤지지 않아도 되도록 가시성을 자동화하는 것입니다.
모바일 기기의 메일 클라이언트, Windows 자격 증명 관리자에 저장된 옛 비밀번호, 도메인 계정으로 실행되는 예약된 작업이나 서비스가 가장 흔한 원인입니다. 실제 사람이 잘못 입력하는 경우는 30% 미만입니다.
Search-ADAccount -LockedOut -UsersOnly 명령을 사용하면 도메인 내 잠긴 모든 사용자 계정 목록을 즉시 반환합니다. 결과를 Export-Csv로 저장하면 일일 보고용으로도 활용할 수 있습니다.
4740 이벤트는 PDC 에뮬레이터 역할을 보유한 도메인 컨트롤러의 보안 로그에 자동으로 전달되어 기록됩니다. 따라서 잠금 추적은 항상 PDC 에뮬레이터에서 시작해야 누락 없이 모든 이벤트를 확인할 수 있습니다.
Microsoft 다운로드 센터에서 "Account Lockout and Management Tools(ALTools)"로 검색해 무료로 다운로드할 수 있습니다. ZIP 파일을 해제하면 LockoutStatus.exe를 즉시 실행할 수 있으며 별도 설치가 필요 없습니다.
원본 컴퓨터에서 만료된 자격 증명이 계속 인증을 시도하는 것입니다. 4740 이벤트의 Caller Computer Name 필드를 확인한 후 해당 PC에서 자격 증명 관리자, 매핑된 드라이브, 예약된 작업, 모바일 기기를 순서대로 점검해 만료된 비밀번호를 모두 제거해야 합니다.