Exchange Server で Windows 拡張保護を構成する
概要
Windows 拡張保護 は、Windows Server の既存の認証を強化し、認証リレーまたは中間者 (MitM) 攻撃を軽減します。 この軽減策は、主に TLS 接続に使用される を介して指定されたチャネル バインド情報によって実装されるセキュリティ情報を使用して Channel Binding Token (CBT) 実現されます。
拡張保護は、Exchange Server 2019 CU14 (以降) をインストールするときに既定で有効になっています。 詳細については、「 リリース済み: 2024 H1 Exchange Server 用累積的な更新プログラム」を参照してください。
以前のバージョンの Exchange Server (Exchange Server 2016 など) では、一部またはすべての Exchange サーバーで ExchangeExtendedProtectionManagement.ps1 スクリプトを使用して拡張保護を有効にすることができます。
このドキュメントで使用される用語
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 Health Checker スクリプトを実行して、拡張保護をアクティブ化する必要がある Exchange サーバーですべての前提条件が満たされているかどうかを確認することをお勧めします。
拡張保護をサポートする Exchange サーバーのバージョン
拡張保護は、2022 年 8 月の Exchange Server セキュリティ更新プログラム (SU) リリース以降の Exchange Server 2013、2016、および 2019 でサポートされています。
組織に Exchange Server 2016 または Exchange Server 2019 がインストールされている場合は、2021 年 9 月の四半期ごとの Exchange 累積的な更新プログラムまたは 2022 H1 累積的な更新プログラムのいずれかを実行している必要があります。 拡張保護の構成を続行する前に、少なくとも 2022 年 8 月以降のセキュリティ更新プログラムがインストールされている 必要があります 。
組織に Exchange Server 2013 がインストールされている場合、Exchange Server は CU23 上に存在し、 2022 年 8 月以降のセキュリティ更新プログラムがインストールされている必要があります。
警告
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する場合は、組織内のすべてのサーバーが を使用して TLS 1.2構成されていることを確認する必要があります。 サーバー間で TLS バージョンの使用が異なると、クライアントまたはサーバー間の接続が失敗する可能性があります。
この要件に加えて、レジストリ値の SchUseStrongCrypto 値は、組織内のすべての 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 2013 と Exchange Server 2016 または Exchange Server 2019 が共存している場合は、拡張保護を有効にする前にパブリック フォルダーを Exchange Server 2016 または Exchange Server 2019 に移行する必要があります。 拡張保護が有効になり、Exchange Server 2013 にパブリック フォルダーが存在すると、エンド ユーザーには表示されなくなります。
警告
Exchange Server 2013 は、2023 年 4 月 11 日に サポート終了 に達しました。
パブリック フォルダー階層をホストする Exchange Server 2016 CU22 または Exchange Server 2019 CU11 以前では、拡張保護を有効にできません
Exchange Server 2016 CU22 または Exchange Server 2019 CU11 以前を含む環境があり、パブリック フォルダーを使用している場合は、拡張保護を有効にする前に 、パブリック フォルダー階層をホストするサーバーのバージョンを確認する必要があります 。
パブリック フォルダー階層をホストするサーバーが、 最新のセキュリティ更新プログラム がインストールされた 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 Online 呼び出しを Exchange サーバーにプロキシするハイブリッド エージェントを介して発行されます。
ハイブリッド エージェントを介して発行された Exchange サーバーで拡張保護を有効にすると、メールボックスの移動や空き時間情報の呼び出しなどのハイブリッド機能が正常に行われなければ中断される可能性があります。 そのため、ハイブリッド エージェントの助けを借りて公開されているすべての Exchange サーバーを特定し、それらの上の Front-End EWS 仮想ディレクトリで拡張保護を有効にしないようにすることが重要です。
ハイブリッド エージェントを使用して公開されている Exchange サーバーの識別
ハイブリッド エージェント経由で発行されたサーバーの一覧がない場合は、次の手順を使用してサーバーを識別できます。 従来の Exchange Server ハイブリッド展開を実行している場合、これらの手順は必要ありません。
- ハイブリッド エージェントがインストールされているコンピューターにログインし、ハイブリッド エージェントの PowerShell モジュール を開きます。 を実行
Get-HybridApplicationして、TargetUriハイブリッド エージェントによって使用される を識別します。 - パラメーターは
TargetUri、ハイブリッド エージェントによって使用されるように構成された Exchange サーバーの Fqdn を提供します。- Fqdn を使用して Exchange サーバー ID を推測し、Exchange サーバー名をメモします。
- で
TargetUriロード バランサー URL を使用している場合は、ロールがインストールされ、Client Accessロード バランサー URL の背後に到達できるすべての Exchange サーバーを識別する必要があります。
重要
拡張保護は、ハイブリッド エージェントを介して発行された Exchange サーバー上の EWS 仮想ディレクトリ Front-End で有効にすることはできません。
ハイブリッド エージェントを介して発行された Exchange サーバーを保護するには、次の手順をお勧めします。
注:
次のシナリオでは、Exchange Server を実行しないサーバーにハイブリッド エージェントがインストールされます。 さらに、このサーバーは、運用 Exchange サーバーとは異なるネットワーク セグメントに配置されます。
- ハイブリッド エージェント経由で発行された Exchange サーバーの場合、ハイブリッド エージェントがインストールされているマシンからの接続のみを許可するように、ファイアウォールによって受信接続を制限する必要があります。 これは、Exchange サーバーから Exchange Online への送信通信には影響しません。
- ハイブリッド エージェント経由で発行された Exchange サーバーでメールボックスをホストする必要はありません。 既存のメールボックスは、他のメールボックス サーバーに移行する必要があります。
拡張保護の有効化
拡張保護は、Exchange Server 2019 CU14 (またはそれ以降) のセットアップ中に自動的に有効になります。 拡張保護をサポートする古いバージョンの Exchange Server では、 Microsoft が提供するスクリプト (推奨) を 使用するか、IIS マネージャーを介して手動で有効にすることができます。
拡張保護を正しく構成するには、組織内のすべての 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 クライアントが設定で OAB Required をダウンロードできなくなったためです。 への 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 で拡張保護を構成するための最も一般的なシナリオについて 説明 します。
スクリプト パラメーターの詳細な例と説明については、スクリプト ドキュメントを参照してください 。
シナリオ 1: すべての Exchange Server で拡張保護を有効にする
次のようにスクリプトを実行して、組織内のすべての 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 上の拡張保護に関して以前に報告されたすべての問題が修正されました。 最新の修正と改善の恩恵を受けるために、組織で実行する Exchange のバージョンの最新の Exchange Server 更新プログラム をインストールすることを強くお勧めします。
問題: Exchange Server 2019 CU14 無人モードセットアップで /PrepareSchema、/PrepareDomain、/PrepareAllDomains を実行すると、拡張保護がアクティブ化されたことが示されます
これは Exchange Server 2019 CU14 の既知の問題であり、無視しても問題ありません。 を実行/PrepareSchema/PrepareDomainするとき、または/PrepareAllDomains「Exchange Server 用の Active Directory とドメインを準備する」のドキュメントで説明されているように、環境を準備する場合、拡張保護は有効になりません。
問題: Outlook クライアントを使用してパブリック フォルダーのアクセス許可を変更すると、"変更されたアクセス許可を変更できません" というエラーが表示され、失敗します。
この問題は、アクセス許可を変更しようとするパブリック フォルダーが、プライマリ パブリック フォルダー メールボックスが別のサーバー上にある間にセカンダリ パブリック フォルダー メールボックスでホストされている場合に発生します。
この問題は、 最新の Exchange Server 更新プログラムで修正されました。 この KB に記載されている手順に従って修正を有効にします。
拡張保護構成スクリプトの実行中の警告とエラー
スクリプトには、既知の問題の警告が表示され、確認が求められます。
拡張保護を有効にしたために既存の Exchange Server 機能が中断されるシナリオに管理者が実行されないようにするために、スクリプトには既知の問題があるシナリオの一覧が用意されています。 拡張保護を有効にする前に、この一覧を注意深く読んで評価してください。 を押
Yすと、拡張保護を有効にすることができます。
前提条件のチェックが失敗したため、スクリプトでは拡張保護が有効になりません。
拡張保護をサポートするビルドを実行する Exchange サーバーはありません。
組織内の Exchange サーバーが Extended Protection をサポートするビルドを実行していない場合、スクリプトはサポートされていないサーバーで 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 組織全体の 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 ビルド (Exchange Server 2019 CU11 から Exchange Server 2019 CU12 など) に更新する場合は、2022 年 8 月の SU をもう一度インストールする必要があります。
覚えて： 更新をすぐに実行する場合 (CU + SU インストールを意味します)、拡張保護をオフにする必要はありません。 SU をすぐにインストールせずに CU に留まる予定の場合は、CU ビルド (SU がインストールされていない) が拡張保護をサポートしていないため、クライアント接続の問題が発生する可能性があるため、拡張保護を無効にする必要があります。
質問： Active Directory フェデレーション サービス (AD FS) for Outlook on the web (OWA) を使用する環境で拡張保護を有効にしても安全ですか?
答え： はい。拡張保護は、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 サーバーと同じ証明書を使用している場合は、その証明書を使用できます。