Exchange Serverで Windows 拡張保護を構成する
概要
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 ActiveSyncOutlook on the WebWeb アプリケーションへのアクセスを許可するために使用されますAutoDiscover。 管理者は、認証、セキュリティ、レポート設定など、いくつかの仮想ディレクトリ設定を構成できます。 拡張保護は、このような認証設定の 1 つです。
拡張保護の設定
または CBTのチェックの動作をChannel Binding Tokens制御します。 この設定で使用できる値を次の表に示します。
| 値 | 説明 |
|---|---|
| なし | IIS が CBT チェックを実行しないことを指定します。 |
| 許可 | CBT チェックが有効になっているが、必須ではないことを指定します。 この設定により、Extended Protection をサポートするクライアントとのセキュリティで保護された通信が可能になり、引き続き Extended Protection を使用できないクライアントがサポートされます。 |
| 必須 | この値は、CBT チェックが必要であることを指定します。 この設定は、拡張保護をサポートしていないクライアントをブロックします。 |
SSL フラグ
クライアントがクライアント証明書を使用して特定の方法で IIS 仮想ディレクトリに接続するには、SSL 設定の構成が必要です。 拡張保護を有効にするには、必要な SSL フラグは と SSL128ですSSL。
SSL オフロード
クライアントとExchange Serverの間のデバイス上の接続を終了し、暗号化されていない接続を使用してExchange Serverに接続します。
SSL ブリッジ
ネットワークの端にあるデバイスが SSL トラフィックを復号化し、それを再暗号化してから Web サーバーに送信するプロセスについて説明します。
モダン ハイブリッドまたはハイブリッド エージェント
これは、Exchange ハイブリッド機能を有効にするために、従来のハイブリッド (ファイアウォール経由の受信ネットワーク接続など) の構成要件の一部を削除する Exchange ハイブリッドを構成する方法の名前です。 この機能の詳細については、 こちらを参照してください。
パブリック フォルダー
共有アクセス用に設計されており、深い階層のコンテンツを参照しやすくするために役立ちます。 パブリック フォルダーの詳細については、 こちらを参照してください。
Exchange Serverで拡張保護を有効にするための前提条件
ヒント
Exchange Server正常性チェッカー スクリプトを実行して、拡張保護をアクティブ化する必要がある 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 以降のインストーラーでは、SSL オフロードがOutlook Anywhere自動的に無効になります。 これは、既定で有効になっている拡張保護の一部です。
NTLM バージョンの要件
NTLMv1 は弱く、中間者 (MitM) 攻撃に対する保護を提供しません。
これは脆弱と見なされ、使用されなくなりました。
NTLMv1 拡張保護と共に使用することはできません。 の代わりにNTLMv2クライアントを使用NTLMv1するように強制し、Exchange サーバーで拡張保護を有効にしている場合、この構成により、Exchange サーバーに対して正常に認証されずに、クライアント側でパスワード プロンプトが表示されます。
注:
セキュリティを強化するには、問題が発生したかどうかにかかわらず、この設定を確認して構成することをお勧めします。
Extended Protection が有効になると、クライアントでパスワード プロンプトが表示される場合は、クライアントとExchange Server側で次のレジストリ キーと値をチェックする必要があります。
レジストリ キー: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
レジストリ値: LmCompatibilityLevel
の値 5Send NTLMv2 response only. Refuse LM & NTLM() に設定することをお勧めします。 少なくとも の値3Send NTLMv2 response onlyを に設定する必要があります。
値を削除すると、オペレーティング システムによってシステムの既定値が適用されます。 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 バージョンに応じて、または1として0解釈でき、サーバー間通信で接続の問題が発生する可能性があります。 これは、特に異なるバージョンの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 サーバー名をメモします。
- で
TargetUriLoad Balancer URL を使用している場合は、ロールがインストールされ、Client AccessLoad 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 サーバー (エッジ トランスポート サーバーを除く) 上の各仮想ディレクトリを、 と sslFlagsの所定のExtended Protection値に設定する必要があります。
次の表は、サポートされているバージョンの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 |
注:
最初のリリース後は、 ではなく、 ではなく にOffRequiredAccept/AllowDefault Website/PowerShellRequired更新Default Website/OABされました。 への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 つあります。
パラメーターを使用すると、拡張保護 () の自動アクティブ化をスキップしたり、EWS 仮想ディレクトリ/DoNotEnableEP_FEEWS (/DoNotEnableEP) Front-End で拡張保護を有効にしたりすることはできません。
警告
拡張保護を無効にすると、サーバーは既知の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 サーバーを特定します。
パラメーターを使用して、無人モードで Exchange Server 2019 CU14 (またはそれ以降) のセットアップを/DoNotEnableEP_FEEWS実行します。 Front-End EWS 仮想ディレクトリでの拡張保護の有効化はスキップされます。
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS
シナリオ 3: Exchange Server 2019 CU14 (またはそれ以降) のセットアップによる拡張保護の有効化をスキップする
パラメーターを使用して、無人モードで Exchange Server 2019 CU14 (またはそれ以降) のセットアップを/DoNotEnableEP実行します。 拡張保護の有効化はスキップされます。
<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 サーバー上のすべての仮想ディレクトリに拡張保護が構成されていることを確認します。
[拡張保護] を [必須] に設定するか、仮想ディレクトリで を受け入れます
- 拡張保護を
IIS Manager (INetMgr.exe)構成する Exchange サーバーで を起動します。 - に
Sites移動し、 または を選択します。Default Web SiteExchange Back End - 構成する仮想ディレクトリを選択します
- 選ぶ
Authentication - が有効になっている場合
Windows Authenticationは、Windows Authentication
- (右側) を選択
Advanced Settingsし、開くウィンドウで [拡張保護] ドロップダウンから適切な値を選択します![IIS マネージャーの [拡張保護設定] ドロップダウン メニューを示す画像](../../../exchangeserver/media/exchange-ep-iismgr-ep-dropdown.png?view=exchserver-2019)
![IIS マネージャーの [拡張保護設定] ドロップダウン メニューを示す画像](../../../exchangeserver/media/exchange-ep-iismgr-ep-dropdown.png?view=exchserver-2019#lightbox)
仮想ディレクトリに必要な SSL 設定を設定する
- 仮想ディレクトリをクリックしてホーム ページを開きます
- 選ぶ
SSL Settings - 設定を
Require SSL確認して、仮想ディレクトリにRequire SSL対して有効になっていることを確認します
- クリック
Applyして新しい設定を確認します
拡張保護の無効化
ExchangeExtendedProtectionManagement.ps1 PowerShell スクリプトを使用して、拡張保護を無効にすることができます。
警告
Extended Protection を無効にすると、サーバーは既知の Exchange の脆弱性に対して脆弱になり、未知の脅威に対する保護が弱くなります。 この機能は有効のままにしておくことをお勧めします。
次のコマンドは、現在のすべての構成場所の値を に設定することで、オンラインになっているすべての Exchange サーバーの拡張保護構成を None無効にします。
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection
拡張保護を無効にするサーバーのサブセットを指定することもできます。
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames ExchServer1, ExchServer2
トラブルシューティング
このセクションには、Extended Protection に存在する既知の問題と、既知の障害シナリオに関するいくつかのトラブルシューティングのヒントが記載されています。
拡張保護に関する既知の問題
Exchange Serverの拡張保護に関して以前に報告されたすべての問題が修正されました。 最新の修正プログラムと機能強化の恩恵を受けるために、organizationで実行する Exchange のバージョンの最新のExchange Server更新プログラムをインストールすることを強くお勧めします。
問題: 2019 CU14 無人モードセットアップ Exchange Serverで /PrepareSchema、/PrepareDomain または /PrepareAllDomains を実行すると、拡張保護がアクティブ化されていることが示されます
これは、Exchange Server 2019 CU14 に関する既知の問題であり、無視しても問題ありません。 を実行/PrepareSchema/PrepareDomainするとき、または/PrepareAllDomains「Exchange Serverの Active Directory とドメインを準備する」のドキュメントで説明されているように、環境を準備するために、拡張保護は有効になっていません。
問題: 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設定されている場合に発生する可能性があります。この問題を解決するには、 パラメーターを指定してスクリプトを
ExchangeExtendedProtectionManagement.ps1ExchangeServerNames実行し、構成が正しく構成されていない拡張保護設定がある 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 サーバーと同じ証明書を使用している場合は、その証明書を使用できます。