인증서 요구 사항 및 열거

• 적용 대상:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

IT 전문가 및 스마트 카드 개발자를 위한 이 항목에서는 인증서를 관리하고 스마트 카드 로그인에 사용하는 방법을 설명합니다.

스마트 카드를 삽입하면 다음 단계가 수행됩니다.

참고

달리 언급하지 않는 한 모든 작업은 자동으로 수행됩니다(CRYPT_SILENT CryptAcquireContext에 전달됨).

1. 스마트 카드 리소스 관리자 데이터베이스는 스마트 카드의 CSP(암호화 서비스 공급자)를 검색합니다.

2. 정규화된 컨테이너 이름은 스마트 카드 판독기 이름을 사용하여 생성되며 CSP에 전달됩니다. 형식은 입니다. \\.<Reader name>\

3. CryptAcquireContext는 기본 컨테이너에 대한 컨텍스트를 검색하기 위해 호출됩니다. 오류가 발생하면 스마트 카드 로그인에 스마트 카드를 사용할 수 없습니다.

4. 컨테이너의 이름은 CryptGetProvParam과 함께 PP_CONTAINER 매개 변수를 사용하여 검색됩니다.

5. 3단계에서 얻은 컨텍스트를 사용하여 CSP는 PP_USER_CERTSTORE 매개 변수에 대해 쿼리됩니다. 자세한 내용은 스마트 카드 아키텍처를 참조하세요. 작업이 성공하면 인증서 저장소의 이름이 반환되고 프로그램 흐름이 8단계로 건너뜁니다.

6. 5단계의 작업이 실패하면 3단계의 기본 컨테이너 컨텍스트가 AT_KEYEXCHANGE 키에 대해 쿼리됩니다.

7. 그런 다음 KP_CERTIFICATE 사용하여 키 컨텍스트에서 인증서를 쿼리합니다. 인증서가 메모리 내 인증서 저장소에 추가됩니다.

8. 5단계 또는 7단계의 인증서 저장소에 있는 각 인증서에 대해 다음 검사가 수행됩니다.

   1. 인증서는 컴퓨터 시스템 시계에 따라 유효해야 합니다(만료되지 않았거나 이후 날짜에 유효하지 않음).
   2. 인증서가 컨테이너의 AT_SIGNATURE 부분에 있지 않아야 합니다.
   3. 인증서에 유효한 UPN(사용자 계정 이름)이 있어야 합니다.
   4. 인증서에는 디지털 서명 키 사용량이 있어야 합니다.
   5. 인증서에 스마트 카드 로그온 EKU가 있어야 합니다.

   이러한 요구 사항을 충족하는 인증서는 인증서의 UPN(또는 인증서 확장의 존재 여부에 따라 전자 메일 주소 또는 제목)을 사용하여 사용자에게 표시됩니다.

9. 그런 다음 프로세스에서 인증서를 선택하고 PIN을 입력합니다.

10. LogonUI.exe 정보를 패키지하고 로그인 시도를 처리하기 위해 Lsass.exe 보냅니다.

11. 성공 LogonUI.exe 하면 닫힙니다. 이로 인해 3단계에서 획득한 컨텍스트가 해제됩니다.

Windows의 스마트 카드 로그인 흐름

인증 중 대부분의 문제는 세션 동작 변경으로 인해 발생합니다. 변경이 발생하면 LSA(로컬 보안 기관)는 세션 컨텍스트를 다시 문의하지 않습니다. 대신 암호화 서비스 공급자를 사용하여 세션 변경을 처리합니다.

인증서의 SAN() 필드에 UPN subjectAltName 을 포함하지 않는 클라이언트 인증서는 더 다양한 인증서를 지원하고 동일한 카드에서 여러 로그인 인증서를 지원하는 로그인에 사용할 수 있습니다.

동일한 카드의 여러 인증서에 대한 지원은 기본적으로 사용하도록 설정됩니다. 그룹 정책을 통해 새 인증서 유형을 사용하도록 설정해야 합니다.

로그온 자격 증명 공급자 정책에 유효한 서명 키 허용 정책을 사용하도록 설정하면 서명 전용 키가 있는 스마트 카드에서 사용할 수 있는 모든 인증서가 로그인 화면에 나열됩니다. 이렇게 하면 사용자가 로그인 환경을 선택할 수 있습니다. 정책을 사용하지 않도록 설정하거나 구성하지 않으면 스마트 카드 서명 키 기반 인증서가 로그인 화면에 나열되지 않습니다.

다음 다이어그램에서는 지원되는 Windows 버전에서 스마트 카드 로그인이 작동하는 방식을 보여 줍니다.

스마트 카드 로그인 흐름

스마트 카드 로그인 중에 수행되는 단계는 다음과 같습니다.

1. Winlogon이 로그인 UI 자격 증명 정보를 요청합니다.

2. 스마트 카드 리소스 관리자가 비동기적으로 시작되고 스마트 카드 자격 증명 공급자는 다음을 수행합니다.

   1. 자격 증명 정보(알려진 자격 증명 목록 또는 자격 증명이 없는 경우 Windows에서 검색한 스마트 카드 판독기 정보)를 가져옵니다.
   2. 스마트 카드 판독기 목록(WinSCard API 사용) 및 각 카드에 삽입된 스마트 카드 목록을 가져옵니다.
   3. 각 카드를 열거하여 그룹 정책에 의해 제어되는 로그인 인증서가 있는지 확인합니다. 인증서가 있는 경우 스마트 카드 자격 증명 공급자는 컴퓨터 또는 터미널의 임시 보안 캐시에 인증서를 복사합니다.

   참고

   스마트 카드 캐시 항목은 주체 이름 또는 주체 키 식별자가 있는 인증서에 대해 만들어집니다. 인증서에 주체 이름이 있는 경우 주체 이름 및 인증서 발급자를 기반으로 하는 인덱스와 함께 저장됩니다. 주체 이름과 인증서 발급자가 같은 다른 인증서를 사용하는 경우 기존 캐시된 항목을 대체합니다. 이 동작이 변경되면 인증서에 주체 이름이 없는 경우 주체 키 식별자 및 인증서 발급자를 기반으로 하는 인덱스를 사용하여 캐시가 만들어지는 조건을 허용합니다. 다른 인증서에 주체 키 식별자 및 인증서 발급자가 동일한 경우 캐시 항목이 대체됩니다. 인증서에 주체 이름이나 주체 키 식별자가 없는 경우 캐시된 항목이 만들어지지 않습니다.

   1. 로그인 UI에 새 자격 증명이 있음을 알 수 있습니다.

3. 로그인 UI는 스마트 카드 자격 증명 공급자로부터 새 자격 증명을 요청합니다. 이에 대한 응답으로 스마트 카드 자격 증명 공급자는 로그인 UI에 각 로그인 인증서를 제공하고 해당 로그인 타일이 표시됩니다. 사용자가 스마트 카드 기반 로그인 인증서 타일을 선택하고 Windows에 PIN 대화 상자가 표시됩니다.

4. 사용자가 PIN을 입력한 다음 Enter 키를 누릅니다. 스마트 카드 자격 증명 공급자는 PIN을 암호화합니다.

5. LogonUI 시스템에 있는 자격 증명 공급자는 PIN을 수집합니다. 스마트 카드 자격 증명 공급자의 자격 증명 패키징의 일부로 데이터는 KERB_CERTIFICATE_LOGON 구조로 패키징됩니다. KERB_CERTIFICATE_LOGON 구조의 주요 내용은 스마트 카드 PIN, CSP 데이터(예: 판독기 이름 및 컨테이너 이름), 사용자 이름 및 도메인 이름입니다. 로그인 도메인이 동일한 포리스트에 없는 경우 인증서를 여러 사용자 계정에 매핑할 수 있으므로 사용자 이름이 필요합니다.

6. 자격 증명 공급자는 데이터(예: 암호화된 PIN, 컨테이너 이름, 판독기 이름 및 카드 키 사양)를 래핑하고 LogonUI로 다시 보냅니다.

7. Winlogon은 LSALogonUser의 사용자 정보와 함께 LogonUI에서 LSA로 데이터를 제공합니다.

8. LSA는 Kerberos SSP(Kerberos 인증 패키지)를 호출하여 사전 인증자가 포함된 Kerberos 인증 서비스 요청(KRB_AS_REQ)을 만듭니다(RFC 4556: PKINIT(Kerberos의 초기 인증을 위한 공개 키 암호화).

   디지털 서명을 사용하는 인증서를 사용하여 인증을 수행하는 경우 사전 인증 데이터는 사용자의 공용 인증서와 해당 프라이빗 키로 디지털 서명된 인증서로 구성됩니다.

   키 암호화를 사용하는 인증서를 사용하여 인증을 수행하는 경우 사전 인증 데이터는 사용자의 공용 인증서와 해당 프라이빗 키로 암호화된 인증서로 구성됩니다.

9. RFC 4556에 따라 요청을 디지털로 서명하려면 프라이빗 키 작업을 위해 해당 CSP를 호출합니다. 이 경우 프라이빗 키가 스마트 카드에 저장되므로 스마트 카드 하위 시스템이 호출되고 필요한 작업이 완료됩니다. 결과는 Kerberos SSP(보안 지원 공급자)로 다시 전송됩니다.

10. Kerberos SSP는 TGT(Ticket-granting-ticket)(RFC 4556당)에 대한 인증 요청을 도메인 컨트롤러에서 실행되는 KDC(키 배포 센터) 서비스로 보냅니다.

11. KDC는 클라이언트 인증서 요구 사항 및 매핑에 자세히 설명된 대로 AD DS(Active Directory Domain Services)에서 사용자의 계정 개체를 찾아서 사용자의 인증서를 사용하여 서명을 확인합니다.

12. KDC는 사용자의 인증서(시간, 경로 및 해지 상태)의 유효성을 검사하여 인증서가 신뢰할 수 있는 원본에서 제공되었는지 확인합니다. KDC는 CryptoAPI를 사용하여 사용자의 인증서에서 도메인 컨트롤러의 루트 저장소에 있는 루트 CA(인증 기관) 인증서로의 인증 경로를 빌드합니다. 그런 다음 KDC는 CryptoAPI를 사용하여 사전 인증 데이터 필드에 포함된 서명된 인증자의 디지털 서명을 확인합니다. 도메인 컨트롤러는 서명을 확인하고 사용자 인증서의 공개 키를 사용하여 요청이 공개 키에 해당하는 프라이빗 키의 소유자로부터 시작되었음을 증명합니다. 또한 KDC는 발급자를 신뢰할 수 있고 NTAUTH 인증서 저장소에 표시되는지 확인합니다.

13. KDC 서비스는 AD DS에서 사용자 계정 정보를 검색합니다. KDC는 AD DS에서 검색하는 사용자 계정 정보를 기반으로 하는 TGT를 생성합니다. TGT의 권한 부여 데이터 필드에는 사용자 SID(보안 식별자), 사용자가 속한 범용 및 전역 도메인 그룹의 SID, 사용자가 멤버인 모든 범용 그룹에 대한 SID(다중 도메인 환경)가 포함됩니다.

14. 도메인 컨트롤러는 KRB_AS_REP 응답의 일부로 클라이언트에 TGT를 반환합니다.

    참고

    KRB_AS_REP 패킷은 다음으로 구성됩니다.

    • PAC(권한 특성 인증서)
    • 사용자의 SID
    • 사용자가 멤버인 모든 그룹의 SID
    • TGS(티켓 부여 서비스) 요청
    • 사전 인증 데이터

    TGT는 KDC의 마스터 키로 암호화되고 세션 키는 임시 키로 암호화됩니다. 이 임시 키는 RFC 4556을 기반으로 파생됩니다. CryptoAPI를 사용하면 임시 키가 암호 해독됩니다. 암호 해독 프로세스의 일부로 프라이빗 키가 스마트 카드에 있는 경우 지정된 CSP를 사용하여 사용자의 공개 키에 해당하는 인증서를 추출하여 스마트 카드 하위 시스템을 호출합니다. (인증서에 대한 프로그래밍 방식 호출에는 CryptAcquireContext, PIN을 사용한 CryptSetProvParam, CryptgetUserKey 및 CryptGetKeyParam이 포함됩니다.) 임시 키를 가져온 후 Kerberos SSP는 세션 키의 암호를 해독합니다.

15. 클라이언트는 KDC(시간, 경로 및 해지 상태)에서 회신의 유효성을 검사합니다. 먼저 KDC 인증서에서 신뢰할 수 있는 루트 CA로 인증 경로를 생성하여 KDC의 서명을 확인한 다음 KDC의 공개 키를 사용하여 회신 서명을 확인합니다.

16. 이제 TGT를 얻었으므로 클라이언트는 로컬 컴퓨터에 로그인하는 데 사용되는 서비스 티켓을 가져옵니다.

17. 성공하면 LSA는 티켓을 저장하고 LSALogonUser에 성공 메시지를 반환합니다. 이 성공 메시지가 실행되면 디바이스에 대한 사용자 프로필이 선택되고 설정되고 그룹 정책 새로 고침이 인스턴스화되고 다른 작업이 수행됩니다.

18. 사용자 프로필을 로드한 후 CertPropSvc(인증 전파 서비스)는 이 이벤트를 감지하고 스마트 카드(루트 인증서 포함)에서 인증서를 읽은 다음 MYSTORE(사용자 인증서 저장소)에 채웁니다.

19. CSP에서 스마트 카드로의 리소스 관리자 통신은 LRPC 채널에서 발생합니다.

20. 인증이 성공하면 인증서가 인증서 전파 서비스(CertPropSvc)에 의해 비동기적으로 사용자 저장소로 전파됩니다.

21. 카드를 제거하면 임시 보안 캐시 저장소의 인증서가 제거됩니다. 인증서는 더 이상 로그인에 사용할 수 없지만 사용자의 인증서 저장소에 남아 있습니다.

참고

로컬 보안 계정 데이터베이스 또는 AD DS 내에서 사용자 계정 또는 그룹 계정을 만들 때 각 사용자 또는 그룹에 대해 SID가 만들어집니다. 사용자 또는 그룹 계정의 이름이 변경되더라도 SID는 변경되지 않습니다.

Kerberos 프로토콜에 대한 자세한 내용은 Microsoft Kerberos를 참조하세요.

기본적으로 KDC는 클라이언트의 인증서에 스마트 카드 클라이언트 인증 EKU szOID_KP_SMARTCARD_LOGON 포함되어 있는지 확인합니다. 그러나 사용하도록 설정된 경우 확장된 키 사용 인증서 특성이 없는 인증서 허용 특성 그룹 정책 설정을 사용하면 KDC에서 SC-LOGON EKU가 필요하지 않을 수 있습니다. SC-LOGON EKU는 공개 키를 기반으로 하는 계정 매핑에 필요하지 않습니다.

KDC 인증서

Active Directory 인증서 서비스는 세 가지 종류의 인증서 템플릿을 제공합니다.

• 도메인 컨트롤러
• 도메인 컨트롤러 인증
• Kerberos 인증

도메인 컨트롤러의 구성에 따라 이러한 유형의 인증서 중 하나가 AS_REP 패킷의 일부로 전송됩니다.

클라이언트 인증서 요구 사항 및 매핑

인증서 요구 사항은 Windows 운영 체제 버전별로 나열됩니다. 인증서 매핑은 인증서의 정보가 사용자 계정에 매핑되는 방법을 설명합니다.

인증서 요구 사항

구성 요소	요구 사항
CRL 배포 지점 위치	필수 아님
주요 사용량	디지털 서명
기본 제약 조건	필수 아님
EKU(확장 키 사용)	스마트 카드 로그인 개체 식별자는 필요하지 않습니다. 메모 EKU가 있는 경우 스마트 카드 로그인 EKU를 포함해야 합니다. EKU가 없는 인증서는 로그인에 사용할 수 있습니다.
주체 대체 이름	스마트 카드 로그인에는 전자 메일 ID가 필요하지 않습니다.
주체	필수 아님
키 교환(AT_KEYEXCHANGE 필드)	그룹 정책 설정을 사용하는 경우 스마트 카드 로그인 인증서에는 필요하지 않습니다. (기본적으로 그룹 정책 설정은 사용하도록 설정되지 않습니다.)
CRL	필수 아님
UPN	필수 아님
참고	스마트 카드 자격 증명 공급자에 대해 모든 인증서를 표시하도록 설정할 수 있습니다.

클라이언트 인증서 매핑

인증서 매핑은 인증서의 SAN(subjectAltName) 필드에 포함된 UPN을 기반으로 합니다. SAN 필드에 정보가 없는 클라이언트 인증서도 지원됩니다.

SSL/TLS는 SAN이 없는 인증서를 매핑할 수 있으며, 매핑은 클라이언트 계정에서 AltSecID 특성을 사용하여 수행됩니다. SSL/TLS 클라이언트 인증에 사용되는 X509 AltSecID는 "X509: <Issuer Name><Subject Name형식입니다. 및 <Subject Name> 는 <Issuer Name> 클라이언트 인증서에서 가져와 '\r' 및 '\n'이 ','로 대체됩니다.

인증서 해지 목록 배포 지점

주체 대체 이름 필드의 UPN

주체 및 발급자 필드

이 계정 매핑은 6개의 다른 매핑 방법 외에도 KDC에서 지원됩니다. 다음 그림에서는 KDC에서 사용하는 사용자 계정 매핑 논리의 흐름을 보여 줍니다.

로그인을 위한 높은 수준의 인증서 처리 흐름

인증서 개체는 사용자 계정 매핑을 수행할 콘텐츠를 찾기 위해 구문 분석됩니다.

• 사용자 이름에 인증서가 제공되면 사용자 이름을 사용하여 계정 개체를 찾습니다. 문자열 일치가 발생하므로 이 작업이 가장 빠릅니다.
• 인증서 개체만 제공되면 사용자 이름을 찾기 위해 여러 작업이 수행되어 사용자 이름을 계정 개체에 매핑합니다.
• 인증에 사용할 수 있는 도메인 정보가 없는 경우 로컬 도메인은 기본적으로 사용됩니다. 조회에 다른 도메인을 사용하는 경우 매핑 및 바인딩을 수행하기 위해 도메인 이름 힌트를 제공해야 합니다.

인증서에서 특성을 검색할 제네릭 API가 없으므로 제네릭 특성을 기반으로 매핑할 수 없습니다. 현재 계정을 찾는 첫 번째 메서드는 검색을 성공적으로 중지합니다. 그러나 클라이언트가 매핑 힌트를 통해 클라이언트 이름을 제공하지 않을 때 두 메서드가 동일한 인증서를 다른 사용자 계정에 매핑하는 경우 구성 오류가 발생합니다.

다음 그림에서는 인증서의 다양한 항목을 확인하여 디렉터리에서 로그인하기 위해 사용자 계정을 매핑하는 프로세스를 보여 줍니다.

인증서 처리 논리

NT_AUTH 정책은 CertVerifyCertificateChainPolicy 함수의 CERT_CHAIN_POLICY_NT_AUTH 매개 변수 섹션에서 가장 잘 설명합니다. 자세한 내용은 CertVerifyCertificateChainPolicy를 참조하세요.

하나의 인증서가 여러 계정에 있는 단일 사용자에 대한 스마트 카드 로그인

단일 사용자 인증서를 여러 계정에 매핑할 수 있습니다. 예를 들어 사용자가 사용자 계정에 로그인하고 도메인 관리자로 로그인할 수도 있습니다. 매핑은 클라이언트 계정의 특성에 따라 생성된 AltSecID를 사용하여 수행됩니다. 이 매핑을 평가하는 방법에 대한 자세한 내용은 클라이언트 인증서 요구 사항 및 매핑을 참조하세요.

참고

각 계정에는 다른 사용자 이름이 있으므로 사용자 이름 힌트 그룹 정책 허용 설정(X509HintsNeeded 레지스트리 키)을 사용하도록 설정하여 사용자가 로그인할 사용자 이름 및 도메인 정보를 입력할 수 있는 선택적 필드를 제공하는 것이 좋습니다.

인증서에서 사용할 수 있는 정보에 따라 로그인 조건은 다음과 같습니다.

1. 인증서에 UPN이 없는 경우:
   1. 하나의 인증서를 가진 단일 사용자가 다른 계정에 로그인해야 하는 경우 로컬 포리스트 또는 다른 포리스트에서 로그인이 발생할 수 있습니다.
   2. 매핑이 고유하지 않은 경우(예: 여러 사용자가 동일한 인증서에 매핑되는 경우) 힌트를 제공해야 합니다.
2. 인증서에 UPN이 있는 경우:
   1. 동일한 포리스트의 여러 사용자에게 인증서를 매핑할 수 없습니다.
   2. 인증서는 서로 다른 포리스트의 여러 사용자에게 매핑될 수 있습니다. 사용자가 다른 포리스트에 로그인하려면 사용자에게 X509 힌트를 제공해야 합니다.

단일 계정으로 여러 사용자에 대한 스마트 카드 로그인

사용자 그룹은 단일 계정(예: 관리자 계정)에 로그인할 수 있습니다. 해당 계정의 경우 사용자 인증서가 로그인에 사용하도록 설정되도록 매핑됩니다.

여러 고유 인증서를 단일 계정에 매핑할 수 있습니다. 제대로 작동하려면 인증서에 UPN이 있을 수 없습니다.

예를 들어 Certificate1에 CN=CNName1이 있고 Certificate2에 CN=User1이 있고 Certificate3에 CN=User2가 있는 경우 Active Directory 사용자 및 컴퓨터 이름 매핑을 사용하여 이러한 인증서의 AltSecID를 단일 계정에 매핑할 수 있습니다.

포리스트에서 스마트 카드 로그인

계정 매핑이 포리스트 간에 작동하기 위해, 특히 인증서에서 사용할 수 있는 정보가 충분하지 않은 경우 사용자는 도메인\사용자와 같은 사용자 이름 또는 정규화된 UPN(예: user@contoso.com)의 형태로 힌트를 입력할 수 있습니다.

참고

스마트 카드 로그인 중에 힌트 필드가 표시되려면 클라이언트에서 사용자 이름 힌트 그룹 정책 허용 설정(X509HintsNeeded 레지스트리 키)을 사용하도록 설정해야 합니다.

PKINIT에 대한 OCSP 지원

RFC 2560에 정의된 OCSP(온라인 인증서 상태 프로토콜)를 사용하면 애플리케이션에서 인증서 해지 상태에 대한 적절한 정보를 얻을 수 있습니다. OCSP 응답은 작고 잘 바인딩되므로 제한된 클라이언트는 OCSP를 사용하여 KDC의 Kerberos에 대한 인증서의 유효성을 확인하고, 큰 CRL의 전송을 방지하고, 제한된 네트워크에서 대역폭을 저장할 수 있습니다. CRL 레지스트리 키에 대한 자세한 내용은 스마트 카드 그룹 정책 및 레지스트리 설정을 참조하세요.

Windows의 KDC는 OCSP 응답을 가져와 사용 가능한 경우 사용합니다. 이 동작은 사용하지 않도록 설정할 수 없습니다. OCSP용 CryptoAPI는 OCSP 응답 및 응답 상태를 캐시합니다. KDC는 서명자 인증서에 대한 OCSP 응답만 지원합니다.

Windows 클라이언트 컴퓨터는 OCSP 응답을 요청하고 사용 가능한 경우 회신에 사용합니다. 이 동작은 사용하지 않도록 설정할 수 없습니다.

도메인 로그인과 함께 사용하기 위한 스마트 카드 루트 인증서 요구 사항

스마트 카드 기반 도메인에서 로그인이 작동하려면 스마트 카드 인증서가 다음 조건을 충족해야 합니다.

• 스마트 카드의 KDC 루트 인증서에는 인증서에 HTTP CRL 배포 지점이 나열되어 있어야 합니다.
• 스마트 카드 로그인 인증서의 인증서에 HTTP CRL 배포 지점이 나열되어 있어야 합니다.
• CRL 배포 지점에는 CRL 배포 지점이 비어 있더라도 유효한 CRL이 게시되고 해당되는 경우 델타 CRL이 있어야 합니다.
• 스마트 카드 인증서는 다음 중 하나를 포함해야 합니다.
  • 고유 이름에 DNS 도메인 이름이 포함된 주체 필드입니다. 그렇지 않으면 적절한 도메인에 대한 해결이 실패하므로 스마트 카드로 원격 데스크톱 서비스 및 도메인 로그인이 실패합니다.
  • 도메인 이름이 실제 도메인으로 확인되는 UPN입니다. 예를 들어 도메인 이름이 Engineering.Corp.Contoso인 경우 UPN은 입니다 username@engineering.corp.contoso.com. 도메인 이름의 일부를 생략하면 Kerberos 클라이언트가 적절한 도메인을 찾을 수 없습니다.

이러한 버전의 도메인에 스마트 카드 로그인을 허용하려면 다음을 수행합니다.

1. CA에서 HTTP CRL 배포 지점 사용
2. CA 다시 시작
3. KDC 인증서 다시 발급
4. 스마트 카드 로그인 인증서 발급 또는 재발행
5. 도메인 로그인에 사용할 스마트 카드에 업데이트된 루트 인증서 전파

해결 방법은 사용자 이름 힌트 그룹 정책 허용 설정(X509HintsNeeded 레지스트리 키)을 사용하도록 설정하여 사용자가 도메인 로그인을 위해 자격 증명 사용자 인터페이스에 힌트를 제공할 수 있도록 하는 것입니다.

클라이언트 컴퓨터가 도메인에 가입되지 않았거나 다른 도메인에 가입된 경우 클라이언트 컴퓨터는 UPN이 아닌 인증서의 고유 이름을 확인하여 서버 도메인을 확인할 수 있습니다. 이 시나리오가 작동하려면 도메인 이름 확인을 위해 인증서에 를 비롯한 DC=<DomainControllerName>전체 주체가 필요합니다.

현재 가입된 도메인에 대한 스마트 카드에 루트 인증서를 배포하려면 다음 명령을 사용할 수 있습니다.

certutil.exe -scroots update

명령줄 도구에 대한 이 옵션에 대한 자세한 내용은 -SCRoots를 참조하세요.