온-프레미스 Microsoft Entra 암호 보호에 대한 질문과 대답

사용자에게 보안 암호 선택 방법에 대해 어떤 지침을 제공해야 하나요?

이 항목에 대한 Microsoft의 현재 지침은 다음 링크에서 찾을 수 있습니다.

Microsoft 암호 지침

온-프레미스 Microsoft Entra Password Protection이 비공용 클라우드에서 지원되나요?

온-프레미스 Microsoft Entra 암호 보호는 Azure Global 및 Azure Government 클라우드에서 모두 지원됩니다.

Microsoft Entra 관리 센터에서는 지원되지 않는 클라우드에서 온-프레미스별 "Windows Server Active Directory에 대한 암호 보호" 구성을 수정할 수 있습니다. 이러한 변경 내용은 지속되지만 적용되지 않습니다. 온-프레미스 프록시 에이전트 또는 포리스트 등록은 지원되지 않는 클라우드에서 지원되지 않으며 이러한 등록 시도는 항상 실패합니다.

내 온-프레미스 사용자의 하위 집합에 Microsoft Entra 암호 보호 혜택을 적용하려면 어떻게 할까요?

지원되지 않습니다. 배포되고 사용하도록 설정되면 Microsoft Entra Password Protection이 모든 사용자에게 동일하게 적용됩니다.

암호 변경과 암호 설정(또는 재설정)의 차이점은 무엇인가요?

암호 변경은 사용자가 이전 암호를 알고 있음을 증명한 후에 새 암호를 선택하는 경우입니다. 예를 들어 사용자가 Windows에 로그인한 다음, 새 암호를 선택하라는 메시지가 표시되면 암호 변경이 발생합니다.

암호 설정(때로는 암호 재설정이라고도 함)은 관리자가 Active Directory 사용자 및 컴퓨터와 같은 관리 도구를 사용하여 계정의 암호를 새 암호로 바꾸는 경우입니다. 이 작업에는 높은 수준의 권한(일반적으로 도메인 관리자)이 필요하며, 작업을 수행하는 사람은 일반적으로 이전 암호를 알지 못합니다. 지원 센터 시나리오는 암호를 잊어버린 사용자를 지원할 때와 같이 암호 집합을 수행하는 경우가 많습니다. 암호로 새 사용자 계정을 처음으로 만들 때 암호 집합 이벤트도 표시됩니다.

암호 유효성 검사 정책은 암호 변경 또는 설정을 수행하는지 여부에 관계없이 동일하게 작동합니다. Microsoft Entra 암호 보호 DC 에이전트 서비스는 다양한 이벤트를 기록하여 암호 변경 또는 설정 작업이 수행되었는지 여부를 알려줍니다. Microsoft Entra 암호 보호 모니터링 및 로깅을 참조하세요.

Microsoft Entra 암호 보호가 설치되면 기존 암호의 유효성을 검사하나요?

아니요 - Microsoft Entra 암호 보호는 암호 변경 또는 설정 작업 중에 일반 텍스트 암호에 대해서만 암호 정책을 적용할 수 있습니다. Active Directory가 암호를 수락하면 해당 암호의 인증 프로토콜별 해시만 유지됩니다. 텍스트 지우기 암호는 유지되지 않으므로 Microsoft Entra Password Protection은 기존 암호의 유효성을 검사할 수 없습니다.

Microsoft Entra 암호 보호가 처음 배포된 후 시간이 지남에 따라 기존 암호가 정상적으로 만료되므로 결국에는 모든 사용자와 계정에서 Microsoft Entra 암호 보호를 통해 유효성이 검사된 암호를 사용하게 됩니다. 원하는 경우 사용자 계정 암호의 일회성 수동 만료로 이 프로세스를 가속화할 수 있습니다.

"암호가 만료되지 않음"으로 구성된 계정은 수동 만료가 수행되지 않는 한 암호를 강제로 변경하지 않습니다.

Active Directory 사용자 및 컴퓨터 관리 스냅인을 사용하여 약한 암호를 설정하려고 하면 중복 암호 거부 이벤트가 기록되는 이유는 무엇인가요?

Active Directory 사용자 및 컴퓨터 관리 스냅인은 먼저 Kerberos 프로토콜을 사용하여 새 암호를 설정하려고 시도합니다. 실패하면 스냅인은 레거시(SAM RPC) 프로토콜을 사용하여 암호를 설정하려고 두 번째 시도합니다. 사용되는 특정 프로토콜은 중요하지 않습니다. 새 암호가 Microsoft Entra Password Protection에 의해 약한 것으로 간주되는 경우 이 스냅인 동작은 기록되는 암호 재설정 거부 이벤트의 두 집합을 생성합니다.

Microsoft Entra 암호 보호 암호 유효성 검사 이벤트가 빈 사용자 이름으로 기록되는 이유는 무엇인가요?

Active Directory는 도메인의 현재 암호 복잡성 요구 사항을 통과하는지 확인하기 위해 NetValidatePasswordPolicy API를 사용하는 것과 같이 암호를 테스트하는 기능을 지원합니다. 이러한 방식으로 암호의 유효성을 검사하는 경우 테스트에는 Microsoft Entra Password Protection과 같은 암호 필터 dll 기반 제품의 유효성 검사도 포함되지만 지정된 암호 필터 dll에 전달된 사용자 이름은 비어 있습니다. 이 시나리오에서 Microsoft Entra Password Protection은 현재 적용 중인 암호 정책을 사용하여 암호의 유효성을 검사하고 이벤트 로그 메시지를 실행하여 결과를 캡처합니다. 그러나 이벤트 로그 메시지에는 빈 사용자 이름 필드가 있습니다.

Microsoft Entra ID에서 암호를 변경하려고 하고 "이전에 해당 암호를 너무 많이 보았습니다. 추측하기 어려운 것을 선택하세요." 응답을 받은 하이브리드 사용자가 있습니다. 이 경우 온-프레미스에서 유효성 검사 시도가 표시되지 않는 이유는 무엇인가요?

하이브리드 사용자가 Microsoft Entra SSPR, MyAccount 또는 다른 Microsoft Entra 암호 변경 메커니즘을 통해 Microsoft Entra ID에서 암호를 변경하면 해당 암호는 클라우드의 글로벌 및 사용자 지정 금지 암호 목록에 대해 평가됩니다. 암호 쓰기 저장을 통해 Active Directory에 도달하면 Microsoft Entra ID에서 이미 유효성이 검사됩니다.

하이브리드 사용자에 대한 유효성 검사에 실패한 Microsoft Entra ID에서 시작된 암호 재설정 및 변경 내용은 Microsoft Entra 감사 로그에서 찾을 수 있습니다. Microsoft Entra ID에서 셀프 서비스 암호 재설정 문제 해결을 참조하세요.

다른 암호 필터 기반 제품과 함께 Microsoft Entra 암호 보호를 설치하도록 지원되나요?

예. 등록된 여러 암호 필터 DLL에 대한 지원은 Windows의 핵심 기능이며 Microsoft Entra 암호 보호와 관련이 없습니다. 암호가 수락되기 전에 모든 등록된 암호 필터 dll에 동의해야 합니다.

Azure를 사용하지 않고 Active Directory 환경 내에서 Microsoft Entra 암호 보호를 배포 및 구성하려면 어떻게 해야 하나요?

지원되지 않습니다. Microsoft Entra 암호 보호는 온-프레미스 Active Directory 환경으로 지원이 확장되는 Azure 기능입니다.

Active Directory 수준에서 정책의 콘텐츠를 수정하려면 어떻게 해야 하나요?

지원되지 않습니다. 정책은 Microsoft Entra 관리 센터를 통해서만 관리할 수 있습니다. 이전 질문도 참조하세요.

sysvol 복제에 DFSR이 필요한가요?

FRS(DFSR에 대한 선행 기술)는 대부분의 알려진 문제를 포함하며, 최신 버전의 Windows Server Active Directory에서 완전히 지원되지 않습니다. MICROSOFT Entra Password Protection의 제로 테스트는 FRS로 구성된 도메인에서 수행됩니다.

자세한 내용은 다음 문서를 참조하세요.

DFSR로 sysvol 복제를 마이그레이션하는 사례

FRS의 경우 종료가 가깝습니다.

도메인이 아직 DFSR을 사용하지 않는 경우 Microsoft Entra Password Protection을 설치하기 전에 DFSR을 사용하도록 마이그레이션해야 합니다. 자세한 내용은 다음 링크를 참조하세요.

SYSVOL 복제 마이그레이션 가이드: FRS에서 DFS로 복제

이 기능을 사용하려면 도메인 sysvol 공유에 얼마나 많은 공간이 필요한가요?

정확한 공간 사용량은 Microsoft 전역 금지 목록의 금지된 토큰의 수 및 길이, 테넌트당 사용자 지정 목록, 암호화 오버헤드 등과 같은 요소에 따라 다릅니다. 이러한 목록의 내용은 향후에 증가할 수 있습니다. 이 점을 염두에 두고 이 기능에는 도메인 sysvol 공유에 최소 5MB의 공간이 필요하다는 것이 합리적입니다.

DC 에이전트 소프트웨어를 설치하거나 업그레이드하는 데 다시 부팅이 필요한 이유는 무엇인가요?

이 요구 사항은 핵심 Windows 동작으로 인해 발생할 수 있습니다.

특정 프록시 서버를 사용하도록 DC 에이전트를 구성하는 방법이 있나요?

아니요. 프록시 서버는 상태 비저장 서버이므로 어떤 프록시 서버를 사용하는지는 중요하지 않습니다.

Microsoft Entra Connect와 같은 다른 서비스와 함께 Microsoft Entra 암호 보호 프록시 서비스를 배포해도 되나요?

예. Microsoft Entra 암호 보호 프록시 서비스와 Microsoft Entra Connect는 서로 직접적으로 충돌하지 않습니다.

안타깝게도 Microsoft Entra 암호 보호 프록시 소프트웨어는 Microsoft Entra 애플리케이션 프록시 소프트웨어에서 설치한 버전과 호환되지 않는 Microsoft Entra Connect 에이전트 업데이트 프로그램 서비스를 설치합니다. 이 비호환성으로 인해 에이전트 업데이트 서비스에서 소프트웨어 업데이트를 위해 Azure에 연결하지 못할 수 있습니다. 동일한 컴퓨터에 Microsoft Entra 암호 보호 프록시 및 Microsoft Entra 애플리케이션 프록시를 설치하지 않는 것이 좋습니다.

DC 에이전트와 프록시는 어떤 순서로 설치하고 등록해야 하나요?

프록시 에이전트 설치, DC 에이전트 설치, 포리스트 등록 및 프록시 등록의 순서가 지원됩니다.

이 기능을 배포할 때 도메인 컨트롤러의 성능 저하가 우려될 수 있나요?

Microsoft Entra 암호 보호 DC 에이전트 서비스는 기존의 정상적인 Active Directory 배포에서 도메인 컨트롤러 성능에 크게 영향을 주지 않아야 합니다.

대부분의 Active Directory 배포에서 암호 변경 작업은 지정된 도메인 컨트롤러에서 전체 워크로드의 작은 비율입니다. 예를 들어 사용자 계정이 10,000개이고 MaxPasswordAge 정책이 30일로 설정된 Active Directory 도메인을 가정해 보세요. 평균적으로 이 도메인은 매일 10000/30=~333개의 암호 변경 작업을 볼 수 있으며, 이는 단일 도메인 컨트롤러에 대한 적은 수의 작업입니다. 이러한 단일 DC에 대한 ~333번의 암호 변경이 1시간 동안 수행되는 최악의 시나리오를 고려해보세요. 예를 들어 이 시나리오는 많은 직원이 모두 월요일 아침에 근무하러 오게 될 때 발생할 수 있습니다. 이 경우에도 여전히 최대 333/60분 = 분당 6개의 암호 변경 내용이 있으며 이는 다시 큰 로드가 아닙니다.

그러나 현재 도메인 컨트롤러가 성능 제한 수준에서 이미 실행 중인 경우(예: CPU, 디스크 공간, 디스크 I/O 등과 관련하여 최대 처리됨) 이 기능을 배포하기 전에 도메인 컨트롤러를 더 추가하거나 사용 가능한 디스크 공간을 확장하는 것이 좋습니다. 위의 sysvol 디스크 공간 사용량에 대한 이전 질문을 참조하세요.

도메인의 일부 DC에서만 Microsoft Entra 암호 보호를 테스트하려고 합니다. 강제로 사용자 암호 변경에 해당 특정 DC를 사용하도록 할 수 있나요?

아니요. Windows 클라이언트 OS는 사용자가 암호를 변경할 때 사용되는 도메인 컨트롤러를 제어합니다. 도메인 컨트롤러는 Active Directory 사이트 및 서브넷 할당, 환경별 네트워크 구성 등의 요소에 따라 선택됩니다. Microsoft Entra Password Protection은 이러한 요소를 제어하지 않으며 사용자의 암호를 변경하기 위해 선택한 도메인 컨트롤러에 영향을 줄 수 없습니다.

부분적으로 이러한 목표에 도달하는 한 가지 방법은 지정된 Active Directory 사이트의 모든 도메인 컨트롤러에서 Microsoft Entra 암호 보호를 배포하는 것입니다. 이 방법은 해당 사이트에 할당된 Windows 클라이언트 및 해당 클라이언트에 로그인하고 암호를 변경하는 사용자에게 적절한 적용 범위를 제공합니다.

PDC(주 도메인 컨트롤러)에만 Microsoft Entra 암호 보호 DC 에이전트 서비스를 설치해도 도메인의 다른 모든 도메인 컨트롤러가 보호되나요?

아니요. 지정된 비 PDC 도메인 컨트롤러에서 사용자 암호가 변경되면 일반 텍스트 암호가 PDC로 절대 전송되지 않습니다(이 생각은 일반적인 오해임). 지정된 DC에서 새 암호가 수락되면 해당 DC는 해당 암호를 사용하여 암호의 다양한 인증-프로토콜 관련 해시를 만든 후 해당 해시를 디렉터리에 유지합니다. 텍스트 지우기 암호는 유지되지 않습니다. 그런 후에 업데이트된 해시가 PDC로 복제됩니다. 경우에 따라 네트워크 토폴로지 및 Active Directory 사이트 디자인과 같은 다양한 요인에 따라 PDC에서 직접 변경될 수 있습니다. (이전 질문을 참조하세요.)

요약하자면, PDC에서 Microsoft Entra 암호 보호 DC 에이전트 서비스를 배포하려면 도메인에서 100%의 기능 보안 검사에 도달해야 합니다. PDC에 기능을 배포해도 도메인의 다른 DC에 대한 Microsoft Entra 암호 보호 보안 혜택만 제공하는 것은 아닙니다.

에이전트를 내 온-프레미스 Active Directory 환경에 설치한 후에도 사용자 지정 스마트 잠금이 작동하지 않는 이유는 무엇인가요?

사용자 지정 스마트 잠금은 Microsoft Entra ID에서만 지원됩니다. Microsoft Entra 관리 센터에서 사용자 지정 스마트 잠금 설정을 변경하면 에이전트가 설치된 경우에도 온-프레미스 Active Directory 환경에 영향을 주지 않습니다.

Microsoft Entra 암호 보호에 System Center Operations Manager 관리 팩을 사용할 수 있나요?

아니요.

정책을 감사 모드로 구성한 경우에도 Microsoft Entra ID에서 여전히 약한 암호를 거부하는 이유는 무엇인가요?

감사 모드는 온-프레미스 Active Directory 환경에서만 지원됩니다. Microsoft Entra ID는 암호를 평가할 때 암시적으로 항상 "적용" 모드에 있습니다.

Microsoft Entra 암호 보호에서 암호를 거부하면 사용자에게 기존 Windows 오류 메시지가 표시됩니다. 사용자가 실제로 무슨 상황이 발생했는지 알 수 있도록 이 오류 메시지를 사용자 지정할 수 있나요?

아니요. 도메인 컨트롤러에서 암호를 거부하는 경우 사용자에게 표시되는 오류 메시지는 도메인 컨트롤러가 아니라 클라이언트 컴퓨터에서 제어합니다. 이 동작은 기본 Active Directory 암호 정책 또는 암호 필터 기반 솔루션(예: Microsoft Entra 암호 보호)에서 암호를 거부하는지 여부에 따라 수행됩니다.

소프트웨어의 올바른 작동을 확인하고 암호 평가 알고리즘을 더 잘 이해하기 위해 다양한 암호에 대한 몇 가지 기본 테스트를 수행할 수 있습니다. 이 섹션에서는 반복 가능한 결과를 생성하도록 설계된 이러한 테스트 방법에 대해 간략하게 설명합니다.

이러한 단계를 수행해야 하는 이유는 무엇일까요? 온-프레미스 Active Directory 환경에서 암호의 제어되고 반복 가능한 테스트를 수행하기 어렵게 만드는 몇 가지 요인이 있습니다.

• 암호 정책은 Azure에서 구성되고 유지되며, 정책의 복사본은 폴링 메커니즘을 사용하여 온-프레미스 DC 에이전트에서 정기적으로 동기화됩니다. 이 폴링 주기에 고유한 대기 시간으로 인해 혼동이 발생할 수 있습니다. 예를 들어 Azure에서 정책을 구성하지만 DC 에이전트와 동기화하는 것을 잊은 경우 테스트에서 예상된 결과를 생성하지 않을 수 있습니다. 폴링 간격은 현재 시간당 한 번으로 하드 코딩되지만, 정책 변경 사이에 한 시간을 기다리는 것은 대화형 테스트 시나리오에 적합하지 않습니다.
• 새 암호 정책이 도메인 컨트롤러에 동기화되면 다른 도메인 컨트롤러에 복제하는 동안 더 많은 대기 시간이 발생합니다. 이러한 지연으로 인해 최신 버전의 정책을 받지 못한 도메인 컨트롤러에 대해 암호 변경을 테스트하는 경우 예기치 않은 결과가 발생할 수 있습니다.
• 사용자 인터페이스를 통해 암호 변경을 테스트하면 결과를 신뢰하기 어렵습니다. 예를 들어 사용자 인터페이스에 잘못된 암호를 잘못 입력하는 것은 쉽습니다. 특히 대부분의 암호 사용자 인터페이스는 사용자 입력을 숨기기 때문에(예: Windows Ctrl-Alt-Delete -> 암호 UI 변경)
• 도메인에 가입된 클라이언트에서 암호 변경을 테스트할 때 사용되는 도메인 컨트롤러를 엄격하게 제어할 수는 없습니다. Windows 클라이언트 OS는 Active Directory 사이트 및 서브넷 할당, 환경별 네트워크 구성 등의 요소를 기반으로 도메인 컨트롤러를 선택합니다.

이러한 문제를 방지하기 위해 다음 단계는 도메인 컨트롤러에 로그인하는 동안 암호 재설정의 명령줄 테스트를 기반으로 합니다.

다음 단계에서는 하나 이상의 도메인 컨트롤러에 DC 에이전트를 설치하고 하나 이상의 프록시를 설치했으며 프록시와 포리스트를 모두 등록했다고 가정합니다.

1. 도메인 관리자 자격 증명 또는 테스트 사용자 계정을 만들고 암호를 재설정할 수 있는 충분한 권한이 있는 다른 자격 증명을 사용하여 도메인 컨트롤러에 로그온합니다. 도메인 컨트롤러에 DC 에이전트 소프트웨어가 설치되어 있고 다시 부팅되었는지 확인합니다.

2. 이벤트 뷰어를 열고, DC 에이전트 관리자 이벤트 로그로 이동합니다.

3. 관리자 권한으로 명령 프롬프트 창을 엽니다.

4. 암호 테스트를 수행하기 위한 테스트 계정을 만듭니다.

   사용자 계정을 만드는 여러 가지 방법이 있지만, 반복적인 테스트 주기 동안 쉽게 수행할 수 있는 명령줄 옵션이 제공됩니다.

   net.exe user <testuseraccountname> /add <password>
   

   아래의 설명을 위해 다음과 같이 "ContosoUser"라는 테스트 계정을 만들었다고 가정합니다.

   net.exe user ContosoUser /add <password>
   

5. 최소한 인증 관리자로 Microsoft Entra 관리 센터에 로그인합니다.

6. 보호 > 인증 방법 > 암호 보호로 이동합니다.

7. 수행하려는 테스트에 필요한 경우 Microsoft Entra 암호 보호 정책을 수정합니다. 예를 들어 [강제 적용 모드] 또는 [감사 모드]를 구성하거나 사용자 지정 금지 암호 목록에서 금지 용어의 목록을 수정하도록 결정할 수 있습니다.

8. DC 에이전트 서비스를 중지했다가 다시 시작하여 새 정책을 동기화합니다.

   이 단계는 다양한 방법으로 수행할 수 있습니다. 한 가지 방법은 마우스 오른쪽 단추로 Microsoft Entra 암호 보호 DC 에이전트 서비스를 클릭하고 "다시 시작"을 선택하여 [서비스 관리] 관리 콘솔을 사용하는 것입니다. 다른 방법은 명령 프롬프트 창에서 다음과 같이 수행할 수 있습니다.

   net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgent
   

9. 이벤트 뷰어를 확인하여 새 정책이 다운로드되었는지 확인합니다.

   DC 에이전트 서비스를 중지하고 시작할 때마다 연속적으로 발생하는 두 개의 30006 이벤트가 표시됩니다. 첫 번째 30006 이벤트는 sysvol 공유의 디스크에 캐시된 정책을 반영합니다. 두 번째 30006 이벤트(있는 경우)에는 업데이트된 테넌트 정책 날짜가 있어야 하며, 이 경우 Azure에서 다운로드한 정책을 반영합니다. 테넌트 정책 날짜 값은 현재 Azure에서 정책을 다운로드한 대략적인 타임스탬프를 표시하도록 코딩되어 있습니다.

   두 번째 30006 이벤트가 표시되지 않으면 계속하기 전에 문제를 해결해야 합니다.

   30006 이벤트는 다음 예와 비슷합니다.

   The service is now enforcing the following Azure password policy.
   
   Enabled: 1
   AuditOnly: 0
   Global policy date: ‎2018‎-‎05‎-‎15T00:00:00.000000000Z
   Tenant policy date: ‎2018‎-‎06‎-‎10T20:15:24.432457600Z
   Enforce tenant policy: 1
   

   예를 들어 적용 모드와 감사 모드를 변경하면 AuditOnly 플래그가 수정됩니다(AuditOnly=0으로 나열된 정책은 적용 모드에 있음). 사용자 지정 금지 암호 목록의 변경 내용은 위의 30006 이벤트에 직접 반영되지 않으며 보안상의 이유로 다른 곳에서는 기록되지 않습니다. 이 변경 후 Azure에서 정책을 성공적으로 다운로드하면 수정된 사용자 지정 금지 암호 목록도 포함됩니다.

10. 테스트 사용자 계정에서 새 암호를 다시 설정하여 테스트를 실행합니다.

    이 단계는 명령 프롬프트 창에서 다음과 같이 수행할 수 있습니다.

    net.exe user ContosoUser <password>
    

    명령이 실행된 후 이벤트 뷰어를 살펴보면 명령의 결과에 대한 자세한 정보를 얻을 수 있습니다. 암호 유효성 검사 결과 이벤트는 DC 에이전트 관리자 이벤트 로그 항목에 설명되어 있습니다. 이러한 이벤트를 사용하여 net.exe 명령의 대화형 출력 외에도 테스트 결과의 유효성을 검사합니다.

    예를 들어 Microsoft 전체 목록에서 금지 암호를 설정하려고 합니다(목록은 문서화되지 않았지만, 여기서 알려진 금지 용어에 대해 테스트할 수 있음). 다음 예에서는 정책을 강제 적용 모드로 구성하고 0개의 용어를 사용자 지정 금지 암호 목록에 추가했다고 가정합니다.

    net.exe user ContosoUser PassWord
    The password doesn't meet the password policy requirements. Check the minimum password length, password complexity, and password history requirements.
    
    More help is available by typing NET HELPMSG 2245.
    

    설명서에 따라 테스트가 암호 재설정 작업이었으므로 ContosoUser 사용자에 대한 10017 및 30005 이벤트가 표시됩니다.

    10017 이벤트는 다음 예와 같습니다.

    The reset password for the specified user was rejected because it didn't comply with the current Azure password policy. For more information, please see the correlated event log message.
    
    UserName: ContosoUser
    FullName: 
    

    30005 이벤트는 다음 예와 같습니다.

    The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy.
    
    UserName: ContosoUser
    FullName: 
    

    재미있었나요? 다른 예를 사용해 보겠습니다! 이제 정책이 감사 모드에 있는 동안 사용자 지정 금지 목록에 의해 금지된 암호를 설정하려고 합니다. 이 예제에서는 정책을 감사 모드로 구성하고, 사용자 지정 금지 암호 목록에 "lachrymose"라는 용어를 추가하고, 앞에서 설명한 대로 DC 에이전트 서비스를 순환하여 결과 새 정책을 도메인 컨트롤러에 동기화하는 단계를 완료했다고 가정합니다.

    좋습니다. 이제 금지 암호의 변형을 설정합니다.

    net.exe user ContosoUser LaChRymoSE!1
    The command completed successfully.
    

    이번에는 정책이 감사 모드에 있으므로 성공했습니다. ContosoUser 사용자에 대한 10025 및 30007 이벤트가 표시됩니다.

    10025 이벤트는 다음 예와 같습니다.

    The reset password for the specified user would normally have been rejected because it didn't comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details.
    
    UserName: ContosoUser
    FullName: 
    

    30007 이벤트는 다음 예와 같습니다.

    The reset password for the specified user would normally be rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.
    
    UserName: ContosoUser
    FullName: 
    

11. 계속 진행하여 선택한 다양한 암호를 테스트하고, 이전 단계에서 설명한 절차를 사용하여 이벤트 뷰어에서 결과를 확인합니다. Microsoft Entra 관리 센터에서 정책을 변경해야 하는 경우 앞에서 설명한 대로 새 정책을 DC 에이전트에 동기화해야 합니다.

Microsoft Entra 암호 보호의 암호 유효성 검사 동작에 대한 제어된 테스트를 수행할 수 있는 절차에 대해 설명했습니다. 도메인 컨트롤러의 명령줄에서 직접 사용자 암호를 재설정하는 것은 이러한 테스트를 수행하는 이상한 수단으로 보일 수 있지만, 앞에서 설명한 대로 반복 가능한 결과를 생성하도록 설계되었습니다. 다양한 암호를 테스트할 때는 예상하지 못한 결과를 설명하는 데 도움이 될 수 있으므로 암호 평가 알고리즘 을 염두에 두어야 합니다.

다음 링크는 핵심 Microsoft Entra Password Protection 설명서의 일부가 아니지만 기능에 대한 추가 정보의 유용한 출처일 수 있습니다.

Microsoft Entra 암호 보호가 이제 일반 공급됩니다!

이메일 피싱 방지 가이드 – 15부: Microsoft Entra 암호 보호 서비스 구현(온-프레미스에도 해당)

이제 Microsoft Entra 암호 보호 및 스마트 잠금이 공개 미리 보기로 제공됨

Microsoft Entra Password Protection 및 배포 방법에 대해 자세히 알아보려면 Microsoft 자동 관리 서비스를 사용할 수 있습니다. 이 서비스는 프리미어 또는 통합 지원 계약을 체결한 고객에게 제공됩니다. 이 서비스를 Microsoft Entra ID: 암호 보호라고 합니다. 자세한 내용은 고객 성공 계정 관리자에게 문의하세요.

다음 단계

여기서 답변되지 않은 온-프레미스 Microsoft Entra 암호 보호 질문이 있으면 아래의 피드백 항목을 제출해 주세요. 감사합니다!

Microsoft Entra 암호 보호 배포