Microsoft Entra 인증서 기반 인증 기술 개념

이 문서에서는 Microsoft Entra CBA(인증서 기반 인증)의 작동 방식을 설명하는 기술 개념을 설명합니다. 테넌트에서 Microsoft Entra CBA를 설정하고 관리하는 방법을 더 잘 알고 있는 기술 배경을 확인하세요.

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

다음 그림에서는 사용자가 Microsoft Entra CBA가 구성된 테넌트에서 애플리케이션에 로그인하려고 할 때 발생하는 일을 보여 줍니다.

다음 단계에서는 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를 ID 공급자로 사용하는 애플리케이션에 대해 성공적으로 인증할 수 있습니다.

   

   전화 로그인 또는 보안 키와 같은 다른 인증 방법을 사용할 수 있게 하는 경우 사용자에게 다른 로그인 대화 상자가 표시될 수 있습니다.

   

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

   엔드포인트는 TLS(전송 계층 보안) 상호 인증을 수행하고 TLS 핸드셰이크의 일부로 클라이언트 인증서를 요청합니다. 이 요청에 대한 항목이 로그인 로그에 표시됩니다.

   참고

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

   TLS 검사를 해제하는 것이 새 URL을 사용하는 발급자 힌트에도 작동하는지 확인합니다. 테넌트 ID를 사용하여 URL을 하드 코딩하지 마세요. B2B(Business-to-Business) 사용자의 경우 테넌트 ID가 변경될 수 있습니다. 정규식을 사용하여 TLS 검사를 해제할 때 이전 URL과 새 URL이 모두 작동할 수 있도록 합니다. 예를 들어, 프록시에 따라 *.certauth.login.microsoftonline.com 또는 *certauth.login.microsoftonline.com을 사용합니다. Azure Government에서는 *.certauth.login.microsoftonline.us 또는 *certauth.login.microsoftonline.us를 사용합니다.

   액세스가 허용되지 않는 한 발급자 힌트를 켜면 CBA가 실패합니다.

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

   

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

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

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

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

발급자 힌트(미리 보기)

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

발급자 힌트 켜기

발급자 힌트를 켜려면 발급자 힌트 확인란을 선택합니다. 인증 정책 관리자는 TLS 검사가 설정된 프록시가 올바르게 업데이트되었는지 확인한 후 I Acknowledge를 선택한 다음 변경 내용을 저장해야 합니다.

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

발급자 힌트를 켜고 트러스트 저장소에서 CA를 추가, 업데이트 또는 삭제하면 발급자 힌트가 클라이언트로 다시 전파되는 동안 최대 10분의 지연이 발생할 수 있습니다. 인증 정책 관리자는 전파를 시작하는 데 발급자 힌트를 사용할 수 있게 된 후 인증서로 로그인해야 합니다.

힌트가 전파될 때까지 사용자는 새 CA에서 발급한 인증서를 사용하여 인증할 수 없습니다. CA 트러스트 저장소 업데이트가 전파될 때 사용자에게 다음 오류 메시지가 표시됩니다.

단일 요소 CBA를 사용하는 MFA

Microsoft Entra CBA는 1단계 인증 및 2단계 인증을 모두 사용할 수 있습니다.

지원되는 몇 가지 조합은 다음과 같습니다.

• CBA(첫 번째 요소) 및 암호 (두 번째 요소)
• CBA(첫 번째 요소) 및 암호 없는 전화 로그인 (두 번째 요소)
• CBA(첫 번째 요소) 및 FIDO2 보안 키 (두 번째 요소)
• 암호(첫 번째 요소) 및 CBA(두 번째 요소)

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

CBA가 활성화된 상태에서 MFA 기능을 취득할 수 있는 옵션

Microsoft Entra CBA는 테넌트 구성에 따라 단일 요소 또는 다단계일 수 있습니다. CBA를 켜면 사용자가 잠재적으로 MFA를 완료할 수 있습니다. 단일 요소 인증서 또는 암호가 있는 사용자는 다른 요소를 사용하여 MFA를 완료해야 합니다.

먼저 MFA를 충족하지 않고는 다른 메서드의 등록을 허용하지 않습니다. 사용자에게 다른 MFA 메서드가 등록되어 있지 않고 CBA의 범위에 있는 경우 사용자는 ID 증명을 사용하여 다른 인증 방법을 등록하고 MFA를 가져올 수 없습니다.

CBA 지원 사용자에게 단일 요소 인증서만 있고 MFA를 완료해야 하는 경우 다음 옵션 중 하나를 선택하여 사용자를 인증합니다.

• 사용자는 암호를 입력하고 단일 요소 인증서를 사용할 수 있습니다.
• 인증 정책 관리자는 임시 액세스 패스를 발급할 수 있습니다.
• 인증 정책 관리자는 전화 번호를 추가하고 사용자 계정에 대한 음성 또는 문자 메시지 인증을 허용할 수 있습니다.

CBA 지원 사용자에게 인증서가 발급되지 않았고 MFA를 완료해야 하는 경우 다음 옵션 중 하나를 선택하여 사용자를 인증합니다.

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

CBA 지원 사용자가 스마트 카드 지원 없이 모바일 디바이스를 사용하지만 MFA를 완료해야 하는 경우와 같이 다단계 인증서를 사용할 수 없는 경우 다음 옵션 중 하나를 선택하여 사용자를 인증합니다.

• 인증 정책 관리자는 임시 액세스 패스를 발급할 수 있습니다.
• 사용자가 다른 MFA 메서드를 등록할 수 있습니다 (사용자가 디바이스에서 다단계 인증서를 사용할 수 있는 경우).
• 인증 정책 관리자는 전화 번호를 추가하고 사용자 계정에 대한 음성 또는 문자 메시지 인증을 허용할 수 있습니다.

CBA를 사용하여 암호 없는 전화 로그인 설정

암호 없는 휴대폰 로그인이 작동하려면 먼저 사용자의 모바일 앱을 통해 레거시 알림을 끕니다.

1. Microsoft Entra 관리 센터에 인증 정책 관리자 이상으로 로그인합니다.

2. 암호 없는 휴대폰 로그인 인증 사용에서 설명하는 단계를 완료합니다.

   중요

   암호 없는 옵션을 선택해야 합니다. 암호 없는 휴대폰 로그인에 추가하는 그룹의 경우 인증 모드 의 값을 암호 없는 값으로 변경해야 합니다. Any를 선택하면 CBA 및 암호 없는 로그인이 작동하지 않습니다.

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

   

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

   

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

단일 요소 인증서가 있고 암호 없는 로그인용으로 구성된 사용자의 예를 생각해 보세요. 사용자는 다음 단계를 완료합니다.

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

   

2. 인증서 또는 스마트 카드 사용을 선택합니다.

   

   전화 로그인 또는 보안 키와 같은 다른 인증 방법을 사용할 수 있게 하는 경우 사용자에게 다른 로그인 대화 상자가 표시될 수 있습니다.

   

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

   

4. 인증서가 단일 단계 인증의 강도로 구성되었으므로 MFA 요구 사항을 충족하려면 두 번째 요소가 필요합니다. 사용 가능한 두 번째 요소는 로그인 대화 상자에 표시됩니다. 이 경우 암호 없는 로그인입니다. Microsoft Authenticator 앱에서 요청 승인을 선택합니다.

   

5. 휴대폰에서 알림을 받습니다. 로그인 승인을 선택하시겠습니까?

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

   

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

인증 바인딩 정책

인증 바인딩 정책은 인증 강도를 단일 요소 또는 다단계로 설정하는 데 도움이 됩니다. 인증 정책 관리자는 기본 메서드를 단일 요소에서 다단계로 변경할 수 있습니다. 관리자는 인증서를 사용IssuerAndSubjectPolicyOID하거나 IssuerPolicyOID 인증서에서 사용자 지정 정책 구성을 설정할 수도 있습니다.

인증서 강도

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

다단계 인증서 인증

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

여러 인증 정책 바인딩 규칙

여러 인증서 특성을 사용하여 여러 사용자 지정 인증 바인딩 정책 규칙을 만들 수 있습니다. 예를 들어 발급자 및 정책 OID를 사용하거나 정책 OID 또는 발급자만 사용하는 것이 있습니다.

다음 시퀀스는 사용자 지정 규칙이 겹칠 때 인증 보호 수준을 결정합니다.

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

사용자 이름 바인딩 정책

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

인증서 바인딩을 사용하여 보안 강화

Microsoft Entra는 인증서 바인딩을 사용하는 7가지 방법을 지원합니다. 일반적으로 매핑 형식은 (SubjectKeyIdentifier) 또는 SKI.와 같이 다시 사용할 수 없는 식별자를 기반으로 하는 경우 높은 선호도로 SHA1PublicKey 간주됩니다. 이러한 식별자는 단일 인증서만 사용하여 사용자를 인증할 수 있다는 높은 보증을 전달합니다.

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

선호도 바인딩 정의 및 재정의

인증 정책 관리자는 사용자가 낮은 선호도 또는 높은 선호도 사용자 이름 바인딩 매핑을 사용하여 인증할 수 있는지 여부를 구성할 수 있습니다.

모든 사용자에게 적용되는 테넌트에 대한 필수 선호도 바인딩 을 설정합니다. 테넌트 전체 기본값을 재정의하려면 발급자 및 정책 OID 또는 정책 OID 또는 발급자만 기반으로 사용자 지정 규칙을 만듭니다.

여러 사용자 이름 정책 바인딩 규칙

여러 사용자 이름 정책 바인딩 규칙을 해결하기 위해 Microsoft Entra ID는 가장 높은 우선 순위(가장 낮은 수) 바인딩을 사용합니다.

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

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

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

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

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

일부 시나리오에서는 조직에서 단일 ID에 대해 여러 인증서를 발급합니다. 모바일 디바이스에 대한 파생 자격 증명일 수도 있지만 보조 스마트 카드 또는 X.509 자격 증명 보유자 지원 디바이스(예: YubiKey)에 대한 자격 증명일 수도 있습니다.

클라우드 전용 계정(M:1)

클라우드 전용 계정의 경우 필드를 고유한 값으로 채워 certificateUserIds 각 인증서를 식별하는 데 사용할 인증서를 최대 5개까지 매핑할 수 있습니다. 인증서를 매핑하려면 관리 센터에서 권한 부여 정보 탭으로 이동합니다.

조직에서 높은 선호도 바인딩(예: IssuerAndSerialNumber선호도)을 사용하는 경우 다음 예제와 같은 값 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 사용자 이름 바인딩이 특정 바인딩 형식을 찾기 위해 필드를 가리키 certificateUserIds 도록 설정된 경우(이 예제 IssuerAndSerialNumber에서는) 사용자가 성공적으로 로그인합니다.

하이브리드 동기화된 계정(M:1)

동기화된 계정의 경우 여러 인증서를 매핑할 수 있습니다. 온-프레미스 Active Directory에서 각 인증서를 altSecurityIdentities 식별하는 값으로 필드를 채웁니다. 조직에서 높은 선호도 바인딩(즉, 강력한 인증) IssuerAndSerialNumber을 사용하는 경우 값은 다음 예와 같을 수 있습니다.

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로 인증해야 합니다. 관리 계정 또는 개발자 또는 임시 의무 계정용일 수 있습니다.

온-프레미스 Active Directory altSecurityIdentities 에서 필드는 인증서 값을 채웁니다. 로그인하는 동안 로그인을 확인하기 위해 Active Directory를 의도한 계정으로 보내기 위해 힌트가 사용됩니다.

Microsoft Entra CBA에는 다른 프로세스가 있으며 힌트가 포함되지 않습니다. 대신 홈 영역 검색은 의도한 계정을 식별하고 인증서 값을 확인합니다. 또한 Microsoft Entra CBA는 필드에서 고유성을 certificateUserIds 적용합니다. 두 계정은 동일한 인증서 값을 채울 수 없습니다.

클라우드 전용 계정(1:M)

클라우드 전용 계정의 경우 여러 사용자 이름 바인딩을 만들고 인증서를 사용하는 각 사용자 계정에 고유 값을 매핑합니다. 각 계정에 대한 액세스는 다른 사용자 이름 바인딩을 사용하여 인증됩니다. 이 인증 수준은 단일 디렉터리 또는 테넌트 경계에 적용됩니다. 인증 정책 관리자는 값이 계정별로 고유하게 유지되는 경우 인증서를 다른 디렉터리 또는 테넌트에서 사용하도록 매핑할 수 있습니다.

인증서를 certificateUserIds 식별하는 고유한 값으로 필드를 채웁니다. 필드를 채웁니다. 관리 센터에서 권한 부여 정보 탭으로 이동합니다.

조직에서 높은 선호도 바인딩(즉, 강력한 인증) IssuerAndSerialNumber 을 사용하는 경우 값은 다음 예제와 SKI같이 표시될 수 있습니다.

사용자 이름 바인딩:

• IssuerAndSerialNumber > certificateUserIds
• SKI > certificateUserIds

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

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

하이브리드 동기화된 계정(1:M)

동기화된 계정에는 다른 접근 방식이 필요합니다. 인증 정책 관리자는 인증서를 사용하는 각 사용자 계정에 고유 값을 매핑할 수 있지만 Microsoft Entra ID의 각 계정에 모든 값을 채우는 일반적인 방법은 이 접근 방식을 어렵게 만듭니다. 대신 Microsoft Entra Connect는 계정당 값을 Microsoft Entra ID의 계정에 채워진 고유한 값으로 필터링해야 합니다. 고유성 규칙은 단일 디렉터리 또는 테넌트 경계에 적용됩니다. 인증 정책 관리자는 값이 계정별로 고유하게 유지되는 경우 인증서를 다른 디렉터리 또는 테넌트에서 사용하도록 매핑할 수 있습니다.

조직에는 단일 Microsoft Entra 테넌트에 사용자를 기여하는 여러 Active Directory 포리스트가 있을 수도 있습니다. 이 경우 Microsoft Entra Connect는 클라우드 계정에 특정 고유 값만 채우라는 동일한 목표를 가진 각 Active Directory 포리스트에 필터를 적용합니다.

Active Directory의 altSecurityIdentities 필드를 인증서를 식별하는 값으로 채웁다. 해당 사용자 계정 유형(예: detailed, admin또는 developer)에 대한 특정 인증서 값을 포함합니다. Active Directory에서 키 특성을 선택합니다. 이 특성은 사용자가 평가하는 사용자 계정 유형(예: msDS-cloudExtensionAttribute1)을 동기화에 지시합니다. 이 특성을 사용하려는 사용자 유형 값(예: , detailed또는 admin.)으로 developer채웁다. 계정이 사용자의 기본 계정인 경우 값은 비어 있거나 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. 각 온-프레미스 Active Directory 포리스트에 대해 높은 우선 순위(낮은 숫자, 100 미만)로 새 사용자 지정 인바운드 규칙을 구성합니다. Expression 필드를 원본으로 사용하여 altSecurityIdentities 변환을 추가합니다. 대상 식은 선택한 키 특성을 사용하고 사용자가 정의한 사용자 유형에 대한 매핑을 사용합니다.

예시:

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-cloudExtensionAttribute1 이 채워져 있는지 먼저 확인합니다. 채워지지 않은 경우 채워 altSecurityIdentities 지는지 확인합니다. 비어 있는 경우 NULL로 설정합니다. 그렇지 않으면 계정이 기본 시나리오입니다.

또한 이 예제에서는 매핑에 대해서만 필터링합니다 IssuerAndSerialNumber . 키 특성이 채워지면 값이 정의된 사용자 유형 중 하나와 같은지 확인합니다. 이 예제에서 해당 값이detailed면 .에서 SHA1PublicKey값을 필터링 altSecurityIdentities 합니다. 값이developer면 .에서 SubjectKeyIssuer값을 필터링 altSecurityIdentities 합니다.

특정 형식의 여러 인증서 값이 발생할 수 있습니다. 예를 들어 여러 값이나 여러 PrincipalNameSKI 값 또는 SHA1-PUKEY 값이 표시될 수 있습니다. 필터는 모든 값을 가져오고 처음 찾은 값뿐만 아니라 Microsoft Entra ID로 동기화합니다.

컨트롤 특성이 비어 있는 경우 빈 값을 푸시하는 방법을 보여 주는 두 번째 예제는 다음과 같습니다.

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 유효성을 검사하면 사용자가 성공적으로 로그인됩니다.

CA(인증 기관) 범위 지정(미리 보기)

Microsoft Entra의 CA 범위를 지정하면 테넌트 관리자가 특정 CA의 사용을 정의된 사용자 그룹으로 제한할 수 있습니다. 이 기능은 권한이 있는 사용자만 특정 CA에서 발급한 인증서를 사용하여 인증할 수 있도록 하여 CBA의 보안 및 관리 효율성을 향상시킵니다.

CA 범위 지정은 여러 사용자 모집단에서 여러 CA가 사용되는 다중 PKI 또는 B2B 시나리오에서 유용합니다. 의도하지 않은 액세스를 방지하고 조직 정책 준수를 지원합니다.

주요 이점

• 인증서 사용을 특정 사용자 그룹으로 제한
• 여러 CA를 통해 복잡한 PKI 환경 지원
• 인증서 오용 또는 손상에 대한 향상된 보호 제공
• 로그인 로그 및 모니터링 도구를 통해 CA 사용량에 대한 가시성을 제공합니다.

관리자는 CA 범위 지정을 사용하여 CA(해당 SKI로 식별됨)를 특정 Microsoft Entra 그룹과 연결하는 규칙을 정의할 수 있습니다. 사용자가 인증서를 사용하여 인증을 시도하면 시스템에서 인증서 발급 CA가 사용자를 포함하는 그룹으로 범위가 지정되는지 여부를 확인합니다. Microsoft Entra는 CA 체인을 진행합니다. 사용자가 모든 범위 규칙의 그룹 중 하나에서 찾을 때까지 모든 범위 규칙을 적용합니다. 사용자가 범위가 지정된 그룹에 있지 않으면 인증서가 유효하지 않더라도 인증이 실패합니다.

CA 범위 지정 기능 설정

1. Microsoft Entra 관리 센터에 인증 정책 관리자 이상으로 로그인합니다.

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

3. 구성에서 인증서 발급자 범위 지정 정책으로 이동합니다.

   

4. 규칙 추가를 선택합니다.

   

5. PKI별로 CA 필터링을 선택합니다.

   클래식 CA는 클래식 CA 저장소의 모든 CA를 표시합니다. 특정 PKI를 선택하면 선택한 PKI의 모든 CA가 표시됩니다.

6. PKI를 선택합니다.

   

7. 인증서 발급자 목록에는 선택한 PKI의 모든 CA가 표시됩니다. 범위 규칙을 만들 인증 기관(CA)을 선택합니다.

   

8. 그룹 추가를 선택합니다.

   

9. 그룹을 선택합니다.

   

10. 추가를 선택하여 규칙을 저장합니다.

    

11. 승인 확인란을 선택한 다음 저장을 선택합니다.

    

12. CA 범위 지정 정책을 편집하거나 삭제하려면 "..." 규칙 행에 있습니다. 규칙을 편집하려면 편집을 선택합니다. 규칙을 삭제하려면 삭제를 선택합니다.

    

알려진 제한 사항

• CA당 하나의 그룹만 할당할 수 있습니다.
• 최대 30개 범위 지정 규칙이 지원됩니다.
• 범위 지정은 중간 CA 수준에서 적용됩니다.
• 잘못된 구성으로 인해 유효한 범위 지정 규칙이 없는 경우 사용자 잠금이 발생할 수 있습니다.

로그인 로그 항목

• 로그인 로그에 성공이 표시됩니다. 추가 세부 정보 탭에 범위 지정 정책 규칙의 CA SKI가 나타납니다.

  

• CA 범위 지정 규칙으로 인해 CBA가 실패하면 로그인 로그의 기본 정보 탭에 500189 오류 코드가 표시됩니다.

  

  최종 사용자에게는 다음과 같은 오류 메시지가 표시됩니다.

  

CBA가 조건부 액세스 인증 강도 정책과 작동하는 방식

기본 제공 Microsoft Entra Phishing 내성 MFA 인증 강도를 사용하여 CBA를 사용하여 리소스에 액세스하도록 지정하는 조건부 액세스 인증 정책을 만들 수 있습니다. 이 정책은 CBA, FIDO2 보안 키 및 비즈니스용 Windows Hello와 같이 피싱에 강한 인증 방법만 허용합니다.

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

고급 옵션의 CBA 강도

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

로그인 로그

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

다음으로, 두 가지 시나리오를 고려합니다. 한 시나리오에서 인증서는 단일 단계 인증을 충족합니다. 두 번째 시나리오에서 인증서는 MFA를 충족합니다.

테스트 시나리오의 경우 MFA가 필요한 조건부 액세스 정책이 있는 사용자를 선택합니다.

주체 대체 이름 및 보안 주체 이름을 사용자 개체에 매핑하여 userPrincipalName 사용자 바인딩 정책을 구성합니다.

사용자 인증서는 다음 스크린샷에 표시된 예제와 같이 구성되어야 합니다.

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

로그인 로그는 일반적으로 로그인 문제를 디버그하는 데 필요한 모든 정보를 제공하지만 특정 값이 필요한 경우도 있습니다. 로그인 로그는 동적 변수를 지원하지 않으므로 경우에 따라 로그인 로그에 디버깅에 필요한 정보가 없습니다.

예를 들어 로그인 로그의 실패 원인은 이 시나리오"The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration."에서 표시 <expectedSKI> 될 수 있으며 <crlAKI> 올바른 값으로 채워지지 않습니다.

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

단일 요소 인증 테스트

첫 번째 테스트 시나리오의 경우 규칙이 단일 단계 인증을 IssuerAndSubject 충족하는 인증 정책을 구성합니다.

1. CBA를 사용하여 테스트 사용자로 Microsoft Entra 관리 센터에 로그인합니다. 규칙이 단일 단계 인증을 IssuerAndSubject 충족하는 인증 정책이 설정됩니다.

2. 로그인 로그를 검색한 다음 선택합니다.

   다음 그림에서는 로그인 로그에서 찾을 수 있는 일부 항목을 보여 줍니다.

   첫 번째 항목은 사용자에게 X.509 인증서를 요청합니다. 중단 상태는 Microsoft Entra ID가 CBA가 테넌트에 대해 설정되어 있는지 확인했음을 의미합니다. 인증을 위해 인증서가 요청됩니다.

   

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

   

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

   

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

   

MFA 테스트

다음 테스트 시나리오의 경우 규칙이 MFA를 충족하는 policyOID 인증 정책을 구성합니다.

1. CBA를 사용하여 Microsoft Entra 관리 센터에 로그인합니다 . 정책이 MFA를 충족하도록 설정되었으므로 사용자 로그인은 두 번째 요소 없이 성공합니다.

2. 로그인을 검색한 다음 선택합니다.

   중단된 상태의 항목을 포함하여 로그인 로그에 여러 항목이 표시됩니다.

   

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

   

   중단 상태가 있는 항목은 추가 세부 정보 탭에 추가 진단 정보를 표시합니다.

   

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

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

CBA 오류 페이지

CBA는 여러 가지 이유로 실패할 수 있습니다. 예를 들어 잘못된 인증서, 사용자가 잘못된 인증서 또는 만료된 인증서를 선택했거나 CRL 문제가 발생합니다. 인증서 유효성 검사에 실패하면 사용자에게 다음 오류 메시지가 표시됩니다.

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

1. 로그인 로그에서 자세한 내용을 보려면 인증 정책 관리자에게 보낼 로깅 정보를 얻으려면 자세한 내용을 선택합니다.

   

2. 로그인하는 다른 방법을 선택하고 사용 가능한 다른 인증 방법을 사용하여 로그인합니다.

   

Microsoft Edge에서 인증서 선택 다시 설정

Microsoft Edge 브라우저는 브라우저를 다시 시작 하지 않고 인증서 선택을 다시 설정하는 기능을 추가했습니다.

사용자는 다음 단계를 완료합니다.

1. CBA가 실패하면 오류 페이지가 나타납니다.

   

2. 주소 URL의 왼쪽에서 잠금 아이콘을 선택한 다음 인증서 선택 항목을 선택합니다.

   

3. 인증서 다시 설정을 선택합니다.

   

4. 다시 설정 선택 항목을 선택합니다.

   

5. 로그인하는 다른 방법을 선택합니다.

   

6. 인증서 또는 스마트 카드 사용을 선택하고 CBA 인증을 계속합니다.

MostRecentlyUsed 메서드의 CBA

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

MRU 메서드를 다시 설정하려면 인증서 선택기를 취소한 다음 로그인하는 다른 방법을 선택합니다. 사용 가능한 다른 방법을 선택한 다음 인증을 완료합니다.

MRU 인증 방법은 사용자 수준에서 설정됩니다. 사용자가 다른 인증 방법을 사용하여 다른 디바이스에 성공적으로 로그인하면 MRU가 현재 로그인된 방법으로 다시 설정됩니다.

외부 ID 지원

외부 ID B2B 게스트 사용자는 홈 테넌트에서 CBA를 사용할 수 있습니다. 리소스 테넌트에 대한 테넌트 간 설정이 홈 테넌트에서 MFA를 신뢰하도록 설정된 경우 홈 테넌트의 사용자 CBA가 적용됩니다. 자세한 내용은 B2B 협업 테넌트 간 액세스 구성을 참조하세요. 현재 리소스 테넌트의 CBA는 지원되지 않습니다.

관련 콘텐츠

• Microsoft Entra CBA 개요
• Microsoft Entra CBA 설정
• Microsoft Entra CBA 인증서 해지 목록
• iOS 디바이스의 Microsoft Entra CBA
• Microsoft Entra CBA Android 디바이스에서
• Microsoft Entra CBA를 사용하여 Windows 스마트 카드 로그인
• 인증서 사용자 ID
• 페더레이션된 사용자 마이그레이션
• 자주 묻는 질문(FAQ)
• Microsoft Entra CBA 문제 해결