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

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

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

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

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

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

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

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

   

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

   참고 항목

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

   

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

   

5. 사용자가 인증서 기반 인증을 선택하면 클라이언트는 인증 엔드포인트(퍼블릭 Microsoft Entra ID의 경우 https://certauth.login.microsoftonline.com)로 리디렉션됩니다. 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를 사용합니다.

   액세스가 허용되지 않는 한, 발급자 힌트를 활성화하면 인증서 기반 인증이 실패합니다.

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

   

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

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

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

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

발급자 힌트 이해(미리 보기)

발급자 힌트는 TLS 핸드셰이크의 일부로 신뢰할 수 있는 CA 표시를 다시 보냅니다. 신뢰할 수 있는 CA 목록은 Entra 신뢰 저장소의 테넌트에서 업로드한 CA(인증 기관)의 대상으로 설정됩니다. 브라우저 클라이언트 또는 네이티브 애플리케이션 클라이언트는 서버에서 다시 보낸 힌트를 사용하여 인증서 선택기에서 표시된 인증서를 필터링할 수 있습니다. 클라이언트는 신뢰 저장소의 CA에서 발급한 인증 인증서만 표시합니다.

발급자 힌트 사용

사용하려면 발급자 힌트 체크박스를 클릭합니다. 인증 정책 관리자는 TLS 검사를 사용하도록 설정된 프록시가 올바르게 업데이트되었는지 확인한 후 승인을 클릭하고 저장해야 합니다.

CA 신뢰 저장소 업데이트 전파

발급자 힌트를 사용하도록 설정하고 신뢰 상태에서 CA를 추가, 업데이트 또는 삭제하면 발급자 힌트를 클라이언트로 다시 전파하는 데 최대 10분이 지연됩니다. 힌트가 전파될 때까지 사용자는 새 CA에서 발급한 인증서로 인증할 수 없습니다.

인증 정책 관리자는 발급자 힌트가 전파를 시작할 수 있도록 설정한 후 인증서로 로그인해야 합니다. CA 신뢰 저장소 업데이트가 전파될 때 사용자에게 아래 오류 메시지가 표시됩니다.

단일 단계 인증서 기반 인증을 사용하는 MFA

Microsoft Entra CBA는 인증을 위한 첫 번째 요소와 거의 없는 요소로 지원됩니다. 지원되는 조합 중 일부는 다음과 같습니다.

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

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

단일 요소 인증서를 사용하여 MFA 기능을 가져오는 옵션

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

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

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

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

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

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

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

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 인증 방법에 매핑하는 설명서를 참조하세요.

다단계 인증서 인증

사용자에게 다단계 인증서가 있는 경우 인증서로만 다단계 인증을 수행할 수 있습니다. 인증 정책 관리자는 인증서가 다단계로 간주되도록 PIN 또는 생체 인식으로 보호되는지 확인해야 합니다.

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

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

1. 발급자 + 정책 OID 규칙이 정책 OID 규칙보다 우선합니다. 정책 OID 규칙은 인증서 발급자 규칙보다 우선합니다.
2. 발급자 + 정책 OID 규칙이 먼저 평가됩니다. 발급자 CA1 및 정책 OID 1.2.3.4.5와 MFA가 포함된 사용자 지정 규칙이 있는 경우, 발급자 값 및 정책 OID를 모두 충족하는 인증서 A에만 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 모두에 바인딩할 수 없음).

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

사용자 이름 바인딩 정책은 사용자 인증서의 유효성을 검사하는 데 도움이 됩니다. 기본적으로 인증서의 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	낮은 선호도
Subject(미리 보기)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	낮은 선호도
SKI	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	certificateUserIds	높은 선호도
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR	certificateUserIds	높은 선호도
IssuerAndSerialNumber(미리 보기)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT 일련 번호의 올바른 값을 가져오려면 이 명령을 실행하고 CertificateUserIds에 표시된 값을 저장합니다. 구문: Certutil –dump –v [~certificate path~] >> [~dumpFile path~] 예: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	높은 선호도

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

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

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

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

1. 사용자 이름 또는 사용자 계정 이름을 사용하여 사용자 개체를 조회합니다.
2. ‘우선 순위’ 특성에 따라 정렬된 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는 사용자 이름 바인딩 정책에서 여러 바인딩 방법을 지원하여 인증 정책 관리자가 하나의 인증서를 여러 Microsoft Entra 사용자 계정 구성에 수용할 수 있습니다.

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

하나의 Microsoft Entra 사용자 계정으로 여러 인증서 지원(M:1)

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

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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

여러 Microsoft Entra 사용자 계정으로 하나의 인증서 지원(1:M)

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

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

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

사용자 이름 바인딩:

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

사용자 계정 CertificateUserIds 값:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

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

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

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

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

포리스트 1 - Account1(bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

포리스트 1 - Account2(bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

포리스트 2 - ADAccount1(bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

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

certificateUserIds에 동기화하기 위한 단계

1. alternativeSecurityIds 필드를 메타버스에 추가하도록 Microsoft Entra Connect 구성
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로 설정합니다. 그렇지 않으면 계정은 기본 사례에 속하며 이 예에서는 Issuer + SerialNumber 매핑으로만 필터링합니다. 키 특성이 채워지면 해당 값이 정의된 사용자 유형 중 하나와 동일한지 확인합니다. 이 예에서는 해당 값이 지원 담당자인 경우 altSecurityIdentities에서 SHA1PublicKey 값으로 필터링합니다. 값이 개발자인 경우 altSecurityIdentities에서 SubjectKeyIssuer 값으로 필터링합니다. 특정 유형의 인증서 값이 여러 개 있을 수 있습니다. 예를 들어 여러 PrincipalName 값, 여러 SKI 또는 SHA1-PUKEY 값이 있을 수 있습니다. 필터는 처음 찾은 값만 가져오는 것이 아니라 모든 값을 가져와서 Microsoft 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를 채우는 이전 또는 후속 규칙이 무시되고 Microsoft Entra ID에서 결과가 비어 있게 됩니다.

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

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

인증서 해지 프로세스 이해

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

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

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

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

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

오류가 발생한 후 Microsoft Entra ID는 서비스 쪽 제한(퍼블릭 Microsoft Entra ID의 경우 45MB, Azure 미국 정부 클라우드의 경우 150MB)에 따라 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에 해지된 것으로 나열됩니다.

     

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

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

해지를 구성하는 방법

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

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

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

다음 단계에서는 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 명령으로 지정된 날짜 아님)으로 설정됩니다.

CRL 유효성 검사 이해(미리 보기)

CRL은 CA(인증 기관)에 의해 유효 기간이 끝나기 전에 해지된 디지털 인증서의 레코드입니다. CA가 Microsoft Entra 신뢰 저장소에 업로드되는 경우 CRL 또는 더 구체적으로 CrlDistributionPoint 특성은 필요하지 않습니다. CRL 엔드포인트 없이 CA를 업로드할 수 있으며 발급 CA에 CRL이 지정되지 않은 경우 인증서 기반 인증이 실패하지 않습니다.

보안을 강화하고 잘못된 구성을 방지하기 위해 인증 정책 관리자는 최종 사용자 인증서를 발급하는 CA에 대해 CRL이 구성되지 않은 경우 CBA 인증이 실패하도록 요구할 수 있습니다.

CRL 유효성 검사 사용

CRL 유효성 검사를 사용하도록 설정하려면 CRL 유효성 검사 필요(권장)를 클릭합니다.

사용하도록 설정하면, 최종 사용자 인증서가 CRL이 구성되지 않은 CA에서 발급된 경우 모든 CBA가 실패합니다.

인증 정책 관리자는 CRL에 수정해야 하는 문제가 있는 경우 CA를 제외할 수 있습니다. 예외 추가를 클릭하고 제외해야 하는 CA를 선택합니다.

제외된 목록의 CA는 CRL을 구성할 필요가 없으며 발급한 최종 사용자 인증서는 인증에 실패하지 않습니다.

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. 로그인을 검색하고 선택합니다.

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

   

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

   

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

   

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

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

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

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

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

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

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

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

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

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

외부 ID 지원

외부 ID B2B 게스트 사용자는 홈 테넌트에서 CBA를 사용할 수 있으며, 리소스 테넌트에 대한 교차 테넌트 설정이 홈 테넌트에서 MFA를 신뢰하도록 설정된 경우 홈 테넌트에 대한 사용자의 CBA 인증이 적용됩니다. Microsoft Entra 테넌트에서 다단계 인증 신뢰를 사용하도록 설정하는 방법에 대한 자세한 내용은 B2B 협업 테넌트 간 액세스 구성을 참조하세요. 리소스 테넌트에 대한 CBA는 아직 지원되지 않습니다.

다음 단계

• Microsoft Entra CBA 개요
• Microsoft Entra CBA 구성 방법
• iOS 디바이스의 Microsoft Entra CBA
• Android 디바이스의 Microsoft Entra CBA
• Microsoft Entra CBA를 사용한 Windows 스마트 카드 로그온
• 인증서 사용자 ID
• 페더레이션된 사용자를 마이그레이션하는 방법
• FAQ
• Microsoft Entra CBA 문제 해결