다음을 통해 공유


Exchange 온-프레미스에서 최신 인증 사용

개요

Exchange Server 2019 CU13 릴리스를 통해 Exchange Server ADFS를 STS(보안 토큰 서비스)로 사용하는 순수 온-프레미스 환경에 대해 (최신 인증이라고도 함) 지원 OAuth 2.0 합니다. 이 문서에서는 이 기능을 사용하도록 설정하기 위한 필수 구성 요소 및 단계를 제공합니다.

Exchange Server 2019의 최신 인증은 최신 인증에 Microsoft Entra ID 사용하는 하이브리드 최신 인증과 혼동해서는 안 됩니다. 실제로 HMA는 여전히 Exchange 하이브리드 구성의 모든 온-프레미스 및 클라우드 사용자에게 최신 인증을 사용하도록 설정하는 유일한 권장 방법입니다. 이 새로운 기능을 사용하면 Microsoft Entra ID 없거나 Exchange 하이브리드 구성에 없는 고객이 최신 인증을 사용할 수 있습니다.

최신 인증은 어떻게 작동하며 이 기능은 나에게 적용할 수 있나요?

최신 인증을 사용하면 사용자가 ADFS를 사용하여 Exchange에 인증할 수 있습니다. 사용자에 대해 최신 인증을 사용하도록 설정하면 Outlook 클라이언트가 ADFS로 리디렉션됩니다. 그러면 사용자는 자격 증명을 제공하거나 다단계 인증을 수행하여 인증할 수 있습니다. ADFS가 사용자를 인증하면 액세스 토큰이 생성됩니다. 이러한 액세스 토큰은 Exchange Server 유효성을 검사하여 사용자의 사서함에 대한 클라이언트 액세스를 제공합니다.

다음 다이어그램에서는 최신 인증을 사용하여 사용자를 인증하기 위한 Exchange Server, ADFS 및 Outlook 간의 조정을 보여 줍니다.

Exchange Server 2019 최신 인증 핸드셰이크 워크플로를 보여 주는 다이어그램 위의 차트에서 최종 사용자에 대해 최신 인증을 사용하도록 설정하면 3a, 4a, 5a 및 6a 단계가 수행됩니다. 3b단계, 4b는 사용자에 대해 최신 인증을 사용하지 않도록 설정할 때 발생합니다.

이 기능을 적용할 수 있는지 평가하려면 다음 표를 참조하세요.

Exchange 구성 이 기능을 적용할 수 있나요? 설명
2019년 Exchange Server 온-프레미스 Exchange organization 해당 없음
Exchange Server 2019, Exchange Server 2016 및 Exchange Server 2013이 혼합된 온-프레미스 Exchange organization 아니오 Exchange Server 2013은 지원되지 않습니다.
Exchange Server 2019 및 Exchange Server 2016이 혼합된 온-프레미스 Exchange organization Exchange 2019 서버만 Front-End(클라이언트 액세스) 서버로 사용할 수 있습니다.
HMA를 사용한 Exchange 하이브리드 organization 아니오 Microsoft Entra ID 사용하는 HMA가 기본 솔루션입니다. 새 인증 정책 사용에 대한 지침을 참조하세요.
HMA 없이 하이브리드 organization 교환 아니오 Microsoft Entra ID HMA를 사용합니다.

Exchange에서 최신 인증을 사용하도록 설정하기 위한 필수 구성 요소

Exchange Server 2019 CU13 이상

최신 인증을 사용하려면 클라이언트 연결에 사용되는 모든 서버에 Exchange Server 2019 CU13이 설치되어 있어야 합니다.

ADFS 2019 이상

온-프레미스 Exchange 환경에서 최신 인증을 사용하도록 설정하려면 Windows Server 2019 이상에서 ADFS(Active Directory Federation Services)가 필요합니다.

회사 외부 네트워크에서 클라이언트 액세스를 사용하도록 설정하려면 웹 애플리케이션 프록시 Server(Windows Server 2019 이상)가 필요할 수도 있습니다.

참고

ADFS 역할은 Exchange Server 구성할 수 없습니다. 자세한 내용은 AD FS 배포 토폴로지 계획을 참조하세요.

클라이언트 필수 구성 요소

최신 인증을 활용하려면 사용자에게 ADFS를 통해 최신 인증과 호환되는 Outlook 또는 기타 네이티브 운영 체제 클라이언트와 같은 클라이언트 애플리케이션이 필요합니다. 처음에 이 기능은 Windows용 Outlook에서 사용할 수 있습니다. 그러나 ADFS 최신 인증과의 호환성은 향후 다른 Outlook 클라이언트로 확장될 예정입니다.

Windows의 Outlook

ADFS를 통한 최신 인증 지원은 다음 버전의 Microsoft Outlook에서 사용할 수 있습니다.

Microsoft 365 앱 Outlook:

채널 지원 버전 빌드(이상)
참가자 채널 2304 16327.20200
현재 채널 2304 16327.20214
월간 엔터프라이즈 채널 2304 16327.20324
반기 기업 채널(미리 보기) 2402 17328.20184
반기 기업 채널 2402 17328.20452

Windows용 Outlook(볼륨 라이선스 & 소매):

버전 않음 버전 빌드(이상)
Outlook 2016(모든 버전) 아니요 해당 없음 해당 없음
Outlook 2019(모든 버전) 아니요 해당 없음 해당 없음
Outlook 2021(소매) 2304 16327.20214
Outlook 2021(볼륨 라이선스) 아니요 해당 없음 해당 없음

여기에 설명된 단계에 따라 Office의 빌드 번호를 검사 수 있습니다.

Windows OS

Windows 클라이언트는 2023년 3월 14일 업데이트가 설치되어 있어야 합니다Windows 11 22H2 or later.

Windows 업데이트 기록을 검토하여 설치 KB5023706 되었는지 확인할 수 있습니다.

ADFS 최신 인증을 사용하는 프로토콜

다음 표에서는 ADFS 최신 인증 토큰을 활용하여 액세스할 수 있는 프로토콜을 간략하게 설명합니다. 더 많은 Exchange Server 프로토콜에 ADFS 최신 인증 지원을 추가하기 위해 지속적으로 노력하고 있습니다.

Protocol(프로토콜) 지원되는 ADFS 최신 인증
HTTP를 통한 MAPI(MAPI/HTTP)
Outlook Anywhere(RPC/HTTP) 아니오
EAS(Exchange Active Sync) 아니요(진행 중인 작업)
EWS(Exchange 웹 서비스)
OWA(Outlook on the Web) (클레임 기반 인증)
ECP(Exchange 관리 Center) (클레임 기반 인증)
OAB(오프라인 주소록)
IMAP 아니요
아니오

ADFS를 STS로 사용하여 Exchange Server 최신 인증을 구성하는 단계

이 섹션에서는 Exchange Server 2019 CU13에서 최신 인증을 구현하는 방법을 자세히 설명합니다.

모든 FE 서버에 Exchange 2019 CU13 설치(적어도)

클라이언트 연결에 사용되는 모든 서버는 Exchange 2019 CU13으로 업그레이드해야 합니다. 이렇게 하면 Exchange 2019에 대한 초기 클라이언트 연결에서 OAuth를 사용하고 2016년 Exchange Server 프록시 연결에서 Kerberos를 사용합니다.

Exchange 2019 CU13은 사용자 수준에서 최신 인증을 허용하거나 차단하는 새로운 인증 정책에 대한 지원을 추가합니다. 최신 인증 차단은 최신 인증을 지원하지 않는 클라이언트가 계속 연결할 수 있도록 하는 데 사용됩니다.

Exchange Server 몇 가지 새 인증 정책 매개 변수를 추가하려면 설치 프로그램을 사용하여 를 실행 /PrepareAD 해야 합니다.

  1. BlockModernAuthActiveSync
  2. BlockModernAuthAutodiscover
  3. BlockModernAuthImap
  4. BlockModernAuthMapi
  5. BlockModernAuthOfflineAddressBook
  6. BlockModernAuthPop
  7. BlockModernAuthRpc
  8. BlockModernAuthWebServices

CU13을 설치한 후 모든 기존 인증 정책(기본 인증 정책 포함)은 위의 매개 변수를 사용하지 않도록 설정합니다. 즉, HMA를 사용하는 고객은 기존 인증 정책을 변경할 필요가 없습니다.

Exchange 하이브리드 고객에게 새 인증 정책이 필요하지 않음

기존 Exchange 하이브리드 고객은 하이브리드 최신 인증을 사용해야 합니다. HMA를 사용하는 하이브리드 고객은 매개 변수 값을 BlockModernAuth* 그대로 0 두고 HMA를 계속 사용할 수 있습니다. ADFS를 사용하여 최신 인증을 설정하기 위해 설명된 단계는 Exchange 하이브리드를 사용하지 않고 순전히 온-프레미스인 고객에게만 관련됩니다.

ADFS(Active Directory Federation Services 설정)

고객은 Exchange 클라이언트가 OAuth(Forms 인증)를 사용하여 Exchange Server 연결할 수 있도록 환경에 ADFS를 설치하고 구성해야 합니다.

Exchange Server 조직의 ADFS 구성에 대한 인증서 요구 사항

ADFS에는 두 가지 기본 유형의 인증서가 필요합니다(자세한 내용은 이 문서를 참조하세요.)

  1. ADFS 서버, 클라이언트, Exchange 서버 및 선택적 웹 애플리케이션 프록시 서버 간의 암호화된 웹 서비스 트래픽에 대한 서비스 통신 SSL(Secure Sockets Layer) 인증서입니다. 모든 클라이언트가 이 인증서를 신뢰해야 하므로 내부 또는 상용 CA(인증 기관)에서 발급한 인증서를 사용하는 것이 좋습니다.
  2. ADFS 서버, Active Directory 도메인 컨트롤러 및 Exchange 서버 간의 암호화된 통신 및 인증을 위한 토큰 서명 인증서입니다. CA에서 토큰 서명 인증서를 요청하거나 자체 서명된 인증서를 만들어 토큰 서명 인증서를 가져올 수 있습니다.

Windows에서 SSL 인증서를 만들고 가져오는 방법에 대한 자세한 내용은 서버 인증서를 참조하세요.

이 시나리오에서 사용하는 인증서의 요약은 다음과 같습니다.

인증서의 CN(일반 이름) (주체, 주체 대체 이름 또는 와일드카드 인증서 일치) 유형 서버에 필요 설명
adfs.contoso.com
enterpriseregistration.contoso.com
CA에서 발급 ADFS 서버,
웹 애플리케이션 프록시 서버(선택 사항)
페더레이션 서버는 SSL 인증서를 사용하여 클라이언트 및 페더레이션 서버 프록시와의 SSL 통신을 위해 웹 서비스 트래픽을 보호합니다.

클라이언트 컴퓨터에서 SSL 인증서를 신뢰해야 하므로 신뢰할 수 있는 CA에서 서명한 인증서를 사용하는 것이 좋습니다. 선택하는 모든 인증서에는 해당 개인 키가 있어야 합니다.
ADFS 토큰 서명 - adfs.contoso.com CA의 자체 서명 또는 문제 ADFS 서버,
웹 애플리케이션 프록시 서버(선택 사항)
토큰 서명 인증서는 X509 인증서입니다. 페더레이션 서버는 연결된 퍼블릭/프라이빗 키 쌍을 사용하여 생성하는 모든 보안 토큰에 디지털 서명합니다. 여기에는 게시된 페더레이션 메타데이터 및 아티팩트 확인 요청의 서명이 포함됩니다.

ADFS 관리 스냅인에 여러 토큰 서명 인증서를 구성하여 하나의 인증서가 만료에 가까워지면 인증서 롤오버를 허용할 수 있습니다. 기본적으로 목록의 모든 인증서가 게시되지만 ADFS에서 토큰에 실제로 서명하는 데는 기본 토큰 서명 인증서만 사용됩니다. 선택하는 모든 인증서에는 해당 개인 키가 있어야 합니다.

엔터프라이즈 CA 또는 공용 CA에서 토큰 서명 인증서를 요청하거나 자체 서명된 인증서를 만들어 토큰 서명 인증서를 가져올 수 있습니다.
mail.contoso.com
autodiscover.contoso.com
CA에서 발급 Exchange 서버,
웹 애플리케이션 프록시 서버(선택 사항)
웹용 Outlook(및 기타 Exchange 서비스)에 대한 외부 클라이언트 연결을 암호화하는 데 사용되는 일반적인 인증서입니다. 자세한 내용은 Exchange 서비스에 대한 인증서 요구 사항을 참조하세요.

ADFS 서버 배포 및 구성

Windows Server 2019 이상을 사용하여 ADFS 서버를 배포합니다. ADFS 서버 배포 및 ADFS 서버구성 및 테스트 단계를 수행합니다. Exchange 서버 및 하나 이상의 클라이언트 컴퓨터에서 웹 브라우저에서 페더레이션 메타데이터의 URL을 열 수 있는지 확인합니다.

URL은 구문을 사용합니다.

https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

예를 들면 다음과 같습니다.

https://adfs.contoso.com/federationmetadata/2007-06/federationmetadata.xml

적절한 SSO 수명 선택

최종 사용자가 자주 다시 인증할 필요가 없도록 적절한 SSO 수명을 선택합니다. SSO 수명을 구성하려면 ADFS 서버에서 ADFS 관리를 열고 작업(ADFS 관리 창의 오른쪽에 있음)에서 선택합니다 Edit Federation Service Properties .

Web SSO lifetime (minutes)사용자가 다시 인증해야 하는 최대 시간인 를 입력합니다.

ADFS에서 인증 방법 구성

Windows용 Outlook에서 최신 인증을 사용하려면 기본 인증 방법을 구성해야 합니다. 아래와 같이 엑스트라넷과 인트라넷 모두에 Forms 인증을 선택하는 것이 좋습니다.

ADFS에서 디바이스 등록 사용

디바이스 등록이 구성되고 디바이스 등록 개요를 확인하여 디바이스 인증이 사용하도록 설정되어 있는지 확인합니다. 이 단계는 사용자에 대한 인증 프롬프트 수를 줄이는 것이 좋으며 ADFS에서 Access Control 정책을 적용하는 데 도움이 될 수 있습니다.

여기에 설명된 대로 디바이스 등록 서비스 검색 및 디바이스 등록 검색 서버 SSL 인증서를 구성하는 모든 단계를 완료 합니다.

Outlook용 ADFS 애플리케이션 그룹 만들기

  1. 마우스 오른쪽 단추를 클릭하고 Application Groups 를 클릭합니다 Add Application Group.

  2. 를 선택합니다 Native Application accessing a web API.

  3. 와 같은 Outlook 이름을 입력하고 다음을 클릭합니다.

  4. 에서 Native application page다음 client identifierredirect Uri 을 추가하고 Outlook에 대해 다음을 클릭합니다.

    • 클라이언트 식별자: d3590ed6-52b3-4102-aeff-aad2292ab01c

    • 리디렉션 URI(다음 두 URI 추가):

      urn:ietf:wg:oauth:2.0:oob

      ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c

  5. 탭에서 Configure Web API 자동 검색, 부하 분산 FQDN, 서버 FQDN 등을 포함하여 Exchange 환경에서 사용하는 모든 FQDN을 추가합니다. 예를 들어:

    • https://autodiscover.contoso.com/
    • https://mail.contoso.com/

    중요

    여기서는 모든 클라이언트 연결 URL이 적용되는지 또는 작동하지 않는지 확인하는 것이 중요합니다. 후행 /'s를 포함하고 URL이 https:// 시작하는지 확인합니다.

  6. 탭에서 Apply Access Control Policy 모든 사용자가 시작하도록 허용한 다음, 필요한 경우 나중에 변경합니다. 페이지 아래쪽에 있는 확인란을 검사 않습니다.

  7. 에서 Configure Application Permissions를 선택하고 Native Application appPermitted Scopes 검사 user_impersonation 아래에서 openid를 선택합니다. 이 외에도 기본적으로 확인됩니다.

  8. 도우미 완료합니다.

Outlook 애플리케이션 그룹에서 발급 변환 규칙 추가

위에서 만든 애플리케이션 그룹의 Outlook경우 발급 변환 규칙을 추가합니다. Outlook 애플리케이션 그룹을 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다.

Web API settings편집하고 아래에서 Issuance Transform Rules 다음 사용자 지정 규칙을 추가합니다.

클레임 규칙 이름 사용자 지정 규칙
ActiveDirectoryUserSID c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"] => issue(claim = c);
ActiveDirectoryUPN c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(claim = c);
AppIDACR => issue(Type = "appidacr", Value = "2");
SCP => issue(Type = "http://schemas.microsoft.com/identity/claims/scope", Value ="user_impersonation");

규칙을 추가한 후 는 Outlook - Web API Properties 다음과 같이 표시됩니다.

필요에 따라 엑스트라넷 액세스를 위해 웹 애플리케이션 프록시 구성할 수 있습니다.

웹 애플리케이션 프록시 Windows Server의 원격 액세스 서버 역할의 일부입니다. 사용자가 회사 네트워크 외부에서 웹 애플리케이션에 액세스할 수 있도록 역방향 프록시 기능을 제공합니다. 웹 애플리케이션 프록시 ADFS 및 함수를 ADFS 프록시로 사용하여 웹 애플리케이션에 대한 액세스를 미리 인증합니다.

웹 애플리케이션 프록시를 사용하려는 경우 웹 애플리케이션 프록시 서버 설치 및 구성에 설명된 단계를 사용하여 구성합니다. 구성되면 OAuth2를 사용하는 애플리케이션 게시에 설명된 단계를 사용하여 또는/에 mail.contoso.com 대한 Autodiscover.contoso.com 규칙을 게시할 수 있습니다.

필요에 따라 클라이언트 액세스를 위해 MFA를 구성할 수도 있습니다.

  1. 원하는 MFA 공급자를 사용하여 ADFS를 구성하려면 다음 링크를 참조하세요.

  2. MFA가 필요한 Access Control 정책을 구성합니다.

최신 인증 구성 Client-Side

모든 사용자에게 배포하기 전에 몇 명의 사용자로 최신 인증을 테스트하는 것이 좋습니다. 파일럿 사용자 그룹이 최신 인증을 사용할 수 있으면 더 많은 사용자를 배포할 수 있습니다.

  1. 클라이언트 업그레이드 및 OS 업그레이드:

    클라이언트 필수 구성 요소 섹션에 설명된 대로 최신 인증은 Windows용 Outlook에서만 지원됩니다. 최신 인증을 사용하려면 Outlook 클라이언트 참가자 채널이 2023년 3월 14일 업데이트 이상과 함께 Windows 11 OS 22H2에 설치되어야 합니다.

  2. 클라이언트 컴퓨터의 레지스트리 변경 내용:

    관리자는 사용자에 대한 레지스트리 값을 구성해야 합니다.

    최신 인증을 사용하도록 설정하고 Outlook에서 ADFS 도메인을 신뢰할 수 있는 도메인으로 추가합니다.

    1. ADFS 도메인을 신뢰할 수 있는 도메인으로 추가하려면 다음 키를 추가합니다.

      • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://ADFS domain/
      • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://ADFS domain

      참고

      ADFS 도메인의 끝에 "/"를 사용 및 사용하지 않고 두 개의 키를 추가합니다.

    2. Windows용 Outlook에서 ADFS를 통해 최신 인증을 사용하도록 설정하려면 에서 HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\다음 REG_DWORD 값을 추가합니다.

      이름
      EnableExchangeOnPremModernAuth 1

      배포 편의를 위해 그룹 정책 사용하여 이러한 레지스트리 변경 내용을 구성할 수 있습니다. organization 그룹 정책 사용하지 않는 경우 사용자는 레지스트리를 수동으로 구성해야 합니다(또는 제공한 스크립트 포함).

최종 사용자에 대한 인증 정책 만들기

organization 모든 사용자에게 ADFS를 사용하여 최신 인증을 지원하는 이메일 클라이언트가 없을 수 있습니다. 이 시나리오에서는 클라이언트를 지원한 사용자에 대해 최신 인증을 사용하도록 설정하고 그렇지 않은 최신 인증 사용자를 차단하는 것이 좋습니다.

사용자 집합에 대해 최신 인증을 사용하도록 설정하고 나머지 사용자에 대한 최신 인증을 차단하려면 다음 두 개 이상의 인증 정책을 만들어야 합니다.

  • 기본적으로 최신 인증을 차단하는 조직 전체 정책입니다.
  • 일부 사용자에게 최신 인증을 선택적으로 허용하는 두 번째 정책입니다.

기본적으로 최신 인증을 차단하는 organization 수준 정책 만들기

최신 인증을 사용하도록 설정하면 모든 Outlook 클라이언트에서 OAuth 토큰을 사용하려고 하지만 일부 클라이언트(예: Mac용 Outlook)는 Microsoft Entra ID OAuth 토큰만 가져올 수 있습니다. 따라서 최신 인증을 사용하도록 설정하면 이러한 클라이언트는 연결할 수 없습니다.

이 시나리오를 방지하려면 최신 인증을 사용하지 않도록 organization 수준 정책을 설정할 수 있습니다. 아래 예제에서는 라는 Block Modern Auth새 인증 정책을 만듭니다.

New-AuthenticationPolicy "Block Modern Auth" -BlockModernAuthWebServices -BlockModernAuthActiveSync -BlockModernAuthAutodiscover -BlockModernAuthImap -BlockModernAuthMapi -BlockModernAuthOfflineAddressBook -BlockModernAuthPop -BlockModernAuthRpc

이 정책은 다음 명령을 사용하여 조직 수준에서 설정할 수 있습니다.

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Modern Auth"

최신 인증을 사용하도록 설정하는 사용자 수준 인증 정책 만들기

다음으로 최신 인증을 사용하도록 설정하는 두 번째 인증 정책을 만듭니다. 지원되는 Outlook 클라이언트가 있는 모든 사용자에게는 클라이언트가 최신 인증을 사용할 수 있도록 이 인증 정책이 할당됩니다.

아래 예제에서는 다음 명령을 사용하여 라는 Allow Modern Auth 새 인증을 만듭니다.

New-AuthenticationPolicy "Allow Modern Auth"

ADFS OAuth 토큰을 사용하도록 Exchange Server 구성

  1. 다음 가상 디렉터리에서 OAuth를 사용할 수 있는지 확인합니다. 사용하도록 설정하지 않은 경우 이러한 모든 가상 디렉터리에서 OAuth를 사용하도록 설정합니다.

    Get-MapiVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*
    Get-WebServicesVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*
    Get-OabVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*
    Get-AutodiscoverVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*
    Get-ActiveSyncVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*
    
  2. 다음 명령을 실행합니다.

    New-AuthServer -Type ADFS -Name MyADFSServer -AuthMetadataUrl https://<adfs server FQDN>/FederationMetadata/2007-06/FederationMetadata.xml
    

    이 명령은 ADFS용 Exchange Server 새 인증 서버 개체를 만드는 데 필요합니다. 인증 서버 개체는 신뢰할 수 있는 발급자의 목록입니다. 이러한 발급자의 OAuth 토큰만 허용됩니다.

  3. 다음 명령을 실행합니다.

    Set-AuthServer -Identity MyADFSServer -IsDefaultAuthorizationEndpoint $true
    

    방금 추가 DefaultAuthorizationEndpoint한 인증 서버를 로 설정합니다. 최신 인증 헤더를 보급할 때 Exchange Server 의 인증 URL을 DefaultAuthorizationEndpoint보급합니다. 이는 클라이언트가 인증에 사용할 엔드포인트를 아는 방법입니다.

  4. organization 수준에서 최신 인증을 사용하도록 설정하려면 이 명령을 실행해야 합니다.

    Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
    
  5. 인증 정책을 할당하여 지원되는 클라이언트를 사용하는 사용자에게 최신 인증을 Allow Modern Auth 사용하도록 설정합니다.

    Set-User -Identity User -AuthenticationPolicy "Allow Modern Auth"
    

최신 인증 흐름 확인

올바르게 구성되면 사용자가 Exchange 서버에 연결할 때 ADFS 로그인 프롬프트가 표시됩니다.

사용자에 대해 최신 인증을 사용하도록 설정된 경우 다른 클라이언트에 미치는 영향

여러 클라이언트(예: Windows용 Outlook 및 Outlook Mobile)가 있는 최신 인증에 대해 사용하도록 설정된 사용자는 각 클라이언트에 대해 서로 다른 환경을 갖게 됩니다. 다음은 최신 인증을 사용할 때 클라이언트가 작동하는 방식에 대한 요약입니다. 다음 표에서는 가 조직 수준에서 로 DefaultAuthenticationPolicy 적용된다고 Block Modern Auth 가정합니다.

클라이언트 동작
Windows용 Outlook(새 버전) 기본적으로 최신 인증을 사용합니다.
Windows용 Outlook(이전 버전) 최신 인증을 사용하려고 하지만 실패합니다.
Outlook Mac 최신 인증을 사용하려고 하지만 실패합니다. 지원은 나중에 제공될 예정입니다.
Outlook iOS 기본 인증으로 대체됩니다.
Outlook Android 기본 인증으로 대체됩니다.
iOS 메일 앱 기본 인증으로 대체됩니다.
Gmail 앱 기본 인증으로 대체됩니다.
OWA/ECP 인증 정책을 사용하지 않습니다.
구성 방법에 따라 는 최신 인증 또는 기본 인증을 사용합니다.
Windows 메일 앱 기본 인증으로 대체되지 않습니다.
Thunderbird 클라이언트 기본 인증으로 대체되지 않습니다.
PowerShell 기본 인증을 사용합니다.

다른 클라이언트에 대해 최신 인증을 사용하도록 설정된 경우 OWA/ECP에 미치는 영향

고객은 웹용 Outlook ADFS 클레임 기반 인증을 사용하거나 사용하지 않을 수 있습니다. 위에서 언급한 단계는 다른 클라이언트에 대해 OAuth를 사용하도록 설정하는 데 필요하며 OWA/ECP 구성 방식에는 영향을 주지 않습니다.

웹용 Outlook AD FS 클레임 기반 인증 사용

변경 인증 정책 후 대기 시간

최신 인증을 허용하거나 레거시 인증을 차단하도록 인증 정책을 변경한 후:

  • 프런트 엔드 서버에서 새 정책을 읽을 때까지 30분 정도 기다립니다.

    또는

  • 모든 프런트 엔드 서버에서 IIS 재설정을 수행합니다.

Exchange Server 최신 인증을 사용하도록 설정한 후 하이브리드 최신 인증으로 마이그레이션

나중에 Exchange 하이브리드를 구성하기로 결정한 ADFS에서 최신 인증을 사용하는 고객은 하이브리드 최신 인증으로 이동해야 합니다. 마이그레이션에 대한 자세한 단계는 이 문서의 이후 버전에 추가됩니다.

인증서 갱신

현재 인증서 구성 평가

Exchange Server 대한 클라이언트 연결과 관련하여 평가해야 하는 인증서는 프런트 엔드 IIS 사이트에 바인딩된 인증서입니다. ADFS 서버의 경우 에서 Get-AdfsCertificate 반환된 모든 인증서가 최신인지 확인하는 것이 이상적입니다.

  1. Exchange Server 관련 인증서를 식별하려면 Exchange Management Shell 내에서 다음을 수행합니다.

    Import-Module WebAdministration
    (Get-ChildItem IIS:SSLBindings | Where-Object {($_.Sites -ne $null) -and ($_.Port -eq "443")}).Thumbprint | ForEach-Object {Get-ExchangeCertificate $_ | Where-Object {$_.Services -Match "IIS"} | Format-Table Thumbprint, Services, RootCAType, Status, NotAfter, Issuer -AutoSize -Wrap}
    
  2. ADFS 서버에서 활성 인증서를 검토하려면 PowerShell 내에서 다음을 수행합니다.

    Get-AdfsCertificate | Format-Table CertificateType, Thumbprint, Certificate -AutoSize -Wrap
    

Exchange Server 인증서 업데이트

클라이언트 연결을 위해 Exchange 인증서를 업데이트해야 하는 경우 새 인증서를 발급하여 Exchange Server로 가져와야 합니다. 그 후에는 최소한 IIS에 대해 인증서를 사용하도록 설정해야 합니다. 구성에 따라 새 인증서에 대해 다른 서비스를 사용하도록 설정해야 하는지 평가합니다.

다음은 Exchange 관리 셸 내의 기존 인증서를 기반으로 모든 서버에서 새 인증서를 만들고, 완료하고, 사용하도록 설정하고, 가져오는 샘플입니다.

  1. 기존 인증서를 기반으로 Exchange Management Shell 내에서 새 인증서 요청을 생성합니다.

    $txtrequest = Get-ExchangeCertificate <Thumbprint> | New-ExchangeCertificate -GenerateRequest -PrivateKeyExportable $true
    
  2. 새 인증서 요청의 원하는 출력 경로를 포함하는 변수를 준비합니다.

    $requestFile = "C:\temp\CertRequest.req"
    
  3. 인증서 요청 파일을 만듭니다.

    [System.IO.File]::WriteAllBytes($requestFile, [System.Text.Encoding]::Unicode.GetBytes($txtrequest))
    

    참고

    인증서 요청에 대한 폴더 경로가 이미 있어야 합니다.

  4. 요청 파일을 CA(인증 기관)와 공유합니다. 완료된 인증서를 가져오는 데 필요한 단계는 CA에 따라 다릅니다.

    참고

    .p7b 는 완료된 요청에 대한 기본 형식입니다.

  5. 완료된 요청의 전체 경로를 포함하는 변수를 준비합니다.

    $certFile = "C:\temp\ExchangeCert.p7b"
    
  6. 원래 요청을 생성한 서버로 요청을 가져옵니다.

    Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes($certFile)) -PrivateKeyExportable $true
    
  7. 완료된 인증서를 보호하기 위한 암호에 대한 단계 변수:

    $pw = Read-Host "Enter password" -AsSecureString
    
  8. 인증서 이진 파일을 변수로 내보냅니다.

    $binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded
    
  9. 완료된 인증서의 원하는 출력 경로에 대한 스테이지 변수:

    $certificate = "\\$env:computername\c$\temp\CompletedExchangeCert.pfx"
    
  10. 다른 서버에서 가져올 완료된 요청을 내보냅니다.

    [System.IO.File]::WriteAllBytes($certificate, $binCert.FileData)
    
  11. 인증서에 바인딩되어야 하는 서비스를 사용하도록 설정합니다.

    Enable-ExchangeCertificate <Thumbprint> -Services IIS
    

    참고

    이전 인증서 구성에 따라 위의 샘플에 더 많은 서비스를 추가해야 할 수 있습니다.

  12. 호스트 파일이 있는 모든 클라이언트 네임스페이스에 대해 클라이언트를 서버로 보내 인증서가 의도한 대로 작동하는지 확인합니다.

  13. 다른 모든 Exchange 서버에서 Exchange 인증서를 가져옵니다.

    Import-ExchangeCertificate -PrivateKeyExportable $true -FileData ([System.IO.File]::ReadAllBytes($certificate)) -Password $pw -Server <Server-Name>
    

    참고

    매개 변수를 -PrivateKeyExportable 포함하는 것은 다른 Exchange 서버로 가져올 때 선택 사항입니다.

  14. 다른 모든 Exchange 서버에서 필요한 Exchange 서비스에 대해 Exchange 인증서를 사용하도록 설정합니다.

    Enable-ExchangeCertificate <Thumbprint> -Services IIS -Server <Server-Name>
    

    참고

    이전 인증서 구성에 따라 위의 샘플에 더 많은 서비스를 추가해야 할 수 있습니다.

ADFS에서 인증서 업데이트

ADFS에 대한 업데이트가 필요한 인증서 유형에 따라 아래에 설명된 단계를 따라야 하는지 여부가 결정됩니다.

인증서 Service-Communications

이 샘플에서는 Exchange Server 인증서 단계에 따라 생성된 것과 같이 인증서 .pfx 를 형식으로 가져오는 데 필요한 PowerShell을 제공합니다. 기본 ADFS 서버에 로그온했는지 확인합니다.

  1. 인증서의 암호를 포함하는 변수를 준비합니다.

    $pw = Read-Host "Enter password" -AsSecureString
    
  2. 인증서의 전체 경로를 포함하는 변수를 준비합니다.

    $certificate = "\\E2k19-1\c$\temp\CompletedExchangeCert.pfx"
    
  3. 인증서를 LocalMachine의 개인 저장소로 가져옵니다.

    Import-PfxCertificate -FilePath $certificate -CertStoreLocation Cert:\LocalMachine\my -Password $pw
    
  4. Service-Communications 인증서를 업데이트합니다.

    Set-AdfsSslCertificate -Thumbprint <Thumbprint>
    

인증서 Token-Signing 및 Token-Decryption

AD FS용 TS 및 TD 인증서 가져오기 및 구성 설명서에 설명된 단계를 따릅니다.

참고

웹용 Outlook 대한 ADFS 클레임 기반 인증에서 Token-Signing 기본 자체 서명된 인증서를 사용하려면 Exchange Server에 인증서를 설치해야 합니다.