最後の Alternate サーバーを削除できないのはなぜですか。

2021年8月31日

[ad_1]

そのため、Exchange オンラインへの移行が完了しました。メールはクラウドにスムーズに流れ込み、すべてのメールボックスがオンラインになりました。移行が終了した今、Exchange サーバーの次は何ですか。

完了後、環境から Exchange Server を削除するために実行するタスクがいくつか用意されていますが、注意すべき重要な点が 1 つあります。Azure AD 接続を実行すると、削除できません毎環境から Exchange サーバー。管理のために少なくとも 1 つを維持する必要があります。この記事では、維持する必要がある内容と、今後の計画を検討できる内容を最小限に抑えるために実行できる操作について説明します。また、今週9月2日にTECで私に参加することができます。

続きを読む: マイクロソフトは、感染したサーバーをきれいにするためにFBIが移動するにつれて、さらに4つのExchangeサーバーの脆弱性を修正します

Azure AD 接続を実行する場合は、受信者管理用の Exchange が必要です。

執筆時点 (2021 年 8 月) では、マイクロソフトは Exchange Online への移行後に少なくとも 1 台の Exchange Server を維持する必要をまだなくなりました。もしハイブリッド ID を実行する予定です。

これは、ハイブリッド ID を実行すると、オンプレミスの Active Directory フォレストとドメインは、Azure Active Directory (Azure AD) に同期されたオブジェクトの真実のソースであり続けるためです。Azure AD は Exchange Online を含む Microsoft 365 が使用するディレクトリであり、ローカル AD から同期されるほとんどすべての属性は Azure AD では読み取り専用であり、ローカルで設定および編集する必要があります。

つまり、新しいユーザーアカウントを作成する場合は、ローカルの Active Directory にユーザーアカウントを作成する必要があります。新しいユーザーアカウントを作成すると、Azure AD Connect は同期ジョブを実行し、新しいユーザーアカウントを表示し、Azure AD で新しい同期アカウントを作成します。新しい Azure AD アカウントは、そのアカウントにリンクされ、重要な属性が欠落している場合は、Exchange 管理センターなどのオンラインツールを使用して、欠損値を入力したり、値を更新したりすることはできません。

ローカルの Active Directory 管理ツールは、Exchange 属性を管理するためのものではありません。缶技術的には、Active Directory ユーザーとコンピューターを使用して (属性エディターを使用して)、ADSIEdit.msc を使用するか、PowerShell スクリプトを使用して、Exchange 固有の属性を設定します。 サポートしない 属性を手動で編集する。マイクロソフトは、サポートのためにマイクロソフトに電話をするオプションが必要な場合は、Exchange サーバーを使用する必要があることを明確に述べています。

マイクロソフトがこの声明を発表した理由は、次のとおりです。まず、マイクロソフトは、環境から最後の Exchange Server を削除するソリューションを提供することにコミットしていますが、小規模、中規模、大規模組織のニーズを考慮する必要がある、合理的に複雑な問題なので、すべてのソリューションに合ったワンサイズを提供することは困難です。Exchange 属性の同期を切断するなどのソリューションはコミュニティで推奨されていますが、AD では古くて古いデータが発生します。書き戻しや調整された変更のための複雑なソリューションは、規制されている多くのエンタープライズ環境では実用的ではなく、小規模な顧客にも適していません。また、Exchange 管理ツールを置き換える一連の PowerShell スクリプトを提供するだけでは、一部の組織では機能する場合がありますが、小規模な組織では管理が複雑すぎます。

単独で実行し、最後の Exchange サーバーを削除する場合は、別のリスクがあります。Microsoft がソリューションを提供すると、自分で行った操作は何でも壊れます。これは、削除を行う前にソリューションに更新プログラムが必要になる可能性があることをマイクロソフトが提案しているためです。

最後に、コンサルタントまたは IT 管理者が提供したサードパーティ製のツールまたはスクリプトが、Exchange 管理センターまたは Exchange 管理シェルと同じ機能を十分にカバーしている場合は、十分にまれです。ローカル Active Directory 内に格納され使用される構成には、Exchange Online で進行中の受信者管理に直接関連するいくつかの領域が含まれていることに注意してください。

ユーザー、共有メールボックス、およびアーカイブのリモートメールボックス管理 (Exchange Online でメールボックスにリンクされた AD 属性の管理)
メールユーザー管理
メール連絡先管理
メールが有効なセキュリティグループの管理
配布グループの管理
承認済みドメインとリモートドメインの管理
電子メールアドレスポリシーの管理と更新
自動検出サービス接続ポイントの管理

私が持っているときでさえこの管理を目的とした合理的に包括的なスクリプトを見ると、Exchange ツールと同じ検証機能が常に提供されるとは限りません。たとえば、プロキシアドレスとプライマリ電子メールアドレスを変更する場合、または電子メールアドレスポリシーに変更を適用する際に同じロジックに従う場合に、アドレスの一意性と RFC 準拠を確保します。スクリプトまたはツールは Active Directory に対して直接動作するため (Exchange に関する知識がほとんどない) Exchange ツールを使用して実行した場合は無効な変更を行うスクリプトを作成できます。

マイクロソフトの状態として- 受信者の管理に関して Exchange が行うすべてを調べることは可能ですが、それは 自己責任で.しかし、時間が経ち、オンプレミスで Exchange を実行するリスクが高まるように見えるため、Microsoft 365 の IT 担当者 (および私のような Microsoft MVP) のコミュニティがリスクをまとめて比較検討し、ソリューションを提供する時期が発生する可能性があります。今はまだ時間ではありませんが。

従来のアプリケーションサーバーに代わって SMTP 電子メールを中継する場合

最も良い方法は、各ベンダの SaaS に対応するアプリケーションをアップグレードするか、少なくとも Microsoft 365 および Exchange Online のネイティブサポートを持つバージョンにアップグレードすることです。Exchange Online を使用して直接電子メールを送信できるように、ソフトウェアを構成する要求によって混乱しているように見える尊敬に値するベンダーは存在しるべきではありません。

このようなアプリケーションは、次の場合 じゃない 2021 年に Exchange Online との間で送信メールを中継するために、オンプレミスのメールサーバーを使用する必要があります。Exchangeオンラインは、 10年.また、これらのベンダーは、Exchange Online で認証された SMTP を使用するだけでは不十分であるというショックや混乱を受けるべきではありません。マイクロソフトは、 2019年9月 (ほぼ3年前)レガシー認証は、期限内にサポートされなくなると発表 SMTP を使用した OAuth 2.0 のサポート約18ヶ月前。開発チームに1時間かけて何を調べるように頼んだベンダー 行う必要があります Microsoft Graph を使用して電子メールメッセージを送信し、ユーザー名とパスワードを保存する必要のない方法で統合を構築し、条件付きアクセスポリシーと多要素認証を利用する環境でシームレスに動作するという結論に達しています。マイクロソフト 365 でアプリケーションが正常に動作するかどうかが仕入先から問い合わされていない場合は、ユーザー以外のユーザーでない限り、疑わしいことがあります。

残念ながら、電話に出てベンダーとの地位を高めることで、ソリューションをサポートするためにあなたから定期的な収益を集める以外はほとんどやっていないという事実は解決されません。また、多くの組織と同様に、このようなアプリケーションを何十ものアプリケーションで実行したり、長い間ビジネスを離れてから長い間開発者によって作成された社内のオーダーメイドアプリケーションが依存している場合、困難な立場に立つ可能性があります。

この位置は、認証されていない安全でない SMTP メッセージを受け入れ、Exchange Online を通じて顧客または従業員のメールボックスに送信されるメッセージを中継する必要がある場合によく使用されます。その場合、多くの場合、最も簡単なオプションは、既存の中継受信コネクタのコピーを使用して、複数の Exchange Server を引き続き実行することです。ここまで読んだように、継続的な管理のためにサーバーが必要なので、多くの場合、意味があります。

「最後の Exchange サーバー」に関する推奨事項

クラウドのみの ID に移行し、現在 Active Directory を削除していないと仮定します (一部の組織 アール) を使用すると、Exchange をオンプレミスで実行し続けることになります。この要件は組織によって多少異なりますが、いくつかの原則に従って導く必要があります。

管理および SMTP 中継の目的で Exchange ハイブリッド機能を実行するために必要なサーバーは、メールボックスをホストするために必要な仕様と同じである可能性は低く、より低い仕様になる可能性があります。
サーバーは通常、オンプレミスまたはクラウドプロバイダーで仮想マシンとして実行するのに適しています。
これらのサーバーで Exchange Server 2016 を実行するだけで済みます。.Exchange Server 2019 を実行する利点は、サーバーコアで実行し、一括オペレーティングシステムのアップグレードをサポートする機能を除いて、今日の利点はありません。
最後の Exchange サーバーの仕様は、通常の Exchange サーバーよりも低い場合があります。最小の要求Exchange Server の irement は通常十分ではありませんが、2 ~ 4 個の仮想 CPU と 12 GB の RAM が搭載されており、100 GB 以上のディスク領域が開始仕様として適切に機能することがよくあります。大量の SMTP リレートラフィックが予想される場合は、サーバーのサイズを適切に設定して、メールキューのデータベースサイズとログが要件を満たしていることを確認し、セキュリティ調査のために拡張ログを保持するのに十分なディスク領域を確保する必要があります。
あなたはすべきです じゃない HTTPS サービスをインターネットに公開する必要があり、すべてのメールボックス (およびパブリックフォルダ) を Exchange Online に移行しました。まず、自動検出レコードを Exchange Online を直接ポイントするように移動し、サービス接続ポイントを$nullに設定します。これらのサーバーにアクセスするクライアントは必要ありません。
SMTP メールを中継する場合送信オンプレミスまたは実行している集中管理型トランスポートにメールを受信しない場合のみ、次の操作を行う必要があります。 じゃない これらのサーバーに対して受信する SMTP メールを許可するファイアウォールルールが必要です。
内部クライアントが Exchange オンプレミスにアクセスする必要がなくなったので、内部ネットワーク上の HTTPS およびその他の接続を Exchange サーバーに制限することもできます。SMTP リレー用の HA を提供するために複数の Exchange Server が必要な場合、HTTPS アクセスはセキュリティで保護されたクライアントからの IT 管理者アクセスにのみ使用するため、負荷分散機能は SMTP リレーにのみ関連し、HTTPS には関係しません。
Active Directory ドメインコントローラーや Azure AD 接続サーバーなど、他の関連サービスを実行しているサーバー上で Exchange メールボックスの役割を実行しないでください。
あなたがべし Exchange サーバーを最新の状態に保つ。これは、最新の更新プログラム、または直前の更新である必要があります (つまり、更新を実行するために変更に同意するために必要な、1 週間などの短期間サポートされた状態を維持します)。さらに、あなた そうですよ べしセキュリティ更新プログラムをリリース後、できるだけ早く適用します。サーバーがインターネットに公開されているかどうかに関係なく、この操作を行います。低い特権のアカウントが侵害されるのが一般的であり、このアカウントは、エスカレートされた特権を得る機会を見つけるためにネットワークを探索するために使用されます。
セキュリティインシデントを調査できるように、Exchange がゼロデイの脅威にさらされることを確認できるように、サーバーのログ機能が設定されていることを確認します。この機能を使用している場合は、ログが SOC または SOC サービスによって使用され、脅威についてリアルタイムで分析されることを確認します。
EPP および EDR ソフトウェアをインストールしていることを確認します。Exchange 管理者は、AV ソフトウェアがデータベースファイルのスキャンを試み、問題を引き起こす可能性があるため、過去に、Exchange Server でウイルス対策ソフトウェアを実行することの有効性について疑問を呈してきました。これは、正しい除外を指定しない場合にのみ発生します。エンドポイント用 Defender などの EDR (エンドポイント検出および応答) ソフトウェアには、Exchange に関する特定の機能と推奨事項も用意されているので、これらの製品を購入した場合は、それらを使用します。

オンプレミスの Exchange サーバーのない未来

ただし、マイクロソフトする最後の Exchange Server を削除するソリューションが提供され、Exchange がサイバーセキュリティの対象になっている場合、Exchange サーバーへのアクセスを制限したり、管理に使用されていない場合にオフにしたりすることが必要になる場合があります。レガシーアプリケーション、マルチファンクションコピー機に SMTP リレーが必要で、Exchange Online への直接配信のためにファイアウォールに大量の送信 SMTP ホールを挿入したくない場合は、何ができますか?

最後の Exchange Server を削除する方法が最終的にリリースされたときに、マイクロソフトが何らかのガイダンスを提供することを期待していますが、いくつかの選択肢を検討することができます。結局のところ、既知の IP アドレスと証明書から TLS で保護されたメッセージを受け入れることができる Exchange Online 側の既知の構成を使用した標準準拠の SMTP リレーのみを検討しています。

最初のオプションは、エッジトランスポートの役割を実行している Exchange サーバーの使用を検討することです。この役割は、DMZ などの境界ネットワーク領域内のスタンドアロンサーバー上のローカル Active Directory ドメインに接続しなくてもインストールできます。エッジトランスポートの役割では、HTTPS サービスはインストールされず、最小ハードウェア要件も低くなります。エッジサーバーハイブリッド展開でサポートされているが、Sans-Exchange の将来のモデルは、EdgeSync 関係を提供する Exchange 2016 メールボックスサーバーが存在せず、代わりにこのモデルが適用されないことを意味します。各エッジサーバーに直接送受信コネクタを作成する.マイクロソフトのライセンスに関するよくある質問特定の役割が指定されていない場合、ハイブリッドメールフローシナリオがエッジトランスポートサーバーを対象とすることを示しますが、このことが当てはまることを Microsoft アカウントマネージャーに確認することが重要です。それ以外の場合、エッジトランスポートの役割は、現在のスキルと同じスキルを使用して、中継受信コネクタと Exchange Online への送信コネクタを維持する機能を提供し、企業ネットワークと Active Directory から Exchange を削除する必要を満たします。

その他のオプションとしては、まず Windows サーバーの IIS SMTP 機能を使用するオプションがあります。これは、一部の組織が成功して使用した構成ですが、Exchange 管理者が Exchange Server 2000 および 2003 から長期間覚えている SMTP 機能と非常によく似ています。IIS SMTP をメール中継に使用することを検討している場合は、使用するオプションを必死に使用する必要があり、マイクロソフト以外のソリューションの方が、継続的な開発とサポートを提供している方が適切な場合があります。Exim、Postfix、Sendmail などのオープンソースメールサーバーは、十分に文書化されており、非常に高いメールフロー負荷を維持できます。クラウドベースのメールフィルタリングソリューションの基盤を形成することがよくありますが、セットアップのスキルが必要で、チェックとメンテナンスが必要です。

ここまで読んで、「いいえ、社内で SMTP メールリレーを管理したくない」と考えている場合は、従来のアプリケーションベンダーに Exchange Online でソフトウェアリレーメールを適切に作成するよう依頼する取り組みを始めるのが、より良いエネルギーを費やし、維持する必要のないソリューションになるかどうかを検討してください。