Active Directory Federation Services의 새로운 기능

Active Directory 페더레이션 서비스에 대 한 Windows Server 2019의 새로운 기능

이 문서에서는 AD FS(Active Directory Federation Services)에 대한 새로운 변경 내용을 설명합니다.

보호된 로그인

다음은 AD FS(Active Directory Federation Services) 2019에서 사용할 수 있는 보호된 로그인에 대한 업데이트에 대한 간략한 요약입니다.

• 외부 인증 공급자를 기본 공급자로 사용합니다. 이제 고객은 제3자 인증 제품을 첫 번째 요소로 사용할 수 있으며 암호를 첫 번째 요소로 노출하지 않을 수 있습니다. 외부 인증 공급자가 두 가지 요소를 증명할 수 있는 경우 MFA를 클레임할 수 있습니다.
• 추가 인증으로 암호 인증. 고객은 암호 없는 옵션이 첫 번째 요소로 사용된 후에 암호를 추가 요소로만 사용할 수 있는 완전히 지원되는 기본 제공 옵션을 제공합니다. 이 옵션은 고객이 있는 그대로 지원되는 GitHub 어댑터를 다운로드해야 하는 AD FS 2016의 고객 환경을 개선합니다.
• 플러그형 위험 평가 모듈. 이제 고객은 사전 인증 단계에서 특정 유형의 요청을 차단하는 자체 플러그 인 모듈을 빌드할 수 있습니다. 이 기능을 사용하면 고객이 ID 보호와 같은 클라우드 인텔리전스를 사용하여 위험한 사용자 또는 위험한 트랜잭션에 대한 로그인을 보다 쉽게 차단할 수 있습니다. 자세한 내용은 AD FS 2019 위험 평가 모델을 사용하여 플러그 인 빌드를 참조 하세요.
• ESL 개선 사항. 다음 기능을 추가하여 2016년 QFE(ESL 빠른 수정 엔지니어링)를 개선합니다.
  • 고객이 AD FS 2012R2 이후 사용할 수 있는 '클래식' 엑스트라넷 잠금 기능으로 보호되는 동안 감사 모드에 있을 수 있습니다. 현재 2016 고객은 감사 모드에서 보호를 받을 수 없습니다.
  • 익숙한 위치에 독립적인 잠금 임계값을 사용할 수 있습니다. 이 기능을 사용하면 공통 서비스 계정으로 실행되는 여러 앱 인스턴스가 최소한의 효과로 암호를 롤오버할 수 있습니다.

기타 보안 개선 사항

AD FS 2019에서는 다음과 같은 보안 개선 사항을 사용할 수 있습니다.

• SmartCard 로그인을 사용하는 원격 PowerShell입니다. 이제 고객은 SmartCards를 사용하여 PowerShell을 통해 AD FS에 원격으로 연결하고 이를 사용하여 다중 노드 cmdlet을 포함한 모든 PowerShell 함수를 관리할 수 있습니다.
• HTTP 헤더 사용자 지정 이제 고객은 다음 헤더를 포함하여 AD FS 응답 중에 내보낸 HTTP 헤더를 사용자 지정할 수 있습니다.
  • HSTS: 이 헤더는 규격 브라우저를 적용하기 위해 HTTPS 엔드포인트에서만 AD FS 엔드포인트를 사용할 수 있음을 전달합니다.
  • x-frame-options: AD FS 관리자는 특정 신뢰 당사자가 AD FS 대화형 로그인 페이지에 대한 iFrame을 포함할 수 있도록 허용합니다. 이 헤더는 주의하여 HTTPS 호스트에서만 사용해야 합니다.
  • 이후 헤더: 다른 미래 헤더도 구성할 수 있습니다.

자세한 내용은 AD FS 2019를 사용하여 HTTP 보안 응답 헤더 사용자 지정을 참조하세요.

인증/정책 기능

다음은 AD FS 2019에의 인증/정책 기능입니다.

• RP당 다른 인증에 대한 인증 메서드를 지정합니다. 이제 고객은 클레임 규칙을 사용하여 추가 인증을 위해 호출할 다른 인증 공급자를 결정할 수 있습니다. 이 기능은 다음 두 가지 사용 사례에 유용합니다.
  • 고객은 다른 인증 공급자에서 다른 인증 공급자로 전환하고 있습니다. 이렇게 하면 사용자를 최신 인증 공급자에 온보딩할 때 그룹을 사용하여 호출되는 추가 인증 공급자를 제어할 수 있습니다.
  • 고객은 특정 애플리케이션에 대한 특정 추가 인증 공급자(예: 인증서)가 필요합니다.
• TLS(전송 계층 보안) 기반 디바이스 인증을 필요한 애플리케이션으로만 제한합니다. 이제 고객은 클라이언트 TLS 기반 디바이스 인증을 디바이스 기반 조건부 액세스를 수행하는 애플리케이션으로만 제한할 수 있습니다. 이 옵션은 TLS 기반 디바이스 인증이 필요하지 않은 애플리케이션에 대해 원치 않는 디바이스 인증(또는 클라이언트 애플리케이션이 처리할 수 없는 경우 실패)을 방지합니다.
• MFA(다단계 인증) 새로 고침 지원. 이제 AD FS는 두 번째 요소 자격 증명의 새로 고침을 기반으로 2단계 자격 증명을 다시 실행하는 기능을 지원합니다. 이 기능을 사용하면 고객이 두 가지 요소로 초기 트랜잭션을 수행하고 두 번째 요소만 주기적으로 프롬프트할 수 있습니다. 이 기능은 요청에 추가 매개 변수를 제공할 수 있고 AD FS에서 구성할 수 있는 설정이 아닌 애플리케이션에서만 사용할 수 있습니다. Azure AD는 "X일 동안 내 MFA 기억"을 구성하고 Azure AD 페더레이션 do기본 트러스트 설정에서 'supportsMFA' 플래그를 true로 설정할 때 이 매개 변수를 지원합니다.

Single Sign-On 개선 사항

AD FS 2019에서는 다음과 같은 Single Sign-On SSO가 개선되었습니다.

• 가운데 테마를 사용하여 페이지를 매긴 UX입니다. 이제 AD FS가 페이지를 매긴 UX 흐름으로 이동하여 AD FS가 유효성을 검사하고 보다 원활한 로그인 환경을 제공할 수 있습니다. 이제 AD FS는 화면 오른쪽 대신 가운데 맞춤 UI를 사용합니다. 이 환경에 맞게 최신 로고 및 배경 이미지가 필요할 수 있습니다. 이 변경 내용은 Azure AD에서 제공되는 기능도 미러.
• 버그 수정: PRT(기본 새로 고침 토큰) 인증을 수행할 때 Win10 디바이스에 대한 영구 SSO 상태입니다. 이 변경은 Windows 10 디바이스에 PRT 인증을 사용할 때 MFA 상태가 유지되지 않는 문제를 해결합니다. 문제의 결과로 최종 사용자에게 MFA(두 번째 요소 자격 증명)를 자주 묻는 메시지가 표시됩니다. 또한 이 수정 버전은 클라이언트 TLS 및 PRT 메커니즘을 통해 수행한 디바이스 인증이 성공하면 일관적인 환경을 제공합니다.

최신 기간 업무 앱 빌드 지원

최신 LOB 앱을 빌드하기 위한 다음과 같은 지원이 AD FS 2019에 추가되었습니다.

• Oauth 디바이스 흐름/프로필. 이제 AD FS는 풍부한 로그인 환경을 지원하기 위해 UI 노출 영역이 없는 디바이스에서 로그인하는 OAuth 디바이스 흐름 프로필을 지원합니다. 이 기능을 사용하면 사용자가 다른 디바이스에서 로그인 환경을 완료할 수 있습니다. 이 기능은 Azure Stack의 Azure CLI 환경에 필요하며 다른 경우에 사용할 수 있습니다.
• 'Resource' 매개 변수 제거 AD FS는 이제 현재 Oauth 사양에 부합하는 리소스 매개 변수를 지정하기 위한 요구 사항을 제거했습니다. 이제 클라이언트는 요청된 권한 외에도 신뢰 당사자 트러스트 식별자를 범위 매개 변수로 제공할 수 있습니다.
• AD FS 응답의 CORS(원본 간 리소스 공유) 헤더입니다. 이제 고객은 클라이언트 쪽 JavaScript 라이브러리가 AD FS의 OpenID 커넥트(OIDC) 검색 문서에서 서명 키를 쿼리하여 id_token 서명의 유효성을 검사할 수 있는 단일 페이지 애플리케이션을 빌드할 수 있습니다.
• PKCE(코드 교환) 지원의 증명 키입니다. AD FS는 OAuth 내에서 보안 인증 코드 흐름을 제공하기 위해 PKCE 지원을 추가합니다. 이 기능은 코드를 하이재킹하고 다른 클라이언트에서 재생하지 못하도록 이 흐름에 추가 보안 계층을 추가합니다.
• 버그 수정: x5t 및 kid 클레임을 보냅니다. 이 변경은 사소한 버그 수정입니다. 이제 AD FS는 서명을 확인하기 위한 키 ID 힌트를 나타내는 "kid" 클레임을 추가로 보냅니다. 이전에는 AD FS가 "x5t" 클레임만 보냈습니다.

향상된 지원 가능성

지원 효율성에 대한 다음과 같은 개선 사항은 이제 AD FS 2019의 일부입니다.

• AD FS 관리자에게 오류 세부 정보를 보냅니다. 관리자는 최종 사용자가 쉽게 사용할 수 있도록 압축된 파일로 저장되도록 최종 사용자 인증 실패와 관련된 디버그 로그를 보내도록 구성할 수 있습니다. 또한 관리 SMTP(Simple Mail Transfer Protocol) 연결을 구성하여 압축된 파일을 심사 전자 메일 계정에 자동으로 메일로 보내거나 전자 메일에 따라 티켓을 자동으로 만들 수 있습니다.

배포 업데이트

AD FS 2019에는 다음 배포 업데이트가 포함되어 있습니다.

• 팜 동작 수준 2019. AD FS 2016과 마찬가지로, 문서의 뒷부분에서 설명하는 새로운 기능을 사용하도록 설정하는 데 필요한 새 팜 동작 수준 버전이 있습니다. 이 업데이트를 통해 다음을 수행할 수 있습니다.
  • Windows Server 2012 R2의 AD FS에서 Windows Server 2016의 AD FS로.
  • Windows Server 2016의 AD FS에서 Windows Server 2019의 AD FS로.

SAML 업데이트

다음 SAML(Security Assertion Markup Language) 업데이트는 AD FS 2019에 있습니다.

• 버그 수정: 집계된 페더레이션의 버그를 수정합니다. 집계된 페더레이션 지원(예: InCommon)에 대한 수많은 버그 수정이 있었습니다. 다음 영역에서 수정 사항을 받았습니다.
  • 집계된 페더레이션 메타데이터 문서에서 많은 수의 엔터티에 대한 크기 조정이 향상되었습니다. 이전에는 "ADMIN0017" 오류로 크기 조정이 실패했습니다.
  • PowerShell cmdlet을 통해 Get-AdfsRelyingPartyTrustsGroup 'ScopeGroupID' 매개 변수를 사용하여 쿼리합니다.
  • 중복 entityID와 관련된 오류 조건 처리

범위 매개 변수의 Azure AD 스타일 리소스 사양

이전에는 AD FS를 사용하려면 원하는 리소스 및 범위가 인증 요청에서 별도의 매개 변수에 있어야 했습니다. 예를 들어 다음 OAuth 요청은 일반적으로 보내는 것처럼 보일 수 있습니다.

https://fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

서버 2019에서 AD FS를 사용하면 이제 범위 매개 변수에 포함된 리소스 값을 전달할 수 있습니다. 이 변경은 Azure AD에 대해서도 인증을 수행할 수 있는 방법과 일치합니다.

이제 범위 매개 변수를 공백으로 구분된 목록으로 구성할 수 있습니다. 여기서 각 항목은 리소스/범위로 구조화됩니다.

참고 항목

인증 요청에서 리소스를 하나만 지정할 수 있습니다. 요청에 둘 이상의 리소스가 포함된 경우 AD FS는 오류를 반환하고 인증은 성공하지 못합니다.

oAuth에 PKCE(코드 교환용 증명 키) 지원

인증 코드 부여를 사용하는 OAuth 퍼블릭 클라이언트는 인증 코드 가로채기 공격에 취약합니다. 이 공격은 RFC 7636에 잘 설명되어 있습니다. 이 공격을 완화하기 위해, Server 2019의 AD FS는 OAuth 인증 코드 부여 흐름을 위한 PKCE(코드 교환용 증명 키)를 지원합니다.

PKCE 지원을 사용하기 위해 이 사양은 OAuth 2.0 권한 부여 및 액세스 토큰 요청에 더 많은 매개 변수를 추가합니다.

A. 클라이언트는 "code_verifier"라는 비밀을 만들고 기록하며 변환된 버전 "t(code_verifier)"("code_challenge"이라고 함)를 파생시킵니다. 비밀은 "t_m" 변환 메서드와 함께 OAuth 2.0 권한 부여 요청으로 전송됩니다.

B. 권한 부여 엔드포인트는 평소와 같이 응답하지만 "t(code_verifier)" 및 변환 메서드를 기록합니다.

C. 그런 다음 클라이언트는 평소와 같이 액세스 토큰 요청에 권한 부여 코드를 보내지만 (A)에서 생성된 "code_verifier" 비밀을 포함합니다.

D. AD FS는 "code_verifier"를 변환하고 (B)의 "t(code_verifier)"와 비교합니다. 같지 않으면 액세스가 거부됩니다.

2019년에 추가 인증 공급자를 선택하는 방법

AD FS는 이미 클레임 규칙 정책에 따라 추가 인증 트리거를 지원합니다. 이러한 정책은 특정 RP 또는 전역 수준에서 설정할 수 있습니다. cmdlet Set-AdfsRelyingPartyTrust(AD FS)를 사용하여 특정 RP에 대한 추가 인증 정책을 설정할 수 있습니다. | AdditionalAuthenticationRules 또는 AdditionalAuthenticationRulesFile 매개 변수를 전달하여 Microsoft Docs를 만듭니다. 전역적으로 설정하려면 관리자가 cmdlet Set-AdfsAdditionalAuthenticationRule(AD FS) | Microsoft Docs.

예를 들어 2012 R2 이상 관리자는 요청이 엑스트라넷에서 오는 경우 추가 인증을 요청하는 다음 규칙을 이미 작성할 수 있습니다.

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "https://schemas.microsoft.com/claims/multipleauthn" );' 

2019년 고객은 이제 클레임 규칙을 사용하여 추가 인증을 위해 호출할 다른 인증 공급자를 결정할 수 있습니다. 이 기능은 다음 두 가지 시나리오에 유용합니다.

고객은 다른 인증 공급자에서 다른 인증 공급자로 전환하고 있습니다. 이렇게 하면 사용자를 최신 인증 공급자에 온보딩할 때 그룹을 사용하여 호출되는 추가 인증 공급자를 제어할 수 있습니다.

고객은 특정 애플리케이션에 대해 특정 추가 인증 공급자(예: 인증서)가 필요하지만 다른 애플리케이션의 경우 다른 방법(Azure AD Multi-Factor Authentication)이 필요합니다.

이 구성은 다른 인증 정책에서 클레임 https://schemas.microsoft.com/claims/authnmethodsproviders 을 발급하여 수행할 수 있습니다. 이 클레임의 값은 인증 공급자의 이름이어야 합니다.

이제 2019년에 이전 클레임 규칙을 수정하여 시나리오에 따라 인증 공급자를 선택할 수 있습니다.

다른 인증 공급자에서 다른 인증 공급자로 전환: 이전에 멘션 규칙을 수정하여 그룹 SID S-1-5-21-608905689-872870963-3921916988-12345에 있는 사용자에 대해 Azure AD Multi-Factor Authentication을 선택할 수 있습니다. 예를 들어 엔터프라이즈에서 관리하는 그룹에 대해 이 수정을 사용하여 Azure AD Multi-Factor Authentication에 등록된 사용자를 추적할 수 있습니다. 이 수정 사항은 관리자가 인증서 인증을 사용하려는 나머지 사용자에게도 적용됩니다.

'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "AzureMfaAuthentication"); 

not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "CertificateAuthentication");’ 

이 예제에서는 두 개의 서로 다른 애플리케이션에 대해 두 개의 서로 다른 인증 공급자를 설정하는 방법을 보여 줍니다.

Azure AD Multi-Factor Authentication을 추가 인증 공급자로 사용하도록 애플리케이션 A를 설정합니다.

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");' 

인증서를 추가 인증 공급자로 사용하도록 애플리케이션 B를 설정합니다.

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");' 

관리 둘 이상의 추가 인증 공급자를 허용하는 규칙을 만들 수도 있습니다. 이 경우 AD FS는 발급된 인증 메서드 공급자를 표시하며 사용자는 해당 공급자 중 하나를 선택할 수 있습니다. 여러 개의 추가 인증 공급자를 허용하려면 여러 클레임 https://schemas.microsoft.com/claims/authnmethodsproviders을 발급해야 합니다.

클레임 평가에서 인증 공급자를 반환하지 않으면 AD FS는 AD FS에서 관리자가 구성한 모든 추가 인증 공급자를 표시하기 위해 대체됩니다. 그런 다음 사용자는 적절한 인증 공급자를 선택해야 합니다.

다른 모든 인증 공급자를 허용하려면 관리자가 cmdlet(Get-AdfsGlobalAuthenticationPolicy)을 사용할 수 있습니다. AdditionalAuthenticationProvider. 클레임 값 https://schemas.microsoft.com/claims/authnmethodsproviders 은 이전에 멘션 cmdlet에서 반환된 공급자 이름 중 하나여야 합니다.

RP가 AD FS Windows Server 2016에서 액세스 제어 정책을 사용하는 경우 특정 추가 인증 공급자를 트리거할 수 없습니다. | Microsoft Docs. 애플리케이션을 액세스 제어 정책에서 벗어나면 AD FS는 해당 정책을 Access Control 정책에서 AdditionalAuthenticationRules 및 IssuanceAuthorizationRules로 복사합니다. 따라서 관리자가 특정 인증 공급자를 사용하려는 경우 액세스 제어 정책을 사용하지 않도록 이동한 다음 AdditionalAuthenticationRules를 수정하여 특정 인증 공급자를 트리거할 수 있습니다.

FAQ

AD FS 관리 이벤트 로그 오류를 어떻게 할까요? "잘못된 Oauth 요청을 받았습니다. 클라이언트 'NAME'은 범위가 'ugs'인 리소스에 액세스할 수 없습니다."?

다음 단계에 따라 문제를 해결합니다.

1. AD FS 관리 콘솔을 시작합니다. 서비스 > 범위 설명으로 이동합니다.
2. "범위 설명"에서 더 많은 옵션을 선택하고 범위 설명 추가를 선택합니다.
3. 이름 아래에 "ugs"를 입력하고 [확인 적용>]을 선택합니다.
4. PowerShell을 관리istrator로 시작합니다.
5. Get-AdfsApplicationPermission 명령을 실행합니다. 가 있는 ScopeNames :{openid, aza} 것을 찾습니다 ClientRoleIdentifier. 을 기록해 ObjectIdentifier둡다.
6. Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs' 명령을 실행합니다.
7. AD FS 서비스를 다시 시작합니다.
8. 클라이언트에서 클라이언트를 다시 시작합니다. WHFB(비즈니스용 Windows Hello 구성하라는 메시지가 표시됩니다.
9. 구성 창이 팝업되지 않으면 추적 로그를 수집하고 추가 문제를 해결해야 합니다.

Azure AD에 대해 요청을 수행하는 방법과 같은 범위 값의 일부로 리소스 값을 전달할 수 있나요?

서버 2019에서 AD FS를 사용하면 이제 범위 매개 변수에 포함된 리소스 값을 전달할 수 있습니다. 이제 범위 매개 변수를 공백으로 구분된 목록으로 구성할 수 있습니다. 여기서 각 항목은 리소스/범위로 구조화됩니다. 예: <create a valid sample request>

AD FS에서 PKCE 확장을 지원하나요?

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

Active Directory 페더레이션 서비스에 대 한 Windows Server 2016의 새로운 기능

이전 버전의 AD FS에 대한 정보를 찾고 있는 경우 Windows Server 2012 또는 2012 R2 및 AD FS 2.0의 AD FS 문서를 참조하세요.

AD FS는 Office 365, 클라우드 기반 SaaS 애플리케이션 및 회사 네트워크의 애플리케이션을 비롯한 다양한 애플리케이션에서 액세스 제어 및 Single Sign-On을 제공합니다.

• IT 조직의 경우 동일한 자격 증명 및 정책 집합을 기반으로 모든 컴퓨터에서 최신 및 레거시 애플리케이션 모두에 로그온 및 액세스 제어를 제공할 수 있습니다.
• 사용자의 경우 친숙한 동일한 계정 자격 증명을 사용하여 원활한 로그온을 제공합니다.
• 개발자를 위한 애플리케이션, 하지 인증 또는 identity에 노력을 집중할 수 있도록 id가 조직 디렉터리에 거주 하는 사용자를 인증 하는 간편한 방법을 제공 합니다.

엑스트라넷에서 암호 제거

AD FS 2016을 사용하면 암호 없이 로그인할 수 있는 세 가지 새로운 옵션을 사용할 수 있으므로 조직은 피싱, 유출 또는 도난된 암호로 인한 네트워크 손상 위험을 방지할 수 있습니다.

Azure Active Directory 다단계 인증으로 로그인

AD FS 2016은 Windows Server 2012 R2에서 AD FS의 MFA(다단계 인증) 기능을 기반으로 합니다. 이제 먼저 사용자 이름과 암호를 입력하지 않고 Azure AD Multi-Factor Authentication 코드만 사용하여 로그온을 허용할 수 있습니다.

• Azure AD Multi-Factor Authentication을 기본 인증 방법으로 사용하면 사용자에게 Azure Authenticator 앱에서 사용자 이름 및 OTP 코드를 입력하라는 메시지가 표시됩니다.
• Azure AD Multi-Factor Authentication을 보조 또는 추가 인증 방법으로 사용하면 사용자는 기본 인증 자격 증명을 제공합니다. 사용자 이름 및 암호, 스마트 카드 또는 사용자 또는 디바이스 인증서를 사용하여 Windows 통합 인증을 사용하여 로그인할 수 있습니다. 그런 다음 텍스트, 음성 또는 OTP 기반 Azure AD Multi-Factor Authentication 로그인에 대한 프롬프트가 표시됩니다.
• 새로운 기본 제공 Azure AD Multi-Factor Authentication 어댑터를 사용하면 AD FS를 사용한 Azure AD Multi-Factor Authentication에 대한 설정 및 구성이 더 간단해졌습니다.
• 조직은 온-프레미스 Azure AD Multi-Factor Authentication 서버 없이도 Azure AD Multi-Factor Authentication을 활용할 수 있습니다.
• Azure AD Multi-Factor Authentication은 인트라넷 또는 엑스트라넷 또는 액세스 제어 정책의 일부로 구성할 수 있습니다.

AD FS를 사용한 Azure AD Multi-Factor Authentication에 대한 자세한 내용은 AD FS 2016 및 Azure AD Multi-Factor Authentication 구성을 참조하세요.

규격 디바이스에서 암호 없는 액세스

에 로그인 할 수 있도록 하려면 이전 디바이스 등록 기능을 기반으로 하는 AD FS 2016 및 액세스 제어 디바이스 준수 상태를 기반으로 합니다. 사용자는 디바이스 자격 증명을 사용하여 로그온할 수 있으며, 디바이스 특성이 변경되면 규정 준수가 다시 평가되므로 항상 정책이 적용되는지 확인할 수 있습니다. 이 기능을 사용하면 다음과 같은 정책을 사용할 수 있습니다.

• 관리 및/또는 규정을 준수하는 디바이스에서만 Access를 사용하도록 설정합니다.
• 관리 및/또는 규정을 준수하는 디바이스에서만 엑스트라넷 액세스를 사용하도록 설정합니다.
• 관리되지 않거나 규정을 준수하지 않는 컴퓨터에 대해 다단계 인증이 필요합니다.

AD FS는 하이브리드 시나리오에서 조건부 액세스 정책의 온-프레미스 구성 요소를 제공합니다. 클라우드 리소스에 대 한 조건부 액세스에 대 한 Azure AD에 디바이스를 등록할 때 AD FS 정책도에 대 한 디바이스 id는 사용할 수 있습니다.

클라우드에서 디바이스 기반 조건부 액세스를 사용하는 방법에 대한 자세한 내용은 Azure Active Directory 조건부 액세스를 참조 하세요.

디바이스를 사용 하는 방법에 대 한 자세한 내용은 AD FS 사용 하 여 조건부 액세스 기반

• AD FS를 사용한 디바이스 기반 조건부 액세스 계획
• AD FS의 액세스 제어 정책

비즈니스용 Windows Hello로 로그인

참고 항목

현재 Google Chrome 및 Chromium 오픈 소스 프로젝트 브라우저에서 빌드된 새로운 Microsoft Edge는 비즈니스용 Windows Hello 사용하는 브라우저 기반 SSO(Single Sign-On)에서 지원되지 않습니다. Internet Explorer 또는 이전 버전의 Microsoft Edge를 사용하세요.

Windows 10 디바이스는 Windows Hello 및 비즈니스용 Windows Hello를 도입하여 사용자 암호를 사용자 제스처(PIN, 지문 또는 안 면 인식 같은 생체 인식 제스처)로 보호된 강력한 디바이스 바인딩 사용자 자격 증명으로 바꿉니다. AD FS 2016은 사용자가 암호를 제공하지 않고 인트라넷 또는 엑스트라넷에서 AD FS 애플리케이션에 로그인할 수 있도록 이러한 새로운 Windows 10 기능을 지원합니다.

조직에서 비즈니스용 Windows Hello 사용하는 방법에 대한 자세한 내용은 조직에서 비즈니스용 Windows Hello 사용을 참조하세요.

애플리케이션에 대한 보안 액세스

다음 변경 내용은 AD FS의 애플리케이션에 대한 보안 액세스에 영향을 줍니다.

최신 인증

AD FS 2016은 Windows 10 및 최신 iOS 및 Android 디바이스 및 앱에 더 나은 사용자 환경을 제공하는 최신 프로토콜을 지원합니다.

자세한 내용은 개발자용 AD FS 시나리오를 참조 하세요.

몰라도 액세스 제어 정책 구성 클레임 규칙 언어

이전에는 AD FS 관리자가 AD FS 클레임 규칙 언어를 사용하여 정책을 구성해야 했기 때문에 정책을 구성하고 기본. 액세스 제어 정책을 사용 하 여 관리자가 템플릿을 사용 하 여 기본 제공 같은 일반적인 정책 적용

• 인트라넷 액세스만 허용합니다.
• 모든 사용자를 허용하고 엑스트라넷에서 MFA를 요구합니다.
• 모든 사용자를 허용하고 특정 그룹의 MFA를 요구합니다.

템플릿은 마법사 기반 프로세스를 사용하여 예외 또는 추가 정책 규칙을 추가하여 쉽게 사용자 지정할 수 있으며 일관된 정책 적용을 위해 하나 이상의 애플리케이션에 적용할 수 있습니다.

자세한 내용은 AD FS의 액세스 제어 정책을 참조 하세요.

비 AD LDAP 디렉터리에 대해 로그온 사용

많은 조직에는 Active Directory 및 타사 디렉터리의 조합입니다. LDAP(Lightweight Directory Access Protocol) v3 규격 디렉터리에 저장된 사용자를 인증하기 위한 AD FS 지원이 추가되면서 이제 AD FS를 다음 용도로 사용할 수 있습니다.

• 타사, LDAP v3 호환 디렉터리에 있는 사용자입니다.
• Active Directory 양방향 트러스트가 구성되지 않은 Active Directory 포리스트의 사용자입니다.
• AD LDS(Active Directory Lightweight Directory Services)의 사용자입니다.

자세한 내용은 Configure AD FS to authenticate users stored in LDAP directories를 참조하세요.

더 나은 로그인 환경

다음 변경 내용은 AD FS에 대한 로그인 환경을 개선합니다.

로그인 환경 AD FS 애플리케이션에 대 한 사용자 지정

이전에 Windows Server 2012 R2의 AD FS는 애플리케이션당 텍스트 기반 콘텐츠의 하위 집합을 사용자 지정하는 기능과 함께 모든 신뢰 당사자 애플리케이션에 대한 일반적인 로그온 환경을 제공했습니다. Windows Server 2016 뿐만 아니라 메시지를 하지만 이미지, 애플리케이션별 로고 및 웹 테마를 지정할 수 있습니다. 또한 새로운 사용자 지정 웹 테마를 만들고 신뢰 당사자별로 이러한 테마를 적용할 수 있습니다.

자세한 내용은 AD FS 사용자 로그인 사용자 지정을 참조 하세요.

관리 효율성 및 운영 향상

다음 섹션에서 Windows Server 2016 Active Directory Federation Services에 도입 된 향상 된 운영 시나리오를 설명 합니다.

더 쉽게 관리 관리에 대 한 감사 간소화

Windows Server 2012 R2용 AD FS에는 단일 요청에 대해 생성된 수많은 감사 이벤트가 있었고 로그인 또는 토큰 발급 활동에 대한 관련 정보가 없거나 여러 감사 이벤트에 분산되었습니다. AD FS 기본적으로 감사 이벤트의 자세한 특성으로 인해 해제 됩니다. AD FS 2016 릴리스마다 감사 되었습니다 더 효율적이 고 상대적으로 간단 합니다.

자세한 내용은 Windows Server 2016에서 AD FS에 대한 향상된 감사 기능을 참조하세요.

Confederations에 참가 하기 위해 SAML 2.0와의 상호 운용성 향상

AD FS 2016에는 여러 엔터티가 포함된 메타데이터를 기반으로 트러스트를 가져오는 지원을 포함하여 더 많은 SAML 프로토콜 지원이 포함되어 있습니다. 이 변경을 통해 InCommon 페더레이션 및 eGov 2.0 표준을 준수하는 다른 구현과 같은 연맹에 참여하도록 AD FS를 구성할 수 있습니다.

자세한 내용은 SAML 2.0과의 상호 운용성 향상을 참조 하세요.

페더레이션된 Microsoft 365 사용자를 위한 간소화된 암호 관리

Active Directory Federation Services (AD FS) 암호 만료 클레임을 보내도록 AD FS로 보호 되는 신뢰 당사자 트러스트 (애플리케이션)를 구성할 수 있습니다. 이러한 클레임을 사용 하는 방법을 애플리케이션에 따라 달라 집니다. 예를 들어, 신뢰 당사자로 Office 365를 통해 업데이트 하도록 구현 Exchange 및 Outlook 곧에-수-만료 된 암호의 페더레이션된 사용자에 게 알려야 합니다.

자세한 내용은 암호 만료 클레임을 보내도록 AD FS 구성을 참조 하세요.

Windows Server 2012 r 2에서 AD FS에서 Windows Server 2016에서 AD FS로 이동 하는 것이 더 쉽습니다.

기존 팜에서 구성 내보내기 및 새로운, 병렬 팜에 가져오기 이전에 필요한 새 버전의 AD FS로 마이그레이션.

이제 Windows Server 2012 R2의 AD FS에서 Windows Server 2016의 AD FS로 쉽게 이동할 수 있습니다. Windows Server 2012 R2 팜에 새 Windows Server 2016 서버를 추가하고 팜은 Windows Server 2012 R2 팜 동작 수준에서 작동합니다. 이제 서버가 Windows Server 2012 R2 팜처럼 보이고 동작합니다.

그런 다음 새 Windows Server 2016 서버를 팜에 추가, 기능을 확인 하 고 부하 분산 장치에서 이전 서버를 제거 합니다. 모든 팜 노드가 Windows Server 2016을 실행한 후에는 팜 동작 수준을 2016으로 업그레이드하고 새 기능을 사용할 준비가 된 것입니다.

자세한 내용은 Windows Server 2016에서 AD FS로 업그레이드를 참조하세요.