사용자 인증서 인증을 위한 AD FS 지원 구성

  • 아티클

이 문서에서는 AD FS(Active Directory Federation Services)에서 사용자 인증서 인증을 사용하도록 설정하는 방법을 설명합니다. 또한 이러한 유형의 인증과 관련된 일반적인 문제에 대한 문제 해결 정보를 제공합니다.

사용자 인증서 인증에는 두 가지 기본 사용 사례가 있습니다.

  • 사용자는 스마트 카드 사용하여 AD FS 시스템에 로그인합니다.
  • 사용자가 모바일 디바이스에 프로비전된 인증서를 사용하고 있습니다.

필수 조건

  • 인증서 인증에 대한 대체 호스트 이름 바인딩에 대한 AD FS 지원에 설명된 모드 중 하나를 사용하여 사용하도록 설정할 AD FS 사용자 인증서 인증 모드를 결정합니다.
  • 중간 인증 기관을 포함하여 모든 AD FS 및 WAP(웹 애플리케이션 프록시) 서버에서 사용자 인증서 신뢰 체인을 설치하고 신뢰하는지 확인합니다. 일반적으로 AD FS 및 WAP 서버에서 GPO(그룹 정책 개체)를 통해 이 작업을 수행합니다.
  • 사용자 인증서에 대한 신뢰 체인의 루트 인증서가 Active Directory의 NTAuth 저장소에 있는지 확인합니다.
  • 대체 인증서 인증 모드에서 AD FS를 사용하는 경우 AD FS 및 WAP 서버에 "certauth" 접두사로 접두사로 지정된 AD FS 호스트 이름이 포함된 SSL(Secure Sockets Layer) 인증서가 있는지 확인합니다. 예를 들면 다음과 같습니다 certauth.fs.contoso.com. 또한 이 호스트 이름에 대한 트래픽이 방화벽을 통해 허용되는지 확인합니다.
  • 엑스트라넷에서 인증서 인증을 사용하는 경우 인증서에 지정된 목록에서 하나 이상의 AIA(기관 정보 액세스) 및 하나 이상의 CRL 배포 지점(CDP) 또는 OCSP(온라인 인증서 상태 프로토콜) 위치에 인터넷에서 액세스할 수 있는지 확인합니다.
  • Microsoft Entra 인증서 인증을 위해 AD FS를 구성하는 경우 인증서 발급자 및 일련 번호에 필요한 Microsoft Entra 설정 및 AD FS 클레임 규칙을 구성했는지 확인합니다.
  • Exchange ActiveSync 클라이언트에 Microsoft Entra 인증서 인증을 사용하는 경우 클라이언트 인증서에는 주체 대체 이름 필드의 주체 이름 값 또는 RFC822 이름 값 중 하나의 Exchange Online에 사용자의 라우팅 가능한 전자 메일 주소가 있어야 합니다. Microsoft Entra ID는 RFC822 값을 디렉터리의 프록시 주소 특성에 매핑합니다.

참고 항목

AD FS는 스마트 카드 또는 인증서 기반 인증을 사용하는 사용자 이름 힌트를 지원하지 않습니다.

사용자 인증서 인증 사용

AD FS 관리 콘솔 또는 PowerShell cmdlet Set-AdfsGlobalAuthenticationPolicy을 사용하여 AD FS에서 인트라넷 또는 엑스트라넷 인증 방법으로 사용자 인증서 인증을 사용하도록 설정합니다.

선택적 고려 사항은 다음과 같습니다.

  • EKU 클레임 유형 https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku외에 인증서 필드 및 확장에 따라 클레임을 사용하려면 Active Directory 클레임 공급자 트러스트에 대해 더 많은 클레임 통과 규칙을 구성합니다. 이 문서의 뒷부분에서 사용 가능한 인증서 클레임 의 전체 목록을 참조하세요.

  • 인증서 유형에 따라 액세스를 제한해야 하는 경우 애플리케이션에 대한 AD FS 발급 권한 부여 규칙의 인증서에 대한 추가 속성을 사용할 수 있습니다. 일반적인 시나리오는 MDM(모바일 디바이스 관리) 공급자가 프로비전한 인증서만 허용하거나 스마트 카드 인증서만 허용하는 것입니다.

    Important

    인증에 디바이스 코드 흐름을 사용하고 Microsoft Entra ID(예: AD FS)가 아닌 ID 공급자를 사용하여 디바이스 인증을 수행하는 고객은 Microsoft Entra 리소스에 디바이스 기반 액세스를 적용할 수 없습니다. 예를 들어 타사 MDM 서비스를 사용하여 관리되는 디바이스만 허용할 수 없습니다.

    Microsoft Entra ID에서 회사 리소스에 대한 액세스를 보호하고 데이터 누출을 방지하려면 Microsoft Entra 디바이스 기반 조건부 액세스를 구성합니다. 예를 들어 Microsoft Entra 조건부 액세스에서 제어 권한을 부여하려면 디바이스를 불만 사항 으로 표시해야 합니다.

    Schannel SSP 기술 개요의 "클라이언트 인증을 위한 신뢰할 수 있는 발급자 관리"의 지침을 사용하여 클라이언트 인증서에 허용되는 발급 인증 기관을 구성합니다.

  • 사용자가 인증서 인증을 수행할 때 사용자의 요구에 맞게 로그인 페이지를 수정하는 것이 좋습니다. 일반적인 경우는 X509 인증서로 로그인을 더 사용자에게 친숙한 것으로 변경하는 것입니다.

Windows 데스크톱에서 Chrome 브라우저에 대한 원활한 인증서 인증 구성

컴퓨터에 클라이언트 인증 목적을 충족하는 여러 사용자 인증서(예: Wi-Fi 인증서)가 있는 경우 Windows 데스크톱의 Chrome 브라우저는 사용자에게 올바른 인증서를 선택하라는 메시지를 표시합니다. 이 프롬프트는 사용자에게 혼동될 수 있습니다. 이 환경을 최적화하기 위해 Chrome에서 올바른 인증서를 자동으로 선택하는 정책을 설정할 수 있습니다.

레지스트리를 변경하여 이 정책을 수동으로 설정하거나 GPO를 통해 자동으로 구성할 수 있습니다(레지스트리 키를 설정하기 위해). 이렇게 하려면 AD FS에 대한 인증을 위해 사용자 클라이언트 인증서에 다른 사용 사례와 다른 발급자가 있어야 합니다.

Chrome에 대한 인증서 인증을 구성하는 방법에 대한 자세한 내용은 Chrome Enterprise 정책 목록을 참조하세요.

인증서 인증 문제 해결

사용자에 대한 인증서 인증을 위해 AD FS를 구성한 경우 일반적인 문제를 해결하려면 다음 정보를 사용합니다.

인증서 신뢰할 수 있는 발급자가 모든 AD FS 및 WAP 서버에서 제대로 구성되었는지 확인

인증서 신뢰할 수 있는 발급자가 제대로 구성되지 않은 경우 일반적인 증상은 HTTP 204 오류입니다. "콘텐츠 https://certauth.adfs.contoso.com."없음;

AD FS는 기본 Windows 운영 체제를 사용하여 사용자 인증서의 소유를 증명하고 인증서 신뢰 체인의 유효성을 검사하여 신뢰할 수 있는 발급자와 일치하는지 확인합니다. 신뢰할 수 있는 발급자와 일치하려면 모든 루트 및 중간 기관이 컴퓨터 인증 기관의 로컬 저장소에서 신뢰할 수 있는 발급자로 구성되었는지 확인해야 합니다.

자동으로 유효성을 검사하려면 AD FS 진단 분석기 도구를 사용합니다. 도구는 모든 서버를 쿼리하고 올바른 인증서가 올바르게 프로비전되었는지 확인합니다.

  1. 도구를 다운로드하고 실행합니다.
  2. 결과를 업로드하고 오류에 대해 검토합니다.

AD FS 인증 정책에서 인증서 인증을 사용할 수 있는지 확인

AD FS는 AD FS와 동일한 호스트 이름을 가진 포트 49443에서 기본적으로 사용자 인증서 인증을 수행합니다(예: adfs.contoso.com). 대체 SSL 바인딩을 사용하여 포트 443(기본 HTTPS 포트)을 사용하도록 AD FS를 구성할 수도 있습니다. 그러나 이 구성에 사용되는 URL은 (예: certauth.contoso.com)입니다 certauth.<adfs-farm-name> . 자세한 내용은 인증서 인증에 대한 대체 호스트 이름 바인딩에 대한 AD FS 지원을 참조하세요.

참고 항목

Windows Server 2016의 AD FS에서는 이제 두 가지 모드가 지원됩니다. 첫 번째 모드는 포트가 443 및 49443인 호스트 adfs.contoso.com 를 사용합니다. 두 번째 모드는 호스트와 adfs.contoso.comcertauth.adfs.contoso.com 포트 443을 사용합니다. 대체 주체 이름으로 지원 certauth.\<adfs-service-name> 하려면 SSL 인증서가 필요합니다. 팜을 만들 때 또는 나중에 PowerShell을 통해 이 작업을 수행할 수 있습니다.

네트워크 연결 문제의 가장 일반적인 경우는 방화벽이 잘못 구성되고 사용자 인증서 인증에 대한 트래픽을 차단한다는 것입니다. 일반적으로 이 문제가 발생하면 빈 화면 또는 500 서버 오류가 표시됩니다. 이 문제를 해결하려면 다음을 수행합니다.

  1. AD FS에서 구성한 호스트 이름 및 포트를 확인합니다.
  2. AD FS 또는 WAP 앞의 방화벽이 AD FS 팜에 hostname:port 대한 조합을 허용하도록 구성되어 있는지 확인합니다. 네트워크 엔지니어가 이 단계를 수행해야 합니다.

CRL 연결 확인

CRL(인증서 해지 목록)은 런타임 해지 검사 수행하기 위해 사용자 인증서로 인코딩되는 엔드포인트입니다. 예를 들어 인증서가 포함된 디바이스를 도난당한 경우 관리자는 해지된 인증서 목록에 인증서를 추가할 수 있습니다. 이전에 이 인증서를 수락한 모든 엔드포인트는 이제 인증에 실패합니다.

모든 AD FS 및 WAP 서버는 CRL 엔드포인트에 도달하여 제공된 인증서가 여전히 유효하고 해지되지 않았는지 확인해야 합니다. CRL 유효성 검사는 HTTPS, HTTP, LDAP 또는 OCSP를 통해 발생할 수 있습니다. AD FS 및 WAP 서버가 엔드포인트에 연결할 수 없는 경우 인증이 실패합니다. 다음 단계를 사용하여 문제를 해결합니다.

  1. PKI(공개 키 인프라) 엔지니어에게 문의하여 PKI 시스템에서 사용자 인증서를 해지하는 데 사용되는 CRL 엔드포인트를 확인합니다.
  2. 각 AD FS 및 WAP 서버에서 사용되는 프로토콜(일반적으로 HTTPS 또는 HTTP)을 통해 CRL 엔드포인트에 연결할 수 있는지 확인합니다.
  3. 고급 유효성 검사를 위해 각 AD FS 및 WAP 서버에서 CAPI2 이벤트 로깅 을 사용하도록 설정합니다.
  4. CAPI2 작업 로그에서 이벤트 ID 41(해지 확인)을 확인합니다.
  5. 를 확인합니다 <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

팁

특정 서버를 가리키도록 DNS 확인(Windows의 호스트 파일)을 구성하여 문제 해결을 위해 단일 AD FS 또는 WAP 서버를 대상으로 지정할 수 있습니다. 이 기술을 사용하면 서버를 대상으로 하여 추적을 사용하도록 설정할 수 있습니다.

SNI 문제 확인

AD FS를 사용하려면 클라이언트 디바이스(또는 브라우저) 및 부하 분산 장치가 SNI(서버 이름 표시)를 지원해야 합니다. 일부 클라이언트 디바이스(예: 이전 버전의 Android)는 SNI를 지원하지 않을 수 있습니다. 또한 부하 분산 장치는 SNI를 지원하지 않거나 SNI에 대해 구성되지 않을 수 있습니다. 이러한 경우 사용자 인증 오류가 발생할 수 있습니다.

이 문제를 해결하려면 네트워크 엔지니어와 협력하여 AD FS 및 WAP용 부하 분산 장치가 SNI를 지원하는지 확인합니다. SNI를 지원하지 못하는 경우 AD FS에서 다음 해결 방법을 사용합니다.

  1. 기본 AD FS 서버에서 관리자 권한 명령 프롬프트 창을 엽니다.
  2. Netsh http show sslcert를 입력합니다.
  3. 페더레이션 서비스의 애플리케이션 GUID 및 인증서 해시를 복사합니다.
  4. netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicaitonGUID}를 입력합니다.

클라이언트 디바이스가 인증서로 올바르게 프로비전되었는지 확인합니다.

일부 디바이스가 제대로 작동하지만 다른 디바이스는 작동하지 않는 것을 알 수 있습니다. 대부분의 경우 사용자 인증서가 일부 클라이언트 디바이스에서 올바르게 프로비전되지 않았음을 의미합니다. 다음 단계를 수행합니다.

  1. 문제가 Android 디바이스와 관련된 경우 가장 일반적인 원인은 인증서 체인이 디바이스에서 완전히 신뢰할 수 없다는 것입니다. 인증서가 올바르게 프로비전되고 전체 체인이 Android 디바이스에서 완전히 신뢰할 수 있는지 확인하려면 MDM 공급업체를 참조하세요.

    문제가 Windows 디바이스와 관련된 경우 로그인한 사용자(시스템 또는 컴퓨터 아님)에 대한 Windows 인증서 저장소를 검사 인증서가 올바르게 프로비전되었는지 검사.

  2. 클라이언트 사용자 인증서를 .cer 파일로 내보내고 명령을 certutil -f -urlfetch -verify certificatefilename.cer실행합니다.

TLS 버전이 AD FS/WAP 서버와 클라이언트 디바이스 간에 호환되는지 확인합니다.

드문 경우이지만 클라이언트 디바이스는 더 높은 버전의 TLS(예: 1.3)만 지원하도록 업데이트됩니다. 또는 AD FS 및 WAP 서버가 클라이언트 디바이스에서 지원하지 않는 더 높은 TLS 버전만 사용하도록 업데이트된 역방향 문제가 있을 수 있습니다.

온라인 SSL 도구를 사용하여 AD FS 및 WAP 서버를 검사 디바이스와 호환되는지 확인할 수 있습니다. TLS 버전을 제어하는 방법에 대한 자세한 내용은 AD FS용 SSL/TLS 프로토콜 및 암호 그룹 관리를 참조하세요.

페더레이션된 do기본 설정에서 Microsoft Entra PromptLoginBehavior가 올바르게 구성되어 있는지 확인합니다.

많은 Office 365 응용 프로그램이 Microsoft Entra ID로 보냅니 prompt=login 다. Microsoft Entra ID는 기본적으로 새 암호 로그인으로 AD FS로 변환합니다. 따라서 AD FS에서 인증서 인증을 구성한 경우에도 사용자에게 암호 로그인만 표시됩니다. 이 문제를 해결하려면 다음을 수행합니다.

  1. cmdlet을 사용하여 Get-MgDomainFederationConfiguration 페더레이션된 do기본 설정을 가져옵니다.
  2. 매개 변수가 PromptLoginBehavior 둘 중 하나 Disabled 또는 .로 설정되어 있는지 확인합니다 NativeSupport.

자세한 내용은 AD FS prompt=login 매개 변수 지원을 참조 하세요.

추가적인 문제 해결

드물게 CRL 목록이 매우 긴 경우 다운로드를 시도할 때 시간이 초과될 수 있습니다. 이 경우 Windows용 Http.sys 레지스트리 설정에 설명된 대로 업데이트 MaxFieldLengthMaxRequestByte 해야 합니다.

참조: 사용자 인증서 클레임 유형 및 예제 값의 전체 목록

클레임 유형 예제 값
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4