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

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에서 수천 개의 서비스 엔드포인트를 처리하는 데 몇 달이 걸릴 것으로 예상됩니다. 여기에는 CBA(Microsoft Entra Certificate Based Authentication) *.certauth.login.microsoftonline.com 및 *.certauth.login.mcirosoftonline.us 사용하는 Entra ID 엔드포인트가 포함됩니다. 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를 구성해야 합니다. 다음 다이어그램에서 볼 수 있듯이 역할 기반 액세스 제어를 사용하여 변경하는 데는 최소 권한 관리자만 필요하도록 합니다. 전역 관리자 역할만 CA를 구성할 수 있습니다.

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

Diagram of the steps required to enable Microsoft Entra certificate-based authentication.

1단계: 인증 기관 구성

Microsoft Entra 관리 센터 또는 PowerShell을 사용하여 CA를 구성할 수 있습니다.

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

인증서 기반 인증을 사용하도록 설정하고 Microsoft Entra 관리 센터에서 사용자 바인딩을 구성하려면 다음 단계를 완료합니다.

  1. 전역 관리자Microsoft Entra 관리 센터에 로그인합니다.

  2. 보호>자세히 보기>보안 센터 (또는 신원 보안 점수) >인증 기관으로 이동하세요.

  3. CA를 업로드하려면 업로드를 선택합니다.

    1. CA 파일을 선택합니다.

    2. CA가 루트 인증서이면 를 선택하고, 그렇지 않으면 아니요를 선택합니다.

    3. 인증서 해지 목록 URL의 경우 해지된 모든 인증서를 포함하는 CA 기본 CRL에 대해 HTTP 인터넷 연결 URL을 설정합니다. URL이 설정되지 않으면 해지된 인증서를 사용한 인증이 실패하지 않습니다.

    4. 델타 인증서 해지 목록 URL의 경우 마지막 기본 CRL이 게시된 후에 해지된 모든 인증서가 포함된 CRL의 HTTP 인터넷 연결 URL을 설정합니다.

    5. 추가를 선택합니다.

      Screenshot of how to upload certification authority file.

  4. CA 인증서를 삭제하려면 인증서를 선택하고 삭제를 선택합니다.

  5. 열을 추가하거나 삭제하려면 을 선택합니다.

참고 항목

기존 CA가 만료되면 새 CA 업로드가 실패합니다. 전역 관리자는 만료된 CA를 삭제하고 새 CA를 업로드하려고 다시 시도해야 합니다.

PowerShell을 사용하여 CA(인증 기관) 구성

신뢰할 수 있는 CA에 대해 하나의 CDP(CRL Distribution Point)만 지원됩니다. CDP는 HTTP URL만 가능합니다. OCSP(Online Certificate Status Protocol) 또는 LDAP(Lightweight Directory Access Protocol) URL은 지원되지 않습니다.

Microsoft Entra ID에서 인증 기관을 구성하려면 각 인증 기관에 대해 다음을 업로드합니다.

  • 인증서의 공개 부분( .cer 형식)
  • CRL(인증서 해지 목록)이 있는 인터넷 연결 URL

인증 기관에 대한 스키마는 다음과 같습니다.

    class TrustedCAsForPasswordlessAuth
    {
       CertificateAuthorityInformation[] certificateAuthorities;
    }

    class CertificateAuthorityInformation

    {
        CertAuthorityType authorityType;
        X509Certificate trustedCertificate;
        string crlDistributionPoint;
        string deltaCrlDistributionPoint;
        string trustedIssuer;
        string trustedIssuerSKI;
    }

    enum CertAuthorityType
    {
        RootAuthority = 0,
        IntermediateAuthority = 1
    }

구성에는 Microsoft Graph PowerShell을 사용할 수 있습니다.

  1. 관리자 권한으로 Windows PowerShell을 시작합니다.

  2. Microsoft Graph PowerShell 설치:

        Install-Module Microsoft.Graph
    

첫 번째 구성 단계로 테넌트와 연결을 설정해야 합니다. 테넌트에 대한 연결이 있으면 디렉터리에 정의된 신뢰할 수 있는 인증 기관을 검토, 추가, 삭제 및 수정할 수 있습니다.

연결

테넌트와 연결을 설정하려면 Connect-MgGraph를 사용합니다.

    Connect-MgGraph

장치

디렉터리에 정의된 신뢰할 수 있는 인증 기관을 검색하려면 Get-MgOrganizationCertificateBasedAuthConfiguration을 사용합니다.

    Get-MgOrganizationCertificateBasedAuthConfiguration

추가

참고 항목

기존 CA가 만료되면 새 CA 업로드가 실패합니다. 테넌트 관리자는 만료된 CA를 삭제한 다음, 새 CA를 업로드해야 합니다.

위의 단계에 따라 Microsoft Entra 관리 센터에서 CA를 추가합니다.

AuthorityType

  • 루트 인증 기관을 나타내려면 0 사용
  • 중간 또는 발급 인증 기관을 나타내려면 1 사용

crlDistributionPoint

CRL을 다운로드하고 CA 인증서와 CRL 정보를 비교하여 이전 PowerShell 예제의 crlDistributionPoint 값이 추가하려는 CA에 대해 유효한지 유효성을 검사할 수 있습니다.

다음 표와 그래픽은 CA 인증서의 정보를 다운로드한 CRL의 특성에 매핑하는 방법을 보여 줍니다.

CA 인증서 정보 = 다운로드한 CRL 정보
Subject = Issuer
주체 키 식별자 = 권한 키 식별자(KeyID)

Compare CA Certificate with CRL Information.

이전 예제의 crlDistributionPoint 값은 CA의 CRL(인증서 해지 목록)에 대한 HTTP 위치입니다. 이 값은 다음과 같은 몇 가지 위치에서 찾을 수 있습니다.

  • CA에서 발급한 인증서의 CDP(CRL 배포 지점) 특성에서.

발급 CA에서 Windows Server를 실행하는 경우:

  • 인증 기관 MMC(Microsoft Management Console)에 있는 CA의 속성에서.
  • certutil -cainfo cdp를 실행하여 CA에서. 자세한 내용은 certutil을 참조하세요.

자세한 내용은 인증서 해지 프로세스 이해를 참조하세요.

인증 기관 구성 유효성 검사

위의 구성 단계 결과가 인증 기관 신뢰 체인의 유효성을 검사하고 구성된 인증 기관 CRL 배포 지점(CDP)에서 CRL(인증서 해지 목록)을 확인하는 Entra ID 기능인지 확인하는 것이 중요합니다. 이 작업을 지원하려면 MSIdentity Tools PowerShell 모듈을 설치하고 Test-MsIdCBATrustStoreConfiguration을 실행하는 것이 좋습니다. 이 PowerShell cmdlet은 엔트라 테넌트 인증 기관 구성을 검토하고 일반적인 잘못된 구성 문제에 대한 오류/경고를 표시합니다.

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

Important

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

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

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

  2. 보호>인증 방법>인증서 기반 인증으로 이동합니다.

  3. 사용 및 대상 아래에서 사용을 선택합니다.

  4. 모든 사용자를 선택하거나 그룹 추가를 선택하여 특정 그룹을 선택합니다.

    Screenshot of how to enable CBA.

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

참고 항목

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

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

인증 바인딩 정책은 단일 요소 또는 다중 요소에 대한 인증 강도를 결정하는 데 도움이 됩니다. 인증 정책 관리자는 기본값을 단일 요소에서 다중 요소로 변경하고 인증서의 발급자 제목 또는 정책 OID 필드에 매핑하여 사용자 지정 정책 규칙을 구성할 수 있습니다.

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

Microsoft Entra 관리 센터에서 CBA를 사용하도록 설정하고 사용자 바인딩을 구성하려면 다음 단계를 완료합니다.

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

  2. 보호>인증 방법>정책으로 이동합니다.

  3. 관리에서 인증 방법>인증서 기반 인증을 선택합니다.

    Screenshot of Authentication policy.

  4. 구성을 선택하여 인증 바인딩 및 사용자 이름 바인딩을 설정합니다.

  5. 보호 수준 특성의 기본값은 단일 요소 인증입니다. 기본값을 MFA로 변경하려면 다단계 인증을 선택합니다.

    참고 항목

    사용자 지정 규칙이 추가되지 않은 경우 기본 보호 수준 값이 적용됩니다. 사용자 지정 규칙이 추가되면 규칙 수준에서 정의된 보호 수준이 대신 적용됩니다.

    Screenshot of how to change the default policy to MFA.

  6. 클라이언트 인증서의 보호 수준을 결정하는 데 도움이 되도록 사용자 지정 인증 바인딩 규칙을 설정할 수도 있습니다. 인증서의 발급자 제목 또는 정책 OID 필드를 사용하여 구성할 수 있습니다.

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

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

    Screenshot of how to add a rule.

    인증서 발급자별로 규칙을 만들려면 인증서 발급자를 선택합니다.

    1. 목록 상자에서 인증서 발급자 식별자를 선택합니다.

    2. 다단계 인증, 낮은 선호도 바인딩을 선택한 다음 추가를 클릭합니다. 메시지가 표시되면 확인을 클릭하여 규칙 추가를 완료합니다.

      Screenshot of multifactor authentication policy.

    정책 OID별로 규칙을 만들려면 정책 OID를 선택합니다.

    1. 정책 OID 값을 입력합니다.

    2. 다단계 인증, 낮은 선호도 바인딩을 선택한 다음 추가를 클릭합니다. 메시지가 표시되면 확인을 클릭하여 규칙 추가를 완료합니다. .

      Screenshot of mapping to Policy OID.

    발급자 및 정책 OID에서 규칙을 만들려면 다음을 수행합니다.

    1. 인증서 발급자정책 OID를 선택합니다.

    2. 발급자를 선택하고 정책 OID를 입력합니다.

    3. 인증 강도의 경우 단일 단계 인증 또는 다단계 인증을 선택합니다.

    4. 선호도 바인딩의 경우 낮음을 선택합니다.

      Screenshot of how to select a low affinity binding.

    5. 추가를 선택합니다.

      Screenshot of how to add a low affinity binding.

    6. 정책 OID가 3.4.5.6이고 CN=CBATestRootProd에서 발급한 인증서로 인증합니다. 인증은 다단계 클레임을 통과하고 가져와야 합니다.

Important

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

  • 비즈니스용 Windows Hello 등록
  • Fido2 보안 키 등록
  • Windows 암호 없는 전화 로그인

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

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

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

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

  1. policyOID 1.2.3.4.6을 사용하여 CN=CBATestRootProd에서 발급한 인증서를 요구하는 인증 바인딩 정책을 추가하려면 높은 선호도 바인딩만 필요합니다(즉, 발급자 및 일련 번호가 사용됨).

    Screenshot of Issuer and Serial Number added the Microsoft Entra admin center.

  2. 인증서 필드를 선택합니다. 이 예제에서는 발급자 및 일련 번호를 선택합니다.

    Screenshot of how to select Issuer and Serial Number.

  3. 지원되는 유일한 사용자 특성은 CertificateUserIds입니다. 추가를 선택합니다.

    Screenshot of how to add Issuer and Serial Number.

  4. 저장을 선택합니다.

로그인 로그에는 사용된 바인딩과 인증서의 세부 정보가 표시됩니다.

Screenshot of Sign-ins log.

  1. 사용자 지정 규칙을 저장하려면 확인을 선택합니다.

Important

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

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

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

사용자 이름 바인딩을 구성하는 방법을 확인하려면 사용자 이름 바인딩 작동 방식을 참조하세요.

certificateUserIds 특성을 사용하는 시나리오에 대한 자세한 내용은 인증서 사용자 ID를 참조 하세요.

Important

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

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

    Screenshot of a username binding policy.

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

  2. 저장을 선택하여 변경 내용을 저장합니다.

최종 구성은 다음 이미지와 같습니다.

Screenshot of the final configuration.

5단계: 구성 테스트

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

인증서 테스트

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

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

    Screenshot of the User Principal Name.

  2. 다음을 선택합니다.

    Screenshot of sign-in with certificate.

    휴대폰 로그인 또는 FIDO2와 같은 다른 인증 방법을 사용하도록 설정한 경우 사용자에게 다른 로그인 화면이 표시될 수 있습니다.

    Screenshot of the alternative sign-in.

  3. 인증서로 로그인을 선택합니다.

  4. 클라이언트 인증서 선택기 UI에서 올바른 사용자 인증서를 선택하고 확인을 선택합니다.

    Screenshot of the certificate picker UI.

  5. 사용자는 MyApps 포털에 로그인해야 합니다.

로그인에 성공했으면 다음을 의미합니다.

  • 사용자 인증서가 테스트 디바이스에 프로비저닝되었습니다.
  • Microsoft Entra ID는 신뢰할 수 있는 CA로 올바르게 구성되었습니다.
  • 사용자 이름 바인딩이 올바르게 구성되었으며 사용자가 검색되고 인증되었습니다.

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

강력한 인증의 유효성을 검사하는 시나리오를 살펴보겠습니다. 단일 단계 인증을 충족하는 발급자를 사용하는 규칙과 다단계 인증을 충족하는 정책 OID를 사용하는 또 다른 규칙의 두 가지 인증 정책 규칙을 만듭니다.

  1. 보호 수준을 단일 단계 인증으로 사용하고 값이 CA 주체 값으로 설정된 발급자 주체 규칙을 만듭니다. 예시:

    CN = WoodgroveCA

  2. 보호 수준을 다단계 인증으로 사용하고 값이 인증서의 정책 OID 중 하나로 설정된 정책 OID 규칙을 만듭니다. 예를 들어 1.2.3.4입니다.

    Screenshot of the Policy OID rule.

  3. 조건부 액세스 - MFA 필요의 단계에 따라 사용자에게 다단계 인증을 요구하도록 조건부 액세스 정책을 만듭니다.

  4. MyApps 포털로 이동합니다. UPN을 입력하고 다음을 선택합니다.

    Screenshot of the User Principal Name.

  5. 인증서로 로그인을 선택합니다.

    Screenshot of sign-in with certificate.

    휴대폰 로그인 또는 보안 키와 같은 다른 인증 방법을 사용하도록 설정한 경우 사용자에게 다른 로그인 화면이 표시될 수 있습니다.

    Screenshot of the alternative sign-in.

  6. 클라이언트 인증서를 선택하고 인증서 정보를 선택합니다.

    Screenshot of the client picker.

  7. 인증서가 표시되고 발급자 및 정책 OID 값을 확인할 수 있습니다. Screenshot of the issuer.

  8. 정책 OID 값을 보려면 세부 정보를 선택합니다.

    Screenshot of the authentication details.

  9. 클라이언트 인증서를 선택하고 확인을 선택합니다.

  10. 인증서의 정책 OID는 구성된 값인 1.2.3.4와 일치하며 다단계 인증을 충족합니다. 마찬가지로 인증서의 발급자는 CN=WoodgroveCA의 구성된 값과 일치하며 단일 단계 인증을 충족합니다.

  11. 정책 OID 규칙이 발급자 규칙보다 우선하므로 인증서는 다단계 인증을 충족합니다.

  12. 사용자에 대한 조건부 액세스 정책이 MFA를 요구하고 인증서가 다단계를 충족하므로 사용자가 애플리케이션에 로그인됩니다.

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

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

  • IssuerAndSerialNumber > CertificateUserIds
  • IssuerAndSubject > CertificateUserIds
  • Subject > CertificateUserIds

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

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

Important

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

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

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

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

Screenshot of the Issuer value.

일련 번호의 올바른 값을 가져오려면 다음 명령을 실행하고 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 

문제 및 제목 수동 매핑

다음은 문제 및 제목 수동 매핑의 예입니다. 발급자 값은 다음과 같습니다.

Screenshot of the Issuer value when used with multiple bindings.

제목 값은 다음과 같습니다.

Screenshot of the Subject value.

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

제목 수동 매핑

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

Screenshot of another Subject value.

CertificateUserId:

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

선호도 바인딩 테스트

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

  2. 보호>인증 방법>정책으로 이동합니다.

  3. 관리에서 인증 방법>인증서 기반 인증을 선택합니다.

  4. 구성을 선택합니다.

  5. 테넌트 수준에서 필수 선호도 바인딩을 설정합니다.

    Important

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

    Screenshot of how to set required affinity binding.

  6. 테스트하려면 필요한 선호도 바인딩낮음으로 선택합니다.

  7. SKI와 같은 높은 선호도 바인딩을 추가합니다. 사용자 이름 바인딩 아래 규칙 추가를 선택합니다.

  8. SKI를 선택하고 추가를 선택합니다.

    Screenshot of how to add an affinity binding.

    완료되면 규칙은 다음 스크린샷과 같습니다.

    Screenshot of a completed affinity binding.

  9. 사용자 인증서에서 SKI의 올바른 값을 갖도록 모든 사용자 개체 CertificateUserIds 특성을 업데이트합니다. 자세한 내용은 CertificateUserIDs에 대해 지원되는 패턴을 참조하세요.

  10. 인증 바인딩에 대한 사용자 지정 규칙을 만듭니다.

  11. 추가를 선택합니다.

    Screenshot of a custom authentication binding.

    완료되면 규칙은 다음 스크린샷과 같습니다.

    Screenshot of a custom rule.

  12. 정책 OID 9.8.7.5를 사용하여 인증서에서 올바른 SKI 값으로 사용자 CertificateUserIds를 업데이트합니다.

  13. 정책 OID 9.8.7.5가 있는 인증서로 테스트하고 사용자는 SKI 바인딩으로 인증되어야 하며 인증서로만 MFA를 받아야 합니다.

Microsoft Graph API를 사용하여 CBA 사용

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

참고 항목

다음 단계에서는 미국 정부 클라우드에서 사용할 수 없는 Graph Explorer를 사용합니다. 미국 정부 클라우드 테넌트는 Postman을 사용하여 Microsoft Graph 쿼리를 테스트할 수 있습니다.

  1. Microsoft Graph 탐색기로 이동합니다.

  2. Graph Explorer에 로그인을 선택하고 테넌트에 로그인합니다.

  3. 단계에 따라 Policy.ReadWrite.AuthenticationMethod 위임된 권한에 동의합니다.

  4. 모든 인증 방법 가져오기:

    GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
    
  5. x509 Certificate 인증 방법에 대한 구성을 가져옵니다.

    GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
    
  6. 기본적으로 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
            }
        ]
    }
    
  7. 204 No content 응답 코드를 가져옵니다. GET 요청을 다시 실행하여 정책이 올바르게 업데이트되었는지 확인합니다.

  8. 정책을 충족하는 인증서로 로그인하여 구성을 테스트합니다.

다음 단계