Microsoft Entra 인증서 기반 인증 기술 심층 분석

  • 아티클

이 문서에서는 Microsoft Entra CBA(인증서 기반 인증)의 작동 방식을 설명하고 Microsoft Entra CBA 구성에 대한 기술 세부 정보를 자세히 설명합니다.

Microsoft Entra 인증서 기반 인증은 어떻게 작동하나요?

다음 이미지는 Microsoft Entra CBA가 사용하도록 설정된 테넌트에서 사용자가 애플리케이션에 로그인하려고 할 때 발생하는 상황에 대해 설명합니다.

Microsoft Entra 인증서 기반 인증의 작동 방식에 대한 단계가 포함된 그림

이제 각 단계를 살펴보겠습니다.

  1. 사용자가 MyApps 포털과 같은 애플리케이션에 액세스하려고 합니다.

  2. 사용자가 아직 로그인하지 않은 경우 사용자는 https://login.microsoftonline.com/의 Microsoft Entra ID 사용자 로그인 페이지로 리디렉션됩니다.

  3. 사용자는 Microsoft Entra 로그인 페이지에 사용자 이름을 입력하고 다음을 선택합니다. Microsoft Entra ID는 테넌트 이름을 사용하여 홈 영역 검색을 수행하고 사용자 이름은 테넌트에서 사용자를 조회하는 데 사용됩니다.

    MyApps용 로그인 포털의 스크린샷

  4. Microsoft Entra ID는 테넌트에 대해 CBA가 사용하도록 설정되어 있는지 확인합니다. CBA가 사용하도록 설정된 경우 암호 페이지에 인증서 또는 스마트 카드 사용 링크가 표시됩니다. 로그인 링크가 표시되지 않으면 테넌트에서 CBA가 사용하도록 설정되어 있는지 확인합니다. 자세한 내용은 Microsoft Entra CBA를 사용하도록 설정하려면 어떻게 해야 하나요?를 참조하세요.

    참고 항목

    테넌트에서 CBA가 사용하도록 설정된 경우 모든 사용자는 암호 페이지에서 인증서 또는 스마트 카드 사용 링크를 볼 수 있습니다. 그러나 CBA 범위에 있는 사용자만 Microsoft Entra ID를 IdP(ID 공급자)로 사용하는 애플리케이션에 대해 성공적으로 인증할 수 있습니다.

    인증서 또는 스마트 카드 사용 스크린샷

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

    FIDO2도 사용하도록 설정된 경우 로그인의 스크린샷

  5. 사용자가 인증서 기반 인증을 선택하면 클라이언트는 공용 Entra ID의 경우 https://certauth.login.microsoftonline.com인 certauth 엔드포인트로 리디렉션됩니다. Azure Government의 경우 certauth 엔드포인트는 https://certauth.login.microsoftonline.us입니다.

    엔드포인트는 TLS 상호 인증을 수행하고 TLS 핸드셰이크의 일부로 클라이언트 인증서를 요청합니다. 이 요청에 대한 항목이 로그인 로그에 나타납니다.

    참고 항목

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

    발급자 힌트가 있는 새 URL에 대해서도TLS 검사 사용 안 함이 이 작동하는지 확인합니다. B2B 사용자에 대해 변경될 수 있으므로 테넌트 ID로 URL을 하드코딩하지 마세요. 정규식을 사용하여 이전 URL과 새 URL이 모두 TLS 검사 비활성화에 작동할 수 있도록 합니다. 예를 들어, 프록시에 따라 *.certauth.login.microsoftonline.com 또는 *certauth.login.microsoftonline.com을 사용합니다. Azure Government에서는 *.certauth.login.microsoftonline.us 또는 *certauth.login.microsoftonline.us를 사용합니다.

    액세스가 허용되지 않는 한 예정된 신뢰할 수 있는 CA 힌트 기능을 사용하도록 설정하면 인증서 기반 인증이 실패합니다.

  6. Microsoft Entra ID는 클라이언트 인증서를 요청합니다. 사용자는 클라이언트 인증서를 선택하고 확인을 선택합니다.

    참고 항목

    신뢰할 수 있는 CA 힌트는 지원되지 않으므로 인증서 목록의 범위를 더 이상 지정할 수 없습니다. 향후 이 기능을 추가할 예정입니다.

    인증서 선택기의 스크린샷

  7. Microsoft Entra ID는 인증서 해지 목록을 확인하여 인증서가 해지되지 않고 유효한지 확인합니다. Microsoft Entra ID는 인증서 필드 값을 사용자 특성 값에 매핑하여 테넌트에 구성된 사용자 이름 바인딩을 사용하여 사용자를 식별합니다.

  8. 다단계 인증이 필요한 조건부 액세스 정책이 있는 고유 사용자가 있고 인증서 인증 바인딩 규칙이 MFA를 충족하는 경우 Microsoft Entra ID는 사용자를 즉시 로그인합니다. MFA가 필요하지만 인증서가 단일 단계만 충족하는 경우 암호 없는 로그인 또는 FIDO2가 이미 등록된 경우 두 번째 단계로 제공됩니다.

  9. Microsoft Entra ID는 로그인 성공을 나타내기 위해 기본 새로 고침 토큰을 다시 보내 로그인 프로세스를 완료합니다.

  10. 사용자 로그인에 성공하면 사용자가 애플리케이션에 액세스할 수 있습니다.

인증서 기반 인증은 MFA를 지원합니다.

Microsoft Entra CBA는 MFA(다단계 인증)를 수행할 수 있습니다. Microsoft Entra CBA는 테넌트 구성에 따라 SF(단일 요소) 또는 MF(다단계)일 수 있습니다. CBA를 사용하도록 설정하면 사용자가 잠재적으로 MFA를 완료할 수 있습니다. 사용자가 CBA 범위에 있을 때 MFA를 완료하려면 추가 구성이 필요하고, 다른 인증 방법을 등록하려면 증명이 필요할 수 있습니다.

CBA 사용 사용자에게 SF(단일 요소) 인증서만 있고 MFA를 완료해야 하는 경우:

  1. 암호 및 SF 인증서를 사용합니다.
  2. 임시 액세스 패스를 발급합니다.
  3. 인증 정책 관리자는 전화번호를 추가하고 사용자 계정에 대한 음성/문자 메시지 인증을 허용합니다.

CBA 사용 사용자가 아직 인증서를 발급하지 않았으며 MFA를 완료해야 하는 경우:

  1. 임시 액세스 패스를 발급합니다.
  2. 인증 정책 관리자는 전화번호를 추가하고 사용자 계정에 대한 음성/문자 메시지 인증을 허용합니다.

CBA 사용 사용자가 스마트 카드 지원 없이 모바일 디바이스와 같은 MF 인증서를 사용할 수 없고 MFA를 완료해야 하는 경우:

  1. 임시 액세스 패스를 발급합니다.
  2. 사용자가 다른 MFA 메서드를 등록해야 합니다(사용자가 MF 인증서를 사용할 수 있는 경우).
  3. 암호 및 MF 인증서를 사용합니다(사용자가 MF 인증서를 사용할 수 있는 경우).
  4. 인증 정책 관리자는 전화번호를 추가하고 사용자 계정에 대한 음성/문자 메시지 인증을 허용합니다.

단일 요소 인증서 기반 인증을 사용하는 MFA(미리 보기)

Microsoft Entra CBA는 단일 단계 인증서로 MFA 요구 사항을 충족하기 위한 두 번째 단계로 사용할 수 있습니다. 지원되는 조합 중 일부는 다음과 같습니다.

  1. CBA(첫 번째 단계) 및 암호 없는 휴대폰 로그인(두 번째 단계인 암호 없는 로그인)
  2. CBA(첫 번째 단계) 및 FIDO2 보안 키(두 번째 단계)
  3. 암호(첫 번째 단계) 및 CBA(두 번째 단계)

사용자는 Microsoft Entra CBA로 로그인하기 전에 MFA를 가져오고 암호 없는 로그인 또는 FIDO2를 등록하는 다른 방법이 있어야 합니다.

Important

사용자는 CBA 메서드 설정에 포함될 때 MFA 가능으로 간주됩니다. 이는 사용자가 등록된 다른 사용 가능한 방법에 대한 인증의 일부로 증명을 사용할 수 없음을 의미합니다. 유효한 인증서가 없는 사용자가 CBA 메서드 설정에 포함되지 않았는지 확인합니다. 인증 작동 방식에 관한 자세한 내용은 Microsoft Entra 다단계 인증을 참조하세요.

CBA를 사용하여 암호 없는 PSI(전화 로그인)를 설정하는 단계

암호 없는 로그인이 작동하려면 사용자가 모바일 앱을 통해 레거시 알림을 사용하지 않도록 설정해야 합니다.

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

  2. 암호 없는 휴대폰 로그인 인증 사용의 단계를 따릅니다.

    Important

    이전 구성에서 암호 없음 옵션을 선택했는지 확인합니다. PSI에 추가된 모든 그룹의 인증 모드를 암호 없음으로 변경해야 합니다. 모두를 선택하면 CBA와 PSI가 작동하지 않습니다.

  3. 보호>다단계 인증>추가 클라우드 기반 다단계 인증 설정을 선택합니다.

    다단계 인증 설정을 구성하는 방법의 스크린샷

  4. 확인 옵션에서 모바일 앱을 통한 알림을 선택 취소하고 저장을 선택합니다.

    모바일 앱을 통해 알림을 제거하는 방법의 스크린샷

단일 단계 인증서 및 암호 없는 로그인을 사용하는 MFA 인증 흐름

단일 요소 인증서가 있고 암호 없는 로그인이 구성된 사용자의 예를 살펴보겠습니다.

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

    사용자 계정 이름을 입력하는 방법의 스크린샷

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

    인증서로 로그인하는 방법의 스크린샷

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

    인증서를 사용하여 로그인하는 대체 방법의 스크린샷

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

    인증서를 선택하는 방법의 스크린샷

  4. 인증서가 단일 단계 인증 강도로 구성되기 때문에 사용자는 MFA 요구 사항을 충족하기 위해 두 번째 단계가 필요합니다. 사용자에게 사용 가능한 두 번째 단계가 표시되며, 이 경우에는 암호 없이 로그인됩니다. 내 Microsoft Authenticator 앱에서 요청 승인을 선택합니다.

    두 번째 요소 요청의 스크린샷.

  5. 휴대폰에 알림이 표시됩니다. 로그인을 승인하려고 하나요?를 선택합니다. 승인 요청의 스크린샷.

  6. 브라우저 또는 앱 화면에 표시되는 번호를 Microsoft Authenticator에 입력합니다.

    숫자 일치 스크린샷

  7. 예를 선택하면 사용자가 인증하고 로그인할 수 있습니다.

인증 바인딩 정책 이해

인증 바인딩 정책은 인증의 강도를 단일 요소 또는 다중 요소로 결정하는 데 도움이 됩니다. 관리자는 기본값을 단일 요소에서 다중 요소로 변경하거나 인증서의 발급자 주체나 정책 OID 또는 발급자 및 정책 OID 필드를 사용하여 사용자 지정 정책 구성을 설정할 수 있습니다.

인증서 강도

관리자는 인증서가 단일 요소인지 다단계 강도인지 결정할 수 있습니다. 자세한 내용은 NIST 인증 보증 수준을 NIST 800-63B SP 800-63B, 디지털 ID 지침: 인증 및 수명 주기 관리를 기준으로 하는 Microsoft Entra 인증 방법에 매핑하는 설명서를 참조하세요.

다단계 인증서 인증

사용자에게 다단계 인증서가 있는 경우 인증서로만 다단계 인증을 수행할 수 있습니다. 그러나 인증 정책 관리istrator는 인증서가 PIN 또는 바이오 메트릭을 사용하여 다단계로 간주되도록 보호해야 합니다.

Microsoft Entra ID가 여러 인증 정책 바인딩 규칙을 확인하는 방법

발급자 + 정책 OID를 사용하거나 정책 OID 또는 발급자만 사용하는 것과 같은 다른 인증서 필드를 사용하여 여러 사용자 지정 인증 바인딩 정책 규칙을 만들 수 있기 때문입니다. 다음은 사용자 지정 규칙이 겹칠 때 인증 보호 수준을 결정하는 데 사용되는 단계입니다. 다음과 같습니다.

  1. 발급자 + 정책 OID 규칙이 정책 OID 규칙보다 우선합니다. 정책 OID 규칙은 인증서 발급자 규칙보다 우선합니다.
  2. 발급자 + 정책 OID 규칙이 먼저 평가됩니다. 발급자 CA1 및 정책 OID 1.2.3.4.5 와 MFA를 사용하는 사용자 지정 규칙이 있는 경우 인증서 A가 발급자 값과 정책 OID를 모두 충족하는 경우에만 MFA가 제공됩니다.
  3. 다음으로 정책 OID를 사용하는 사용자 지정 규칙이 평가됩니다. 정책 OID가 1.2.3.4.5인 인증서 A가 있고 해당 인증서를 기반으로 하는 파생된 자격 증명 B가 있고 정책 OID가 1.2.3.4.5.6이고 사용자 지정 규칙이 MFA를 사용하고 값이 1.2.3.4.5인 정책 OID로 정의되는 경우 인증서 A만 MFA를 충족하고 자격 증명 B는 단일 요소 인증만 충족합니다. 사용자가 로그인하는 동안 파생된 자격 증명을 사용하고 MFA를 갖도록 구성된 경우 성공적인 인증을 위한 두 번째 요소를 묻는 메시지가 표시됩니다.
  4. 여러 정책 OID 간에 충돌이 있는 경우(예: 인증서에 단일 요소 인증에 바인딩하고 다른 하나는 MFA에 바인딩하는 두 개의 정책 OID가 있는 경우) 인증서를 단일 요소 인증으로 처리합니다.
  5. 다음으로 발급자 CA를 사용하는 사용자 지정 규칙이 평가됩니다.
  6. 인증서에 정책 OID 및 발급자 규칙이 모두 일치하는 경우 정책 OID는 항상 먼저 검사, 정책 규칙이 없으면 발급자 바인딩이 검사. 정책 OID는 발급자보다 강력한 인증 바인딩 우선 순위가 높습니다.
  7. 하나의 CA가 MFA에 바인딩되면 CA에서 발급하는 모든 사용자 인증서가 MFA 자격을 갖습니다. 단일 요소 인증에도 동일한 논리가 적용됩니다.
  8. 하나의 정책 OID가 MFA에 바인딩되면 이 정책 OID를 OID 중 하나로 포함하는 모든 사용자 인증서(사용자 인증서에는 여러 정책 OID가 있을 수 있음)가 MFA로 간주됩니다.
  9. 하나의 인증서 발급자만 하나의 유효한 강력한 인증 바인딩을 가질 수 있습니다(즉, 인증서는 단일 요소와 MFA 둘 다에 바인딩할 수 없습니다).

Important

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

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

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

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

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

사용자 이름 바인딩 정책 이해

사용자 이름 바인딩 정책은 사용자 인증서의 유효성을 검사하는 데 도움이 됩니다. 기본적으로 인증서의 SAN(주체 대체 이름) 사용자 이름은 사용자를 결정하기 위해 사용자 개체의 UserPrincipalName 특성에 매핑됩니다.

인증서 바인딩을 사용하여 더 높은 보안 달성

인증서 바인딩에는 7가지 지원 방법이 있습니다. 일반적으로 매핑 형식은 다시 사용할 수 없는 식별자(예: 주체 키 식별자 또는 SHA1 퍼블릭 키)를 기준으로 하는 경우 선호도가 높은 것으로 간주됩니다. 이러한 식별자는 단일 인증서만 해당 사용자를 인증하는 데 사용할 수 있음을 보다 확실하게 보장합니다.

사용자 이름 및 이메일 주소를 기반으로 하는 매핑 형식은 선호도가 낮은 것으로 간주됩니다. Microsoft Entra ID는 재사용 가능한 식별자를 기반으로 선호도가 낮은 것으로 간주되는 세 가지 매핑을 구현합니다. 다른 것들은 선호도가 높은 바인딩으로 간주됩니다. 자세한 내용은 certificateUserIds를 참조하세요.

인증서 매핑 필드 certificateUserIds의 값 예제 사용자 개체 특성 Type
주체 이름 X509:<PN>bob@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 낮은 선호도
RFC822Name X509:<RFC822>user@woodgrove.com userPrincipalName
onPremisesUserPrincipalName
certificateUserIds		 낮은 선호도
IssuerAndSubject(미리 보기) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds 낮은 선호도
제목(미리 보기) X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds 낮은 선호도
SKI X509:<SKI>123456789abcdef certificateUserIds 높은 선호도
SHA1PublicKey X509:<SHA1-PUKEY>123456789abcdef certificateUserIds 높은 선호도
IssuerAndSerialNumber(미리 보기) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
일련 번호의 올바른 값을 가져오려면 이 명령을 실행하고 CertificateUserIds에 표시된 값을 저장합니다.
구문:
Certutil –dump –v [~certificate path~] >> [~dumpFile path~]
예:
certutil -dump -v firstusercert.cer >> firstCertDump.txt		 certificateUserIds 높은 선호도

테넌트 수준에서 선호도 바인딩을 정의하고 사용자 지정 규칙으로 재정의(미리 보기)

이 기능을 사용하면 인증 정책 관리자는 선호도가 낮거나 선호도가 높은 사용자 이름 바인딩 매핑을 사용하여 사용자를 인증할 수 있는지 여부를 구성할 수 있습니다. 모든 사용자에게 적용되는 테넌트에 대해 필수 선호도 바인딩을 설정할 수 있습니다. 발급자 및 정책 OID 또는 정책 OID 또는 발급자를 기반으로 사용자 지정 규칙을 만들어 테넌트 전체 기본값을 재정의할 수도 있습니다.

Microsoft Entra ID가 여러 사용자 이름 정책 바인딩 규칙을 확인하는 방법

가장 높은 우선 순위(가장 낮은 번호) 바인딩을 사용합니다.

  1. 사용자 이름 또는 사용자 계정 이름을 사용하여 사용자 개체를 조회합니다.
  2. 'priority' 특성에 따라 정렬된 CBA 인증 메서드 구성에서 테넌트 관리자가 설정한 모든 사용자 이름 바인딩 목록을 가져옵니다. 현재 우선 순위 개념은 포털 UX에 노출되지 않습니다. 그래프는 각 바인딩에 대한 우선 순위 특성을 반환하며 평가 프로세스에 사용됩니다.
  3. 테넌트가 높은 선호도 바인딩을 사용하도록 설정했거나 인증서 값이 높은 선호도 바인딩이 필요한 사용자 지정 규칙과 일치하는 경우 목록에서 낮은 선호도 바인딩을 모두 제거합니다.
  4. 인증이 성공할 때까지 목록의 각 바인딩을 평가합니다.
  5. 구성된 바인딩의 X.509 인증서 필드가 제공된 인증서에 있는 경우 Microsoft Entra ID는 인증서 필드의 값과 사용자 개체 특성 값과 일치합니다.
    1. 일치하는 항목이 발견되면 사용자 인증이 성공합니다.
    2. 일치하는 항목을 찾을 수 없는 경우 다음 우선 순위 바인딩으로 이동합니다.
  6. X.509 인증서 필드가 제시된 인증서에 없으면 다음 우선 순위 바인딩으로 이동합니다.
  7. 구성된 모든 사용자 이름 중 하나가 일치하고 사용자 인증이 성공할 때까지 바인딩이 유효한지 검사합니다.
  8. 구성된 사용자 이름 바인딩에서 일치하는 항목을 찾을 수 없으면 사용자 인증이 실패합니다.

여러 사용자 이름 바인딩을 사용하여 Microsoft Entra 구성 보호

Microsoft Entra 사용자 계정에 인증서를 바인딩하는 데 사용할 수 있는 각 Microsoft Entra 사용자 개체 특성(userPrincipalName, onPremiseUserPrincipalName, certificateUserIds)에는 인증서가 단일 Microsoft Entra 사용자 계정과만 일치하도록 하는 고유한 제약 조건이 있습니다. 그러나 Microsoft Entra CBA는 관리자가 여러 Entra 사용자 계정 구성에 하나의 인증서를 수용할 수 있도록 사용자 이름 바인딩 정책에서 여러 바인딩 메서드를 지원합니다.

Important

여러 바인딩을 구성하는 경우 CBA가 사용자를 인증하기 위해 각 바인딩의 유효성을 검사하므로 Microsoft Entra CBA 인증은 선호도가 가장 낮은 바인딩만큼만 안전합니다. 단일 인증서가 여러 Microsoft Entra 계정과 일치하는 시나리오를 방지하기 위해 인증 정책 관리자는 다음을 수행할 수 있습니다.

  • 사용자 이름 바인딩 정책에서 단일 바인딩 방법을 구성합니다.
  • 테넌트에 여러 바인딩 방법이 구성되어 있고 하나의 인증서가 여러 계정에 매핑되는 것을 허용하지 않으려는 경우 인증 정책 관리자는 정책에 구성된 모든 허용 방법이 동일한 Microsoft Entra 계정에 매핑되도록 해야 합니다. 모든 사용자 계정에는 모든 바인딩과 일치하는 값이 있어야 합니다.
  • 테넌트에 여러 바인딩 메서드가 구성된 경우 인증 정책 관리istrator는 두 개 이상의 낮은 선호도 바인딩이 없는지 확인해야 합니다.

예를 들어, PrincipalName에 UPN에 매핑된 두 개의 사용자 이름 바인딩과 CertificateUserIds에 대한 SKI(SubjectKeyIdentifier)가 있다고 가정해 보겠습니다. 인증서를 단일 계정에만 사용하려면 인증 정책 관리자는 계정에 인증서에 있는 UPN이 있는지 확인하고 동일한 계정의 CertificateUserId 특성에 SKI 매핑을 구현해야 합니다.

한 개의 Entra 사용자 계정으로 여러 인증서에 대한 지원(M:1)

조직에서 단일 ID에 대해 여러 인증서를 발급하는 시나리오가 있습니다. 가장 일반적으로 이것은 모바일 디바이스에 대한 파생 자격 증명이거나 보조 스마트카드 또는 x509 자격 증명 보유자 지원 디바이스(예: Yubikey)에 대한 자격 증명일 수도 있습니다.

클라우드 전용 계정 클라우드 전용 계정 의 경우 certificateUserIds 필드(사용자 포털의 권한 부여 정보)를 각 인증서를 식별하는 고유 값으로 채워 사용할 수 있도록 여러 인증서(최대 5개)를 매핑할 수 있습니다. 조직에서 발급자 + SerialNumber라고 하는 높은 선호도 바인딩을 사용하는 경우 CertificateUserIds 내의 값은 다음과 같을 수 있습니다.

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

이 예제에서 첫 번째 값은 X509Certificate1을 나타내고 두 번째 값은 X509Certificate2를 나타냅니다. 사용자는 로그인 시 인증서를 표시할 수 있으며 CBA 사용자 이름 바인딩이 certificateUserIds 필드를 가리키도록 설정되어 특정 바인딩 유형(예: 이 예제의 Issuer+SerialNumber)을 찾으면 사용자가 성공적으로 로그인합니다.

하이브리드 동기화된 계정 동기화된 계정 의 경우 AD의 altSecurityIdentities 필드를 각 인증서를 식별하는 값을 채워 사용할 여러 인증서를 매핑할 수 있습니다. 조직에서 높은 선호도(즉, 강력한 인증) 바인딩을 사용하는 경우 발급자 + SerialNumber라고 하며 다음과 같이 표시할 수 있습니다.

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

이 예제에서 첫 번째 값은 X509Certificate1을 나타내고 두 번째 값은 X509Certificate2를 나타냅니다. 그런 다음 이러한 값을 Azure AD의 certificateUserIds 필드로 동기화해야 합니다.

여러 Entra 사용자 계정이 있는 하나의 인증서에 대한 지원(1:M)

조직에서 사용자가 동일한 인증서를 사용하여 여러 ID로 인증해야 하는 시나리오가 있습니다. 가장 일반적으로 이는 관리 계정용입니다. 개발자 계정 또는 임시 의무 계정일 수도 있습니다. 기존 AD에서 altSecurityIdentities 필드는 인증서 값을 채우는 데 사용되며 로그인하는 동안 힌트를 사용하여 AD를 원하는 계정으로 보내 로그인에 검사. Microsoft Entra CBA에서는 이것이 다르며 힌트가 없습니다. 대신 홈 영역 검색은 인증서 값을 검사 원하는 계정을 식별합니다. 다른 주요 차이점은 Microsoft Entra CBA가 certificateUserIds 필드에서 고유성을 적용한다는 것입니다. 즉, 두 계정이 모두 동일한 인증서 값을 채울 수 없습니다.

Important

동일한 자격 증명을 사용하여 다른 Entra ID 계정으로 인증하는 것은 매우 안전한 구성이 아니며 여러 Entra 사용자 계정에 대해 하나의 인증서를 허용하지 않는 것이 좋습니다.

클라우드 전용 계정 클라우드 전용 계정의 경우 여러 사용자 이름 바인딩을 만들어야 하며 인증서를 활용할 각 사용자 계정에 고유 값을 매핑해야 합니다. 각 계정은 다른 사용자 이름 바인딩을 사용하여 인증됩니다. 이는 단일 디렉터리/테넌트 경계 내에 적용됩니다(즉, 테넌트 관리자는 값이 계정당 고유하지 기본 한 다른 디렉터리/테넌트에서도 사용할 인증서를 매핑할 수 있습니다).

certificateUserIds 필드(사용자 포털의 권한 부여 정보)를 원하는 인증서를 식별하는 고유 값으로 채웁니다. 조직에서 높은 선호도 바인딩(즉, 강력한 인증) 바인딩을 사용하는 경우 발급자 + SerialNumber 및 SKI라고 말하면 다음과 같이 표시할 수 있습니다.

사용자 이름 바인딩:

  • 발급자 + 일련 번호 -> CertificateUserIds
  • SKI -> CertificateUserIds

사용자 계정 CertificateUserIds 값:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

이제 두 사용자가 로그인 시 동일한 인증서를 표시하면 해당 계정이 해당 인증서의 고유 값과 일치하므로 사용자가 성공적으로 로그인합니다. 한 계정은 Issuer+SerialNumber를 사용하여 인증되고 다른 계정은 SKI 바인딩을 사용하여 인증됩니다.

참고 항목

이러한 방식으로 사용할 수 있는 계정 수는 테넌트에 구성된 사용자 이름 바인딩 수로 제한됩니다. 조직에서 높은 선호도 바인딩만 사용하는 경우 지원되는 계정 수는 3으로 제한됩니다. 조직에서 낮은 선호도 바인딩도 활용하는 경우 이 숫자는 7개의 계정(PrincipalName 1개, RFC822Name 1개, SubjectKeyIdentifier 1개, SHA1PublicKey 1개, 발급자+주체 1개, 발급자+직렬 번호 1개, 주체 1개)로 증가합니다.

하이브리드 동기화된 계정 동기화된 계정의 경우 접근 방식이 다릅니다. 테넌트 관리자는 인증서를 활용하는 각 사용자 계정에 고유 값을 매핑할 수 있지만, Entra ID의 각 계정에 모든 값을 채우는 일반적인 방법은 이 작업을 어렵게 만듭니다. 대신 Azure AD 커넥트 계정당 원하는 값을 Entra ID의 계정에 채워진 고유 값으로 필터링해야 합니다. 고유성 규칙은 단일 디렉터리/테넌트 경계 내에 적용됩니다(즉, 테넌트 관리자가 계정당 고유한 값을 다시 기본 한 다른 디렉터리/테넌트에서도 사용할 인증서를 매핑할 수 있습니다). 또한 조직에는 사용자를 단일 Entra ID 테넌트에 기여하는 여러 AD 포리스트가 있을 수 있습니다. 이 경우 Azure AD 커넥트 클라우드 계정에 원하는 고유 값만 채우기 위해 동일한 목표를 가진 이러한 각 AD 포리스트에 필터를 적용합니다.

AD의 altSecurityIdentities 필드를 원하는 인증서를 식별하는 값으로 채우고 해당 사용자 계정 유형에 대해 원하는 인증서 값(예: detailee, admin, developer 등)을 포함합니다. AD에서 사용자가 평가하는 사용자 계정 유형(예: msDS-cloudExtensionAttribute1)을 동기화에 알려주는 키 특성을 선택합니다. 이 특성을 세부 정보, 관리자 또는 개발자와 같이 원하는 사용자 유형 값으로 채웁다. 사용자의 기본 계정인 경우 값을 빈/null로 둘 수 있습니다.

계정은 다음과 같이 표시할 수 있습니다.

포리스트 1 - Account1(bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

포리스트 1 - Account2(bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

포리스트 2 – ADAccount1(bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

그런 다음 이러한 값을 Entra ID의 certificateUserIds 필드에 동기화해야 합니다.

certificateUserIds와 동기화하는 단계

  1. Metaverse에 alternativeSecurityIds 필드를 추가하도록 Azure AD 연결 구성
  2. 각 AD 포리스트에 대해 우선 순위가 높은 새 사용자 지정 인바운드 규칙을 구성합니다(100보다 낮은 수). altSecurityIdentities 필드를 원본으로 사용하여 식 변환을 추가합니다. 대상 식은 선택한 키 특성과 정의한 사용자 유형에 대한 매핑을 사용합니다.
  3. 예시:
IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

위의 예제에서 altSecurityIdentities 및 키 특성 msDS-cloudExtensionAttribute1is는 먼저 검사 채워져 있는지 확인합니다. 그렇지 않은 경우 altSecurityIdentities가 채워지는지 확인하기 위해 검사. 비어 있으면 NULL로 설정합니다. 그렇지 않으면 계정이 기본 사례에 속하며 이 예제에서는 발급자+SerialNumber 매핑으로만 필터링합니다. 키 특성이 채워지면 정의된 사용자 유형 중 하나와 같은지 확인하기 위해 값이 검사. 이 예제에서 해당 값이 detailee이면 altSecurityIdentities에서 SHA1PublicKey 값으로 필터링합니다. 값이 개발자인 경우 altSecurityIdentities에서 SubjectKeyIssuer 값으로 필터링합니다. 특정 형식의 여러 인증서 값이 있을 수 있습니다. 예를 들어 여러 PrincipalName 값 또는 여러 SKI 또는 SHA1-PUKEY 값이 있습니다. 필터는 모든 값을 가져오고 처음 찾은 값뿐만 아니라 Entra ID로 동기화됩니다.

  1. 컨트롤 특성이 비어 있는 경우 빈 값을 푸시하는 방법을 보여 주는 두 번째 예제는 다음과 같습니다.
IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
)

altSecurityIdentities의 값이 컨트롤 특성의 검색 값과 일치하지 않으면 AuthoritativeNull이 전달됩니다. 이렇게 하면 alternativeSecurityId를 채우는 이전 또는 후속 규칙이 무시되고 결과가 Entra ID에 비어 있습니다.

  1. 우선 순위가 낮은 새 사용자 지정 아웃바운드 규칙을 구성합니다(160보다 높음 – 목록 맨 아래).
  2. alternativeSecurityIds 필드를 원본으로, certificateUserIds 필드를 대상으로 사용하여 직접 변환을 추가합니다.
  3. 동기화 주기를 실행하여 Entra ID의 데이터 채우기를 완료합니다.

각 테넌트에서 CBA가 인증서에서 매핑한 필드 형식에 대한 certificateUserIds 필드를 가리키는 사용자 이름 바인딩으로 구성되었는지 확인합니다. 이제 이러한 사용자는 로그인 시 인증서를 표시할 수 있으며 인증서의 고유 값이 certificateUserIds 필드에 대해 유효성을 검사한 후에 해당 사용자가 성공적으로 로그인됩니다.

인증서 해지 프로세스 이해

인증서 해지 프로세스를 통해 관리자는 이전에 발급된 인증서가 향후 인증에 사용되지 않도록 해지할 수 있습니다. 인증서 취소는 사용자의 이미 발급된 토큰을 취소하지 않습니다. 해지 구성에서 수동으로 토큰을 해지하는 단계를 따릅니다.

Microsoft Entra ID는 인증 기관에서 고객의 CRL(인증서 해지 목록)을 다운로드하고 캐시하여 사용자 인증 중에 인증서가 해지되었는지 확인합니다.

관리자는 Microsoft Entra 테넌트에서 신뢰할 수 있는 발급자의 설정 프로세스 중에 CRL 배포 지점을 구성할 수 있습니다. 신뢰할 수 있는 각 발급자에는 인터넷 연결 URL을 사용하여 참조할 수 있는 CRL이 있어야 합니다.

Important

Microsoft Entra ID가 대화형 로그인에서 성공적으로 다운로드 및 캐시하기 위한 CRL의 최대 크기는 공용 Entra ID에서 20MB, Azure US Government 클라우드에서 45MB이며 CRL을 다운로드하는 데 필요한 시간은 10초를 초과해서는 안 됩니다. Microsoft Entra ID에서 CRL을 다운로드할 수 없는 경우 해당 CA에서 발급한 인증서를 사용하는 인증서 기반 인증이 실패합니다. CRL 파일을 크기 제한 이내로 유지하는 모범 사례로, 적절한 제한 내에서 인증서 수명을 유지하고 만료된 인증서를 정리합니다. 자세한 내용은 CRL 크기에 제한이 있나요?를 참조하세요.

사용자가 인증서를 사용하여 대화형 로그인을 수행하고 CRL이 클라우드에 대한 대화형 제한을 초과하면 다음 오류를 나타내며 초기 로그인이 실패합니다.

"{uri}에서 다운로드한 CRL(인증서 해지 목록)이 Microsoft Entra ID의 CRL에 허용되는 최대 크기({size}바이트)를 초과했습니다. 잠시 후 다시 시도하세요. 그래도 문제가 계속되면 테넌트 관리자에게 문의하세요."

오류가 발생한 후 Microsoft Entra ID는 서비스 쪽 제한(공용 Entra ID의 경우 45MB, Azure US Gov 클라우드의 경우 150MB)에 따라 CRL 다운로드를 시도합니다.

Important

관리자가 CRL 구성을 건너뛰면 Microsoft Entra ID는 사용자의 인증서 기반 인증 중에 CRL 검사를 수행하지 않습니다. 이는 초기 문제 해결에 도움이 될 수 있지만 프로덕션 용도로 고려해서는 안 됩니다.

현재로서는 성능 및 안정성상의 이유로 OCSP(온라인 인증서 상태 프로토콜)를 지원하지 않습니다. OCSP용 클라이언트 브라우저에서 연결할 때마다 CRL을 다운로드하는 대신 Microsoft Entra ID는 처음 로그인할 때 한 번 다운로드하고 캐시하므로 CRL 확인의 성능과 안정성이 개선됩니다. 또한 매번 검색 속도가 빨라지도록 캐시를 인덱싱합니다. 고객은 인증서 해지용 CRL을 게시해야 합니다.

다음 단계는 CRL 검사의 일반적인 흐름입니다.

  1. Microsoft Entra ID는 해당 신뢰할 수 있는 발급자 또는 인증 기관의 인증서가 있는 사용자의 첫 번째 로그인 이벤트에서 CRL 다운로드를 시도합니다.
  2. Microsoft Entra ID는 이후 사용을 위해 CRL을 캐시하고 재사용합니다. CRL 문서의 다음 업데이트 날짜 및 가능한 경우 다음 CRL 게시 날짜(Windows Server CA에서 사용)를 따릅니다.
  3. 다음과 같은 경우 사용자 인증서 기반 인증이 실패합니다.

    • CRL은 신뢰할 수 있는 발급자에 대해 구성되었으며 Microsoft Entra ID는 가용성, 크기 또는 대기 시간 제약 조건 조건으로 인해 CRL을 다운로드할 수 없습니다.

    • 사용자의 인증서가 CRL에 해지된 것으로 나열됩니다.

      CRL에서 해지된 사용자 인증서의 스크린샷

    • Microsoft Entra ID는 캐시된 CRL 문서가 만료된 경우 배포 지점에서 새 CRL을 다운로드하려고 시도합니다.

참고 항목

Microsoft Entra ID는 발급 CA의 CRL와 루트 CA까지의 PKI 신뢰 체인에 있는 다른 CA를 확인합니다. PKI 체인의 CRL 유효성 검사를 위해 리프 클라이언트 인증서의 CA를 최대 10개로 제한합니다. 이러한 제한은 CRL이 더 큰 많은 수의 CA가 있는 PKI 체인을 업로드하여 악의적인 행위자가 서비스를 중단하지 않도록 하기 위한 것입니다. 테넌트의 PKI 체인에 CA가 5개보다 많이 있고 CA 손상이 발생한 경우 관리자는 Microsoft Entra 테넌트 구성에서 손상된 신뢰할 수 있는 발급자를 제거해야 합니다.

Important

CRL 캐싱 및 게시 주기의 특성으로 인해 인증서 해지의 경우 Microsoft Entra ID에서 영향을 받는 사용자의 모든 세션도 해지하는 것이 좋습니다.

현재로서는 CRL 다운로드를 수동으로 강제하거나 다시 트리거할 수 있는 방법이 없습니다.

해지를 구성하는 방법

클라이언트 인증서를 철회하기 위해 Microsoft Entra ID는 인증 기관 정보의 일부로 업로드된 URL에서 CRL(인증서 해지 목록)을 가져와 캐시합니다. CRL의 마지막 게시 타임스탬프(개시 날짜 속성)는 CRL이 여전히 유효한지 확인하는 데 사용됩니다. CRL은 목록의 일부인 인증서에 대한 액세스 권한을 해지하기 위해 주기적으로 참조됩니다.

추가 인스턴트 해지가 필요하면(예: 사용자가 디바이스를 분실한 경우) 사용자의 권한 부여 토큰이 무효화될 수 있습니다. 권한 부여 토큰을 무효화하려면 Windows PowerShell을 사용하여 이 특정 사용자에 대한 StsRefreshTokenValidFrom 필드를 설정합니다. 액세스 권한을 해지하려는 각 사용자에 대한 StsRefreshTokenValidFrom 필드를 업데이트해야 합니다.

해지가 지속되도록 하려면 개시 날짜를 StsRefreshTokenValidFrom으로 설정한 값 이후의 날짜로 설정하고 문제의 인증서가 CRL에 있는지 확인해야 합니다.

참고 항목

Azure AD와 MSOnline PowerShell 모듈은 2024년 3월 30일부터 더 이상 사용되지 않습니다. 자세히 알아보려면 사용 중단 업데이트를 참조하세요. 이 날짜 이후에는 이러한 모듈에 대한 지원이 Microsoft Graph PowerShell SDK 및 보안 수정 사항에 대한 마이그레이션 지원으로 제한됩니다. 사용되지 않는 모듈은 2025년 3월 30일까지 계속 작동합니다.

Microsoft Graph PowerShell로 마이그레이션하여 Microsoft Entra ID(이전의 Azure AD)와 상호 작용하는 것이 좋습니다. 일반적인 마이그레이션 관련 질문은 마이그레이션 FAQ를 참조하세요. 참고: MSOnline 버전 1.0.x는 2024년 6월 30일 이후 중단될 수 있습니다.

다음 단계에서는 StsRefreshTokenValidFrom 필드를 설정하여 권한 부여 토큰을 업데이트 및 무효화하기 위한 프로세스를 설명합니다.

  1. PowerShell에 커넥트:

    Connect-MgGraph

  2. 사용자에 대한 현재 StsRefreshTokensValidFrom 값을 검색합니다.

            $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
        $user.StsRefreshTokensValidFrom

  3. 사용자에 대한 새 StsRefreshTokensValidFrom 값을 현재 타임스탬프와 같게 구성합니다.

            Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")

설정하는 날짜는 이후 날짜여야 합니다. 날짜가 이후 날짜가 아닌 경우 StsRefreshTokensValidFrom 속성이 설정되지 않은 것입니다. 날짜가 이후 날짜인 경우 StsRefreshTokensValidFrom 이 현재 시간(Set-MsolUser 명령으로 지정된 날짜 아님)으로 설정됩니다.

CBA가 조건부 액세스 인증 강도 정책을 사용하는 방법

고객은 조건부 액세스 인증 강도 정책을 만들어 CBA를 사용하여 리소스에 액세스하도록 지정할 수 있습니다.

기본 제공 피싱 방지 MFA 인증 강도를 사용할 수 있습니다. 해당 정책은 CBA, FIDO2 보안 키 및 비즈니스용 Windows Hello 같은 피싱에 강한 인증 방법만 허용합니다.

CBA만 중요한 리소스에 액세스할 수 있도록 사용자 지정 인증 강도를 만들 수도 있습니다. CBA를 단일 요소, 다단계 또는 둘 다로 허용할 수 있습니다. 자세한 내용은 조건부 액세스 인증 강도를 참조 하세요.

고급 옵션을 사용한 CBA 인증 강도

CBA 인증 방법 정책에서 관리자는 CBA 메서드에서 인증 바인딩 정책을 사용하여 인증서의 강도를 확인할 수 있습니다. 이제 사용자가 CBA를 수행하여 특정 중요한 리소스에 액세스할 때 발급자 및 정책 OID에 따라 특정 인증서를 사용하도록 요구하는 사용자 지정 인증 강도를 만들 때 고급 옵션을 구성할 수 있습니다. 이 기능은 리소스에 액세스할 수 있는 인증서 및 사용자를 결정하는 보다 정확한 구성을 제공합니다. 자세한 내용은 조건부 액세스 인증 강도에 대한 고급 옵션을 참조 하세요.

로그인 로그 이해

로그인 로그는 로그인 및 사용자가 리소스를 사용하는 방법에 대한 정보를 제공합니다. 로그인 로그에 대한 자세한 내용은 Microsoft Entra ID의 로그인 로그를 참조하세요.

인증서가 단일 요소 인증을 충족하는 시나리오와 인증서가 MFA를 충족하는 시나리오의 두 가지 시나리오를 살펴보겠습니다.

테스트 시나리오의 경우 MFA가 필요한 조건부 액세스 정책이 있는 사용자를 선택합니다. SAN Principal Name을 UserPrincipalName에 매핑하여 사용자 바인딩 정책을 구성합니다.

사용자 인증서는 다음 스크린샷과 같이 구성해야 합니다.

사용자 인증서의 스크린샷

로그인 로그의 동적 변수에 대한 로그인 문제 해결

로그인 로그는 사용자의 로그인 문제를 디버그하기 위한 모든 정보를 제공하지만 특정 값이 필요한 경우가 있으며 로그인 로그가 동적 변수를 지원하지 않으므로 로그인 로그에 누락된 정보가 있을 수 있습니다. 예: 로그인 로그의 실패 원인은 "CRL(인증서 해지 목록)에서 서명 유효성 검사에 실패했습니다. 필요한 주체 키 식별자 {expectedSKI}가 CRL 기관 키 {crlAK}을(를) 일치하지 않습니다. 테넌트 관리자에게 CRL 구성을 검사 요청하세요." 여기서 {expectedSKI} 및 {crlAKI}는 올바른 값으로 채워지지 않습니다.

CBA로 로그인하는 사용자가 실패하면 오류 페이지의 '자세히' 링크에서 로그 세부 정보를 복사하세요. 자세한 내용은 CBA 오류 페이지 이해를 참조 하세요.

단일 요소 인증 테스트

첫 번째 테스트 시나리오의 경우 발급자 주체 규칙이 단일 요소 인증을 충족하는 인증 정책을 구성합니다.

필요한 단일 요소 인증을 보여 주는 인증 정책 구성의 스크린샷

  1. CBA를 사용하여 Microsoft Entra 관리 센터에 테스트 사용자로 로그인합니다. 인증 정책은 발급자 주체 규칙이 단일 요소 인증을 충족하도록 설정됩니다.

  2. 로그인 로그를 검색하고 선택합니다.

    로그인 로그에서 찾을 수 있는 몇 가지 항목을 자세히 살펴보겠습니다.

    첫 번째 항목은 사용자에게 X.509 인증서를 요청합니다. 중단 상태는 Microsoft Entra ID가 테넌트에서 CBA가 사용하도록 설정되어 있고 인증을 위해 인증서가 요청되었음을 유효성 검사했음을 의미합니다.

    로그인 로그의 단일 요소 인증 항목 스크린샷

    활동 세부 정보는 사용자가 인증서를 선택하는 예상 로그인 흐름의 일부일 뿐임을 보여 줍니다.

    로그인 로그의 활동 세부 정보 스크린샷

    추가 세부 정보에는 인증서 정보가 표시됩니다.

    로그인 로그의 다단계 추가 세부 정보 스크린샷

    이러한 추가 항목은 인증이 완료되고 기본 새로 고침 토큰이 브라우저로 다시 전송되고 사용자에게 리소스에 대한 액세스 권한이 부여되었음을 보여 줍니다.

    로그인 로그의 새로 고침 토큰 항목 스크린샷

다단계 인증 테스트

다음 테스트 시나리오에서는 policyOID 규칙이 다단계 인증을 충족하는 인증 정책을 구성합니다.

필요한 다단계 인증을 보여 주는 인증 정책 구성의 스크린샷

  1. CBA를 사용하여 Microsoft Entra 관리 센터에 로그인합니다. 다단계 인증을 만족하도록 정책이 설정되어 있으므로 두 번째 요소 없이 사용자 로그인에 성공합니다.

  2. 로그인을 검색하고 선택합니다.

    로그인 로그에 중단 상태인 항목을 비롯한 여러 항목이 표시됩니다.

    로그인 로그의 여러 항목 스크린샷

    활동 세부 정보는 사용자가 인증서를 선택하는 예상 로그인 흐름의 일부일 뿐임을 보여 줍니다.

    로그인 로그의 2단계 로그인 세부 정보 스크린샷

    중단됨 상태의 항목에는 추가 세부 정보 탭에 더 많은 진단 정보가 있습니다.

    로그인 로그에서 중단된 시도 세부 정보의 스크린샷

    다음 표에는 각 필드에 대한 설명이 나와 있습니다.

    필드 설명
    사용자 인증서 주체 이름 인증서의 주체 이름 필드를 참조하세요.
    사용자 인증서 바인딩 인증서: 사용자 이름; 사용자 특성: userPrincipalName; 순위: 1
    이는 어떤 SAN PrincipalName 인증서 필드가 userPrincipalName 사용자 특성에 매핑되었고 우선 순위가 1인지 보여 줍니다.
    사용자 인증서 인증 수준 multiFactorAuthentication
    사용자 인증서 인증 수준 유형 PolicyId
    이는 정책 OID가 인증 강도를 결정하는 데 사용되었음을 보여 줍니다.
    사용자 인증서 인증 수준 식별자 1.2.3.4
    인증서의 식별자 정책 OID 값을 보여 줍니다.

인증서 기반 인증 오류 페이지 이해

인증서가 유효하지 않거나 사용자가 잘못된 인증서 또는 만료된 인증서를 선택했거나 CRL(인증서 해지 목록) 문제가 발생하여 인증서 기반 인증이 실패할 수 있습니다. 인증서 유효성 검사에 실패하면 다음 오류가 표시됩니다.

인증서 유효성 검사 오류의 스크린샷

인증서 선택기를 취소했기 때문에 이 오류가 발생한 것이더라도 브라우저에서 CBA가 실패하는 경우 브라우저 세션을 닫고 새 세션을 열어 CBA를 다시 시도해야 합니다. 브라우저가 인증서를 캐시하기 때문에 새 세션이 필요합니다. CBA를 다시 시도하면 브라우저는 TLS 챌린지 중에 캐시된 인증서를 전송하여 로그인 실패 및 유효성 검사 오류를 발생시킵니다.

자세한 내용을 선택하여 관리자에게 보낼 수 있는 로깅 정보를 가져옵니다. 그러면 관리자는 로그인 로그에서 자세한 정보를 얻을 수 있습니다.

오류 세부 정보의 스크린샷

사용자가 로그인할 수 있는 다른 방법을 시도하려면 다른 로그인 방법을 선택합니다.

참고 항목

브라우저에서 CBA를 다시 시도하는 경우 브라우저 캐싱 문제로 인해 계속 실패합니다. 사용자는 새 브라우저 세션을 열고 다시 로그인해야 합니다.

새 로그인 시도의 스크린샷

MRU(MostRecentlyUsed) 방법의 인증서 기반 인증

사용자가 CBA를 사용하여 성공적으로 인증을 받으면 사용자의 MRU(MostRecentlyUsed) 인증 방법이 CBA로 설정됩니다. 다음에 사용자가 UPN을 입력하고 다음을 선택하면 사용자가 CBA 방법으로 직접 이동되고 인증서 또는 스마트 카드 사용을 선택할 필요가 없습니다.

MRU 방법을 다시 설정하려면 사용자가 인증서 선택기를 취소하고, 다른 로그인 방법을 선택한 다음, 사용자가 사용할 수 있는 다른 방법을 선택하고 성공적으로 인증을 받아야 합니다.

외부 ID 지원

외부 ID는 Microsoft Entra CBA를 사용하여 리소스 테넌트에 대한 다단계 인증을 수행할 수 없습니다. 대신 사용자가 홈 테넌트에서 CBA를 사용하여 MFA를 수행하고 홈 테넌트에서 MFA를 신뢰하도록 리소스 테넌트에 대한 테넌트 간 설정을 지정해야 합니다.

Microsoft Entra 테넌트에서 다단계 인증 신뢰를 사용하도록 설정하는 방법에 대한 자세한 내용은 B2B 협업 테넌트 간 액세스 구성을 참조하세요.

다음 단계