Microsoft Entra 인증서 기반 인증 설정

조직에서는 MICROSOFT Entra CBA(인증서 기반 인증)를 사용하여 사용자 X.509 인증서를 통해 피싱 방지, 최신 및 암호 없는 인증을 구현할 수 있습니다.

이 문서에서는 X.509 인증서를 사용하여 테넌트 사용자가 인증하도록 허용하거나 요구하도록 Microsoft Entra 테넌트 설정 방법을 알아봅니다. 사용자는 애플리케이션 및 브라우저 로그인에 PKI(엔터프라이즈 공개 키 인프라)를 사용하여 X.509 인증서를 만듭니다.

Microsoft Entra CBA가 설정되면 로그인하는 동안 사용자에게 암호를 입력하는 대신 인증서를 사용하여 인증하는 옵션이 표시됩니다. 일치하는 여러 인증서가 디바이스에 있는 경우 사용자는 관련 인증서를 선택하고 사용자 계정에 대해 인증서의 유효성을 검사합니다. 유효성 검사가 성공하면 사용자가 로그인합니다.

이 문서에 설명된 단계를 완료하여 Office 365 Enterprise 및 미국 정부 계획의 테넌트에 대해 Microsoft Entra CBA를 구성하고 사용합니다. PKI가 이미 구성되어 있어야 합니다.

필수 조건

다음 전제 조건이 충족되었는지 확인하십시오.

하나 이상의 CA(인증 기관) 및 중간 CA가 Microsoft Entra ID로 구성됩니다.
사용자는 Microsoft Entra ID의 클라이언트 인증을 위해 테넌트에 구성된 신뢰할 수 있는 PKI에서 발급된 사용자 인증서에 액세스할 수 있습니다.
각 CA에는 인터넷 연결 URL에서 참조할 수 있는 CRL(인증서 해지 목록)이 있습니다. 신뢰할 수 있는 CA에 CRL이 구성되지 않은 경우 Microsoft Entra ID는 CRL 검사를 수행하지 않고 사용자 인증서 해지가 작동하지 않으며 인증이 차단되지 않습니다.

고려 사항

PKI가 안전하고 쉽게 손상될 수 없는지 확인합니다. 위반이 발생하면 공격자는 클라이언트 인증서를 만들고 서명하고 온-프레미스에서 동기화된 사용자를 포함하여 테넌트에서 모든 사용자를 손상시킬 수 있습니다. 강력한 키 보호 전략 및 기타 물리적 및 논리적 제어는 외부 공격자 또는 내부자 위협이 PKI의 무결성을 손상시키지 않도록 심층 방어를 제공할 수 있습니다. 자세한 내용은 PKI 보안을 참조하세요.
선택한 알고리즘, 키 길이 및 데이터 보호를 포함하여 Microsoft Cryptography에 대한 모범 사례는 Microsoft 권장 사항을 참조하세요. 권장 알고리즘, 권장 키 길이 및 NIST 승인 곡선 중 하나를 사용해야 합니다.
지속적인 보안 개선의 일환으로 Azure 및 Microsoft 365 엔드포인트는 TLS 1.3에 대한 지원을 추가했습니다. 이 프로세스는 Azure 및 Microsoft 365에서 수천 개의 서비스 엔드포인트를 처리하는 데 몇 달이 걸릴 것으로 예상됩니다. Microsoft Entra CBA에서 사용하는 Microsoft Entra 엔드포인트는 업데이트 *.certauth.login.microsoftonline.com*.certauth.login.microsoftonline.us에 포함됩니다.

TLS 1.3은 인터넷에서 가장 일반적으로 배포된 보안 프로토콜의 최신 버전입니다. TLS 1.3은 데이터를 암호화하여 두 엔드포인트 간에 보안 통신 채널을 제공합니다. 사용되지 않는 암호화 알고리즘을 제거하고, 이전 버전에 대한 보안을 강화하며, 가능한 한 많은 핸드셰이크를 암호화합니다. 애플리케이션 및 서비스에서 TLS 1.3 테스트를 시작하는 것이 좋습니다.
PKI를 평가할 때 인증서 발급 정책 및 적용을 검토하는 것이 중요합니다. 앞에서 설명한 대로 Microsoft Entra 구성에 CA를 추가하면 해당 CA에서 발급한 인증서가 Microsoft Entra ID의 모든 사용자를 인증할 수 있습니다.

CA가 인증서를 발급하는 방법과 시기 및 재사용 가능한 식별자를 구현하는 방법을 고려하는 것이 중요합니다. 관리자는 특정 인증서를 사용하여 사용자를 인증할 수 있는지 확인해야 하지만 높은 선호도 바인딩만 사용하여 특정 인증서만 사용자를 인증할 수 있다는 높은 수준의 보증을 달성해야 합니다. 자세한 내용은 높은 선호도 바인딩을 참조하세요.

Microsoft Entra CBA 구성 및 테스트

Microsoft Entra CBA를 켜기 전에 몇 가지 구성 단계를 완료해야 합니다.

관리자는 사용자 인증서를 발급하는 신뢰할 수 있는 CA를 구성해야 합니다. 다음 다이어그램에 표시된 것처럼 Azure는 RBAC(역할 기반 액세스 제어)를 사용하여 최소 권한의 관리자만 변경하도록 합니다.

중요한

사용 권한이 가장 적은 역할을 사용하는 것이 좋습니다. 이 방법은 조직의 보안을 개선하는 데 도움이 됩니다. 전역 관리자는 긴급 시나리오 또는 기존 역할을 사용할 수 없는 경우 제한해야 하는 높은 권한의 역할입니다.

필요에 따라 인증서를 단일 단계 인증 또는 MFA(다단계 인증)에 매핑하도록 인증 바인딩을 구성할 수 있습니다. 인증서 필드를 사용자 개체의 특성에 매핑하도록 사용자 이름 바인딩을 구성합니다. 인증 정책 관리자는 사용자 관련 설정을 구성할 수 있습니다.

모든 구성이 완료되면 테넌트에서 Microsoft Entra CBA를 켭니다.

Microsoft Entra 인증서 기반 인증을 켜는 데 필요한 단계의 개요를 보여 주는 다이어그램

1단계: PKI 기반 트러스트 저장소를 사용하여 CA 구성

Microsoft Entra에는 새로운 PKI 기반 CA 트러스트 저장소가 있습니다. 트러스트 저장소는 CA를 각 PKI에 대한 컨테이너 개체 내에 유지합니다. 관리자는 CA의 플랫 목록을 관리할 수 있는 것보다 PKI를 기반으로 컨테이너에서 CA를 더 쉽게 관리할 수 있습니다.

PKI 기반 트러스트 저장소는 CA 수와 각 CA 파일의 크기에 대한 클래식 신뢰 저장소보다 더 높은 제한을 가합니다. PKI 기반 트러스트 저장소는 각 CA 개체에 대해 최대 250개의 CA와 8KB를 지원합니다.

클래식 트러스트 저장소를 사용하여 CA를 구성하는 경우 PKI 기반 트러스트 저장소를 설정하는 것이 좋습니다. PKI 기반 트러스트 저장소는 확장 가능하며 발급자 힌트와 같은 새로운 기능을 지원합니다.

관리자는 사용자 인증서를 발급하는 신뢰할 수 있는 CA를 구성해야 합니다. 최소 권한의 관리자만 변경해야 합니다. PKI 기반 트러스트 저장소에는 Privileged Authentication 관리자 역할이 할당됩니다.

PKI 기반 트러스트 저장소의 PKI 업로드 기능은 Microsoft Entra ID P1 또는 P2 라이선스에서만 사용할 수 있습니다. 그러나 Microsoft Entra 무료 라이선스를 사용하면 관리자는 PKI 파일을 업로드하는 대신 모든 CA를 개별적으로 업로드할 수 있습니다. 그런 다음 PKI 기반 트러스트 저장소를 구성하고 업로드된 CA 파일을 추가할 수 있습니다.

Microsoft Entra 관리 센터를 사용하여 CA 구성

PKI 컨테이너 개체 만들기(Microsoft Entra 관리 센터)

PKI 컨테이너 개체를 만들려면 다음을 수행합니다.

Privileged Authentication 관리자 역할이 할당된 계정으로 Microsoft Entra 관리 센터에 로그인합니다.
Entra ID>ID 보안 점수>공개 키 인프라로 이동합니다.
PKI 만들기를 선택합니다.
표시 이름에 이름을 입력합니다.
선택하고생성합니다.
열을 추가하거나 삭제하려면 열 편집을 선택합니다.
PKIs 목록을 새로 고치려면 새로 고침을 선택합니다.

PKI 컨테이너 개체 삭제

PKI를 삭제하려면 PKI를 선택하고 삭제를 선택합니다. PKI에 CA가 포함된 경우 PKI의 이름을 입력하여 PKI의 모든 CA 삭제를 승인합니다. 그런 다음 삭제를 선택합니다.

PKI 컨테이너 개체에 개별 CA 업로드

PKI 컨테이너에 CA를 업로드하려면 다음을 수행합니다.

인증 기관 추가를 선택합니다.
CA 파일을 선택합니다.
CA가 루트 인증서인 경우 예를 선택합니다. 그렇지 않으면 아니요를 선택합니다.
인증서 해지 목록 URL의 경우 해지된 모든 인증서를 포함하는 CA 기본 CRL에 대한 인터넷 연결 URL을 입력합니다. URL이 설정되지 않은 경우 해지된 인증서를 사용하여 인증하려는 시도가 실패하지 않습니다.
델타 인증서 해지 목록 URL의 경우 마지막 기본 CRL이 게시된 이후 해지된 모든 인증서가 포함된 CRL의 인터넷 연결 URL을 입력합니다.
CA가 발급자 힌트에 포함되지 않아야 하는 경우 발급자 힌트를 해제합니다. 발급자 힌트 플래그는 기본적으로 꺼져 있습니다.
저장을 선택합니다.
CA를 삭제하려면 CA를 선택하고 삭제를 선택합니다.
열을 추가하거나 삭제하려면 열 편집을 선택합니다.
PKIs 목록을 새로 고치려면 새로 고침을 선택합니다.

처음에는 100개의 CA 인증서가 표시됩니다. 창을 아래로 스크롤하면 더 많이 표시됩니다.

PKI 컨테이너 개체에 모든 CA 업로드

PKI 컨테이너에 모든 CA를 대량 업로드하려면 다음을 수행합니다.

PKI 컨테이너 개체를 만들거나 기존 컨테이너를 엽니다.
PKI 업로드를 선택합니다.
파일의 HTTP 인터넷 연결 URL을 입력합니다 .p7b .
파일의 SHA-256 체크섬을 입력합니다.
업로드를 선택합니다.

PKI 업로드 프로세스는 비동기적입니다. 각 CA가 업로드되면 PKI에서 사용할 수 있습니다. 전체 PKI 업로드에는 최대 30분이 걸릴 수 있습니다.
새로 고침을 선택하여 CA 목록을 새로 고칩니다.
업로드된 각 CA CRL 엔드포인트 특성은 CRL 배포 지점 특성으로 나열된 CA 인증서의 첫 번째 사용 가능한 HTTP URL로 업데이트됩니다. 리프 인증서를 수동으로 업데이트해야 합니다.

PKI .p7b 파일의 SHA-256 체크섬을 생성하려면 다음을 실행합니다.

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

PKI 편집

PKI 행에서 ... 를 선택하고 편집을 선택합니다.
새 PKI 이름을 입력합니다.
저장을 선택합니다.

인증 기관 편집

CA 행에서 ... 를 선택하고 편집을 선택합니다.
요구 사항에 따라 CA 유형(루트 또는 중간), CRL URL, 델타 CRL URL 또는 발급자 힌트 사용 플래그에 대한 새 값을 입력합니다.
저장을 선택합니다.

발급자 힌트 특성 대량 편집

여러 CA를 편집하고 발급자 힌트 사용 특성을 켜거나 끄려면 여러 CA를 선택합니다.
편집을 선택한 다음 발급자 힌트 편집을 선택합니다.
선택한 모든 CA에 대해 발급자 힌트 사용 확인란을 선택하거나 선택 취소하여 선택한 모든 CA에 대해 발급자 힌트 사용 플래그를 해제합니다. 기본값은 확정되지 않습니다.
저장을 선택합니다.

PKI 복원

삭제된 PKIs 탭을 선택합니다.
PKI를 선택하고 PKI 복원을 선택합니다.

CA 복원

삭제된 CA 탭을 선택합니다.
CA 파일을 선택한 다음 인증 기관 복원을 선택합니다.

CA에 대한 isIssuerHintEnabled 특성 구성

발급자 힌트는 TLS(전송 계층 보안) 핸드셰이크의 일부로 신뢰할 수 있는 CA 표시기를 다시 보냅니다. 신뢰할 수 있는 CA 목록은 테넌트가 Microsoft Entra 트러스트 저장소에 업로드하는 CA의 주체로 설정됩니다. 자세한 내용은 발급자 힌트 이해를 참조하세요.

기본적으로 Microsoft Entra 트러스트 저장소에 있는 모든 CA의 주체 이름은 힌트로 전송됩니다. 특정 CA에 대해서만 힌트를 다시 보내려면 발급자 힌트 특성을 isIssuerHintEnabledtrue.로 설정합니다.

서버는 발급자 힌트(CA의 주체 이름)에 대해 최대 16KB 응답을 TLS 클라이언트에 다시 보낼 수 있습니다. 사용자 인증서를 isIssuerHintEnabled 발급하는 true CA에 대해서만 특성을 설정하는 것이 좋습니다.

동일한 루트 인증서의 여러 중간 CA가 사용자 인증서를 발급하는 경우 기본적으로 모든 인증서가 인증서 선택기에서 표시됩니다. 특정 CA에 대해 true 설정하는 isIssuerHintEnabled 경우 인증서 선택기에서 관련 사용자 인증서만 표시됩니다.

Microsoft Graph API를 사용하여 CA 구성

다음 예제에서는 Microsoft Graph를 사용하여 PKI 또는 CA에 대한 HTTP 메서드를 통해 CRUD(만들기, 읽기, 업데이트 및 삭제) 작업을 실행하는 방법을 보여 줍니다.

PKI 컨테이너 개체 만들기(Microsoft Graph)

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/
Content-Type: application/json
{
   "displayName": "ContosoPKI"
}

모든 PKI 개체 가져오기

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations
ConsistencyLevel: eventual

PKI ID로 PKI 개체 가져오기

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/
ConsistencyLevel: eventual

.p7b 파일을 사용하여 CA 업로드

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-id>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
     "uploadUrl":"https://CBA/demo/CBARootPKI.p7b,
     "sha256FileHash": "AAAAAAD7F909EC2688567DE4B4B0C404443140D128FE14C577C5E0873F68C0FE861E6F"
}

PKI의 모든 CA 가져오기

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities
ConsistencyLevel: eventual

CA ID별 PKI에서 특정 CA 가져오기

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
ConsistencyLevel: eventual

특정 CA 발급자 힌트 플래그 업데이트

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
   "isIssuerHintEnabled": true
}

PowerShell을 사용하여 CA 구성

이러한 단계에서는 Microsoft Graph PowerShell을 사용합니다.

관리자 권한으로 실행 옵션을 사용하여 PowerShell을 시작합니다.

Microsoft Graph PowerShell SDK를 설치하고 가져옵니다.

Install-Module Microsoft.Graph -Scope AllUsers
Import-Module Microsoft.Graph.Authentication
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

테넌트에 연결하고 모두 수락합니다.

   Connect-MGGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All" -TenantId <tenantId>

PKI 기반 트러스트 저장소와 클래식 CA 저장소 간의 우선 순위 지정

CA가 PKI 기반 CA 저장소와 클래식 CA 저장소 모두에 있는 경우 PKI 기반 트러스트 저장소의 우선 순위가 지정됩니다.

클래식 CA 저장소는 다음 시나리오에서 우선 순위가 지정됩니다.

CA는 두 저장소에 모두 존재하며 PKI 기반 저장소에는 CRL이 없지만 클래식 저장소 CA에는 유효한 CRL이 있습니다.
CA는 두 저장소에 모두 존재하며 PKI 기반 저장소 CA CRL은 클래식 저장소 CA CRL과 다릅니다.

Microsoft Entra 로그인 로그 중단 항목에는 인증 중에 클래식 또는 레거시 트러스트 저장소가 전혀 사용되었는지 여부를 나타내는 두 가지 특성이 추가 세부 정보 아래에 있습니다.

사용된 레거시 저장소 는 PKI 기반 저장소가 사용됨을 나타내는 값이 0 입니다. 값 이 1이면 클래식 또는 레거시 저장소가 사용됨을 나타냅니다.
레거시 저장소 사용 정보는 클래식 또는 레거시 저장소가 사용되는 이유를 표시합니다.

PKI 기반 저장소 또는 클래식 CA 저장소를 사용하기 위한 로그인 로그 항목을 보여 주는 스크린샷

감사 로그

신뢰 저장소 내의 PKI 또는 CA에서 실행하는 CRUD 작업은 Microsoft Entra 감사 로그에 표시됩니다.

클래식 CA 저장소에서 PKI 기반 저장소로 마이그레이션

테넌트 관리자는 모든 CA를 PKI 기반 저장소에 업로드할 수 있습니다. 그러면 PKI CA 저장소는 클래식 저장소보다 우선 순위가 지정되며 모든 CBA 인증은 PKI 기반 저장소를 통해 수행됩니다. 테넌트 관리자는 로그인 로그에서 클래식 또는 레거시 저장소가 사용되었다는 표시가 없음을 확인한 후 클래식 또는 레거시 저장소에서 CA를 제거할 수 있습니다.

FAQ

PKI 업로드가 실패하는 이유는 무엇인가요?

PKI 파일이 유효하고 문제 없이 액세스할 수 있는지 확인합니다. PKI 파일의 최대 크기는 2MB(CA 개체당 250 CA 및 8KB)입니다.

PKI 업로드에 대한 서비스 수준 계약은 무엇인가요?

PKI 업로드는 비동기 작업이며 완료하는 데 최대 30분이 걸릴 수 있습니다.

PKI 파일에 대한 SHA-256 체크섬을 생성하려면 어떻게 해야 하나요?

PKI .p7b 파일의 SHA-256 체크섬을 생성하려면 다음 명령을 실행합니다.

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

2단계: 테넌트에 대한 CBA 켜기

중요한

사용자가 인증 방법 정책의 CBA 범위로 지정된 경우 사용자는 MFA를 완료할 수 있는 것으로 간주됩니다. 이 정책 요구 사항은 사용자가 인증의 일부로 ID 증명을 사용하여 사용 가능한 다른 방법을 등록할 수 없음을 의미합니다. 사용자가 인증서에 액세스할 수 없는 경우 인증서가 잠기고 MFA에 대한 다른 메서드를 등록할 수 없습니다. 인증 정책 관리자 역할이 할당된 관리자는 유효한 인증서가 있는 사용자에 대해서만 CBA를 설정해야 합니다. CBA에 모든 사용자를 포함하지 마세요. 유효한 인증서를 사용할 수 있는 사용자 그룹만 사용합니다. 자세한 내용은 Microsoft Entra 다단계 인증을 참조하세요.

Microsoft Entra 관리 센터를 통해 CBA를 켜려면 다음을 수행합니다.

인증 정책 관리자 역할 이상이 할당된 계정으로 Microsoft Entra 관리 센터에 로그인합니다.
모든 그룹 그룹으로> 이동합니다.
새 그룹을 선택하고 CBA 사용자에 대한 그룹을 만듭니다.
Entra ID>인증 방법>인증서 기반 인증으로 이동합니다.
사용 및 대상에서 사용을 선택한 다음 I 승인 확인란을 선택합니다.
그룹>추가 선택 선택
만든 그룹과 같은 특정 그룹을 선택한 다음 선택을 선택합니다. 모든 사용자 대신 특정 그룹을 사용합니다.
저장을 선택합니다.

테넌트에 대해 CBA가 켜지면 테넌트 내 모든 사용자에게 인증서를 사용하여 로그인하는 옵션이 표시됩니다. CBA를 사용할 수 있는 사용자만 X.509 인증서를 사용하여 인증할 수 있습니다.

참고

네트워크 관리자는 엔드포인트 외에도 조직의 클라우드 환경에 대한 인증서 인증 엔드포인트에 login.microsoftonline.com 대한 액세스를 허용해야 합니다. 인증서 인증 엔드포인트에서 TLS 검사를 해제하여 클라이언트 인증서 요청이 TLS 핸드셰이크의 일부로 성공하는지 확인합니다.

3단계: 인증 바인딩 정책 구성

인증 바인딩 정책은 인증 강도를 단일 요소 또는 MFA로 설정하는 데 도움이 됩니다. 테넌트에서 모든 인증서에 대한 기본 보호 수준은 단일 단계 인증입니다.

테넌트 수준에서 기본 선호도 바인딩은 낮은 선호도입니다. 인증 정책 관리자는 기본값을 1단계 인증에서 MFA로 변경할 수 있습니다. 보호 수준이 변경되면 테넌트에 있는 모든 인증서가 MFA로 설정됩니다. 마찬가지로 테넌트 수준에서 선호도 바인딩을 높은 선호도로 설정할 수 있습니다. 그런 다음 높은 선호도 특성만 사용하여 모든 인증서의 유효성을 검사합니다.

중요한

관리자는 테넌트 기본값을 대부분의 인증서에 적용할 수 있는 값으로 설정해야 합니다. 테넌트 기본값과 다른 보호 수준 또는 선호도 바인딩이 필요한 특정 인증서에 대해서만 사용자 지정 규칙을 만듭니다. 모든 인증 방법 구성은 동일한 정책 파일에 있습니다. 여러 중복 규칙을 만들면 정책 파일 크기 제한을 초과할 수 있습니다.

인증 바인딩 규칙은 발급자, OID(정책 개체 ID) 및 발급자 및 정책 OID와 같은 인증서 특성을 지정된 값에 매핑합니다. 규칙은 해당 규칙에 대한 기본 보호 수준 및 선호도 바인딩을 설정합니다.

Microsoft Entra 관리 센터를 통해 기본 테넌트 설정을 수정하고 사용자 지정 규칙을 만들려면 다음을 수행합니다.

인증 정책 관리자 역할 이상이 할당된 계정으로 Microsoft Entra 관리 센터에 로그인합니다.
Entra ID>인증 방법>정책으로 이동합니다.
마이그레이션 관리에서 인증 방법>인증서 기반 인증을 선택합니다.
인증 바인딩 및 사용자 이름 바인딩을 설정하려면 구성을 선택합니다.
기본값을 MFA로 변경하려면 다단계 인증을 선택합니다. 보호 수준 특성의 기본값은 단일 단계 인증입니다.

참고

사용자 지정 규칙이 추가되지 않은 경우 기본 보호 수준이 적용됩니다. 사용자 지정 규칙을 추가하면 규칙 수준에서 정의된 보호 수준이 기본 보호 수준 대신 적용됩니다.
또한 테넌트 기본값과 보호 수준 또는 선호도 바인딩에 다른 값이 필요한 클라이언트 인증서의 보호 수준을 결정하는 데 도움이 되도록 사용자 지정 인증 바인딩 규칙을 설정할 수도 있습니다. 인증서에서 발급자 주체 또는 정책 OID 또는 두 필드를 사용하여 규칙을 구성할 수 있습니다.

인증 바인딩 규칙은 인증서 특성(발급자 또는 정책 OID)을 값에 매핑합니다. 이 값은 해당 규칙의 기본 보호 수준을 설정합니다. 여러 규칙을 만들 수 있습니다. 다음 예제에서는 테넌트 기본값이 다단계 인증 이고 선호도 바인딩의 경우 낮 다고 가정합니다.

사용자 지정 규칙을 추가하려면 규칙 추가를 선택합니다.

인증서 발급자별로 규칙을 만들려면 다음을 수행합니다.
1. 인증서 발급자를 선택합니다.
2. 인증서 발급자 식별자의 경우 관련 값을 선택합니다.
3. 인증 강도의 경우 다단계 인증을 선택합니다.
4. 선호도 바인딩의 경우 낮게를 선택합니다.
5. 추가를 선택합니다.
6. 메시지가 표시되면 I 승인 확인란을 선택하여 규칙을 추가합니다.
정책 OID로 규칙을 만들려면:
1. 정책 OID를 선택합니다.
2. 정책 OID의 경우 값을 입력합니다.
3. 인증 강도의 경우 단일 단계 인증을 선택합니다.
4. 선호도 바인딩의 경우 선호도 바인딩에 대해 낮음을 선택합니다.
5. 추가를 선택합니다.
6. 메시지가 표시되면 I 승인 확인란을 선택하여 규칙을 추가합니다.
발급자 및 정책 OID로 규칙을 만들려면 다음을 수행합니다.
1. 인증서 발급자 및 정책 OID를 선택합니다.
2. 발급자를 선택하고 정책 OID를 입력합니다.
3. 인증 강도의 경우 다단계 인증을 선택합니다.
4. 선호도 바인딩의 경우 낮게를 선택합니다.
5. 추가를 선택합니다.
6. 정책 OID 3.4.5.6 가 있고 CN=CBATestRootProd발급된 인증서를 사용하여 인증합니다. 다단계 클레임에 대한 인증 통과를 확인합니다.
발급자 및 일련 번호로 규칙을 만들려면 다음을 수행합니다.
1. 인증 바인딩 정책을 추가합니다. 정책을 사용하려면 정책 OID 1.2.3.4.6 를 사용하여 발급한 CN=CBATestRootProd 인증서에 높은 선호도 바인딩만 필요합니다. 발급자와 일련 번호가 사용됩니다.
2. 인증서 필드를 선택합니다. 이 예제에서는 발급자 및 일련 번호를 선택합니다.
3. 지원되는 유일한 사용자 특성은 .입니다 certificateUserIds. 추가를 선택하고 certificateUserIds 선택합니다.
4. 저장을 선택합니다.
  
  로그인 로그에는 로그인에 사용된 바인딩과 인증서의 세부 정보가 표시됩니다.
확인을 선택하여 사용자 지정 규칙을 저장합니다.

중요한

개체 식별자 형식을 사용하여 정책 OID를 입력합니다. 예를 들어 인증서 정책에 모든 발급 정책이 표시되면 규칙을 추가할 때처럼 2.5.29.32.0 정책 OID를 입력합니다. 모든 발급 정책 문자열이 규칙 편집기에서 유효하지 않으며 적용되지 않습니다.

4단계: 사용자 이름 바인딩 정책 구성

사용자 이름 바인딩 정책은 사용자 인증서의 유효성을 검사하는 데 도움이 됩니다. 기본적으로 사용자를 확인하려면 인증서 userPrincipalName 의 보안 주체 이름을 사용자 개체에 매핑합니다.

인증 정책 관리자는 기본값을 재정의하고 사용자 지정 매핑을 만들 수 있습니다. 자세한 내용은 사용자 이름 바인딩 작동 방식을 참조하세요.

특성을 사용하는 다른 시나리오는 certificateUserIds인증서 사용자 ID를 참조하세요.

중요한

사용자 이름 바인딩 정책에서 사용자 개체의 특성과 userPrincipalName 같은 certificateUserIdsonPremisesUserPrincipalName동기화된 특성을 사용하는 경우 온-프레미스 Windows Server Active Directory에서 관리 권한이 있는 계정은 Microsoft Entra ID의 이러한 특성에 영향을 주는 변경을 수행할 수 있습니다. 예를 들어 Microsoft Entra Connect Server에서 사용자 개체 또는 관리자 역할에 대한 권한을 위임한 계정은 이러한 유형의 변경을 수행할 수 있습니다.

사용자 특성 중 하나로 바인딩할 X.509 인증서 필드 중 하나를 선택하여 사용자 이름 바인딩을 만듭니다. 사용자 이름 바인딩 순서는 바인딩의 우선 순위 수준을 나타냅니다. 첫 번째 사용자 이름 바인딩은 우선 순위가 가장 높습니다.

지정된 X.509 인증서 필드가 인증서에 있지만 Microsoft Entra ID에서 해당 값이 있는 사용자 개체를 찾지 못하면 인증에 실패합니다. 그런 다음, Microsoft Entra ID는 목록에서 다음 바인딩을 시도합니다.
저장을 선택합니다.

최종 구성은 다음 예제와 유사합니다.

5단계: 구성 테스트

이 섹션에서는 인증서 및 사용자 지정 인증 바인딩 규칙을 테스트하는 방법을 설명합니다.

인증서 테스트

첫 번째 구성 테스트에서 디바이스 브라우저를 사용하여 MyApps 포털 에 로그인하려고 시도합니다.

UPN(사용자 계정 이름)을 입력합니다.
다음을 선택합니다.

휴대폰 로그인 또는 FIDO2와 같은 다른 인증 방법을 사용할 수 있게 만든 경우 사용자에게 다른 로그인 대화 상자가 표시될 수 있습니다.
인증서로 로그인을 선택합니다.
클라이언트 인증서 선택기 UI에서 올바른 사용자 인증서를 선택하고 확인을 선택합니다.
MyApps 포털에 로그인했는지 확인합니다.

귀하의 로그인이 성공적이라면 다음을 알고 있는 것입니다.

사용자 인증서가 테스트 디바이스에 프로비전됩니다.
Microsoft Entra ID는 신뢰할 수 있는 CA를 사용하도록 올바르게 구성됩니다.
사용자 이름 바인딩이 올바르게 구성되었습니다. 사용자가 검색되고 인증됩니다.

사용자 지정 인증 바인딩 규칙 테스트

다음으로, 강력한 인증의 유효성을 검사하는 시나리오를 완료합니다. 두 가지 인증 정책 규칙을 만듭니다. 하나는 단일 단계 인증을 충족하는 발급자 주체를 사용하고 다른 하나는 정책 OID를 사용하여 다단계 인증을 충족하는 것입니다.

보호 수준의 단일 단계 인증을 사용하여 발급자 주체 규칙을 만듭니다. 값을 CA 주체 값으로 설정합니다.

예시:

CN=WoodgroveCA
다단계 인증의 보호 수준이 있는 정책 OID 규칙을 만듭니다. 인증서의 정책 OID 중 하나로 값을 설정합니다. 예제는 1.2.3.4입니다.
사용자가 MFA를 요구하도록 Microsoft Entra 조건부 액세스 정책을 만듭니다. 조건부 액세스 - MFA 필요에 설명된 단계를 완료합니다.
MyApps 포털로 이동합니다. UPN을 입력하고 다음을 선택합니다.
인증서 또는 스마트 카드 사용을 선택합니다.

전화 로그인 또는 보안 키와 같은 다른 인증 방법을 사용할 수 있게 만든 경우 사용자에게 다른 로그인 대화 상자가 표시될 수 있습니다.
클라이언트 인증서를 선택한 다음 인증서 정보를 선택합니다.

인증서가 표시되고 발급자 및 정책 OID 값을 확인할 수 있습니다.
정책 OID 값을 보려면 세부 정보를 선택합니다.
클라이언트 인증서를 선택하고 확인을 선택합니다.

인증서의 정책 OID는 구성된 값 1.2.3.4 과 일치하며 MFA를 충족합니다. 인증서의 발급자에서 구성된 값 CN=WoodgroveCA 과 일치하고 단일 단계 인증을 충족합니다.

정책 OID 규칙이 발급자 규칙보다 우선하기 때문에 인증서는 MFA를 충족합니다.

사용자에 대한 조건부 액세스 정책에는 MFA가 필요하고 인증서는 MFA를 충족하므로 사용자가 애플리케이션에 로그인할 수 있습니다.

사용자 이름 바인딩 정책 테스트

사용자 이름 바인딩 정책은 사용자 인증서의 유효성을 검사하는 데 도움이 됩니다. 사용자 이름 바인딩 정책에는 다음 세 가지 바인딩이 지원됩니다.

IssuerAndSerialNumber > certificateUserIds
IssuerAndSubject > certificateUserIds
Subject > certificateUserIds

기본적으로 Microsoft Entra ID는 인증서 userPrincipalName 의 보안 주체 이름을 사용자 개체에 매핑하여 사용자를 확인합니다. 인증 정책 관리자는 기본값을 재정의하고 앞에서 설명한 대로 사용자 지정 매핑을 만들 수 있습니다.

인증 정책 관리자는 새 바인딩을 설정해야 합니다. 준비하려면 해당 사용자 이름 바인딩에 대한 올바른 값이 사용자 개체의 특성에서 certificateUserIds 업데이트되었는지 확인해야 합니다.

클라우드 전용 사용자의 경우 Microsoft Entra 관리 센터 또는 Microsoft Graph API 를 사용하여 값을 certificateUserIds업데이트합니다.
온-프레미스 동기화된 사용자의 경우 Microsoft Entra Connect 규칙을 따르거나 값을 동기화하여 AltSecIdMicrosoft Entra Connect를 사용하여 온-프레미스의 값을 동기화합니다.

중요한

발급자, 주체 및 일련 번호 값의 형식은 인증서에서 해당 형식의 역순이어야 합니다. 발급자 또는 주체 값에 공백을 추가하지 마세요.

발급자 및 일련 번호 수동 매핑

다음 예제에서는 발급자 및 일련 번호 수동 매핑을 보여 줍니다.

추가할 발급자 값은 다음과 같습니다.

C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate

발급자 값에 대한 수동 매핑을 보여 주는 스크린샷

일련 번호에 대한 올바른 값을 가져오려면 다음 명령을 실행합니다. 에 표시된 값을 저장합니다 certificateUserIds.

명령 구문은 다음과 같습니다.

certutil –dump –v [~certificate path~] >> [~dumpFile path~]

예시:

certutil -dump -v firstusercert.cer >> firstCertDump.txt

명령에 대한 예제는 다음과 같습니다.certutil

certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer 

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

   b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48

추가할 certificateUserId일련 번호 값은 다음과 같습니다.

b24134139f069b49997212a86ba0ef48

값은 certificateUserIds 다음과 같습니다.

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48

발급자 및 주체 수동 매핑

다음 예제에서는 발급자 및 주체 수동 매핑을 보여 줍니다.

발급자 값은 다음과 같습니다.

여러 바인딩과 함께 사용할 때 발급자 값을 보여 주는 스크린샷

주체 값은 다음과 같습니다.

제목 값을 보여 주는 스크린샷.

값은 certificateUserId 다음과 같습니다.

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

제목 수동 매핑

다음 예제에서는 주체 수동 매핑을 보여 줍니다.