Windows AD 도메인에서 잠긴 사용자 계정의 원인을 찾는 방법

최근 Outlook에서 발생한 사건 이후에 다음 문제를 어떻게 가장 효율적으로 해결할 수 있을지 궁금했습니다.

상당히 전형적인 중소 규모의 AD 인프라 (여러 DC, 여러 내부 서버 및 Windows 클라이언트, DMZ 내에서 사용자 인증을 위해 AD 및 LDAP를 사용하는 여러 서비스 (SMTP 릴레이, VPN, Citrix 등) 및 여러 내부)를 가정합니다. 인증을 위해 AD에 의존하는 모든 서비스 (Exchange, SQL Server, 파일 및 인쇄 서버, 터미널 서비스 서버) 모든 시스템에 대한 전체 액세스 권한이 있지만 개별적으로 확인하기에는 클라이언트를 계산하는 것이 너무 많습니다.

이제 알 수없는 이유로 몇 분마다 암호 잠금 정책으로 인해 하나 이상의 사용자 계정이 잠긴 것으로 가정합니다.

• 이를 담당하는 서비스 / 기계를 찾는 가장 좋은 방법은 무엇입니까?
• 인프라가 순수하고 추가 관리 도구가없는 표준 Windows라고 가정 할 때 기본 설정과 거의 변경되지 않으면 그러한 잠금의 원인을 찾는 프로세스를 가속화하거나 개선 할 수있는 방법이 있습니까?
• 이러한 계정 잠금 DOS에 대비하여 시스템의 복원력을 향상시키기 위해 무엇을 할 수 있습니까? 계정 잠금을 사용 중지하는 것은 명백한 대답이지만 복잡한 경우에도 쉽게 악용 가능한 암호를 사용하는 사용자 문제가 발생합니다.

주어진 답변에 보이지 않는 것을 추가하십시오.

이를 담당하는 서비스 / 기계를 찾는 가장 좋은 방법은 무엇입니까?

당신은 할 수없는 단지 PDCE를 전체 도메인에 대한 계정 잠금에 대한 최신 정보를 가지고 있지만, 어떤 클라이언트에 대한 정보를 가지고 있지 않기 때문에 IP (즉, PDCE의 보안 로그를 확인하거나 hostname) 실패한 로그온 시도는 PDCe 이외의 다른 DC에서 실패한 로그온 시도가 발생했다고 가정 한 것입니다. PDCe는 "계정 xyz가 잠겼습니다"라고 말하지만 도메인의 다른 DC에서 실패한 로그온이 발생한 위치는 말할 수 없습니다. 실제로 로그온의 유효성을 검사 한 DC 만 클라이언트 주소를 포함하여 로그온 실패를 기록합니다. 또한 RODC를이 토론에 참여시키지 않습니다.

여러 도메인 컨트롤러가있을 때 실패한 로그온 시도가 발생하는 위치를 확인하는 두 가지 좋은 방법이 있습니다. 이벤트 전달 , 마이크로 소프트의 계정 잠금 도구 .

중앙 위치로 이벤트 전달을 선호합니다. 모든 도메인 컨트롤러에서 실패한 로그온 시도를 중앙 로깅 서버로 전달합니다. 그런 다음 전체 도메인에서 실패한 로그온을 찾을 수있는 곳이 한 곳뿐입니다. 사실 저는 개인적으로 Microsoft의 계정 잠금 도구를 좋아하지 않으므로 이제 한 가지 좋은 방법이 있습니다.

이벤트 전달. 당신은 그것을 좋아할 것입니다.

인프라가 순수한 표준 Windows라고 가정하면 추가 관리 도구가없고 기본 변경 사항이 거의 없다고 가정하면 이러한 잠금의 원인을 찾는 프로세스를 가속화하거나 개선 할 수있는 방법이 있습니까?

위 참조. 그런 다음 SCOM 또는 Nagios와 같은 모니터링 시스템이나 사용하는 모든 것을 단일 이벤트 로그와 결합하여 휴대 전화를 문자 메시지 등으로 만들 수 있습니다. 그것보다 더 가속되지는 않습니다.

그러한 계정 잠금 DOS에 대비하여 시스템의 복원력을 향상시키기 위해 무엇을 할 수 있습니까?

1. 사용자 교육. 도메인 사용자 계정으로 실행되도록 Windows 서비스 설정을 중지하고, RDP 세션이 완료되면 로그 오프하고, Outlook에 대해 캐시 된 암호의 Windows 자격 증명 저장소를 지우는 방법 등을 알려주십시오.
2. 사용자가 더 이상 해당 사용자 계정의 비밀번호를 관리 할 필요가없는 관리 서비스 계정을 사용하십시오. 사용자는 모든 것을 망쳐 놓았습니다. 사용자에게 선택권을 주면 항상 잘못된 선택을합니다. 따라서 그들에게 선택권을주지 마십시오.
3. GPO를 통한 원격 세션 시간 초과 적용 사용자가 RDP 세션에서 6 시간 동안 유휴 상태 인 경우 시작하십시오.

더 큰 환경에서 관리자 계정을 정리하는 동안에도 같은 문제가 발생했습니다. DC의 감사 로그는 기술적으로 필요한 정보를 제공하지만 ManageEngine의 ADAudit Plus 제품을 구현하기로 결정했습니다.이 제품은 이러한 로그를 검색하고 AD의 변경 사항과 함께 로그온 시도를 찾습니다. 기본 제공보고 기능과 약간의 Excel 작업을 사용하여 로그온의 출처를 쉽게 파악할 수있었습니다. 우리의 경우 다양한 응용 프로그램을 구현할 때 서비스 계정 대신 관리자 계정을 사용한 관리자와 관련이있었습니다.

그러한 계정 잠금 DOS에 대비하여 시스템의 복원력을 향상시키기 위해 무엇을 할 수 있습니까?

당신은 할 수 없습니다.

집을 태울 수있는 많은 것들이 있습니다. DHCP 범위가 소진 될 때까지 IP 주소를 반복적으로 요청하는 간단한 코드와 같습니다. 또는 MFT가 가득 찰 때까지 디렉토리를 작성하는 간단한 코드이며 파티션을 다시 포맷하여 복원해야합니다. 모든 것을 막을 수는 없습니다.

잠금이있는보다 일반적인 시나리오는 몇 년 전보다 훨씬 다양한 장치에서 자격 증명을 입력하는 사람들입니다. 프린터 (이메일 스캔 용) 또는 스마트 폰 또는 태블릿과 같은. 자격 증명을 입력 한 위치를 잊어 버렸거나 더 이상 장치에 액세스 할 수없는 경우 장치가 계속 인증을 시도 할 수 있습니다. 전자 메일 인증은 이러한 장치를 추적하기 어려운 벡터이며 사용자가 액세스하더라도 해당 장치에 액세스 할 수 없거나 위치를 알 수 없습니다. IP 10.4.5.27? 계정을 잠금 해제하기 위해 매일 헬프 데스크에 연락해야하는 한 명의 사용자를 알고 있습니다. 그러면 즉시 로그온 한 다음 계정이 다시 잠 깁니다. 그들은 몇 달 동안 이것을했습니다. 계정 이름을 바꾸라고했습니다.

인생에는 불쾌감이 있습니다. 모두 제거 할 수는 없습니다.