AD FS FAQ(질문과 대답)

AD FS는 연결된 다음 문서 중 하나의 단계를 완료하여 업그레이드/마이그레이션할 수 있습니다.

• Windows Server 2012 R2 AD FS에서 Windows Server 2016 AD FS 이상으로: (Windows Server 2016 AD FS에서 Windows Server 2019 AD FS로 업그레이드하는 경우 프로세스는 동일합니다.)
  • WID 데이터베이스를 사용하여 Windows Server 2016에서 AD FS로 업그레이드
  • SQL 데이터베이스를 사용하여 Windows Server 2016에서 AD FS로 업그레이드
• Windows Server 2012 AD FS에서 Windows Server 2012 R2 AD FS로:
  • Windows Server 2012 R2에서 AD FS로 마이그레이션
• AD FS 2.0에서 Windows Server 2012 AD FS로:
  • Windows Server 2012에서 AD FS로 마이그레이션
• AD FS 1.x 에서 AD FS 2.0으로:
  • AD FS 1.x에서 AD FS 2.0으로 업그레이드

AD FS 2.0 또는 2.1(Windows Server 2008 R2 또는 Windows Server 2012)에서 업그레이드해야 하는 경우 C:\Windows\ADFS에 있는 기본 제공 스크립트를 사용합니다.

HTTP/2 지원이 Windows Server 2016에 추가되었지만, 클라이언트 인증서 인증에는 HTTP/2를 사용할 수 없습니다. 많은 AD FS 시나리오에서 클라이언트 인증서 인증을 사용합니다. 그리고 많은 클라이언트에서는 HTTP/1.1을 사용하여 요청 다시 시도를 지원하지 않습니다. 따라서 AD FS 팜 구성은 로컬 서버의 HTTP 설정을 HTTP/1.1로 다시 구성합니다. 이 다시 구성에서는 서버를 다시 시작해야 합니다.

이 구성이 지원되지만, 새로운 AD FS 2016 기능은 이 구성에 지원되지 않습니다. 이 구성은 AD FS 2012 R2에서 AD FS 2016으로 마이그레이션하는 동안 임시적입니다. 따라서 장기간 사용하면 안 됩니다.

예, 하지만 다음과 같은 부작용이 있습니다.

• Azure AD에서 페더레이션 메타데이터에 액세스할 수 없으므로 토큰 서명 인증서 업데이트를 수동으로 관리해야 합니다. 토큰 서명 인증서를 수동으로 업데이트하는 방법에 대한 자세한 내용은 Office 365 및 Azure Active Directory에 대한 페더레이션 인증서 갱신을 참조하세요.
• 레거시 인증 흐름(예: ExO 프록시 인증 흐름)을 사용할 수 없습니다.

AD FS는 상태 비저장 시스템이므로 로그인에 대한 부하 분산이 매우 간단합니다. 다음은 부하 분산 시스템에 대한 몇 가지 주요 권장 사항입니다.

• 부하 분산 장치는 IP 선호도를 사용하여 구성하면 안 됩니다. IP 선호도는 특정 Exchange Online 시나리오에서 서버의 하위 집합에 과도한 부하가 발생할 수 있습니다.
• 부하 분산 장치는 HTTPS 연결을 종료하고 AD FS 서버에 대한 새 연결을 시작하면 안 됩니다.
• 부하 분산 장치는 연결 IP 주소를 AD FS에 보낼 때 HTTP 패킷의 원본 IP로 변환해야 합니다. 부하 분산 장치에서 HTTP 패킷의 원본 IP를 보낼 수 없는 경우 부하 분산 장치는 IP 주소를 X-Forwarded-For 헤더에 추가해야 합니다. 이 단계는 특정 IP 관련 기능(예: 금지된 IP 및 엑스트라넷 스마트 잠금)을 올바르게 처리하는 데 필요합니다. 이 구성이 올바르게 구현되지 않으면 보안이 저하될 수 있습니다.
• 부하 분산 장치는 SNI를 지원해야 합니다. 그렇지 않은 경우 SNI를 지원하지 않는 클라이언트를 처리하기 위한 HTTPS 바인딩을 만들도록 AD FS가 구성되어 있는지 확인합니다.
• 부하 분산 장치는 AD FS HTTP 상태 프로브 엔드포인트를 사용하여 AD FS 또는 웹 애플리케이션 프록시 서버가 실행 중인지 검색해야 합니다. 200 OK가 반환되지 않으면 해당 서버를 제외해야 합니다.

AD FS는 여러 개의 다중 포리스트 구성을 지원합니다. 기본 AD DS 트러스트 네트워크를 사용하여 신뢰할 수 있는 여러 영역에서 사용자를 인증합니다. 양방향 포리스트 트러스트는 더 쉽게 설정할 수 있으므로 사용하는 것이 매우 좋습니다. 이는 트러스트 시스템이 제대로 작동하도록 하는 데 도움이 됩니다.

또한:

• 파트너 ID가 포함된 경계 네트워크(DMZ라고도 함) 포리스트와 같은 단방향 포리스트 트러스트가 있는 경우 AD FS를 회사 포리스트에 배포하는 것이 좋습니다. 경계 네트워크 포리스트는 LDAP를 통해 연결된 다른 로컬 클레임 공급자 트러스트로 처리됩니다. 이 경우 Windows 통합 인증은 경계 네트워크 포리스트 사용자에 대해 작동하지 않습니다. 암호 인증은 LDAP에 지원되는 유일한 메커니즘이므로 이 인증을 사용해야 합니다.

  이 옵션을 사용할 수 없는 경우 경계 네트워크 포리스트에서 다른 AD FS 서버를 설정해야 합니다. 회사 포리스트의 AD FS 서버에서 클레임 공급자 트러스트로 추가합니다. 사용자가 홈 영역 검색을 수행해야 하지만, Windows 통합 인증 및 암호 인증은 모두 작동합니다. 회사 포리스트의 AD FS에서 경계 네트워크 포리스트의 사용자에 대한 추가 정보를 얻을 수 없으므로 경계 네트워크 포리스트의 AD FS에서 발급 규칙을 적절하게 변경합니다.

• 도메인 수준 트러스트가 지원되며 작동할 수 있습니다. 그러나 포리스트 수준 트러스트 모델로 이동하는 것이 좋습니다. 또한 UPN 라우팅 및 NetBIOS 이름 확인이 올바르게 작동하는지 확인해야 합니다.

예, IPv6 주소는 친숙하고 알 수 없는 위치로 간주됩니다.

AD FS는 타사 다단계 인증 공급자에서 통합할 수 있는 확장 가능한 메커니즘을 제공합니다. 이에 대해 설정된 인증 프로그램이 없습니다. 공급업체에서 릴리스하기 전에 필요한 유효성 검사를 수행했다고 가정합니다.

Microsoft에 알린 공급업체 목록은 AD FS 다단계 인증 공급자에서 확인할 수 있습니다. 알 수 없는 공급자가 있을 수 있습니다. 새 공급자가 검색되면 목록을 업데이트합니다.

예, 타사 프록시는 AD FS 앞에 배치할 수 있지만, 타사 프록시에서 웹 애플리케이션 프록시 대신 사용할 MS-ADFSPIP 프로토콜을 지원해야 합니다.

현재 다음과 같은 타사 공급자를 알고 있습니다. 알 수 없는 공급자가 있을 수 있습니다. 새 공급자가 검색되면 이 목록을 업데이트합니다.

• F5 액세스 정책 관리자
• Citrix ADC(애플리케이션 배달 컨트롤러)

AD FS 2016 버전의 스프레드시트는 다운로드할 수 있습니다. 또한 이 스프레드시트는 Windows Server 2012 R2의 AD FS에 사용할 수 있습니다.

Apple은 AD FS에 인증하는 iOS 앱의 호출에 영향을 줄 수 있는 ATS(App Transport Security)라는 일단의 요구 사항을 발표했습니다. ATS를 사용하여 연결 요구 사항을 지원하는지 확인하여 AD FS 및 웹 애플리케이션 프록시 서버에서 준수하는지 확인할 수 있습니다. 특히 다음을 확인해야 합니다.

• AD FS 및 웹 애플리케이션 프록시 서버에서 TLS 1.2를 지원합니다.
• TLS 연결의 협상된 암호 그룹에서 전달 완전 보안을 지원합니다.

SSL 2.0 및 3.0과 TLS 1.0, 1.1 및 1.2의 사용 및 사용 안 함에 대한 자세한 내용은 AD FS에서 SSL 프로토콜 관리를 참조하세요.

AD FS 및 웹 애플리케이션 프록시 서버에서 ATP를 지원하는 TLS 암호 그룹만 협상하도록 하려면 ATP 규격 암호 그룹 목록에 없는 모든 암호 그룹을 사용하지 않도록 설정할 수 있습니다. 사용하지 않도록 설정하려면 Windows TLS PowerShell cmdlet을 사용합니다.

"sub" 클레임의 값은 클라이언트 ID와 앵커 클레임 값의 해시입니다.

새로 고침 토큰의 수명은 AD FS에서 원격 클레임 공급자 트러스트로부터 가져온 토큰의 수명입니다. 액세스 토큰의 수명은 액세스 토큰을 발급하는 신뢰 당사자의 토큰 수명입니다.

사용자 지정된 id_token을 사용하여 관련 정보를 id_token 자체에 추가할 수 있습니다. 자세한 내용은 id_token에서 내보낼 클레임 사용자 지정을 참조하세요.

이 시나리오에서는 AD FS 2016에서 특수 ValueType(http://www.w3.org/2001/XMLSchema#json) 및 이스케이프 문자(\x22)가 추가되었습니다. 다음 샘플을 발급 규칙 및 액세스 토큰의 최종 출력에 사용합니다.

발급 규칙 샘플:

=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");

액세스 토큰에서 발급된 클레임:

"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}

Windows Server 2019에서 AD FS를 사용하면 이제 범위 매개 변수에 포함된 리소스 값을 전달할 수 있습니다. 범위 매개 변수는 각 항목이 리소스/범위로 구조화되는 공백으로 구분된 목록으로 구성할 수 있습니다.

Windows Server 2019의 AD FS는 OAuth 인증 코드 권한 부여 흐름에 대해 PKCE(코드 교환 증명 키)를 지원합니다.

지원됨:

• aza. 브로커 클라이언트용 OAuth 2.0 프로토콜 확장을 사용하고 aza 범위가 범위 매개 변수에 포함된 경우 서버에서 새 주 새로 고침 토큰을 발급하고 응답의 refresh_token 필드에 설정합니다. 또한 refresh_token_expires_in 필드가 적용되는 경우 이를 새 주 새로 고침 토큰의 수명으로 설정합니다.
• openid. 애플리케이션에서 OpenID Connect 권한 부여 프로토콜의 사용을 요청할 수 있도록 허용합니다.
• logon_cert. 애플리케이션에서 인증된 사용자를 대화형으로 로그인하는 데 사용할 수 있는 로그온 인증서를 요청할 수 있도록 허용합니다. AD FS 서버는 응답에서 access_token 매개 변수를 생략하는 대신, Base64로 인코딩된 CMS 인증서 체인 또는 CMC 전체 PKI 응답을 제공합니다. 자세한 내용은 처리 세부 정보를 참조하세요.
• user_impersonation. AD FS에서 on-behalf-of 액세스 토큰을 요청하려는 경우에 필요합니다. 이 범위를 사용하는 방법에 대한 자세한 내용은 AD FS 2016에서 OAuth를 사용하는 OBO(On-Behalf-Of)를 통해 다중 계층 애플리케이션 빌드를 참조하세요.

지원 안 됨:

• vpn_cert. 애플리케이션에서 EAP-TLS 인증을 사용하여 VPN 연결을 설정하는 데 사용할 수 있는 VPN 인증서를 요청할 수 있도록 허용합니다. 이 범위는 더 이상 지원되지 않습니다.
• email. 애플리케이션에서 로그인한 사용자에 대한 이메일 클레임을 요청할 수 있도록 허용합니다. 이 범위는 더 이상 지원되지 않습니다.
• profile. 애플리케이션에서 로그인한 사용자에 대한 프로필 관련 클레임을 요청할 수 있도록 허용합니다. 이 범위는 더 이상 지원되지 않습니다.

AD FS SSL 인증서는 AD FS 관리 스냅인의 AD FS 서비스 통신 인증서와 다릅니다. AD FS SSL 인증서를 변경하려면 PowerShell을 사용해야 합니다. AD FS 및 WAP 2016의 SSL 인증서 관리의 지침을 따릅니다.

SSL 프로토콜 및 암호 그룹 사용 및 사용 안 함에 대한 자세한 내용은 AD FS에서 SSL 프로토콜 관리를 참조하세요.

• 프록시를 사용하여 Windows 통합 인증을 사용하는 AD FS 요청을 프록시하는 경우 프록시 SSL 인증서는 페더레이션 서버 SSL 인증서와 동일한 키를 사용해야 합니다.
• AD FS ExtendedProtectionTokenCheck 속성이 사용하도록 설정된 경우(AD FS의 기본 설정) 프록시 SSL 인증서는 페더레이션 서버 SSL 인증서와 동일한 키를 사용해야 합니다.
• 그렇지 않으면 AD FS SSL 인증서와 다른 키가 프록시 SSL 인증서에 있을 수 있습니다. 동일한 요구 사항을 충족해야 합니다.

애플리케이션에서 구성되고 사용하도록 설정된 인증 방법에 매핑되는 특정 인증 URI를 명시적으로 요구하는 경우 AD FS는 하나의 인증 방법만 로그인 화면에 표시합니다. 이 방법은 WS-Federation 요청에서 wauth 매개 변수로 전달됩니다. SAML 프로토콜 요청에서는 RequestedAuthnCtxRef 매개 변수로 전달됩니다. 요청한 인증 방법만 표시됩니다. (예를 들어 암호 로그인입니다.)

Azure AD에서 AD FS를 사용하는 경우 일반적으로 애플리케이션에서 prompt=login 매개 변수를 Azure AD에 보냅니다. Azure AD는 기본적으로 이 매개 변수에서 AD FS에 대한 새 암호 기반 로그인을 요청하도록 변환합니다. 이 시나리오는 네트워크의 AD FS에서 암호 로그인을 표시할 수 있거나 인증서를 사용하여 로그인하는 옵션을 표시하지 않을 수 있는 가장 일반적인 이유입니다. 이 문제는 Azure AD에서 페더레이션된 도메인 설정을 변경하여 쉽게 해결할 수 있습니다.

자세한 내용은 Active Directory Federation Services prompt=login 매개 변수 지원을 참조하세요.

AD FS 서비스 계정을 변경하려면 AD FS 도구 상자 서비스 계정 PowerShell 모듈을 사용합니다. 지침은 AD FS 서비스 계정 변경을 참조하세요.

AD FS에서 WIA(Windows 통합 인증)를 사용하도록 브라우저 구성을 참조하세요.

AD FS 또는 디바이스 AD FS를 통한 비즈니스용 Windows Hello 인증서 등록의 디바이스를 기반으로 하는 액세스 제어 정책이 없는 경우 BrowserSsoEnabled를 해제할 수 있습니다. BrowserSsoEnabled를 사용하면 AD FS에서 디바이스 정보가 포함된 클라이언트로부터 PRT(주 새로 고침 토큰)를 수집할 수 있습니다. 해당 토큰이 없으면 AD FS의 디바이스 인증이 Windows 10 디바이스에서 작동하지 않습니다.

관리자는 사용자가 새 자격 증명을 입력하지 않고도 SSO(Single Sign-On)를 가져오는 기간과 관리자가 이러한 동작을 제어할 수 있는 방법에 대해 궁금해하는 경우가 많습니다. 해당 동작 및 이를 제어하는 구성 설정은 AD FS Single Sign-On 설정 문서에서 설명하고 있습니다.

여기에는 다양한 쿠키 및 토큰의 기본 수명(수명을 제어하는 매개 변수와 함께)이 나와 있습니다.

등록된 디바이스

• PRT 및 SSO 쿠키: 최대 90일이며, PSSOLifeTimeMins를 통해 제어됩니다. (디바이스가 적어도 14일마다 사용되는 경우. 이 기간은 DeviceUsageWindow에 의해 제어됩니다.)

• 새로 고침 토큰: 일관된 동작을 제공하기 위해 이전 매개 변수를 기반으로 하여 계산됩니다.

• access_token: 기본적으로 1시간이며, 신뢰 당사자를 기반으로 합니다.

• id_token: access_token과 동일합니다.

등록되지 않은 디바이스

• SSO 쿠키: 기본적으로 8시간이며, SSOLifetimeMins를 통해 제어됩니다. KMSI(로그인 상태 유지)가 사용하도록 설정된 경우 기본값은 24시간입니다. 이 기본값은 KMSILifetimeMins를 통해 구성할 수 있습니다.

• 새로 고침 토큰: 기본적으로 8시간입니다. KMSI가 사용하도록 설정된 경우 24시간입니다.

• access_token: 기본적으로 1시간이며, 신뢰 당사자를 기반으로 합니다.

• id_token: access_token과 동일합니다.

AD FS는 기밀 클라이언트에 대한 암시적 흐름을 지원하지 않습니다. 클라이언트 인증은 토큰 엔드포인트에 대해서만 사용하도록 설정되며, AD FS는 클라이언트 인증 없이 액세스 토큰을 발급하지 않습니다. 기밀 클라이언트에서 액세스 토큰이 필요하고 사용자 인증도 필요한 경우 권한 부여 코드 흐름을 사용해야 합니다.

HSTS는 웹 보안 정책 메커니즘입니다. HTTP 및 HTTPS 엔드포인트가 모두 있는 서비스에 대한 프로토콜 다운그레이드 공격 및 쿠키 하이재킹을 완화하는 데 도움이 됩니다. 이를 통해 웹 서버는 웹 브라우저(또는 기타 규정 준수 사용자 에이전트)에서 HTTP 프로토콜이 아니라 HTTPS를 통해서만 상호 작용해야 한다고 선언할 수 있습니다.

웹 인증 트래픽에 대한 모든 AD FS 엔드포인트는 HTTPS를 통해서만 열립니다. 따라서 AD FS는 HSTS 정책 메커니즘에서 만드는 위협을 완화합니다. (설계상 수신기가 HTTP에 없으므로 HTTP로 다운그레이드되지 않습니다.) 또한 AD FS는 모든 쿠키를 보안 플래그로 표시하여 쿠키를 HTTP 프로토콜 엔드포인트가 있는 다른 서버에 보내지 않도록 방지합니다.

따라서 HSTS를 다운그레이드할 수 없으므로 AD FS 서버에는 HSTS가 필요하지 않습니다. AD FS 서버는 HTTP를 사용할 수 없고 쿠키가 안전한 것으로 표시되므로 규정 준수 요구 사항을 충족합니다.

마지막으로 AD FS 2016(최신 패치 포함) 및 AD FS 2019는 HSTS 헤더를 내보낼 수 있도록 지원합니다. 이 동작을 구성하려면 AD FS를 사용하여 HTTP 보안 응답 헤더 사용자 지정을 참조하세요.

웹 애플리케이션 프록시 서버 앞에서 SSL 종료를 수행하지 않는 것이 좋습니다. 웹 애플리케이션 프록시 서버 앞에서 수행되는 경우 X-MS-Forwarded-Client-IP에는 웹 애플리케이션 프록시 서버 앞에 있는 네트워크 디바이스의 IP가 포함됩니다. AD FS에서 지원하는 다양한 IP 관련 클레임에 대한 간단한 설명은 다음과 같습니다.

• X-MS-Client-IP. STS에 연결된 디바이스의 네트워크 IP입니다. 엑스트라넷 요청의 경우 이 클레임에는 항상 웹 애플리케이션 프록시 서버의 IP가 포함됩니다.
• X-MS-Forwarded-Client-IP. Exchange Online에서 AD FS에 전달한 모든 값을 포함하는 다중값 클레임입니다. 또한 웹 애플리케이션 프록시 서버에 연결된 디바이스의 IP 주소도 포함합니다.
• Userip. 엑스트라넷 요청의 경우 이 클레임에는 X-MS-Forwarded-Client-IP 값이 포함됩니다. 인트라넷 요청의 경우 이 클레임에는 X-MS-Client-IP와 동일한 값이 포함됩니다.

또한 AD FS 2016(최신 패치 포함) 이상 버전에서는 X-Forwarded-For 헤더 캡처도 지원합니다. 계층 3에서 전달하지 않는 부하 분산 장치 또는 네트워크 디바이스(IP가 유지됨)는 들어오는 클라이언트 IP를 업계 표준 X-Forwarded-For 헤더에 추가해야 합니다.

AD FS UserInfo 엔드포인트는 항상 OpenID 표준에서 지정한 대로 주체 클레임을 반환합니다. AD FS는 UserInfo 엔드포인트를 통해 요청된 추가 클레임을 지원하지 않습니다. ID 토큰에 더 많은 클레임이 필요한 경우 AD FS의 사용자 지정 ID 토큰을 참조하세요.

이 그룹은 FSMO PDC 역할이 있는 Windows 2016 도메인 컨트롤러가 도메인에 있는 경우에만 만들어집니다. 오류를 해결하려면 그룹을 수동으로 만들면 됩니다. 서비스 계정을 그룹 멤버로 추가한 후 다음 단계에 따라 필요한 권한을 추가합니다.

1. Active Directory 사용자 및 컴퓨터를 엽니다.
2. 왼쪽 창에서 마우스 오른쪽 단추로 도메인 이름을 클릭한 다음, 속성을 선택합니다.
3. 보안을 선택합니다. (보안 탭이 없는 경우 보기 메뉴에서 고급 기능을 켭니다.)
4. 고급, 추가, 보안 주체 선택을 차례로 선택합니다.
5. 사용자, 컴퓨터, 서비스 계정 또는 그룹 선택 대화 상자가 표시됩니다. 선택할 개체 이름 입력 텍스트 상자에서 키 관리 그룹을 입력합니다. 확인을 선택합니다.
6. 적용 대상 상자에서 하위 사용자 개체를 선택합니다.
7. 페이지 아래쪽으로 스크롤하여 모두 지우기를 선택합니다.
8. 속성 섹션에서 msDS-KeyCredentialLink 읽기 및 msDS-KeyCredentialLink 쓰기를 선택합니다.

Android ADAL 라이브러리를 사용하는 앱의 경우 페더레이션 사용자에 대한 Azure AD의 인증이 실패할 수 있습니다. 앱에서 로그인 페이지를 표시하려고 하면 AuthenticationException이 발생합니다. Chrome 브라우저에서 AD FS 로그인 페이지는 안전하지 않은 것으로 설명할 수 있습니다.

모든 버전과 모든 디바이스에 대해 Android는 인증서의 authorityInformationAccess 필드에서 추가 인증서 다운로드를 지원하지 않습니다. 이 제한은 Chrome 브라우저에도 적용됩니다. 전체 인증서 체인이 AD FS에서 전달되지 않으면 중간 인증서가 없는 서버 인증 인증서로 인해 이 오류가 발생합니다.

이 문제는 SSL 인증서와 함께 필요한 중간 인증서를 보내도록 AD FS 및 웹 애플리케이션 프록시 서버를 구성하여 해결할 수 있습니다.

한 컴퓨터에서 AD FS 및 웹 애플리케이션 프록시 서버의 컴퓨터 개인 저장소로 가져올 SSL 인증서를 내보내는 경우 프라이빗 키를 내보내고 개인 정보 교환 - PKCS #12를 선택해야 합니다.

또한 가능한 경우 인증서 경로의 모든 인증서 포함 및 확장 속성 모두 내보내기를 선택해야 합니다.

Windows Server에서 certlm.msc를 실행하고, *.pfx를 컴퓨터의 개인 인증서 저장소로 가져옵니다. 이렇게 하면 서버에서 전체 인증서 체인을 ADAL 라이브러리로 전달합니다.

AD FS는 HEAD 요청을 지원하지 않습니다. 애플리케이션에서 AD FS 엔드포인트에 대해 HEAD 요청을 사용하지 않아야 합니다. 이러한 요청을 사용하면 예기치 않거나 지연된 HTTP 오류 응답이 발생할 수 있습니다. 또한 예기치 않은 오류 이벤트가 AD FS 이벤트 로그에 표시될 수 있습니다.

IdP에서 발급한 토큰의 유효 기간이 1시간 미만인 경우 새로 고침 토큰이 발급되지 않습니다. 새로 고침 토큰이 발급되도록 하려면 IdP에서 발급한 토큰의 유효 기간을 1시간 넘게 늘립니다.

RP 토큰 암호화는 AES256으로 설정됩니다. 다른 값으로 변경할 수 없습니다.

혼합 모드 AD FS 팜은 임시로 사용할 수 있습니다. 계획하는 동안 업그레이드 프로세스 전에 SSL 인증서를 롤오버하거나, SSL 인증서를 업데이트하기 전에 프로세스를 완료하고 팜 동작 수준을 높이는 것이 좋습니다. 해당 권장 사항을 따르지 않은 경우 다음 지침에 따라 SSL 인증서를 업데이트합니다.

웹 애플리케이션 프록시 서버에서는 Set-WebApplicationProxySslCertificate를 계속 사용할 수 있습니다. AD FS 서버에서 netsh를 사용해야 합니다. 다음 단계를 완료합니다.

1. 유지 관리를 위해 AD FS 2016 서버의 하위 집합을 선택합니다.

2. 이전 단계에서 선택한 서버에서 MMC를 통해 새 인증서를 가져옵니다.

3. 기존 인증서를 삭제합니다.

   a. netsh http delete sslcert hostnameport=fs.contoso.com:443

   b. netsh http delete sslcert hostnameport=localhost:443

   c. netsh http delete sslcert hostnameport=fs.contoso.com:49443

4. 새 인증서를 추가합니다.

   a. netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable sslctlstorename=AdfsTrustedDevices

   b. netsh http add sslcert hostnameport=localhost:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable

   c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable clientcertnegotiation=Enable

5. 선택한 서버에서 AD FS 서비스를 다시 시작합니다.

6. 유지 관리를 위해 웹 애플리케이션 프록시 서버의 하위 집합을 제거합니다.

7. 선택한 웹 애플리케이션 프록시 서버에서 MMC를 통해 새 인증서를 가져옵니다.

8. 다음 cmdlet을 사용하여 웹 애플리케이션 프록시 서버에서 새 인증서를 설정합니다.

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. 선택한 웹 애플리케이션 프록시 서버에서 서비스를 다시 시작합니다.

10. 선택한 웹 애플리케이션 프록시 및 AD FS 서버를 프로덕션 환경에 다시 배치합니다.

나머지 AD FS 및 웹 애플리케이션 프록시 서버를 동일한 방식으로 업데이트합니다.

AD FS 및 웹 애플리케이션 서버는 엔드포인트에서 SSL 종료를 수행하지 않는 방화벽을 지원합니다. 또한 AD FS/웹 애플리케이션 프록시 서버에는 다음과 같은 기본 제공 메커니즘이 있습니다.

• 사이트 간 스크립팅과 같은 일반적인 웹 공격을 방지합니다.
• AD FS 프록시를 수행합니다.
• MS-ADFSPIP 프로토콜에 정의된 모든 요구 사항을 충족합니다.

AD FS 2016에서는 토큰 바인딩을 사용하도록 자동으로 설정되며, 프록시 및 페더레이션 시나리오에서 알려진 여러 문제가 발생합니다. 이 이벤트는 이러한 문제로 인해 발생합니다. 이 이벤트 문제를 해결하려면 다음 PowerShell 명령을 실행하고 토큰 바인딩 지원을 제거합니다.

Set-AdfsProperties -IgnoreTokenBinding $true

Windows Server 2019로 업그레이드한 후에도 웹 애플리케이션 프록시의 구성 버전은 계속 Windows Server 2016으로 표시됩니다. 웹 애플리케이션 프록시에는 Windows Server 2019에 대한 새로운 버전별 기능이 없습니다. AD FS에서 팜 동작 수준이 높아진 경우에도 웹 애플리케이션 프록시가 Windows Server 2016으로 계속 표시됩니다. 이 동작은 의도된 것입니다.

ESL이 사용하도록 설정되면 AD FS에서 ADFSArtifactStore 데이터베이스로부터 사용자의 계정 활동과 알려진 위치를 추적합니다. 이 데이터베이스는 추적된 사용자 및 알려진 위치의 수에 따라 크기를 조정합니다. ESL을 사용 설정하도록 계획하는 경우 ADFSArtifactStore 데이터베이스의 크기가 100,000명 사용자당 최대 1GB의 속도로 확장한다고 예측할 수 있습니다.

AD FS 팜에서 Windows 내부 데이터베이스를 사용하는 경우 데이터베이스 파일의 기본 위치는 C:\Windows\WID\Data입니다. 이 드라이브가 가득 차지 않도록 방지하려면 ESL을 사용하도록 설정하기 전에 5GB 이상의 사용 가능한 스토리지가 있어야 합니다. 디스크 스토리지 외에도, ESL을 사용하도록 설정한 후에 총 프로세스 메모리를 500,000명 이하의 사용자 집단에 대해 최대 1GB의 추가 RAM까지 늘리도록 계획합니다.

이벤트의 텍스트는 다음과 같습니다.

Active Directory trust enumeration was unable to enumerate one of more domains due to the following error. Enumeration will continue but the Active Directory identifier list may not be correct. Validate that all expected Active Directory identifiers are present by running Get-ADFSDirectoryProperties.

이 이벤트는 AD FS에서 트러스트된 포리스트 체인의 모든 포리스트를 열거하고 모든 포리스트에 연결하려고 할 때 포리스트가 트러스트되지 않으면 발생합니다. 예를 들어 AD FS 포리스트 A와 포리스트 B가 트러스트되고, 포리스트 B와 포리스트 C를 트러스트되었다고 가정합니다. AD FS에서 세 개의 포리스트를 모두 열거하고 포리스트 A와 포리스트 C 간의 트러스트를 찾으려 시도합니다. AD FS에서 오류가 발생한 포리스트의 사용자를 인증해야 하는 경우 AD FS 포리스트와 오류가 발생한 포리스트 간에 트러스트를 설정합니다. AD FS에서 오류가 발생한 포리스트의 사용자를 인증하지 않아야 하는 경우 이 오류를 무시합니다.

이벤트의 텍스트는 다음과 같습니다.

Microsoft.IdentityServer.AuthenticationFailedException: MSIS5015: Authentication of the presented token failed. Token Binding claim in token must match the binding provided by the channel.

AD FS 2016에서는 토큰 바인딩을 사용하도록 자동으로 설정되며, 프록시 및 페더레이션 시나리오에서 알려진 여러 문제가 발생합니다. 이 이벤트는 이러한 문제로 인해 발생합니다. 이 이벤트 문제를 해결하려면 다음 PowerShell 명령을 실행하고 토큰 바인딩 지원을 제거합니다.

Set-AdfsProperties -IgnoreTokenBinding $true

이벤트의 텍스트는 다음과 같습니다.

System.ServiceModel.FaultException: The formatter threw an error while trying to deserialize the message: There was an error while trying to deserialize parameter schemas.microsoft.com/ws/2009/12/identityserver/protocols/policystore:maxBehaviorLevel". The InnerException message was "Invalid enum value 'Win2019' cannot be deserialized into type 'Microsoft.IdentityServer.FarmBehavior'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

이 이벤트는 다음 두 설명이 모두 true일 때 발생합니다.

• 혼합 모드 팜이 있습니다.
• AD FS 2019에서 팜 최대 동작 수준 정보를 주 페더레이션 서버에 제공하지만 페더레이션 서버 버전 2016에서는 인식되지 않습니다.

AD FS 2019는 2개월 후에 부실해지고 팜에서 자동으로 제거될 때까지 Win2019 MaxBehaviorLevel 값을 팜에서 계속 공유하려고 합니다. 이 이벤트가 발생하지 않도록 방지하려면 주 페더레이션 역할을 최신 버전의 페더레이션 서버로 마이그레이션합니다. AD FS 팜을 Windows Server 2019 팜 동작 수준으로 업그레이드하려면의 지침을 따릅니다.