Windows Active Directory(AD) 환경에서 계정 비밀번호를 변경한 이후 계정 잠금이 반복되는 경우가 있습니다. 사용자가 직접 로그인을 시도하지 않았는데도 계정이 잠기거나, 관리자가 잠금을 해제한 지 얼마 지나지 않아 동일한 문제가 발생하기도 합니다.
이때 확인할 대상 중 하나가 Windows 서비스에 저장된 계정 비밀번호입니다.
일부 서비스는 사용자의 정보를 저장 후 업데이트 AD정보가 업데이트 되지 않는 케이스도 있어 실무에서도 계정이 잠기는 케이스가 간혹 있었습니다.
특정 서비스가 도메인 계정으로 실행되도록 설정되어 있고, 해당 서비스에 이전 비밀번호가 남아 있다면 인증 실패가 반복될 수 있습니다. 특히 하나의 계정을 여러 서버에서 공동으로 사용한다면 어느 서버에서 인증을 시도하는지 파악하기가 쉽지 않습니다.
이 글에서는 Windows 서비스에 등록된 AD 계정의 비밀번호 불일치로 반복적인 계정 잠금이 발생하는 상황을 중심으로, 잠금 발생 장비와 실제 서비스를 추적하는 방법을 살펴보겠습니다.
Windows 서비스에 저장된 이전 비밀번호가 계정 잠금을 발생시키는 구조
Windows 서비스는 사용자가 로그인하지 않아도 백그라운드에서 특정 작업을 수행할 수 있습니다. 이때 서비스 실행 계정으로 Local System과 같은 기본 제공 계정뿐 아니라 별도의 AD 도메인 계정을 지정할 수도 있습니다.
예를 들어 CONTOSO\svc_batch라는 계정을 사용해 업무 시스템의 연동 서비스를 실행한다고 가정하겠습니다.
관리자가 AD에서 svc_batch의 비밀번호를 변경했지만, Windows 서비스의 로그온 설정에는 변경 전 비밀번호가 남아 있을 수 있습니다.
이 상태에서 서비스가 시작되거나 해당 계정의 자격 증명으로 인증을 일정횟수 이상 시도하여 실패하면 계정이 잠길 수 있습니다. 이에 따라 실패 횟수가 AD의 계정 잠금 정책에 설정된 임계값에 도달하면 계정이 잠깁니다.
여기서 주의할 점은 비밀번호가 변경되었다는 이유만으로 모든 실행 중인 서비스가 즉시 인증에 실패하는 것은 아니라는 점입니다. 서비스 시작 여부, 인증 방식, 새로운 인증 요청 발생 여부에 따라 문제가 나타나는 시점이 달라집니다.
도메인 컨트롤러 이벤트 로그에서 잠금 발생 장비 확인
반복적인 계정 잠금이 발생하면 먼저 도메인 컨트롤러(DC)의 보안 로그에서 실제 잠금 시각과 관련 장비를 확인해야 합니다.
Windows 이벤트 뷰어에서 Windows 로그 → 보안으로 이동하고 이벤트 ID 4740을 조회합니다. 해당 이벤트는 계정 잠금 발생을 기록하며, Account That Was Locked Out에서 대상 계정을, Caller Computer Name에서 잠금과 관련된 컴퓨터 이름을 확인할 수 있습니다.
예를 들어 잠긴 계정이 svc_batch이고 Caller Computer Name에 APP-SVR02가 표시된다면 해당 서버가 중요한 조사 대상이 됩니다.
다만 4740 이벤트에 표시된 컴퓨터 이름이 항상 최종 원인 프로그램을 직접 가리키는 것은 아닙니다. 중간 인증 시스템이 존재하거나 기록이 불완전한 경우 추가적인 로그 확인이 필요합니다.
관련 인증 이벤트는 다음과 같이 구분할 수 있습니다.
| 이벤트 ID | 확인 대상 | 주요 확인 항목 |
|---|---|---|
| 4740 | AD 계정 잠금 | 잠긴 계정, Caller Computer Name, 발생 시각 |
| 4771 | Kerberos 사전 인증 실패 | 계정, Client Address, Failure Code |
| 4776 | NTLM 자격 증명 검증 | Logon Account, Source Workstation, Error Code |
| 4625 | 인증을 시도한 시스템의 로그온 실패 | Account Name, Logon Type, Status |
Kerberos 인증 실패 이벤트 4771에서 0x18은 잘못된 비밀번호로 인한 사전 인증 실패를 나타냅니다. NTLM 인증 이벤트 4776에서는 0xC000006A가 잘못된 비밀번호를, 0xC0000234가 계정이 잠긴 상태를 의미합니다.
이러한 이벤트를 동일한 계정과 시간대로 연결하면 반복적인 인증 실패의 출발지를 좁힐 수 있습니다. 다만 이벤트의 존재만으로 특정 서비스가 원인이라고 확정해서는 안 됩니다.
잠금 발생 서버에서 서비스 실행 계정 확인
잠금과 관련된 서버를 확인했다면 해당 서버에서 어떤 Windows 서비스가 문제의 AD 계정을 사용하는지 살펴볼 차례입니다.
가장 간단한 방법은 services.msc를 실행해 서비스 목록을 확인하는 것입니다. 서비스의 속성에서 로그온(Log On) 탭을 열면 특정 도메인 계정으로 실행되도록 설정되어 있는지 확인할 수 있습니다.
서비스가 많다면 PowerShell을 사용해 실행 계정을 조회할 수도 있습니다. 다음은 예시 도메인 계정을 사용하는 서비스를 찾는 조회 전용 명령어입니다.
Get-CimInstance Win32_Service | Where-Object StartName -EQ 'CONTOSO\svc_batch' | Select-Object Name,DisplayName,StartName,State이 명령어는 명령을 실행한 서버에서 해당 계정으로 구성된 Windows 서비스를 조회합니다. 계정 표기가 UPN 형식 등으로 다른 경우에는 조회 조건을 조정해야 합니다.
의심 서비스가 발견되면 해당 서버의 보안 이벤트 4625도 함께 확인합니다. Logon Type 5는 서비스 로그온을 의미하므로 문제의 계정과 잠금 발생 시각이 일치한다면 원인 분석에 도움이 됩니다.
단, 4625의 Logon Type 5가 확인되지 않았다고 해서 서비스 계정 문제를 완전히 배제할 수는 없습니다. 실행 중인 서비스가 다른 방식으로 네트워크 인증을 시도했거나 감사 로그가 수집되지 않았을 가능성도 고려해야 합니다.
원인 서비스 확인 후 비밀번호를 수정하고 재발 여부 검증
문제 서비스를 특정했다면 AD 계정의 잠금부터 반복해서 해제하기보다 해당 서비스가 사용하는 자격 증명을 먼저 바로잡아야 합니다.
일반 도메인 사용자 계정으로 실행되는 서비스라면 서비스 속성의 로그온 설정에서 올바른 비밀번호를 적용하는 방법을 검토할 수 있습니다. 이때 동일한 계정을 사용하는 다른 서버나 서비스가 있는지도 함께 확인해야 합니다.
수정 과정에서는 서비스 중단 가능성, 의존 관계, 운영 업무 영향을 고려해야 합니다. 서비스 재시작이 필요한 경우에는 변경 승인과 작업 시간을 확보한 다음 진행하는 것이 적절합니다.
변경 후에는 다음 사항을 확인합니다.
- 서비스가 정상적으로 시작되고 필요한 업무 기능을 수행하는지
- 동일 계정에서 새로운 인증 실패 이벤트가 반복되지 않는지
- 기존 잠금을 해제한 이후 다시 잠금 이벤트가 발생하는지
- 다른 서버에도 이전 자격 증명이 남아 있지 않은지
반복적인 비밀번호 관리 문제가 있는 환경에서는 그룹 관리 서비스 계정인 gMSA(Group Managed Service Account) 도입도 검토할 수 있습니다. gMSA는 Windows와 AD가 비밀번호를 관리하도록 설계된 계정이지만, 대상 서비스와 운영 환경에서 지원되는지 먼저 확인해야 합니다.
자주 묻는 질문
Q1. 4740 이벤트의 Caller Computer Name이 비어 있으면 어떻게 해야 하나요?
4740만으로 출발지를 확인하기 어렵다면 동일한 시간대의 4771에서 Client Address를, 4776에서 Source Workstation을 확인할 수 있습니다. 중간 인증 시스템이 존재하는 환경에서는 관련 서버의 로그를 추가로 분석해야 합니다.
Q2. 4771 이벤트에서 0x18이 발생하면 Windows 서비스 계정 문제인가요?
아닙니다. 0x18은 Kerberos 사전 인증 과정에서 잘못된 비밀번호가 사용되었음을 나타내며, 원인이 Windows 서비스인지까지 구분하지는 않습니다. 서비스 실행 계정과 서버 로그를 추가로 확인해야 합니다.
Q3. AD에서 계정 잠금만 해제하면 문제가 해결되나요?
이전 비밀번호를 사용하는 서비스가 계속 인증을 시도한다면 계정이 다시 잠길 수 있습니다. 반복되는 실패의 원인을 수정한 뒤 잠금을 해제하고 재발 여부를 확인하는 것이 적절합니다.
Q4. gMSA로 변경하면 계정 잠금 문제가 완전히 사라지나요?
gMSA는 비밀번호를 자동으로 관리하므로 수동 비밀번호 변경에 따른 불일치 위험을 줄이는 데 도움이 됩니다. 그러나 서비스 호환성, 계정 사용 권한, 호스트 구성 문제까지 자동으로 해결하는 것은 아닙니다.
결론
AD 계정의 잠금이 반복될 때 중요한 것은 단순히 계정을 다시 사용할 수 있도록 만드는 것이 아니라 어느 장비에서, 어떤 계정으로, 어떤 인증 실패가 발생하는지 확인하는 것입니다.
Windows 서비스 계정이 의심된다면 도메인 컨트롤러의 4740 이벤트로 잠금 발생 장비를 좁히고, 4771·4776과 해당 서버의 4625 이벤트를 연결해 살펴볼 수 있습니다.
이후 실제 서비스의 실행 계정과 저장된 자격 증명을 확인하고, 필요한 변경을 적용한 뒤 인증 실패가 재발하는지 검증해야 합니다. 이 순서를 지키면 계정 잠금 해제만 반복하는 상황에서 벗어나 원인에 근거한 조치를 수행할 수 있습니다.