SMTP 匿名リレー用に Alternate Server 2019 を構成する方法

この資料では、Exchange Server 2019 を匿名の中継として構成する方法のガイダンスを提供し、この 2016 そして 2013 このシナリオを扱う記事。内部ネットワークの範囲を使用して、Exchange Server 2019 を独自のネットワーク内で匿名中継として構成する方法を文書化し、電子メールを中継できるユーザーを制限します。
匿名リレーの機能
匿名の中継は、サービスやアプリケーションが SMTP 電子メールを送信できるようにする組織の一般的な要件です。ハイブリッド展開を使用する組織では、汎用 SMTP サーバーではなく、Exchange 2019 サーバーを使用して匿名で電子メールを中継することもできます。マイクロソフトの文書化 Exchange ハイブリッド展開の前提条件 Exchange Server 2019 のサポートが含まれ、Exchange 2019 サーバーを使用する場合はさらに強化されます。
テストフレームワーク
このシナリオをラボでテストする場合は、お客様に対するご馳走をお願いします。我々は、再生可能なラボを作成し、 自動化されたラボフレームワーク。 ザ このシナリオの Exchange 2019 ラボ には、ドメイン コントローラー、Exchange 2019 サーバー、および Windows 10 クライアント コンピューターが含まれています。これらの演習シナリオは、インターネットに接続するためのものではなく、この記事で説明する手順を再現することを目的としたものです。
ザ 自動化されたラボフレームワーク では、ここで繰り返すつもりはない、開始方法に関する広範なガイダンスを提供します。しかし、ここでは実用的な365で、我々は始めるために繰り返し可能な経験を提供するためにかなりの作業をしました。はじめにセクションを作成しました。ガイダンスを見つけることができます。 ここは.
実用的な365は、ラボの構成に沿って従います

ラボには 3 台のマシンが含まれています。
名前 | 役割 | IPアドレス |
ラボ 2019DC1 | ドメイン コントローラ | 192.168.12.3 |
ラボ2019EX1 | Windows サーバー 2019 の Exchange サーバー 2019 | 192.168.12.4 |
ラボ2019クライアント | Windows 10 ドメインに参加しているクライアント | 192.168.12.5 |
内部リレーか第三者リレーか?
内部リレーは、内部送信元からの電子メールを受け付け、送信先に転送するように構成された SMTP サーバーまたはサービスです。その送信先は、オンプレミスの Exchange 組織、Office 365 テナント、または IT ポリシーで許可されている場合は、外部の電子メール ドメインである可能性があります。
第三中継とは、誤って設定された電子メールサーバーで、どこからでも接続でき、任意のドメインに対して電子メールを受け付けます。オープンリレーは、次の傾向があります 浄化者によって見つかる 大量の電子メールを送信し、ブロックまたはブラックリストに載ってしまうシステムを引き継ぐスパムの。
SMTP トラフィックの処理
匿名の中継を構成する場合、サーバー、プリンタ、アプリケーションなどの許可されたサービスのサブネットを指定しているため、または構造化されていない環境で SMTP 要求がどこから発生するかを知る必要があります。明らかに明確に定義されたサブネットは、作業しやすいですが、IPアドレスのリストも格納できます。両方のシナリオを以下で説明します。
名前空間
ネームスペースは、将来サービスを証明し、後日スケールアウトできる重要な設計上の考慮事項です。DNS エイリアスまたはロード バランサーを使用して、relay.company.com と呼ばれる SMTP ネーム スペースを負荷分散されたネーム スペースとして設計する場合があることを考慮してください。また、名前付け規則の一部としてシアトルおよびロンドン・ヒースロー空港コードを使用して、relay-sea.company.com や relay-lhr.company.com などの地理的なコンポーネントを追加することもできます。
単一のマシンしか持っていない場合、なぜネームスペースを作成するのでしょうか?これは、サービスを提供するマシン名から作成したサービスを抽象化することで、将来の設計を証明するためにこれを行います。
Exchange 2019 にアップグレードする Exchange 2013 サーバーを使用するシアトルのブランチ オフィス シナリオを考えてみましょう。SMTPSEA.COMPANY.COM ではなく、EXSEA2013 を SMTP リレーとして使用するようにプリンタとアプリケーションが構成されている場合は、古いサーバを新しいサーバにスワップアウトするのではなく、サーバを指すように設定された多くのポイントを再構成する必要があります。ネームスペースの後ろに1つ。
ラボでは、まず、Lab2019DC1 の DNS コンソールを使用して、Exchange 2019 サーバー LAB2019EX1 (図 1) を指す CNAME mail.practical365lab.com レコードを作成します。

図 1: 名前空間の CNAME レコード
エクスチェンジ 2019
Exchange Server 2019 アーキテクチャ Exchange サーバーを単一の構成要素として展開しますのは、フロントエンドとバックエンドの役割を含んでいます。フロントエンドトランスポートおよびトランスポートサービス 同じサーバーに同じ場所に配置されている.新しい Exchange 2019 サーバーをインストールすると、Exchange がインターネットから電子メールを受信できるようにする既定の受信コネクタを含む、いくつかの受信コネクタが作成されます。既定の受信コネクタの詳細を簡単に確認し、専用の匿名リレー コネクタを作成する場合は無視します。
まず、PowerShell と Exchange 管理 GUI を使用して、Exchange 2019 サーバー (LAB2019EX1) の既定のコネクタを調べることから始めましょう。
受信コネクタを取得します。
[PS] 受信 >コネクタを取得する
ID バインドが有効
——– ——– ——-
LAB2019EX1デフォルトのLAB2019EX1 {0.0.0.0:2525、 [::]:2525} 真
LAB2019EX1クライアント プロキシ LAB2019EX1 {[::]:465, 0.0.0.0:465} 真
LAB2019EX1デフォルト フロントエンド LAB2019EX1 {[::]:25, 0.0.0.0:25} 真
LAB2019EX1アウトバウンド プロキシ フロントエンド LAB2019EX1 {[::]:717, 0.0.0.0:717} 真
LAB2019EX1クライアント フロントエンド LAB2019EX1 {[::]:587, 0.0.0.0:587} 真
[PS] C:>
取得–受信コネクタ [PS] C:>取得–受信コネクタ 同一性 バインド 有効 ———— ———— ———– ラボ2019EX1デフォルト ラボ2019EX1 {0.0.0.0:2525, [::]:2525} 真 ラボ2019EX1クライアント プロキシ ラボ2019EX1 {[::]:465, 0.0.0.0:465} 真 ラボ2019EX1デフォルト フロントエンド ラボ2019EX1 {[::]:25, 0.0.0.0:25} 真 ラボ2019EX1送信 プロキシ フロントエンド ラボ2019EX1 {[::]:717, 0.0.0.0:717} 真 ラボ2019EX1クライアント フロントエンド ラボ2019EX1 {[::]:587, 0.0.0.0:587} 真 [PS] C:> |
Exchange 管理センターで、 メールフロー それから 受信コネクタ.受信コネクタを表示するサーバーを選択してください:

専用受信コネクタ
特定の内部 IP アドレスから匿名リレー用の専用受信コネクタを作成します。これは、インターネットから電子メールを受信するように構成されている既定の受信コネクタを変更するよりも良い考えです。既定の受信コネクタを変更しないと、サーバーが誤って第三者中継になることを防ぎます。
ラボでは、内部アドレス範囲は 192.168.12.0/24 ですが、コネクタが接続を受け付けないように構成する必要はありません。e サブネット全体。この記事のために、IPアドレス192.168.12.5のAB2019クライアントがアプリケーションサーバー/多機能プリンタであると仮定します。デモンストレーションのために、SMTP リレー サービスを必要とするプリンタに 192.168.20.0/24 範囲が構成されていることを前提とし、それに応じてコネクタを構成します。これにより、コネクタを保護するために、さくらんぼの IP アドレスとサブネット全体を追加するデモンストレーションを行うことができます。
次の PowerShell コマンドを発行して、コネクタを作成および構成します。
#Create、"P365 匿名リレー" という新しいフロントエンド受信コネクタを作成します。
新しい受信コネクタ -名前 “P365 匿名リレー" '
-トランスポート ロール フロントエンド トランスポート -カスタム – バインディング 0.0.0.0:25 '
-リモートIpRanges 192.168.12.5,192.168.20.0/24
匿名で使用する「P365匿名リレー」を#Configure
受信コネクタの設定 “P365 匿名リレー" – アクセス許可グループ匿名ユーザー
受信コネクタ “P365 匿名リレー" |AD アクセス許可の追加 – ユーザー “NT 機関匿名ログオン" '
-拡張権利 “Ms-Exch-SMTP-受け入れ- 任意の受信者"
外部でセキュリティ保護された「P365 匿名リレー」を#Configure
受信コネクタ “P365 匿名リレー" -認証メカニズム外部権限 '
-アクセス許可グループのサーバー
#Create、"P365 匿名リレー" という新しいフロントエンド受信コネクタを作成します。 新機能–受信コネクタ –名前 「P365 匿名リレー」 ` –トランスポートロール フロントエンドトランスポート –習慣 –バインド 0.0.0.0:25 ` –リモート IpRanges 192.168.12.5, 192.168.20.0/24 匿名で使用する「P365匿名リレー」を#Configure セット–受信コネクタ 「P365 匿名リレー」 –アクセス許可グループ 匿名ユーザー 取得–受信コネクタ 「P365 匿名リレー」 | 足す–AD アクセス許可 –利用者 “NT 機関匿名ログオン" ` –拡張権利 「Ms-Exch-SMTP-受け入れ-任意の受信者」 外部でセキュリティ保護された「P365 匿名リレー」を#Configure セット–受信コネクタ 「P365 匿名リレー」 –認証メカニズム 外部権限 ` –アクセス許可グループ サーバー |
上記のコマンドの PowerShell 出力は次のとおりです。
ID バインドが有効
——– ——– ——-
LAB2019EX1P365 匿名リレー {0.0.0.0:25} 真
[PS] C:>
[PS] C:>#Configure 「P365 匿名リレー」を匿名で使用する
[PS] C:>セット受信コネクタ “P365 匿名リレー" – アクセス許可グループ匿名ユーザー
[PS] C:>受信コネクタ “P365 匿名リレー" |AD アクセス許可の追加 – ユーザー “NT 機関匿名ログオン" '
>> -拡張権利 “Ms-Exch-SMTP-Accept-Any-Recipient"
ID ユーザー拒否の継承
——– —- —- ———
ラボ2019EX1P365 A..NT オーソリティANON..偽の偽
[PS] C:>
[PS] 外部で保護された C:>#Configure “P365 匿名リレー"
[PS] C:>セット受信コネクタ “P365 匿名リレー" -認証メカニズム外部権限 '
>> -アクセス許可グループのサーバー
[PS] C:>
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
[PS] C:>#Create、"P365 匿名リレー" という新しいフロントエンド受信コネクタを作成します。 [PS] C:>新機能–受信コネクタ –名前 「P365 匿名リレー」 ` >> –トランスポートロール フロントエンドトランスポート –習慣 –バインド 0.0.0.0:25 ` >> –リモート IpRanges 192.168.12.5, 192.168.20.0/24 同一性 バインド 有効 ———— ———— ———– ラボ2019EX1P365 アノニマス リレー {0.0.0.0:25} 真 [PS] C:> [PS] C:>匿名で使用する「P365匿名リレー」を#Configure [PS] C:>セット–受信コネクタ 「P365 匿名リレー」 –アクセス許可グループ 匿名ユーザー [PS] C:>取得–受信コネクタ 「P365 匿名リレー」 | 足す–AD アクセス許可 –利用者 “NT 機関匿名ログオン" ` >> –拡張権利 「Ms-Exch-SMTP-受け入れ-任意の受信者」 同一性 利用者 打ち消す 継承 ———— —— —— ————– ラボ2019EX1P365 ある... NT 権限アノン... 偽 偽 [PS] C:> [PS] C:>外部でセキュリティ保護された「P365 匿名リレー」を#Configure [PS] C:>セット–受信コネクタ 「P365 匿名リレー」 –認証メカニズム 外部権限 ` >> –アクセス許可グループ サーバー [PS] C:> |
Exchange 管理コンソールからコネクタにアクセスするには、 メールフロー それから 受信コネクタ:

新しいコネクタをダブルクリックし、セキュリティをクリックして検証し、スコープを設定してセキュリティを表示します。:

ネットワーク設定:

どのように我々はそれが働いた知っていますか?
以下では、アプリケーションサーバーLab2019Clientから、送信メールメッセージを使用して、LAB2019Clientマシンからコネクタをテストするテストを参照してください。コネクタを作成する前に、コネクタを作成した後、匿名で電子メールを中継することができませんでしたが、テストは成功します。
PowerShell を使用したテスト
PowerShell の送信メール メッセージ コマンドレットを使用したテストの出力を次の図 6 に示します。
メール メッセージの送信 -smtp サーバー mail.practical365lab.com '
-'administrator@practical365lab.com から-「nicolasblank@gmail.com へ」
-件名 'テストメール’ -ポート 25
送信–メールメッセージ –サーバー 郵便.実用的な365ラボ.com ` –差出人 '管理者@実用的な365ラボ.com' –宛先 'ニコラスブランク@gmail.com' ' –件名 '試験 電子メール' –港 25 |

Telnet を使用したテスト
Telnet を使用したテスト – 下図 7 に示す受信コネクタを構成する前に行います。Telnet テストで Exchange 2019 サーバー経由でメールを中継しようとすると、失敗すると予想されます。

Telnet を使用したテスト – 下図 8 に示す受信コネクタを構成した後。このテストは、Exchange 2019 で受信され、配信のためにキューに入れられたメール メッセージで正常に終了します。

継続的なメンテナンス
mail.practical365lab.com の DNS エイリアスを作成したので、いつでも、担当する Exchange サーバーを新しいバージョンに置き換えたり、ロード バランサーによってホストされる仮想 IP アドレスの背後に複数の Exchange サーバーを構成したりできます。
PowerShell を使用してコネクタを作成したので、作成ロジックを必要な数のサーバーにレプリケートできます。
ディスカッション
コメント一覧
まだ、コメントがありません