Microsoft Entra 인증서 기반 인증을 구성하는 방법

아티클
11/24/2024

Microsoft Entra CBA(인증서 기반 인증)를 사용하면 조직은 사용자가 앱 및 브라우저 로그인을 위해 PKI(엔터프라이즈 공개 키 인프라)에서 만든 X.509 인증서를 사용하여 인증하도록 허용하거나 요구하도록 Microsoft Entra 테넌트를 구성할 수 있습니다. 이 기능을 통해 조직은 x.509 인증서를 사용하여 피싱 방지 최신 암호 없는 인증을 채택할 수 있습니다.

로그인하는 동안 사용자에게 암호를 입력하는 대신 인증서로 인증하는 옵션도 표시됩니다. 디바이스에 일치하는 인증서가 여러 개 있는 경우 사용자는 사용할 인증서를 선택할 수 있습니다. 인증서가 사용자 계정에 대해 유효성이 검사되며 성공하는 경우 사용자가 로그인합니다.

다음 지침에 따라 Office 365 Enterprise 및 미국 정부 플랜의 테넌트용 Microsoft Entra CBA를 구성하고 사용합니다. PKI(공개 키 인프라)가 이미 구성되어 있어야 합니다.

필수 조건

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

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

Important

PKI가 안전하고 쉽게 손상되지 않는지 확인합니다. 손상된 경우 공격자는 클라이언트 인증서를 만들고 서명하고 테넌트에서 온-프레미스에서 동기화된 사용자와 클라우드 전용 사용자 모두를 손상할 수 있습니다. 그러나 강력한 키 보호 전략은 HSM 활성화 카드 또는 아티팩트의 안전한 스토리지를 위한 토큰과 같은 기타 실제 및 논리적 제어와 함께 심층 방어를 제공하여 외부 공격자 또는 내부 위협이 PKI의 무결성을 손상시키는 것을 방지할 수 있습니다. 자세한 내용은 PKI 보안을 참조하세요.

Important

알고리즘 선택, 키 길이 및 데이터 보호와 관련된 Microsoft 암호화에 대한 모범 사례를 보려면 Microsoft 권장 사항을 참조하세요. 권장 알고리즘, 키 길이 및 NIST 승인 곡선 중 하나를 사용하세요.

Important

지속적인 보안 개선의 일환으로 Azure/M365 엔드포인트는 TLS1.3에 대한 지원을 추가하고 있으며 이 프로세스는 Azure/M365 전체에서 수천 개의 서비스 엔드포인트를 처리하는 데 몇 달이 걸릴 것으로 예상됩니다. 여기에는 Microsoft Entra CBA(인증서 기반 인증) *.certauth.login.microsoftonline.com 및 *.certauth.login.microsoftonline.us에서 사용되는 Microsoft Entra 엔드포인트가 포함됩니다. TLS 1.3은 인터넷에서 가장 많이 배포된 보안 프로토콜의 최신 버전으로, 데이터를 암호화하여 두 엔드포인트 간의 보안 통신 채널을 제공합니다. TLS 1.3은 사용되지 않는 암호화 알고리즘을 제거하고 이전 버전에 비해 보안을 강화하며 가능한 많은 핸드셰이크를 암호화하는 것을 목표로 합니다. 개발자는 애플리케이션 및 서비스에서 TLS 1.3 테스트를 시작하는 것이 좋습니다.

참고 항목

PKI를 평가할 때 인증서 발급 정책 및 적용을 검토하는 것이 중요합니다. 앞서 언급한 대로 CA(인증 기관)를 Microsoft Entra 구성에 추가하면 해당 CA에서 발급한 인증서가 Microsoft Entra ID의 모든 사용자를 인증할 수 있습니다. 이런 이유로 CA가 인증서를 발급할 수 있는 방법과 시기, 재사용 가능한 식별자를 구현하는 방법을 고려하는 것이 중요합니다. 관리자가 특정 인증서만 사용자를 인증하는 데 사용할 수 있도록 해야 하는 경우 관리자는 높은 선호도 바인딩을 단독으로 사용하여 특정 인증서만 사용자를 인증할 수 있다는 높은 수준의 보증을 달성해야 합니다. 자세한 내용은 높은 선호도 바인딩을 참조하세요.

Microsoft Entra CBA 구성 및 테스트 단계

Microsoft Entra CBA를 사용하도록 설정하려면 몇 가지 구성 단계를 수행해야 합니다. 먼저 관리자는 사용자 인증서를 발급하는 신뢰할 수 있는 CA를 구성해야 합니다. 다음 다이어그램에서 볼 수 있듯이 역할 기반 액세스 제어를 사용하여 변경하는 데는 최소 권한 관리자만 필요하도록 합니다.

이러한 기능을 관리하려면 전역 관리자가 필요합니다.

선택적으로 인증서를 단일 단계 또는 다단계 인증에 매핑하도록 인증 바인딩을 구성하고 인증서 필드를 사용자 개체 특성에 매핑하도록 사용자 이름 바인딩을 구성할 수도 있습니다. 인증 정책 관리자는 사용자 관련 설정을 구성할 수 있습니다. 모든 구성이 완료되면 테넌트에서 Microsoft Entra CBA를 사용하도록 설정합니다.

Microsoft Entra 인증서 기반 인증을 사용하도록 설정하는 데 필요한 단계의 다이어그램.

1단계: PKI 기반 트러스트 저장소를 사용하여 인증 기관 구성(미리 보기)

Entra에는 새로운 PKI(공개 키 인프라) 기반 CA(인증 기관) 트러스트 저장소가 있습니다. PKI 기반 CA 트러스트 저장소는 CA를 서로 다른 각 PKI에 대한 컨테이너 개체 내에 유지합니다. 관리자는 하나의 플랫 CA 목록보다 더 쉬운 PKI를 기반으로 컨테이너에서 CA를 관리할 수 있습니다.

PKI 기반 트러스트 저장소에는 CA 수와 각 CA 파일의 크기에 대한 제한이 더 높습니다. PKI 기반 트러스트 저장소는 각 CA 개체에 대해 최대 250개의 CA 및 8KB 크기를 지원합니다. 확장 가능하고 발급자 힌트와 같은 새로운 기능을 지원하는 CA를 저장하기 위해 새 PKI 기반 트러스트 저장소를 사용하는 것이 좋습니다.

참고 항목

이전 트러스트 저장소를 사용하여 CA를 구성하는 경우 PKI 기반 트러스트 저장소를 구성하는 것이 좋습니다.

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

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

Microsoft Entra 관리 센터를 사용하여 인증 기관 구성

PKI 컨테이너 개체 만들기

PKI 컨테이너 개체를 만듭니다.
인증 정책 관리자로 Microsoft Entra 관리 센터에 로그인합니다.
보호>로 이동하여 더 많은>Security Center(또는 ID 보안 점수) >공개 키 인프라(미리 보기)를 표시합니다.
+ PKI 만들기를 클릭합니다.
표시 이름을 입력 합니다.
만들기를 클릭합니다.
열을 추가하거나 삭제하려면 열을 선택합니다.
새로 고침을 선택하여 PPI 목록을 새로 고칩니다 .

PKI 컨테이너 개체 삭제

PKI를 삭제하려면 PKI를 선택하고 삭제를 선택합니다. PKI에 CA가 있는 경우 PKI의 이름을 입력하여 PKI 내에 있는 모든 CA의 삭제를 승인하고 삭제를 선택합니다.

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

PKI 컨테이너에 CA를 업로드하려면 다음을 수행합니다.
1. + 인증 기관 추가를 클릭합니다.
2. CA 파일을 선택합니다.
3. CA가 루트 인증서이면 예를 선택하고, 그렇지 않으면 아니요를 선택합니다.
4. 인증서 해지 목록 URL의 경우 해지된 모든 인증서를 포함하는 CA 기본 CRL에 대해 HTTP 인터넷 연결 URL을 설정합니다. URL이 설정되지 않은 경우 해지된 인증서를 사용한 인증은 실패하지 않습니다.
5. 델타 인증서 해지 목록 URL의 경우 마지막 기본 CRL이 게시된 후에 해지된 모든 인증서가 포함된 CRL의 HTTP 인터넷 연결 URL을 설정합니다.
6. 발급자 힌트 플래그는 기본적으로 사용하도록 설정됩니다. CA가 발급자 힌트에 포함되지 않아야 하는 경우 발급자 힌트를 끕니다.
7. 저장을 선택합니다.
8. CA 인증서를 삭제하려면 인증서를 선택하고 삭제를 선택합니다.
9. 열을 추가하거나 삭제하려면 열을 선택합니다.
10. 새로 고침을 선택하여 CA 목록을 새로 고칩니다 .

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

PKI 컨테이너에 모든 CA를 한 번에 업로드하려면 다음을 수행합니다.
1. PKI 컨테이너 개체를 만들거나 엽니다.
2. PKI 업로드를 선택합니다.
3. .p7b 파일을 사용할 수 있는 http 인터넷 연결 URL을 입력합니다.
4. 파일의 SHA256 체크섬을 입력합니다.
5. 업로드를 선택합니다.
6. PKI 업로드는 비동기 프로세스입니다. 각 CA가 업로드되면 PKI에서 사용할 수 있습니다. PKI 업로드를 완료하는 데 최대 30분이 걸릴 수 있습니다.
7. 새로 고침을 선택하여 CA를 새로 고칩니다 .
PKI .p7b 파일의 SHA256 체크섬을 생성하려면 다음 명령을 실행합니다.
```
Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256
```

PKI 편집

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

CA 편집

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

PKI 복원

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

CA 복원

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

CA에서 isIssuerHintEnabled 특성 이해

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

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

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

동일한 루트 인증서의 여러 중간 CA가 최종 사용자 인증서를 발급하는 경우 기본적으로 모든 인증서가 인증서 선택기에서 표시됩니다. 그러나 isIssuerHintEnabled를 특정 CA에 true 대해 설정하는 경우 인증서 선택기에서 적절한 사용자 인증서만 표시됩니다. isIssuerHintEnabled를 사용하도록 설정하려면 CA를 편집하고 값을 업데이트합니다true.

Microsoft Graph API를 사용하여 인증 기관 구성

Microsoft Graph API를 사용하여 CA를 구성할 수 있습니다. 다음 예제에서는 Microsoft Graph를 사용하여 PKI 또는 CA에 대해 CRUD(만들기, 읽기, 업데이트 또는 삭제) 작업을 실행하는 방법을 보여 줍니다.

PKI 컨테이너 개체 만들기

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/microsoftgraph/installation)을 사용할 수 있습니다.

관리자 권한으로 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에 대한 모든 CRUD 작업은 Microsoft Entra 감사 로그에 로그인됩니다.

감사 로그 다이어그램

FAQ

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

답변: PKI 파일이 유효하고 문제 없이 액세스할 수 있는지 확인합니다. PKI 파일의 최대 크기는

질문: PKI 업로드에 대한 SLA(서비스 수준 계약)는 무엇인가요?

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

질문: PKI 파일에 대한 SHA256 체크섬을 생성하려면 어떻게 해야 할까요?

답변: PKI.p7b 파일의 SHA256 체크섬을 생성하려면 다음 명령을 실행합니다.

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

2단계: 테넌트에서 CBA 사용

Important

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

Microsoft Entra 관리 센터에서 CBA를 사용하도록 설정하려면 다음 단계를 완료합니다.

최소한 인증 정책 관리자로 Microsoft Entra 관리 센터에 로그인합니다.
그룹>모든 그룹으로 이동하여 새 그룹을> 선택하고 CBA 사용자에 대한 그룹을 만듭니다.
보호>인증 방법>인증서 기반 인증으로 이동합니다.
사용 및 대상 아래에서 사용을 선택합니다.
그룹 추가를 선택하여 만든 그룹과 같은 특정 그룹을 선택합니다. 모든 사용자 대신 특정 그룹을 사용합니다.

테넌트에서 인증서 기반 인증을 사용하도록 설정하면 테넌트 내의 모든 사용자에게 인증서로 로그인하는 옵션이 표시됩니다. CBA를 사용하도록 설정된 사용자만 X.509 인증서를 사용하여 인증할 수 있습니다.

참고 항목

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

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

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

인증 정책 관리자는 기본값을 단일 요소에서 다중 요소로 변경하고 사용자 지정 정책 규칙을 구성할 수 있습니다. 인증 바인딩 규칙은 발급자, OID(정책 개체 ID) 또는 발급자 및 정책 OID와 같은 인증서 특성을 값에 매핑하고 해당 규칙에 대한 기본 보호 수준을 선택합니다. 여러 규칙을 만들 수 있습니다.

Microsoft Entra 관리 센터에서 테넌트 기본 설정을 수정하려면 다음 단계를 완료합니다.

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

참고 항목

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

인증 바인딩 규칙은 인증서 특성(발급자 또는 정책 OID)을 값에 매핑하고 해당 규칙에 대한 기본 보호 수준을 선택합니다. 여러 규칙을 만듭니다.

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

인증서 발급자별로 규칙을 만들려면 인증서 발급자를 선택합니다.
1. 목록 상자에서 인증서 발급자 식별자를 선택합니다.
2. 다단계 인증, 낮음 선호도 바인딩을 선택한 다음 추가를 클릭합니다. 메시지가 표시되면 동의함을 클릭하여 규칙 추가를 완료합니다.
정책 OID별로 규칙을 만들려면 정책 OID를 선택합니다.
1. 정책 OID 값을 입력합니다.
2. 다단계 인증, 낮음 선호도 바인딩을 선택한 다음 추가를 클릭합니다. 메시지가 표시되면 동의함을 클릭하여 규칙 추가를 완료합니다.
발급자 및 정책 OID에서 규칙을 만들려면 다음을 수행합니다.
1. 인증서 발급자와 정책 OID를 선택합니다.
2. 발급자를 선택하고 정책 OID를 입력합니다.
3. 인증 강도의 경우 단일 요소 인증 또는 다단계 인증을 선택합니다.
4. 선호도 바인딩의 경우 낮음을 선택합니다.
5. 추가를 선택합니다.
6. 정책 OID가 3.4.5.6이고 CN=CBATestRootProd에서 발급한 인증서로 인증합니다. 인증은 다단계 클레임을 통과하고 가져와야 합니다.

Important

Microsoft Entra 테넌트 인증 정책 관리자가 발급자와 정책 OID를 모두 사용하여 CBA 인증 정책 규칙을 구성하는 알려진 문제가 있습니다. 이 문제는 다음을 비롯한 일부 디바이스 등록 시나리오에 영향을 줍니다.

비즈니스용 Windows Hello 등록
FIDO2 보안 키 등록
Windows 암호 없는 휴대폰 로그인

Workplace Join, Microsoft Entra ID 및 하이브리드 Microsoft Entra 디바이스 조인 시나리오를 사용한 디바이스 등록은 영향을 받지 않습니다. 발급자 또는 정책 OID를 사용하는 CBA 인증 정책 규칙은 영향을 받지 않습니다. 완화하려면 관리자는 다음을 수행해야 합니다.

발급자 및 정책 OID 옵션을 모두 사용하는 인증서 기반 인증 정책 규칙을 편집합니다. 발급자 또는 정책 OID 요구 사항을 제거하고 저장합니다. -또는-
발급자와 정책 OID를 모두 사용하는 인증 정책 규칙을 제거합니다. 발급자 또는 정책 OID만 사용하는 규칙을 만듭니다.

이 문제를 해결하기 위해 노력하고 있습니다.

발급자 및 일렬 번호에서 규칙을 만들려면 다음을 수행합니다.

인증 바인딩 정책을 추가합니다. 정책에서는 policyOID 1.2.3.4.6을 사용하여 CN=CBATestRootProd에서 발급한 모든 인증서에 높은 선호도 바인딩만 필요합니다. 발급자 및 일련 번호가 사용됩니다.
인증서 필드를 선택합니다. 이 예제에서는 발급자 및 일련 번호를 선택하겠습니다.
지원되는 유일한 사용자 특성은 CertificateUserIds입니다. 추가를 선택합니다.
저장을 선택합니다.

로그인 로그에는 로그인에 사용된 바인딩과 인증서의 세부 정보가 표시됩니다.
사용자 지정 규칙을 저장하려면 확인을 선택합니다.

Important

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

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

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

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

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

Important

사용자 이름 바인딩 정책이 사용자 개체의 CertificateUserIds, onPremisesUserPrincipalName 및 userPrincipalName 특성과 같은 동기화된 특성을 사용하는 경우 Active Directory에서 관리자 권한이 있는 계정(예: 사용자 개체에 대한 위임된 권한 또는 Microsoft Entra Connect 서버에 대한 관리 권한이 있는 계정)은 Microsoft Entra ID의 이러한 특성에 영향을 미치는 변경을 수행할 수 있습니다.

사용자 특성 중 하나로 바인딩할 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 필요의 단계에 따라 사용자에게 다단계 인증을 요구하도록 조건부 액세스 정책을 만듭니다.
MyApps 포털로 이동합니다. UPN을 입력하고 다음을 선택합니다.
인증서로 로그인을 선택합니다.

휴대폰 로그인 또는 보안 키와 같은 다른 인증 방법을 사용하도록 설정한 경우 사용자에게 다른 로그인 화면이 표시될 수 있습니다.
클라이언트 인증서를 선택하고 인증서 정보를 선택합니다.
인증서가 표시되고 발급자 및 정책 OID 값을 확인할 수 있습니다.
정책 OID 값을 보려면 세부 정보를 선택합니다.
클라이언트 인증서를 선택하고 확인을 선택합니다.
인증서의 정책 OID는 구성된 값인 1.2.3.4와 일치하며 다단계 인증을 충족합니다. 마찬가지로 인증서의 발급자는 CN=WoodgroveCA의 구성된 값과 일치하며 단일 단계 인증을 충족합니다.
정책 OID 규칙이 발급자 규칙보다 우선하므로 인증서는 다단계 인증을 충족합니다.
사용자에 대한 조건부 액세스 정책이 MFA를 요구하고 인증서가 다단계를 충족하므로 사용자가 애플리케이션에 로그인됩니다.

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

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

IssuerAndSerialNumber>CertificateUserIds
IssuerAndSubject>CertificateUserIds
Subject>CertificateUserIds

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

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

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

Important

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

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

다음은 발급자 및 일련 번호 수동 매핑의 예입니다. 추가할 발급자 값은 다음과 같습니다.

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에 추가할 SerialNumber 값은 다음과 같습니다.

b24134139f069b49997212a86ba0ef48

CertificateUserId:

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

제목 수동 매핑

다음은 제목 수동 매핑의 예입니다. 제목 값은 다음과 같습니다.

다른 주체 값의 스크린샷.

CertificateUserId:

X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

선호도 바인딩 테스트

최소한 인증 정책 관리자로 Microsoft Entra 관리 센터에 로그인합니다.
보호>인증 방법>정책으로 이동합니다.
관리에서 인증 방법>인증서 기반 인증을 선택합니다.
구성을 선택합니다.
테넌트 수준에서 필수 선호도 바인딩을 설정합니다.

Important

테넌트 전체 선호도 설정에 주의하세요. 테넌트에 대한 필수 선호도 바인딩을 변경하고 사용자 개체에 적절한 값이 없는 경우 전체 테넌트에서 잠글 수 있습니다. 마찬가지로 모든 사용자에게 적용되고 높은 선호도 바인딩이 필요한 사용자 지정 규칙을 만들면 테넌트 사용자가 잠글 수 있습니다.
테스트하려면 필요한 선호도 바인딩을 낮음으로 선택합니다.
SKI와 같은 높은 선호도 바인딩을 추가합니다. 사용자 이름 바인딩 아래 규칙 추가를 선택합니다.
SKI를 선택하고 추가를 선택합니다.

완료되면 규칙은 다음 스크린샷과 같습니다.
사용자 인증서에서 SKI의 올바른 값을 갖도록 모든 사용자 개체 CertificateUserIds 특성을 업데이트합니다. 자세한 내용은 CertificateUserIDs에 대해 지원되는 패턴을 참조하세요.
인증 바인딩에 대한 사용자 지정 규칙을 만듭니다.
추가를 선택합니다.

완료되면 규칙은 다음 스크린샷과 같습니다.
정책 OID 9.8.7.5를 사용하여 인증서에서 올바른 SKI 값으로 사용자 CertificateUserIds를 업데이트합니다.
정책 OID 9.8.7.5가 있는 인증서로 테스트하고 사용자는 SKI 바인딩으로 인증되어야 하며 인증서로만 MFA를 받아야 합니다.

Microsoft Graph API를 사용하여 CBA 사용

CBA를 사용하도록 설정하고 Graph API를 사용하여 사용자 이름 바인딩을 구성하려면 다음 단계를 완료합니다.

Microsoft Graph 탐색기로 이동합니다.
Graph Explorer에 로그인을 선택하고 테넌트에 로그인합니다.
단계에 따라 Policy.ReadWrite.AuthenticationMethod 위임된 권한에 동의합니다.

모든 인증 방법 가져오기:

GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy

x509 Certificate 인증 방법에 대한 구성을 가져옵니다.

GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate

기본적으로 x509 Certificate 인증 방법은 사용하지 않도록 설정되어 있습니다. 사용자가 인증서로 로그인할 수 있도록 하려면 인증 방법을 사용하도록 설정하고 업데이트 작업을 통해 인증 및 사용자 이름 바인딩 정책을 구성해야 합니다. 정책을 업데이트하려면 PATCH 요청을 실행합니다.

요청 본문.:

PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
Content-Type: application/json

{
    "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
    "id": "X509Certificate",
    "state": "enabled",
    "certificateUserBindings": [
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "onPremisesUserPrincipalName",
            "priority": 1
        },
        {
            "x509CertificateField": "RFC822Name",
            "userProperty": "userPrincipalName",
            "priority": 2
        }, 
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "certificateUserIds",
            "priority": 3
        }
    ],
    "authenticationModeConfiguration": {
        "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
        "rules": [
            {
                "x509CertificateRuleType": "issuerSubject",
                "identifier": "CN=WoodgroveCA ",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            },
            {
                "x509CertificateRuleType": "policyOID",
                "identifier": "1.2.3.4",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            }
        ]
    },
    "includeTargets": [
        {
            "targetType": "group",
            "id": "all_users",
            "isRegistrationRequired": false
        }
    ]
}

204 No content 응답 코드를 가져옵니다. GET 요청을 다시 실행하여 정책이 올바르게 업데이트되었는지 확인합니다.
정책을 충족하는 인증서로 로그인하여 구성을 테스트합니다.

Microsoft PowerShell을 사용하여 CBA 사용

PowerShell을 엽니다.

Microsoft Graph에 연결:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

CBA 사용자에 대한 그룹을 정의하기 위한 변수를 만듭니다.
```
$group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
```

요청 본문을 정의합니다.

$body = @{
"@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
"id" = "X509Certificate"
"state" = "enabled"
"certificateUserBindings" = @(
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "SubjectKeyIdentifier"
        "userProperty" = "certificateUserIds"
        "priority" = 1
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "PrincipalName"
        "userProperty" = "UserPrincipalName"
        "priority" = 2
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "RFC822Name"
        "userProperty" = "userPrincipalName"
        "priority" = 3
    }
)
"authenticationModeConfiguration" = @{
    "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration"
    "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor"
    "rules" = @(
        @{
            "@odata.type" = "#microsoft.graph.x509CertificateRule"
            "x509CertificateRuleType" = "policyOID"
            "identifier" = "1.3.6.1.4.1.311.21.1"
            "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor"
        }
    )
}
"includeTargets" = @(
    @{
        "targetType" = "group"
        "id" = $group.Id
        "isRegistrationRequired" = $false
    }
) } | ConvertTo-Json -Depth 5

PATCH 요청을 실행합니다.

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"

다음을 통해 공유

Microsoft Entra 인증서 기반 인증을 구성하는 방법

필수 조건

Microsoft Entra CBA 구성 및 테스트 단계

1단계: PKI 기반 트러스트 저장소를 사용하여 인증 기관 구성(미리 보기)

Microsoft Entra 관리 센터를 사용하여 인증 기관 구성

PKI 컨테이너 개체 만들기

PKI 컨테이너 개체 삭제

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

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

PKI 편집

CA 편집

PKI 복원

CA 복원

CA에서 isIssuerHintEnabled 특성 이해

Microsoft Graph API를 사용하여 인증 기관 구성

PKI 컨테이너 개체 만들기

모든 PKI 개체 가져오기

PKI ID로 PKI 개체 가져오기

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

PKI의 모든 CA 가져오기

CA ID로 PKI 내에서 특정 CA 가져오기

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

감사 로그

FAQ

2단계: 테넌트에서 CBA 사용

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

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

5단계: 구성 테스트

인증서 테스트

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

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

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

문제 및 제목 수동 매핑

제목 수동 매핑

선호도 바인딩 테스트

Microsoft Graph API를 사용하여 CBA 사용

요청 본문.:

Microsoft PowerShell을 사용하여 CBA 사용

다음 단계

피드백

추가 리소스