適用対象:
2016 2019 Subscription Edition
概要
Windows 拡張保護は、Windows Serverの既存の認証を強化し、認証リレーまたは中間者 (MitM) 攻撃を軽減します。 この軽減策は、主に TLS 接続に使用される Channel Binding Token (CBT) を介して指定されたチャネル バインド情報によって実装されるセキュリティ情報を使用して実現されます。
拡張保護は、Exchange Server 2019 CU14 (またはそれ以降) をインストールするときに既定で有効になります。 詳細については、「Released: 2024 H1 Cumulative Update for Exchange Server」を参照してください。
以前のバージョンのExchange Server (たとえば、Exchange Server 2016) では、一部またはすべての Exchange サーバーで ExchangeExtendedProtectionManagement.ps1 スクリプトを使用して Extended Protection を有効にすることができます。
このドキュメントで使用される用語
Virtual Directory または vDir
Exchange Serverは、Exchange ActiveSync、Outlook on the Web、AutoDiscover サービスなどの Web アプリケーションへのアクセスを許可するために使用されます。 管理者は、認証、セキュリティ、レポート設定など、いくつかの仮想ディレクトリ設定を構成できます。 拡張保護は、このような認証設定の 1 つです。
拡張保護の設定
Channel Binding TokensまたはCBTのチェックの動作を制御します。 この設定で使用できる値を次の表に示します。
| 値 | 説明 |
|---|---|
| なし | IIS が CBT チェックを実行しないことを指定します。 |
| 許可 | CBT チェックが有効になっているが、必須ではないことを指定します。 この設定により、Extended Protection をサポートするクライアントとのセキュリティで保護された通信が可能になり、引き続き Extended Protection を使用できないクライアントがサポートされます。 |
| 必須 | この値は、CBT チェックが必要であることを指定します。 この設定は、拡張保護をサポートしていないクライアントをブロックします。 |
SSL フラグ
クライアントがクライアント証明書を使用して特定の方法で IIS 仮想ディレクトリに接続するには、SSL 設定の構成が必要です。 拡張保護を有効にするには、必要な SSL フラグが SSL され、 SSL128されます。
SSL オフロード
クライアントとExchange Serverの間のデバイス上の接続を終了し、暗号化されていない接続を使用してExchange Serverに接続します。
SSL ブリッジ
ネットワークの端にあるデバイスが SSL トラフィックを復号化し、それを再暗号化してから Web サーバーに送信するプロセスについて説明します。
モダン ハイブリッドまたはハイブリッド エージェント
これは、Exchange ハイブリッド機能を有効にするために、従来のハイブリッド (ファイアウォール経由の受信ネットワーク接続など) の構成要件の一部を削除する Exchange ハイブリッドを構成する方法の名前です。 この機能の詳細については、 こちらを参照してください。
パブリック フォルダー
共有アクセス用に設計されており、深い階層のコンテンツを参照しやすくするために役立ちます。 パブリック フォルダーの詳細については、 こちらを参照してください。
Exchange Serverで拡張保護を有効にするための前提条件
ヒント
Exchange Serverヘルス チェッカー スクリプトを実行して、Extended Protection をアクティブ化する必要がある Exchange サーバーですべての前提条件が満たされているかどうかをチェックすることをお勧めします。
拡張保護をサポートする Exchange サーバーのバージョン
拡張保護は、2022 年 8 月の Exchange Server セキュリティ更新プログラム (SU) リリース以降の 2013 年、2016 年、2019 年Exchange Serverでサポートされています。
organizationに 2016 Exchange Serverまたは 2019 Exchange Serverがインストールされている場合は、2021 年 9 月の四半期 Exchange 累積Updatesまたは 2022 H1 累積的な更新プログラムのいずれかを実行している必要があります。 拡張保護の構成を続行する前に、少なくとも 2022 年 8 月以降のセキュリティ更新プログラムがインストールされている 必要があります 。
organizationに 2013 Exchange Serverインストールされている場合は、2022 年 8 月以降のセキュリティ更新プログラムがインストールされている CU23 にExchange Serverする必要があります。
警告
Exchange Server 2013 は、2023 年 4 月 11 日にサポートが終了しました。
Outlook Anywhere の構成要件
Outlook Anywhereの SSL オフロードは既定で有効になっており、拡張保護を有効にする前に無効にする必要があります。
例 3 で説明されている手順に従います。
重要
Exchange Server 2019 CU14 以降のインストーラーでは、Outlook Anywhereの SSL オフロードが自動的に無効になります。 これは、既定で有効になっている拡張保護の一部です。
NTLM バージョンの要件
NTLMv1 は弱く、中間者 (MitM) 攻撃に対する保護を提供しません。
これは脆弱と見なされ、使用されなくなりました。
NTLMv1 拡張保護と共に使用することはできません。 クライアントがNTLMv2ではなくNTLMv1を使用するように強制し、Exchange サーバーで拡張保護を有効にしている場合、この構成により、Exchange サーバーに対して正常に認証されずにクライアント側でパスワード プロンプトが表示されます。
注:
セキュリティを強化するには、問題が発生したかどうかにかかわらず、この設定を確認して構成することをお勧めします。
Extended Protection が有効になると、クライアントでパスワード プロンプトが表示される場合は、クライアントとExchange Server側で次のレジストリ キーと値をチェックする必要があります。
レジストリ キー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
レジストリ値: LmCompatibilityLevel
5の値 (Send NTLMv2 response only. Refuse LM & NTLM) に設定することをお勧めします。 少なくともSend NTLMv2 response only3の値に設定する必要があります。
値を削除すると、オペレーティング システムによってシステムの既定値が適用されます。 Windows Server 2008 R2 以降では、3に設定されているかのように扱われます。
設定を一元的に管理する場合は、次のグループ ポリシーを使用して行うことができます。
ポリシーの場所: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
詳細情報: ネットワーク セキュリティ: LAN Manager 認証レベル
TLS 要件
拡張保護を有効にする前に、すべての Exchange サーバーですべての TLS 構成が一貫していることを確認する必要があります。 たとえば、いずれかのサーバーで TLS 1.2 を使用する場合は、organization内のすべてのサーバーが TLS 1.2 を使用して構成されていることを確認する必要があります。 サーバー間で TLS バージョンの使用が異なると、クライアントまたはサーバー間の接続が失敗する可能性があります。
この要件に加えて、SchUseStrongCryptoレジストリ値の値は、organization内のすべての Exchange サーバーで1の値に設定する必要があります。
この値が明示的に 1 に設定されていない場合、このキーの既定値は、Exchange Server バイナリで使用されている .NET バージョンに応じて0または1として解釈でき、サーバー間通信で接続の問題が発生する可能性があります。 これは、特に異なるバージョンのExchange Server (たとえば、Exchange Server 2016 および Exchange Server 2019) が使用されている場合に発生する可能性があります。
SystemDefaultTlsVersionsレジストリ値にも同じことが当てはまります。これは、明示的に 1 の値に設定する必要もあります。
これらのレジストリ値が期待どおりに構成されていない場合、この構成ミスにより、サーバー間またはクライアント間の通信がサーバーまたはクライアントで TLS の不一致を引き起こす可能性があり、その結果、接続の問題が発生する可能性があります。
Exchange サーバーで必要な TLS 設定を構成するには、このExchange Server TLS 構成のベスト プラクティス ガイドを参照してください。
サード パーティ製ソフトウェアの互換性
拡張保護を有効にする前に、Exchange Server環境内のすべてのサード パーティ製品に対してテストを実施し、それらが正しく機能することを確認する必要があります。 拡張保護がサポートされているかどうかが不明な場合は、仕入先に連絡して確認する必要があります。
たとえば、クライアント マシンを保護するためにローカル プロキシ サーバーを介して接続を送信していたウイルス対策ソリューションを見てきました。 このようなシナリオでは、Exchange サーバーへの通信が妨げるため、中間者 (MitM) 接続と見なされるため、これを無効にする必要があります。これは Extended Protection によってブロックされます。
拡張保護が有効な場合にクライアント接続に影響を与える可能性があるシナリオ
SSL オフロード シナリオ
SSL オフロードを使用する環境では、拡張保護は サポートされていません 。 SSL オフロード中の SSL 終了により、拡張保護が失敗します。 Exchange 環境で拡張保護を有効にするには、Load Balancer で SSL オフロードを使用しないでください 。
SSL ブリッジング のシナリオ
拡張保護 は、 特定の条件下で SSL ブリッジングを使用する環境でサポートされます。 SSL ブリッジングを使用して Exchange 環境で拡張保護を有効にするには、 Exchange とロード バランサーで同じ SSL 証明書を使用する必要があります。 異なる証明書を使用すると、拡張保護チャネル バインド トークンチェックが失敗し、その結果、クライアントが Exchange サーバーに接続できなくなります。
拡張保護とパブリック フォルダーのシナリオ
次のセクションでは、拡張保護が有効になっている場合にエラーが発生する可能性があるパブリック フォルダーのシナリオについて説明します。
共存環境でパブリック フォルダーを使用Exchange Server 2013 サーバーで拡張保護を有効にすることはできません
Exchange Server 2013 で拡張保護を有効にするには、Exchange Server 2013 でホストされているパブリック フォルダーがないことを確認します。 Exchange Server 2016 または Exchange Server 2019 と Exchange Server 2013 が共存している場合は、拡張保護を有効にする前に、パブリック フォルダーを 2016 年または Exchange Server 2019 Exchange Serverに移行する必要があります。 拡張保護が有効になり、Exchange Server 2013 にパブリック フォルダーが存在すると、エンド ユーザーには表示されなくなります。
警告
Exchange Server 2013 は、2023 年 4 月 11 日にサポートが終了しました。
Exchange Server 2016 CU22 またはパブリック フォルダー階層をホストする 2019 CU11 以前のExchange Serverで拡張保護を有効にすることはできません
Exchange Server 2016 CU22 または Exchange Server 2019 CU11 以前を含む環境があり、パブリック フォルダーを使用している場合は、拡張保護を有効にする前に、パブリック フォルダー階層をホストするサーバーのバージョンを確認する必要があります。
パブリック フォルダー階層をホストするサーバーが、最新のセキュリティ UpdatesがインストールExchange Server 2016 CU23 または Exchange Server 2019 CU12 (またはそれ以降) にアップグレードされていることを確認します。 Exchange サーバーをサポートされているバージョンにアップグレードできない場合は、必要なバージョンを実行するExchange Serverにパブリック フォルダー階層を移動します。
次の表を使用して、明確にすることができます。
| Exchange のバージョン | CU がインストールされている | SU がインストールされている | ホスト PF メールボックス | EP はサポートされていますか? |
|---|---|---|---|---|
| Exchange 2013 | CU23 | 2022 年 8 月 (またはそれ以上) | 不要 | はい |
| Exchange 2016 | CU22 | 2022 年 8 月 (またはそれ以上) | 階層メールボックスなし | はい |
| Exchange 2016 | CU23 (2022 H1) 以降 | 2022 年 8 月 (またはそれ以上) | 任意 | はい |
| Exchange 2019 | CU11 | 2022 年 8 月 (またはそれ以上) | 階層メールボックスなし | はい |
| Exchange 2019 | CU12 (2022 H1) 以降 | 2022 年 8 月 (またはそれ以上) | 任意 | はい |
| その他のバージョン | その他の CU | その他の SU | 任意 | 不要 |
拡張保護と最新のハイブリッド構成
次のセクションではExchange Serverモダン ハイブリッド シナリオについて説明します。これにより、拡張保護が有効になっている場合にエラーが発生する可能性があります。
ハイブリッド エージェントを使用して発行された Exchange Server で拡張保護を完全に構成することはできません
最新のハイブリッド構成では、Exchange サーバーはハイブリッド エージェントを介して発行され、Exchange サーバーへのExchange Online呼び出しをプロキシします。
ハイブリッド エージェントを介して発行された Exchange サーバーで拡張保護を有効にすると、メールボックスの移動や空き時間情報の呼び出しなどのハイブリッド機能が正常に行われなければ中断される可能性があります。 そのため、ハイブリッド エージェントの助けを借りて公開されているすべての Exchange サーバーを特定し、それらの上の Front-End EWS 仮想ディレクトリで拡張保護を有効にしないようにすることが重要です。
ハイブリッド エージェントを使用して公開されている Exchange サーバーの識別
ハイブリッド エージェント経由で発行されたサーバーの一覧がない場合は、次の手順を使用してサーバーを識別できます。 クラシック Exchange Server ハイブリッドデプロイを実行している場合、これらの手順は必要ありません。
- ハイブリッド エージェントがインストールされているコンピューターにログインし、ハイブリッド エージェントの PowerShell モジュール を開きます。
Get-HybridApplicationを実行して、ハイブリッド エージェントによって使用されるTargetUriを特定します。 -
TargetUriパラメーターは、ハイブリッド エージェントによって使用されるように構成された Exchange サーバーの Fqdn を提供します。- Fqdn を使用して Exchange サーバー ID を推測し、Exchange サーバー名をメモします。
-
TargetUriでLoad Balancer URL を使用している場合は、Client Accessロールがインストールされ、Load Balancer URL の背後に到達できるすべての Exchange サーバーを特定する必要があります。
重要
拡張保護は、ハイブリッド エージェントを介して発行された Exchange サーバー上の EWS 仮想ディレクトリ Front-End で有効にすることはできません。
ハイブリッド エージェントを介して発行された Exchange サーバーを保護するには、次の手順をお勧めします。
注:
次のシナリオでは、ハイブリッド エージェントは、Exchange Serverを実行しないサーバーにインストールされます。 さらに、このサーバーは、運用 Exchange サーバーとは異なるネットワーク セグメントに配置されます。
- ハイブリッド エージェント経由で発行された Exchange サーバーの場合、ハイブリッド エージェントがインストールされているマシンからの接続のみを許可するように、ファイアウォールによって受信接続を制限する必要があります。 これは、Exchange サーバーからExchange Onlineへの送信通信には影響しません。
- ハイブリッド エージェント経由で発行された Exchange サーバーでメールボックスをホストする必要はありません。 既存のメールボックスは、他のメールボックス サーバーに移行する必要があります。
拡張保護の有効化
拡張保護は、Exchange Server 2019 CU14 (またはそれ以降) のセットアップ中に自動的に有効になります。 拡張保護をサポートする古いバージョンのExchange Serverでは、Microsoft が提供するスクリプト (推奨) を使用するか、IIS マネージャーを介して手動で有効にすることができます。
拡張保護を正しく構成するには、organization内のすべての Exchange サーバー上の各仮想ディレクトリ (エッジ トランスポート サーバーを除く) を、Extended ProtectionとsslFlagsの指定された値に設定する必要があります。
次の表は、サポートされているバージョンのExchange Serverの各仮想ディレクトリに必要な設定をまとめたものです。
| IIS Web サイト | Virtual Directory | 推奨値 | 推奨される sslFlags |
|---|---|---|---|
Default Website |
API |
Required |
Ssl,Ssl128 |
Default Website |
AutoDiscover |
Off |
Ssl,Ssl128 |
Default Website |
ECP |
Required |
Ssl,Ssl128 |
Default Website |
EWS |
Accept (UI) / Allow (スクリプト) |
Ssl,Ssl128 |
Default Website |
MAPI |
Required |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync |
Accept (UI) / Allow (スクリプト) |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync/Proxy |
Accept (UI) / Allow (スクリプト) |
Ssl,Ssl128 |
Default Website |
OAB |
Accept (UI) / Allow (スクリプト) |
Ssl,Ssl128 |
Default Website |
OWA |
Required |
Ssl,Ssl128 |
Default Website |
PowerShell |
Off |
SslNegotiateCert |
Default Website |
RPC |
Required |
Ssl,Ssl128 |
Exchange Backend |
API |
Required |
Ssl,Ssl128 |
Exchange Backend |
AutoDiscover |
Off |
Ssl,Ssl128 |
Exchange Backend |
ECP |
Required |
Ssl,Ssl128 |
Exchange Backend |
EWS |
Required |
Ssl,Ssl128 |
Exchange Backend |
Microsoft-Server-ActiveSync |
Required |
Ssl,Ssl128 |
Exchange Backend |
Microsoft-Server-ActiveSync/Proxy |
Required |
Ssl,Ssl128 |
Exchange Backend |
OAB |
Required |
Ssl,Ssl128 |
Exchange Backend |
OWA |
Required |
Ssl,Ssl128 |
Exchange Backend |
PowerShell |
Required |
Ssl,SslNegotiateCert,Ssl128 |
Exchange Backend |
RPC |
Required |
Ssl,Ssl128 |
Exchange Backend |
PushNotifications |
Required |
Ssl,Ssl128 |
Exchange Backend |
RPCWithCert |
Required |
Ssl,Ssl128 |
Exchange Backend |
MAPI/emsmdb |
Required |
Ssl,Ssl128 |
Exchange Backend |
MAPI/nspi |
Required |
Ssl,Ssl128 |
注:
最初のリリースの後、RequiredではなくAccept/AllowされるようにDefault Website/OABを更新し、RequiredではなくOffするようにDefault Website/PowerShellしました。
Default Website/OABへの変更は、Outlook for Macクライアントが Required 設定で OAB をダウンロードできなくなったためです。
Default Website/PowerShellの変更は、Exchange Serverの既定の構成では、PowerShell Front-End 仮想ディレクトリへの NTLM 認証を使用した接続が許可されていないため、拡張保護は適用されないためです。
Default Website/PowerShell仮想ディレクトリの変更は、Microsoft カスタマー サービスおよびサポート (CSS) から明示的に通知されない限りサポートされません。
Exchange Server 2019 CU14 (またはそれ以降) インストーラーを使用した拡張保護の有効化
Exchange Server 2019 CU14 以降では、Exchange Server 2019 累積的な更新プログラム (CU) インストーラーによって、セットアップが実行されるメールボックス サーバーで拡張保護が自動的に有効になります。 これは、新規インストールの場合、または既存のExchange Serverインストールを最新バージョンにアップグレードする場合に発生します。
既定の動作で有効になっている拡張保護を制御するために、無人セットアップ モードで使用できる新しいパラメーターが 2 つあります。
パラメーターは、拡張保護 (/DoNotEnableEP) の自動アクティブ化をスキップしたり、Front-End EWS 仮想ディレクトリ (/DoNotEnableEP_FEEWS) で拡張保護を有効にしたりするために使用できます。
警告
拡張保護を無効にすると、サーバーは既知のExchange Serverの脆弱性に対して脆弱になり、未知の脅威に対する保護が弱くなります。 この機能は有効のままにしておくことをお勧めします。
拡張保護 CU インストーラーの構成シナリオ
このセクションでは、Exchange Server 2019 CU14 (またはそれ以降) の累積的な更新プログラム (CU) インストーラーの助けを借りて、Exchange Serverで拡張保護を構成するための最も一般的なシナリオについて説明します。
「Exchange Serverで拡張保護を有効にするための前提条件」セクションで説明されているように、Exchange サーバーが適切に構成され、要件を満たしていることを確認します。
シナリオ 1: Exchange Server 2019 で拡張保護を有効にする
Exchange Server 2019 CU14 (またはそれ以降) のセットアップを、参加モードまたは無人モードで実行します。 インストーラーは、実行されたサーバーのインストールの一部として拡張保護を構成します。
シナリオ 2: ハイブリッド エージェントを介して発行されたExchange Server 2019 で拡張保護を有効にする
「ハイブリッド エージェントを使用して公開される Exchange サーバーの識別」セクションで説明されている手順に従って、ハイブリッド エージェント経由で発行される Exchange サーバーを特定します。
/DoNotEnableEP_FEEWS パラメーターを使用して、無人モードで Exchange Server 2019 CU14 (またはそれ以降) のセットアップを実行します。 Front-End EWS 仮想ディレクトリでの拡張保護の有効化はスキップされます。
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS
シナリオ 3: Exchange Server 2019 CU14 (またはそれ以降) のセットアップによる拡張保護の有効化をスキップする
/DoNotEnableEP パラメーターを使用して、無人モードで Exchange Server 2019 CU14 (またはそれ以降) のセットアップを実行します。 拡張保護の有効化はスキップされます。
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP
警告
拡張保護を有効にしないと、サーバーは既知の Exchange の脆弱性に対して脆弱になり、未知の脅威に対する保護が弱くなります。 この機能を有効にすることをお勧めします。
PowerShell スクリプトを使用した拡張保護の有効化
ExchangeExtendedProtectionManagement.ps1 スクリプトを使用して、一部またはすべての Exchange サーバーで一度に拡張保護を有効にすることができます。
重要
Exchange Server環境内で拡張保護を有効にするには、すべての Exchange サーバーで多くの変更を加える必要があります。 IIS マネージャーを使用してこれらの変更を手動で行う代わりに、Microsoft によって提供されるスクリプトを使用することをお勧めします。
実行して拡張保護を構成する前に、スクリプトの最新バージョンをダウンロードしてください。
このスクリプトは、Exchange Management Shell (EMS) がインストールされている環境内の任意の特定のExchange Serverで実行できます。
PowerShell スクリプトを使用して拡張保護を構成するためのアクセス許可
スクリプトを実行するユーザーは、 Organization Management ロール グループのメンバーである必要があります。 スクリプトは、管理者特権の Exchange 管理シェル (EMS) から実行する必要があります。
拡張保護スクリプト構成シナリオ
このセクションでは、ExchangeExtendedProtectionManagement.ps1PowerShell スクリプトの助けを借りて、Exchange Serverで Extended Protection を構成するための最も一般的なシナリオについて説明します。
スクリプト パラメーターの詳細な例と説明については、スクリプト ドキュメントを参照してください 。
シナリオ 1: すべてのExchange Serverで拡張保護を有効にする
次のようにスクリプトを実行して、organization内のすべての Exchange サーバーで拡張保護を有効にします。
.\ExchangeExtendedProtectionManagement.ps1
このスクリプトでは、拡張保護を有効にするために、すべての Exchange サーバーが最低限必要な CU および SU バージョンにあることを確認するために、いくつかのチェックを実行します。 また、すべての Exchange サーバーが同じ TLS 構成を使用しているかどうかを確認します。
前提条件のチェックに合格すると、スクリプトによって拡張保護が有効になり、スコープ内のすべての Exchange サーバーのすべての仮想ディレクトリに必要な SSL フラグが追加されます。 Exchange サーバーが要件を満たしていない場合に停止します (たとえば、一貫性のない TLS 構成が検出された場合)。
シナリオ 2: モダン ハイブリッド構成を実行するときに拡張保護を構成する
モダン ハイブリッド構成がある場合は、モダン ハイブリッド エージェントを使用して発行された Exchange Server 上の Front-End EWS 仮想ディレクトリで拡張保護を有効にすることをスキップする必要があります。
この構成は、 ExcludeVirtualDirectories パラメーターを使用して実行できます。
.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames MHServer1, MHServer2 -ExcludeVirtualDirectories "EWSFrontEnd"
IIS マネージャーを使用して拡張保護を有効にする
スクリプトを使用せずに環境内で拡張保護を手動で有効にする場合は、次の手順を使用できます。
注:
拡張保護を手動で有効にする場合は、 上記の表で説明したように、Exchange サーバー上のすべての仮想ディレクトリに拡張保護が構成されていることを確認します。
[拡張保護] を [必須] に設定するか、仮想ディレクトリで を受け入れます
- 拡張保護を構成する Exchange サーバーで
IIS Manager (INetMgr.exe)を起動します -
Sitesに移動し、Default Web SiteまたはExchange Back End - 構成する仮想ディレクトリを選択します
- 選ぶ
Authentication -
Windows Authenticationが有効になっている場合は、Windows Authentication
-
Advanced Settings(右側) を選択し、開くウィンドウで [拡張保護] ドロップダウンから適切な値を選択します![IIS マネージャーの [拡張保護設定] ドロップダウン メニューを示す画像](../../../exchangeserver/media/exchange-ep-iismgr-ep-dropdown.png)
![IIS マネージャーの [拡張保護設定] ドロップダウン メニューを示す画像](../../../exchangeserver/media/exchange-ep-iismgr-ep-dropdown.png#lightbox)
仮想ディレクトリに必要な SSL 設定を設定する
- 仮想ディレクトリをクリックしてホーム ページを開きます
- 選ぶ
SSL Settings -
Require SSL設定を確認して、仮想ディレクトリに対してRequire SSLが有効になっていることを確認します
- [
Apply] をクリックして、新しい設定を確認します
拡張保護の無効化
ExchangeExtendedProtectionManagement.ps1 PowerShell スクリプトを使用して、拡張保護を無効にすることができます。
警告
Extended Protection を無効にすると、サーバーは既知の Exchange の脆弱性に対して脆弱になり、未知の脅威に対する保護が弱くなります。 この機能は有効のままにしておくことをお勧めします。
次のコマンドは、現在のすべての構成場所の値を None に設定することで、オンラインになっているすべての Exchange サーバーの拡張保護構成を無効にします。
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection
拡張保護を無効にするサーバーのサブセットを指定することもできます。
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames ExchServer1, ExchServer2
Exchange 証明書の更新
Exchange Serverでの証明書の更新は、セキュリティで保護された通信を維持し、サーバー操作の整合性を確保するために不可欠です。 セキュリティ環境の変化に伴い、公的証明機関 (CA) によって発行される証明書の有効期間が短くなり、多くの場合、年単位でより頻繁な更新が必要になりました。
このセクションでは、Exchange Serverを拡張保護構成で実行するときに証明書を更新または置き換える手順について説明します。 特に、SSL ブリッジングが構成されているロード バランサーでExchange Serverを実行する場合は、「SSL ブリッジング シナリオ」セクションで説明されているように、Exchange Serverのフロントエンドと同じ証明書をロード バランサーで使用する必要があります。
警告
ロード バランサーまたはExchange Serverで証明書を変更すると、クライアント接続が中断され、証明書の不一致が原因で Outlook で資格情報ポップアップが表示される可能性があります。
期限切れの証明書を更新する
最初の手順として、証明書署名要求 (CSR) を作成する必要があります。 そのためには、Exchange Server証明書の更新に関するドキュメントに記載されている手順に従います。
次に、選択した CA に CSR を送信して、新しい証明書を発行します。 「保留中のExchange Server証明書要求の完了」ドキュメントの手順に従って、Exchange Serverの保留中の要求を完了します。
拡張保護を無効にする
次の手順として、Exchange サーバーで拡張保護を一時的に無効にする必要があります。 ロード バランサーで使用される証明書は、Exchange Serverでアクティブになる新しい証明書とは異なるため、この手順をスキップすると、クライアントがExchange Serverに接続できなくなる可能性があります。
拡張保護を無効にするには、このドキュメントの「 拡張保護の無効化 」セクションの手順に従います。
Exchange Server サービスとロード バランサーに証明書を割り当てる
次に、更新された証明書を Exchange サービスに割り当てます。 これを行う手順については、サービスへの証明書の割り当てに関するドキュメントExchange Server参照してください。
次の例では、証明書は、
Mailboxロールを実行しているすべての Exchange サーバー上のIISサービスに割り当てられます。 管理者特権の Exchange 管理シェル (EMS) からこのコマンドを実行してください。Get-ExchangeServer | Where-Object { $_.ServerRole -eq "Mailbox" } | ForEach-Object { Enable-ExchangeCertificate -Thumbprint <thumbprint> -Server $_.Fqdn -Services IIS }拡張保護を再度有効にする
更新された証明書をExchange Server サービスに割り当て、ロード バランサーまたはリバース プロキシ デバイスで置き換えた後、もう一度 Extended Protection を有効にします。 これを行うには、このドキュメントの 「PowerShell スクリプトを使用した拡張保護の有効化 」セクションの手順に従います。
Exchange モダン ハイブリッド構成を実行している場合は、EWS フロントエンドで拡張保護を有効にしないでください。 詳細については、「 シナリオ 2: モダン ハイブリッド構成の実行時に拡張保護を構成する 」セクションを参照してください。
トラブルシューティング
このセクションには、Extended Protection に存在する既知の問題と、既知の障害シナリオに関するいくつかのトラブルシューティングのヒントが記載されています。
拡張保護に関する既知の問題
Exchange Serverの拡張保護に関して以前に報告されたすべての問題が修正されました。 最新の修正プログラムと機能強化の恩恵を受けるために、organizationで実行する Exchange のバージョンの最新のExchange Server更新プログラムをインストールすることを強くお勧めします。
問題: 2019 CU14 無人モードセットアップ Exchange Serverで /PrepareSchema、/PrepareDomain または /PrepareAllDomains を実行すると、拡張保護がアクティブ化されていることが示されます
これは、Exchange Server 2019 CU14 に関する既知の問題であり、無視しても問題ありません。 Exchange Serverドキュメントの「Active Directory とドメインを準備する」の説明に従って、環境を準備するために/PrepareSchema、/PrepareDomain、または/PrepareAllDomainsを実行している場合、拡張保護は有効になりません。
問題: Outlook クライアントを使用してパブリック フォルダーのアクセス許可を変更すると、"変更されたアクセス許可を変更できません" というエラーが表示され、失敗します。
この問題は、アクセス許可を変更しようとするパブリック フォルダーが、プライマリ パブリック フォルダー メールボックスが別のサーバー上にある間にセカンダリ パブリック フォルダー メールボックスでホストされている場合に発生します。
この問題は、最新のExchange Server更新プログラムで修正されました。 この KB に記載されている手順に従って修正を有効にします。
問題: Outlook クライアントを使用してパブリック フォルダーを作成すると、"パブリック フォルダーを作成できません" というエラーが表示されます。 このオブジェクトに対してこの操作を実行するための十分なアクセス許可がありません。 フォルダーの連絡先またはシステム管理者を参照してください。
この問題は、アクセス許可を変更しようとするパブリック フォルダーが、プライマリ パブリック フォルダー メールボックスが別のサーバー上にある間にセカンダリ パブリック フォルダー メールボックスでホストされている場合に発生します。
この問題は、最新のExchange Server更新プログラムで修正されました。
この KB に記載されている手順に従って修正を有効にします。 この修正プログラムは、この KB で説明されている問題に対処するために、PublicFolderHierarchyHandlerEnabler を無効に設定するグローバル オーバーライドが実装されている場合は機能しないことに注意してください。
拡張保護構成スクリプトの実行中の警告とエラー
スクリプトには、既知の問題の警告が表示され、確認が求められます。
拡張保護を有効にしたために既存のExchange Server機能が中断されるシナリオに管理者が実行されないようにするために、スクリプトには既知の問題があるシナリオの一覧が用意されています。 拡張保護を有効にする前に、この一覧を注意深く読んで評価してください。
Yを押すと、拡張保護を有効にすることができます。
前提条件のチェックが失敗したため、このスクリプトでは拡張保護が有効になりません。
拡張保護をサポートするビルドを実行する Exchange サーバーはありません。
拡張保護をサポートするビルドを実行している Exchange サーバーがorganizationに存在しない場合、スクリプトはサポートされていないサーバーで Extended Protection を有効にして、サーバー間の通信が失敗しないようにしません。
このケースを解決するには、すべての Exchange サーバーを最新の CU と SU に更新し、スクリプトをもう一度実行して拡張保護を有効にします。
TLS の不一致が検出されました。
有効 で一貫性のある TLS 構成は、 スコープ内のすべての Exchange サーバーで必要です。 スコープ内のすべてのサーバーの TLS 設定が同じでない場合、拡張保護を有効にすると、メールボックス サーバーへのクライアント接続が中断されます。
詳細については、「Exchange Server TLS 構成のベスト プラクティス」を参照してください。
一部の Exchange サーバーは使用できない/到達可能です。
スクリプトは、スコープ内のすべての Exchange サーバーに対して複数のテストを実行します。 これらのサーバーの 1 つ以上に到達できない場合、スクリプトはこれらのマシンで必要な構成アクションを実行できないため、それらを除外します。
サーバーがオフラインの場合は、オンラインに戻ったらすぐに拡張保護を構成する必要があります。 他の理由でサーバーに到達できなかった場合は、サーバー自体でスクリプトを実行して拡張保護を有効にする必要があります。
ユーザーは、1 つ以上のクライアントを介して自分のメールボックスにアクセスできません
Extended Protection が有効になった後に、一部またはすべてのクライアントが認証エラーをユーザーに提供し始める理由は複数あります。
ユーザーは、Outlook for Windows、Outlook for Mac、Outlook Mobile、またはネイティブ iOS メール クライアントを使用して、メールボックスに永続的または散発的にアクセスすることはできません。
Exchange organization全体の TLS 構成が同じでない場合 (たとえば、拡張保護が有効になった後にいずれかの Exchange サーバーで TLS 構成が変更された場合)、この構成ミスによってクライアント接続が失敗する可能性があります。 この問題を解決するには、すべての Exchange サーバーで TLS を適切に構成する手順をチェックし、スクリプトを使用して Extended Protection をもう一度構成します。
SSL オフロードが使用されているかどうかを確認します。 SSL が終了すると、拡張保護チャネル バインド トークンチェックが失敗します。これは、SSL オフロードが中間者と見なされるため、拡張保護によって防止されます。 この問題を解決するには、SSL オフロードを無効にし、スクリプトを使用して拡張保護を再度有効にします。
ユーザーは Outlook for Windows と OWA を使用してメールにアクセスできますが、Outlook for Mac、Outlook Mobile、iOS ネイティブメール クライアントなどの Windows 以外のクライアントを介してアクセスすることはできません。 これは、EWS や Exchange ActiveSync の拡張保護設定が、1 つまたはすべての Front-End サーバーで
Requiredに設定されている場合に発生する可能性があります。この問題を解決するには、
ExchangeServerNamesパラメーターを使用してExchangeExtendedProtectionManagement.ps1スクリプトを実行し、正しく構成されていない拡張保護設定がある Exchange サーバーの名前を渡します。 パラメーターを指定せずにスクリプトを実行してチェックし、すべてのサーバーに対して拡張保護を再度構成することもできますまたは、
IIS Manager (INetMgr.exe)を使用して、これらの仮想ディレクトリの拡張保護設定を 、表で説明されているように適切な値に変更することもできます。 スクリプトは正しい値をチェックし、値が期待どおりに設定されていない場合は自動的に再構成を実行するため、スクリプトを使用することを強くお勧めします。
NTLM SSO が使用され、拡張保護が有効になっている場合、ユーザーは macOS または iOS で Apple Safari ブラウザーを使用して OWA または ECP にアクセスできません。
macOS プラットフォーム上のユーザーの場合は、拡張保護サポートを備えた Web ブラウザーを利用することをお勧めします。 Microsoft Edge (Chromium) をお勧めします。
iOS プラットフォーム上のユーザーの場合、拡張保護がサポートされている Web ブラウザーはありません。
両方のプラットフォームで機能するソリューションは、OWA と ECP 用にハイブリッド モダン認証を構成するか、Outlook on the webで AD FS 要求ベースの認証を使用することです。
上記の手順を実行しても、一部のクライアントがまだ期待どおりに動作していない場合は、一時的に Extended Protection をロールバックし、サポート ケースを開いて Microsoft に問題を報告できます。 「 拡張保護の無効化 」セクションで説明されている手順に従います。
ハイブリッドの空き時間情報またはメールボックスの移行が機能しない
モダン ハイブリッドを使用している場合、拡張保護を有効にすると、この記事の説明に従って構成が実行されなかった場合に、空き時間情報やメールボックスの移行などのハイブリッド機能が機能しなくなる可能性があります。 この問題を解決するには、 ハイブリッド エージェントを使用して発行されたハイブリッド サーバーを特定 し、 これらのサーバー上の Front-End EWS 仮想ディレクトリで拡張保護を無効にします。
パブリック フォルダーが表示またはアクセスできなくなりました
拡張保護が有効になっていると、パブリック フォルダーの接続に影響する可能性がある 2 つの問題があります。 この記事の 「拡張保護とパブリック フォルダー」 セクションに記載されている手順に従ってください。
FAQ
質問： 以前の累積的な更新プログラム (CU) に既にインストールされている場合、2022 年 8 月のセキュリティ更新プログラム (SU) をインストールする必要がありますか?
答える：はい。新しい CU ビルドに更新する場合は、2022 年 8 月の SU をもう一度インストールする必要があります (たとえば、2019 CU11 Exchange Server 2019 CU12 をExchange Server)。
思い出す： 更新をすぐに実行する場合 (CU + SU インストールを意味します)、拡張保護をオフにする必要はありません。 SU をすぐにインストールせずに CU に留まる予定の場合は、CU ビルド (SU がインストールされていない) が拡張保護をサポートしていないため、クライアント接続の問題が発生する可能性があるため、拡張保護を無効にする必要があります。
質問：Outlook on the web (OWA) にActive Directory フェデレーション サービス (AD FS) (AD FS) を使用する環境で拡張保護を有効にしても安全ですか?
答える： はい。拡張保護は、OWA での AD FS 要求ベースの認証には影響しません。
質問： ハイブリッド モダン認証 (HMA) を使用する環境で Windows 拡張保護を有効にしても安全ですか?
答える： はい。HMA はこの変更の影響を受けることはありません。 拡張保護は HMA をさらに強化しませんが、Windows 認証はハイブリッド モダン認証をサポートしていないアプリケーションに引き続き使用できます。これを考慮すると、引き続き Exchange オンプレミス サービスを持つ任意の環境で拡張保護を有効にすることをお勧めします。
質問： 拡張保護はハイブリッドモダン認証またはMicrosoft Teams統合に影響しますか?
答える： 拡張保護は、Microsoft Teams統合またはハイブリッド モダン認証には影響しません。
質問：HTTP 400 状態コードを使用して拡張保護を有効にした後、OWA/ECP にアクセスできません。OWA/ECP は Entra アプリケーション プロキシを介して発行されます。これを解決するにはどうすればよいですか?
答える：Entra アプリケーション プロキシを介した Exchange OWA/ECP の発行はサポートされていません。拡張保護標準でサポートされているネットワーク トポロジを使用して OWA/ECP を発行する必要があります。
質問： MitM 攻撃を防ぐことが重要であることを理解していますが、独自の証明書を使用して独自のデバイスを途中で持つことができますか?
答える： デバイスが Exchange サーバーと同じ証明書を使用している場合は、その証明書を使用できます。