Q. Windows의 주요 로그온 유형은 무엇이며, Account Lockout 분석에 왜 중요한가?
A. Interactive, Network, Batch, Unlock, Remote Interactive(RDP), Cached Interactive다. 어떤 경로로 인증이 발생했는지에 따라 조회할 이벤트 로그와 의심 지점을 좁힐 수 있다(예: RDP라면 4624/4625 Type 10, 네트워크 접근이라면 4776/4768/4769 등).
Q. “어디서 로그온하고 누가 자격 증명을 검증하나?”를 판단하는 기본 축은?
A. 로컬 SAM(LSASS) vs 도메인(DC)이다. 로컬이면 4624/4625, 도메인이라면 4768/4769/4776 이벤트 중심으로 본다. 이 구분이 잘못되면 원인지를 끝없이 헤맬 수 있다.
Q. Account Lockout Threshold/Duration/Reset Counter는 각각 무엇을 통제하나?
A. Threshold=잠금 유발 실패 횟수, Duration=자동 해제까지 잠금 유지 시간(0이면 관리자 해제 전까지), Reset Counter=실패 누적을 0으로 되돌리는 대기 시간(분 단위)이다.
Q. “Threshold=0”과 “Duration=0”의 의미 차이는?
A. Threshold=0은 “절대 잠그지 않음.” Duration=0은 “잠기면 관리자만 해제.”(자동 해제 없음)이다. 운영 목표에 맞춰 전혀 다른 효과를 낸다.
Q. 잠금 설정을 너무 공격적으로(Threshold=3, Duration=2h 등) 두면 생기는 운영 리스크는?
A. 빈번한 DoS 성격의 잠금, 헬프데스크 폭주, 사용자/업무 중단, 공격자에 대한 ‘도움’ 제공 등이다. 과도 저강성 모두 문제다.
Q. Microsoft 권고의 잠금 정책 튜닝 가이드는 대략 어떻게 잡나?
A. Threshold는 환경/리스크에 맞게, Duration은 30–60분 권고, Reset Counter는 30분 미만으로 두어 사용자/보안 밸런스를 맞춘다(문서의 제안/서포터빌리티 관점).
Q. 도메인 전체의 현재 잠금 정책 값은 어디서 확인하나?
A. PDC에서 net accounts 또는 도메인 NC의 lockoutDuration/lockoutThreshold/lockoutObservationWindow 속성으로 확인한다.
Q. 대표적인 로그온 실패/상태 코드 해석은?
A. 0xC0000064(존재 없는 사용자), 0xC000006A(잘못된 사용자/암호), 0xC0000234(잠금), 0xC0000071(암호 만료), 0xC0000072(계정 비활성) 등이다. 코드로 원인을 빠르게 분기한다.
Q. Bad Password 검증 시 어떤 DC가 ‘진실’을 판단하나?
A. PDC 에뮬레이터가 권위자다. 다른 DC가 실패를 받으면 PDC에 재확인하는 흐름을 통해 최신 올바른 암호를 기준 삼는다.
36214a48-b151-4d60-be5f-f10f4d1…
Q. 비밀번호 변경 직후 발생하는 “N-2 패스워드” 시나리오가 왜 잠금을 유발할 수 있나?
A. 일부 워크스테이션/서비스가 오래된(N-1/N-2) 암호를 재시도하며 BadPwd를 쌓기 때문. 복제가 즉시/동기식이 아니고, 캐시/저장 암호가 남아 있으면 발생한다.
Q. 사용자 객체에서 잠금/실패 관련 핵심 속성은?
A. badPwdCount, badPasswordTime, pwdLastSet, (계산 속성) msDS-User-Account-Control-Computed 등. 이들로 “언제/얼마나 실패했나, 암호 갱신 타이밍”을 연계 분석한다.
Q. 도메인/사용자 잠금 속성의 “복제” 특성은?
A. 도메인 속성(Threshold/Duration/ObservationWindow)과 사용자 속성(badPwdCount 등)은 복제된다. 다만 Bad Password 판정/최종 권위는 PDC가 관여한다.
Q. “같은 계정의 다중 로그인(여러 PC/RDS)”이 왜 대표적 원인인가?
A. 한 곳에서 암호 변경 후 다른 세션이나 서비스에 과거 암호가 남아 있으면 일괄 재시도가 BadPwd 폭주를 만든다. 특히 휴면 RDS 세션/드라이브 매핑에 주의.
Q. 서비스 계정/스케줄러가 Lockout의 “고질병”인 이유는?
A. 암호 변경 후 서비스/작업 스케줄러의 저장 암호가 갱신되지 않으면 주기적 재시도로 BadPwd 누적이 확실히 발생한다. 점검 1순위다.
Q. Credential Manager(자격 증명 관리자)는 왜 확인해야 하나?
A. 앱/드라이브 매핑/웹 서비스가 암호를 저장한다. 오래된 항목이 있으면 BadPwd를 계속 유발하므로 cmdkey /list 확인 및 cmdkey /delete 정리, 저장 금지 GPO 검토가 필요하다.
Q. LMCompatibility Level이 Bad Password 문제에 관여하는 방식은?
A. NTLMv1/v2 수용/전송 정책 조합이 어긋나면 챌린지/응답 검증 실패가 빈발한다. “보안 표준화(최소 NTLMv2)”와 호환성 확인이 필요하다.
Q. 애플리케이션의 “자동 재시도” 로직은 왜 위험한가?
A. 단기간에 다량 실패를 쌓아 Threshold를 순식간에 넘긴다. 재시도 횟수/간격 제한과 백오프가 없으면 잠금 폭탄이 된다.
Q. LockoutStatus.exe로 무엇을 빠르게 파악할 수 있나?
A. 어떤 DC에서 잠금이 관찰되는지, 소스 DC/사이트, 사용자 상태, 원격 로그 활성화까지 지원한다. 1차 스코핑 도구로 탁월하다.
Q. “스코핑 질문”의 핵심 축은 무엇인가?
A. WHO(누가/역할), WHAT(서비스 계정/일반/사용 기기), WHERE(단일/다중 도메인·사이트·RODC), WHEN(패턴/빈도/시작 시점/최근 변경)으로 빠르게 범위를 압축한다.
Q. DC/멤버/클라이언트에서 어떤 로그를 수집·분석해야 하나?
A. Security(4624/4625/4776/4768/4769), Netlogon/Kerberos ETL, IIS(웹 프론트 인증 시), 필요 시 TSS 스크립트로 클라이언트 측 상세 추적을 켠다(워크플로우 참조).
Q. “단일 사용자 반복 잠금”과 “광범위 잠금”의 1차 분기 대응은?
A. 단일: 저장 암호/세션/서비스/작업 스케줄러/특정 단말 집중. 광범위: 정책 변경/IDP/애플리케이션 배포/네트워크 영향 등 공통 원인 가설로 접근한다.
Q. RODC가 있는 사이트에서 Lockout 분석 시 주의점은?
A. 암호 캐시/프록시 특성으로 PDC 재확인이 중요해진다. RODC에서 본 이벤트만으로 결론을 내지 말고 PDC/허브 사이트 상관 이벤트를 함께 본다.
Q. Fine-Grained Password Policy(FGPP)가 Lockout 전략에 주는 이점은?
A. 하나의 도메인 정책으로는 충돌하는 요구(예: 금융팀 vs 일반 사용자)를 만족하기 어렵다. FGPP로 OU/그룹별 암호·잠금 기준을 차등화해 보안/업무 균형을 잡는다.
Q. FGPP와 3rd-party Password Filter의 차이는?
A. FGPP는 AD 네이티브로 정책을 세분화하고, 필터는 암호 복잡도/사전 금지 등의 규칙을 확장한다. 목적이 다르며 함께 쓸 수 있다.
Q. 비밀번호를 인증 체계에서 제거(WHFB/FIDO)하면 Lockout은 사라지나?
A. 크게 줄지만 “암호 기반 경로가 남아있거나(레거시 앱/서비스), Winlogon 단계 등에서 실제 암호 입력이 발생”하면 여전히 Lockout이 발생할 수 있다. 완전 전환·차단이 중요.
Q. “업무시간에만, 사용자 부재 중에도 BadPwd가 분출”되는 케이스의 정석 원인은?
A. 같은 층·여러 PC에서 캐시/저장 자격 증명이 자동 인증을 시도(드라이브 매핑, 에이전트, 서비스 등). 사용자는 로그인 안 해도 네트워크 에이전트가 재시도한다.
Q. 도메인 정책 적용 위치/우선순위 관점에서 잠금 정책은 어디에 적용되나?
A. 로컬/워크그룹은 Secpol, 도메인 계정은 도메인 수준(특히 DC)에 적용된다. “클라이언트 OU 정책이 도메인 계정 잠금을 바꾸지 않는다”는 점을 기억.
Q. “암호 바꿨는데 계속 잠긴다”를 현장에서 빠르게 좁히는 체크리스트는?
A. (1) 해당 계정으로 실행 중인 서비스/작업 (2) 남아있는 RDS/콘솔 세션 (3) Credential Manager/드라이브 매핑 (4) 모바일/앱 토큰 (5) 웹/IIS 백엔드 인증 경로.
Q. 트러블슈팅 워크플로우의 골자는?
A. 스코핑 → PDC/소스 DC 확인(LockoutStatus) → 이벤트·ETL 상관분석 → 저장 자격 증명/재시도 원천 제거 → 정책 튜닝(FGPP 포함) → 재발 감시 순이다.
Q. 운영 안전장치로 “정책 값” 말고 무엇을 병행해야 재발을 줄일 수 있나?
A. 앱의 재시도 제한/백오프, 서비스 계정 암호 변경 표준운영절차(SOP), 암호 변경 알림 후 24–48h 집중 모니터링, 저장 자격증명 금지 GPO, 정기 Lockout 리포트다.
1) 어떤 DC가 ‘잠금’을 최종 결정하나요?
A: 도메인 PDC Emulator가 권위자입니다. 비밀번호 실패가 발생한 DC는 PDC로 질의를 프록시하며(PDC가 가용하면), PDC가 badPwdCount/lockoutTime 기준으로 잠금 여부를 결정합니다. PDC가 비가용한 경우, 로컬 DC가 임시 판단을 하지만, 일관성 보장을 위해 PDC 가용성 확보가 핵심입니다.
2) badPwdCount는 복제되나요?
A: 아니요. badPwdCount는 DC 로컬 유지 값입니다. 반면 잠금 상태를 의미하는 lockoutTime은 복제됩니다. 그래서 DC마다 badPwdCount가 달라 보여도, 잠금은 일관되게 적용됩니다.
3) 계정 잠금 관련 핵심 속성은?
A:
- badPwdCount(로컬 DC 카운터, 비복제)
- badPasswordTime(마지막 실패 시각)
- lockoutTime(잠금 시각; 0이면 잠금 아님, 복제됨)
- msDS-User-Account-Control-Computed(계산 속성; LOCKOUT 플래그로 현재 잠금 상태 확인)
- pwdLastSet(암호 변경 시각)
4) PowerShell로 “현재 잠금/실패 이력”을 정확히 읽는 법?
A:
5) lockoutTime는 어떤 시간 형식인가요?
A: Windows FILETIME(UTC 기반 100ns 틱)입니다. 사람이 읽을 값으로 변환하려면:
6) FGPP(세분화 암호/잠금 정책) 우선순위는?
A: PSO(Password Settings Object) 의 msDS-PasswordSettingsPrecedence 값이 작을수록 우선. 링크 대상은 사용자/글로벌 보안 그룹만(OU 직접 링크 불가). 여러 PSO가 적용 가능하면 가장 낮은 precedence가 승리합니다.
7) RODC가 있을 때 잠금 처리는 어떻게 흐르나요?
A: RODC는 쓰기 불가이므로 실패 인증은 가용한 쓰기 가능한 DC로 포워딩됩니다. 실제 lockoutTime 설정은 writable DC에서 수행되고 복제됩니다. 4740의 Caller Computer가 RODC로 보일 수 있으니, 경로를 이해하고 추적하세요.
8) Kerberos/NTLM 실패가 잠금 카운트에 어떻게 반영되나요?
A:
- Kerberos: KDC에서 4768/4771(Pre-auth 실패 시 흔히 0x18)
- NTLM: DC의 4776(Credential Validation 실패)
- 멤버 서버/워크스테이션은 4625를 남깁니다(DC로 위임된 검증은 결국 DC에서 카운트 증가).
9) “Caller Computer Name”이 비거나 의심스러울 때는?
A: NAT/프록시/앱 계층(예: NPS/ADFS/웹앱) 때문에 원 발원지가 사라질 수 있습니다. 이럴 땐 Netlogon 디버그를 켜세요:
이벤트/네트로그를 교차로 읽어 “진짜 원인지”를 역추적합니다.
10) 관리자(내장 Administrator) 계정도 잠길 수 있나요?
A: 내장 Administrator는 잠금 정책의 대상이 아닙니다.(보안상 논쟁이 있으나 역사적 호환성으로 예외) 운영 환경에선 이 계정 로그온 경로 제한/감사 강화가 필수입니다.
11) 정책 파라미터 간 상호작용(Threshold/Duration/Reset)은?
A:
- Threshold: 실패 n회 → 잠금
- Reset counter after: 이 시간 내 누적 실패만 카운트
- Duration: 잠금 유지 시간(0=관리자만 해제)
권장: Duration ≥ Reset(동일·초과)로 잡아 예측 가능성을 높이세요.
12) 서비스 계정 잠금이 자주 나는 구조적 이유 3가지
A:
- 다수 서버/잡이 동일 계정 사용(어딘가에 옛 암호 저장)
- 스냅샷 롤백으로 과거 암호를 쓰는 노드 존재
- App Pool/Agent/Task Scheduler에 저장된 암호 누락
→ 암호 변경 시 전 배포 지점을 스캔/검증하는 표준 절차가 필요합니다.
13) “컴퓨터 계정”도 잠금 대상인가요?
A: 일반적으로 사용자 계정에 잠금 정책이 적용됩니다. 컴퓨터 계정 문제는 대개 보안 채널(secure channel) 파손/암호 불일치로 인한 인증 실패지 “잠금”이 아닙니다. 현상은 비슷해 보여도 원인·해결책이 다릅니다(재조인/암호 재설정 등).
14) 시간 불일치(Time Skew)로도 잠금이 발생하나요?
A: 시간 불일치는 Kerberos 실패(예: KRB_AP_ERR_SKEW)를 유발하지만, 잘못된 암호 실패가 아니므로 lockout 카운터와는 별개입니다. 시간대/동기화는 KDC 5분 규칙 내로 유지하세요.
15) 캐시된 자격 증명(Windows Cached Logons)이 잠금에 미치는 영향?
A: 오프라인 캐시 로그온 자체는 DC에 접속하지 않으므로 카운트를 올리지 않습니다. 하지만 네트워크 재가용 시 백그라운드 연결(드라이브/서비스)이 옛 암호로 재인증하며 잠금을 유발할 수 있습니다.
16) 스마트카드 PIN 오입력이 잠금을 만들까요?
A: 스마트카드 PIN 잠김은 카드 단에서 발생합니다. AD 측의 “암호 실패”가 아니므로 lockout과 직결되지 않습니다.(인증 경로/실패 코드 분석 필요)
17) PTA/SSO와 잠금의 관계(Azure AD 시나리오)
A: PTA(Pass-through Authentication) 는 클라우드 실패 로그온을 온프레미스 DC로 위임하므로 잘못된 암호가 누적되면 온프레미스 계정 잠금으로 이어질 수 있습니다. 반면 PHS(Password Hash Sync) 경로의 실패는 클라우드에서 종결되어 온프레 잠금에 직접 영향이 없습니다.
18) Lockout 근원을 빠르게 모아보는 감사 정책 세트
A:
→ DC/리소스 서버 모두 일관적으로 설정하고, 이벤트 4740/4768/4771/4776/4625를 상관 분석합니다.
19) Search-ADAccount로 잠금 현황 일괄 점검
A:
운영에선 OU별 분류/메일 알림 파이프라인을 붙이면 좋습니다.
20) “잠금은 풀렸는데 다시 잠긴다”의 전형적 원인 추적 순서
A: (1) 4740의 Caller → (2) 해당 호스트에서 4625 필터(오래된 자격 증명) → (3) cmdkey /list·자격 증명 관리자 확인 → (4) 작업 스케줄러/서비스/AppPool(IIS) 재확인 → (5) 모바일/클라이언트 앱(Outlook/OneDrive/Teams) 재등록.
21) 동일 계정으로 다중 노드 실행 시 안전 가이드
A: 서비스 계정은 MFA 불가·인터랙티브 불가·권한 최소화가 원칙. 더 안전하게는 노드 분리(계정 분산) 또는 그룹 관리 서비스 계정(gMSA) 도입으로 암호 배포 리스크를 줄입니다.
22) 이벤트 코드로 “암호 틀림 vs 제한 위반” 구분
A:
- 0xC000006A: 암호 틀림 → lockout 카운트 증가
- 0xC0000064: 사용자 없음 → 카운트 증가 안 함(일반적으로)
- 0xC000006F: 허용되지 않는 시간
- 0xC0000070: 로그온 제한(워크스테이션)
→ 암호 틀림과 정책 위반을 분리해야 불필요한 잠금을 피할 수 있습니다.
23) “잠금 해제”와 “암호 재설정”의 차이
A:
- Unlock: lockoutTime만 초기화(원인 제거는 아님)
- Reset Password: 암호 변경 + 잠금 해제(대개 함께 처리)
원인(옛 암호 사용 프로세스)을 제거하지 않으면 즉시 재잠금됩니다.
24) “유도형 DoS(타인이 의도적으로 잠금)” 대응
A:
- 임계값을 너무 보수적으로 잡지 않기(예: 3회는 위험)
- VPN/웹앱 프런트에 CAPTCHA/레이트리밋
- 내장 Administrator 비노출/제어
- 계정 보호(스마트락아웃은 AzureAD 영역) + 경보 규칙
25) RADIUS/NPS·WAF·메일게이트웨이 등이 만들 수 있는 잠금
A: 외부 시스템이 DC에 NTLM/Kerberos 검증 위임을 하면, 그 시스템이 4740의 Caller로 보일 수 있습니다. 진짜 사용자의 접속 원점 IP는 해당 시스템의 로컬 로그(NPS, ADFS, 리버스 프록시)에서 이어서 추적해야 합니다.
26) 로그온 유형별(lockout 영향) 이해
A:
- 2(Interactive), 3(Network), 10(RemoteInteractive/RDP): 잘못된 암호면 카운트 증가
- 서비스/배치도 해당 계정의 네트워크 인증 실패로 카운트 증가 가능
→ “사용자가 직접 치지 않았다”는 주장을 로그온 유형으로 반박/설명할 수 있습니다.
27) “왜 어떤 환경에선 4740이 특정 DC에만 찍히나?”
A: 실패를 처음 처리한 DC(또는 PDC와의 상호작용을 담당한 DC)에 집중 로그가 남기 때문입니다. 사이트/서브넷 설계가 엉켜있거나 클라이언트가 원거리 DC로 인증하면, 추적 난이도가 올라갑니다(사이트링크/서브넷 재점검 권장).
28) 잠금 재현(테스트) 시 주의
A: 자동화로 반복 실패를 던질 수는 있으나, 운영 DC에 불필요한 부하/잠금을 유발할 수 있습니다. 별도 랩/테스트 OU에서 제한적으로 수행하고, 감사 정책/임계값을 운영과 동일하게 맞추세요.
29) “Reset counter after”가 너무 짧을 때의 부작용
A: 사용자 타이핑 실수 몇 번에도 잠금이 빈발합니다. 반대로 너무 길면 공격에 취약해집니다. 일반 권장은 Threshold=5, Reset=15분, Duration=30분이지만, 외부 노출 경로(VDI/VPN/메일앱) 트래픽 패턴에 맞춰 조정해야 합니다.
30) 현장 진단을 위한 ‘미니 런북’
A:
- DC에서 4740 수집 → Caller 정리
- 해당 Caller에서 4625와 애플리케이션 로그 상관
- Netlogon 디버그(짧은 기간)로 계정·호스트 상관
- 문제 계정의 서비스/작업/앱/자격증명 저장소(cmdkey/자격 증명 관리자) 전수 점검
- 근본 원인 제거 후 Unlock/Reset, 24~48시간 모니터링
1️⃣ 계정 잠금이란 무엇인가요?
A:
Active Directory 환경에서 사용자가 여러 번 잘못된 비밀번호를 입력했을 때, 보안을 위해 로그온을 차단하는 보호 메커니즘입니다. 이는 무차별 대입 공격(Brute-force attack)을 방지하기 위한 것입니다.
2️⃣ 계정 잠금 임계값(Account Lockout Threshold)이란?
A:
지정된 횟수 이상 비밀번호를 잘못 입력할 경우 계정이 잠기게 되는 기준 횟수입니다.
예: 5회 실패 → 계정 잠금.
3️⃣ 계정 잠금 기간(Account Lockout Duration)은 무엇인가요?
A:
계정이 잠긴 후 자동으로 해제되기까지의 시간(분 단위)입니다.
예: 30분 설정 시, 30분 후 자동 해제됩니다.
0분으로 설정하면 관리자만 수동으로 해제할 수 있습니다.
4️⃣ 잠금 카운터 재설정 시간(Reset Account Lockout Counter After)이란?
A:
비밀번호 입력 실패 횟수를 초기화하는 기준 시간입니다.
예를 들어, 15분 내 5회 실패하면 잠기지만, 15분이 지나면 실패 카운트가 0으로 초기화됩니다.
5️⃣ Account Lockout 정책은 어디서 설정하나요?
A:
도메인 전체 정책으로 적용되며,
경로:
Group Policy Management Console (GPMC)
➡ Default Domain Policy
➡ Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy
6️⃣ 계정 잠금 시 어떤 이벤트 로그가 남나요?
A:
- DC(Security Log)
- Event ID 4740: "A user account was locked out."
- Source: Microsoft Windows Security Auditing
- Caller Computer Name 항목을 통해 어떤 컴퓨터에서 실패가 발생했는지 확인할 수 있습니다.
7️⃣ 실제 비밀번호 오류가 발생한 컴퓨터를 어떻게 찾나요?
A:
Event ID 4740의 Caller Computer Name 또는
Netlogon.log에서 0xC0000234 (account locked) 또는 0xC000006A (bad password) 패턴을 확인합니다.
8️⃣ Netlogon 디버그 로그를 활성화하는 방법은?
A:
이후 %windir%\debug\netlogon.log 파일을 확인하면 실패한 인증 요청이 기록됩니다.
9️⃣ 어떤 이유로 정상 사용자의 계정이 자주 잠길 수 있나요?
A:
- 저장된 자격 증명(Cached Credentials)
- 오래된 서비스 계정 비밀번호
- 스케줄러(Task Scheduler)나 서비스의 잘못된 자격증명
- 모바일 기기/Outlook/OneDrive에서의 저장된 비밀번호 불일치
- 네트워크 드라이브 연결 후 비밀번호 변경 누락
10️⃣ "Caller Computer Name"이 비어 있는 경우는 왜인가요?
A:
Kerberos 티켓 만료 후 재인증 시, DC 간 요청 또는 NAT 환경에서는 원본 컴퓨터 정보가 누락될 수 있습니다.
이 경우 Netlogon 로그 분석이 필요합니다.
11️⃣ 비밀번호 입력 실패 이벤트 ID는 무엇인가요?
A:
Event ID 4625 – “An account failed to log on.”
→ Failure Reason, Status Code(0xC000006A 등)으로 원인 파악 가능.
12️⃣ 계정 잠금 관련 주요 Status Code는?
| 0xC000006A | 잘못된 비밀번호 |
| 0xC0000064 | 존재하지 않는 사용자 |
| 0xC0000234 | 계정이 잠금 상태 |
| 0xC0000070 | 계정 제한 |
| 0xC0000193 | 계정 만료 |
13️⃣ 여러 DC가 있을 때 어떤 DC 로그를 확인해야 하나요?
A:
계정이 인증 요청을 받은 DC에서 4740 이벤트가 기록됩니다.
repadmin /showrepl로 복제 상태를 확인하고, 동일 시간대 다른 DC의 로그를 비교해야 합니다.
14️⃣ 잘못된 비밀번호가 반복적으로 발생하는 시스템을 찾는 PowerShell 명령은?
A:
15️⃣ 잠금 원인이 모바일/Outlook 저장 자격 증명일 경우 해결 방법은?
A:
- Outlook → 계정 제거 후 재등록
- Windows Credential Manager → 기존 저장 비밀번호 삭제
- 모바일 → Exchange 계정 재로그인
16️⃣ 서비스 계정이 자주 잠기는 경우의 원인은?
A:
- 서비스 실행 계정 비밀번호 변경 후, 다른 서버/스케줄러에 옛 비밀번호가 남아 있는 경우
- 복제된 VM Snapshot 롤백 후 이전 자격 증명 사용 중인 경우
17️⃣ 계정 잠금 정책의 보안적 권장 설정은?
A:
| Account lockout threshold | 5회 |
| Reset account lockout counter after | 15분 |
| Account lockout duration | 30분 |
18️⃣ 계정 잠금 정책이 너무 엄격할 때의 부작용은?
A:
- 비정상적인 서비스 중단 (계정 잠금으로 인한 로그인 실패)
- 내부 DoS(자체 서비스 방해) 가능성
- Helpdesk 티켓 급증
19️⃣ 계정 잠금 해제 방법은?
A:
- Active Directory Users and Computers → 사용자 계정 → [속성] → [계정] → “계정 잠김 해제” 체크 해제
- 또는 PowerShell:
-
Unlock-ADAccount -Identity <UserName>
20️⃣ Account Lockout Troubleshooting을 위한 Microsoft 공식 도구는?
A:
-
- LockoutStatus.exe
- EventCombMT.exe
- AcctInfo.dllMicrosoft Account Lockout and Management Tools (ALTools)