SE の雑記

続いてはエンタープライズ アレイの構築になります。
エンタープライズ アレイの場合、[Enterprise Management Server] (EMS) という役割のサーバーが必要となります。

この EMS ですが、TMG サーバー (TMG の F/W 機能を持つサーバー) と共存することができません。
そのため、エンタープライズ アレイを構築する場合は、別途 EMS 用のサーバーを準備する必要があります。

エンタープライズ アレイの構築としてまずは、EMS のインストールについてまとめていきたいと思います。

[環境の概要]

今回の環境ですが最初の環境は以下の図のようになっています。
TMG-01 / 02 に関してはスタンドアロン アレイと同様で最初はスタンドアロン サーバーとして構築しています。
EMS をインストールする TMG-EMS-01 / 02 に関しては、ドメインに参加させた状態となっています。
今回の投稿では、EMS をインストールする手順からまとめていきたいと思います。

[1 台目の EMS のインストール]

それでは、EMS をインストールしていきたいと思います。

1. TMG 2010 Enterprise Edition のインストールメディアを挿入し、[autorun.hta] を実行します。
2. [準備ツールの実行] をクリックします。
   
3. UAC が働いた場合は、[はい] をクリックします。
   
4. [次へ] をクリックします。
   
5. [ライセンス条項に同意します] を有効にして、[次へ] をクリックします。
   
6. [Enterprise Management Server (EMS) (アレイの一元管理に使用)]? を選択し、[次へ] をクリックします。
   ?
7. [次へ] をクリックすると、EMS をインストールするのに必要な役割、機能がインストールされます。
   
8. [Forefront TMG インストール ウィザードの起動] を有効 (デフォルト) にし、[完了] をクリックします。
   
9. UAC が働いた場合は、[はい] をクリックします。
   
10. [次へ] をクリックします。
    
11. [使用許諾契約書に同意します] を選択し、[次へ] をクリックします。
    
12. [次へ] をクリックします。
    ?
13. [次へ] をクリックします。
    
14. 今回は最初の EMS のインストールになりますので、[この EMS に新しいエンタープライズ構成を作成] を選択し、
    [次へ] をクリックします。
    
15. [次へ] をクリックします。
    
16. エンタープライズ名を入力して、[次へ] をクリックします。
    エンタープライズは TMG の管理単位の最上位の階層となります。
    
17. 今回はドメイン環境ですので、[単一のドメインに展開] を選択して、[次へ] をクリックします。
    ?
18. [インストール] をクリックします。
    
    
19. [完了] をクリックします。
    

これで 1 台目の EMS のインストールは完了です。
インストールが完了すると以下のような構成となります。

EMS は TMG の CSS の機能のみを持つサーバーとなり、F/W の機能は持ちません。
このサーバーは以下のサービスが動いているシンプルなサーバーとなります。

• Microsoft Forefront TMG 記憶域
• ISAGCCTRL

構成を補完するためのサービスのみを提供している形になりますね。

[2 台目の EMS のインストール]

続いて、EMS を冗長化するために 2 台目の EMS をインストールしたいと思います。

1. 以下の画面までは 1 台目のインストールと手順は同じです。
   こちらの画面が表示されたら、[この EMS に既存のエンタープライズ構成をコピー] を選択し、[次へ] をクリックします。
   
2. 1 台目の構成保管サーバーのサーバー名を入力し、[次へ] をクリックします。
   

今回は、[Domain Users] グループのユーザーで、各 TMG / EMS サーバーのローカル [Administrators] グループに
参加しているユーザーでログオンしています。

3. [ネットワーク上でレプリケートする] を選択して、[次へ] をクリックします。
   # 私の環境ですとなぜか表示がおかしいのです…。
   
4. 今回はドメイン環境なので、[単一のドメイン内に展開] を選択して、[次へ] をクリックします。
   
5. [インストール] をクリックします。
   
   
6. [完了] をクリックします。
   

以上で、EMS のインストールは完了です。
この手順までで以下の環境が構築できました。

このままでは、TMG サービスのサーバーはスタンドアロン サーバーとなっており、各 TMG サーバーが EMS に接続していない
状態となっています。

次の投稿で、スタンドアロン サーバーを EMS に接続する手順をまとめていきたいと思います。

TMG (Threat Management Gateway) 2010 で冗長構成をとるためには、TMG でアレイを構成する必要があります

TMG のアレイには以下の 2 種類があります。

1. スタンドアロン アレイ
2. エンタープライズ アレイ

ドメイン環境とワークグループ環境では構築の方法が異なるようなのですが、今回は非武装 AD に参加している TMG が 2 台ある状態で、
スタンドアロン アレイ を構築する手順をまとめてみたいと思います。
# ワークグループ環境の場合は、サーバー認証証明書とそのサーバー認証証明書のルート証明書が必要となります。

[環境の概要]

今回の環境ですが、最初は以下のような状態で構築しています。
?

TMG を AD 上に 2 台構築してあり、現在はアレイを組んでいない状態 (スタンドアロン サーバー) となっています。

TMG の Enterprise Edition では、構成保管サーバー (CSS:Configuration Storage Server) として AD LDS が使用されています。
内容を確認したい場合、[LDAP://localhost:2171/CN=FPC2] に ADSI エディターで接続をすることで確認をすることができます。
?
TMG ではマスターの情報は、AD LDS に格納され、その情報が各 TMG サーバーのローカルレジストリに反映されるようになっています。

アレイを組むことで、各 TMG サーバーで同一の CSS を使用できるようになります。

スタンドアロン アレイの場合は、CSS は単一、エンタープライズ アレイの場合は CSS のレプリカを作成し冗長化を
することができるようになります。

?

[スタンドアロン アレイの構築]

それでは実際にスタンドアロン アレイを構築したいと思います。

1. まずは、どの TMG サーバーをアレイ マネージャーとするかを決めます。
   アレイ マネージャーは AD LDS を実行するサーバーになります。
   スタンドアロン アレイの場合、アレイ マネージャーに TMG サーバーを参加させることで冗長構成をとることになります。
2. アレイ マネージャーとするサーバーを決めたら、参加させるサーバーで [Forefront TMG の管理] を実行します。
   
3. [Forefront TMG (<サーバー名>)] を右クリックして、[アレイへの参加] をクリックします。
   
4. [次へ] をクリックします。
   
5. [指定したアレイ メンバー (アレイ マネージャー) によって管理されるスタンドアロン アレイに参加します。] を選択し、[次へ] をクリックします。
   ?
6. アレイ マネージャーとする TMG サーバーのサーバー名を入力し、[ログオンしているユーザーの資格情報を使って接続する] を選択し、
   [次へ] をクリックします。
   
   今回は、[Domain Users] グループのユーザーで、各 TMG サーバーのローカル [Administrators] グループに参加しているユーザーで
   ログオンしています。
7. [完了] をクリックします。
   

   [完了] をクリックすると、アレイの参加が開始されます。
   

8. [OK] をクリックします。
   

以上で、スタンドアロン アレイの設定は完了です。

構成とシステムを確認した画面が以下になるのですが、サーバーが 2 台構成となっているのが確認できます。

[Forefront TMG (<サーバー名>)] を右クリックして、プロパティを開いた画面が以下になります。
[種類] が [スタンドアロン アレイ] になっているのが確認できますね。
エンタープライズ アレイの場合は、使用する CSS のサーバーが指定できるのですが、スタンドアロン アレイの場合、CSS は単一の
サーバーとなるため、CSS のサーバーを指定することはできません。

こちらは、アレイに参加していない別のサーバーで取得したものになります。
アレイに参加する前のサーバーは、[スタンドアロン サーバー] となっていますね。
?

[スタンドアロン アレイ構築後のサーバーの環境]

スタンドアロン アレイを構築するとサーバーの環境は以下のように変更されます。
パッと見わかりずらいのですが、[TMG-02] からディレクトリサービスの画像が消えています。
?

スタンドアロン アレイ構築時の環境変化のポイントだと思うのですが、アレイに参加しているサーバーは、アレイ マネージャー以外の
サーバーで AD LDS が [無効] な状態になります。

これは、スタンドアロン アレイでは、アレイ マネージャーが唯一の CSS になるからだと思います。

はじめ、この辺の動きが理解できておらず、すったもんだしましたがようやく構成が理解できてきました。
この構成では、TMG サーバーは冗長化されているのですが、CSS が冗長化できていない状態となっています。

CSS を冗長化するためにはエンタープライズ アレイの構成を構築する必要があります。

次の投稿でエンタープライズ アレイの構成で構築をしてみたいと思います。

TMG 2010 ではネットワーク検査システム (Network Inspection System) という機能が追加されています。
バーチャルパッチといわれるような機能に相当し、TMG で既知の脆弱性の検査をし脆弱性を狙った攻撃をブロックする機能になります。

検査される内容に関しては、以下のように管理されており基本的には MS のセキュリティ情報と対応付けられており、
それぞれのセキュリティの問題に対して、署名という形でブロックする情報が管理されています。

この情報は Microsoft Update 経由で更新ができるようになっており、定期的に更新ができるようになっています。

検査の内容に関しては署名セットという形でパックされた形で管理されており、内部ではバージョン管理がされています。
何かの理由で以前配信された署名セットを使いたいといった場合には、アクティブにする署名セットを手動で選択することも可能です。

?

この検査機能ですが、昨日から構成について調べてみたのですが、以下の図のようなインライン型の IDS (Intrusion Detection System) となるようで、
検査をするためには、TMG を介してアクセスされるようにネットワークを構成する必要があるようなんですよね。
# IDS 大きく分類すると、はインライン型とネットワーク型に分かれるようです。私はネットワーク苦手で恥ずかしながらインライン型しか知りませんでした…。
　【特集】 続 不正侵入対策最前線

この機能を使うことで、セキュリティパッチが提供されていない、レガシー OS (Windows NT / 95 / 98 / 2000 (2000 はもうじきですね) 等) に関しても、
TMG 経由のアクセスに関しては脆弱性を狙っての攻撃をブロックすることができるようになります。

簡単な図にするとこのような形式でしょうか。
TMG で検査がされれば脆弱性を狙った攻撃はブロックされますので、TMG の後ろに配置しているサーバーの OS には依存しない形になります。
?

ただし、このような形でアクセスができるネットワーク環境になると TMG では検査ができないので NIS が機能しません。
# ネットワーク機器側でポートミラーで飛ばせば良いのかな？？
ネットワークの構成は考える必要がありそうですね。
私はネットワーク関連が苦手なので、もしかしたら間違っているのかも…。
このようなアクセスが可能な場合でも検査できる！！ということでしたらコメントを頂けるととても助かります。

?

この NIS の機能なのですが、TMG ではテスト用に 2 種類の署名が用意されており、正常に構成されているかの動作検証をすることができるようになっています。
今回は、このテスト用の署名を使った NIS のテストについてまとめていきたいと思います。

[テスト用の署名]

NIS のテスト用の署名として、HTTP と SMB のテスト署名が用意されています。
これらの署名を使ったテストなのですが、TMG のヘルプにも記載があるのですがヘルプの内容が間違っているようで、テスト用の署名の名称だったり、
テストで使用するための URL / ファイル名を見つけることができなかったりします…。
# [NIS の機能をテストする] というヘルプがあるのですが、内容がいまいち…。

TMG の書籍として、
Microsoft Forefront Threat Management Gateway (TMG) Administrator’s Companion (Pro -Administrator’s Campanion)
という書籍があるのですが、この中に HTTP を使用した NIS のテスト方法について記載がされています。

本を買うのはちょっと・・・。という方にはホワイトペーパーも用意されています。
# というより、NIS に関してはホワイトペーパーの方が詳しいです。
ホワイトペーパーでは、HTTP だけでなく、SMB のテスト方法についても記載されています。

[Word]
Guide for Configuring, Monitoring and Troubleshooting the Network Inspection System (NIS) in Forefront Threat Management Gateway (TMG) 2010

[PDF]
Guide for Configuring, Monitoring and Troubleshooting the Network Inspection System (NIS) in Forefront Threat Management Gateway (TMG) 2010

テストをする際には、ホワイトペーパーを一読した方が良いと思います。
# 私は英語の能力がべらぼーに低いので眺めながら (とてもとても読めません…) やったのですが何とかテストで
きました。

テスト用の署名は以下の 2 種類になります。

[HTTP 用]

[SMB 用]

# 私の環境、なぜか SMB のテスト用の署名が同一名称で 2 つありました…。

これらの署名で検知されるようなアクセスをすることで NIS のテストをすることが可能です。

[HTTP のテスト]

HTTP 用のテストに関しては方法は簡単で、TMG を経由するような環境を作ってからブラウザで特定の URL にアクセスすることで確認ができます。

テスト用の URL は以下のものになります。
# ホワイトペーパーに記載されています。

http://www.contoso.com/testNIS.aspx?testValue=1!2@34$5%6^[{NIS-Test-URL}]1!2@34$5%6^

NIS の署名を無効にしている状態で、上記の URL にアクセスすると、US の microsfot.com にアクセスされます。

それでは HTTP 用の NIS の署名を有効にしてテスト用の URL にアクセスをしてみます。

[500 Internal Server Error. トラフィックが IPS によってブロックされましたという。] というエラーが発生し、
ネットワークのアクセスがブロックされます。

TMG のログにも以下のように NIS でブロックされたというログが出力されます。

上のアクセスですが、このような形になっています。
デフォルトゲートウェイとして、TMG を構成しています。
# NIC 2 枚で、[エッジ ファイアウォール] として構成しています。
この場合、エラーコードとしては [500] となるようです。

?

以下の図のような形で、クライアントのデフォルト G/W としては、ルーターを設定して、プロキシとして TMG を設定してアクセスをしてみます。

?

エラーメッセージは同じなのですが、[502 Proxy Error] という形で NIS による検査がされます。
?

プロキシとして設定した場合に NIS で検査された場合は以下のようなログが TMG に記録されます。

ゲートウェイでなく、プロキシにしても HTTP に関しては検査ができますね。
単一ネットワークの場合、ゲートウェイとして TMG を構成するのはできないと思いますので、その場合はプロキシとして構成する必要があります。

?

[SMB のテスト]

もう一つのテスト用の署名として SMB の署名が用意されています。

SMB のテスト署名を使ったテストに関してもホワイトペーパーに記載がされています。
これに関しては、TMG を経由するようにして特定のファイル名のファイルをコピーすることでテストをすることができます。

今回は以下の構成に市提案す。

テストに使用するファイル名は以下の名称になります。

C0AABD79-351B-4c98-8AE7-69F4279FEF54.txt

SMB 用のテスト用署名を無効にしている状態ではこのファイル名のファイルをゲートウェイとして構成している TMG を介してコピーすることができます。

SMB のテスト用署名が有効になっている状態では、ファイルをコピーすると以下のエラーが発生します。

TMG のログには、CIFS が NIS によりブロックされていることが出力されています。

テストに関してはこれらのテスト署名を使用することで実施することができます。
パフォーマンス測定などもこれらのテスト署名でできそうですね。

先週の頭まで、MCP 70-659 の勉強で検証環境に VDI や RemoteApp を構築していました。
VDI と RemoteApp は RD (リモートデスクトップ) Web アクセスで公開することができます。

私の使っている検証環境には TMG 2010 があるので、リバースプロキシ越しで使うことができるのかな？
と思って RD Web アクセス用のルールを作って試してみました。

?

■TMG 2010 のファイアウォールポリシー

リバースプロキシはファイアウォールポリシーで設定をすることになります。
パスの変換ルールとして [RDWeb] を許可するルールを作る必要があります。

設定については以下の画像の用になります。
[/RDWeb/*] のパスに対してのアクセスを許可しています。
?

ブリッジに関しては [HTTPS to HTTPS] (TMG が 443 で受けて RD Web アクセスの 443 に接続) で設定しているのですが、
これは [HTTPS to HTTP] （TMG が 443で受けて RD Web アクセスの 80 に接続) でもよいかもしれないですね。
?

ざっくりとした概要図を書くと以下のようになります。
# 正確には RD 接続ブローカーや、RD ゲートウェイも入っていたりするのですが。

?

クライアントからは、TMG 2010 に HTTPS でアクセスできれば RD Web アクセスを経由して、VDI や RemoteAppを
使用することができるようになります。

?

VDI / RemoteApp は RD ゲートウェイを設定することができ、[接続承認ポリシー] [リソース承認ポリシー] と
組み合わせることもできます。
　 　

TMG と RD ゲートウェイが組み合わされるため、構築していて認証される個所がよくわからなくなってきましたが…。
設定がきちんとされていれば、TMG 2010 越しで VDI と RemoteAppを使用することができるようになります。

Windows 7 の [RemoteApp とデスクトップ接続] も TMG 2010 越しで使用することができます。
?
　

リスナーの認証設定によっては、[認証の委任] を [委任できません。クライアントは直接認証できます] に
設定しないとうまく動作しないことがあるかも知れません。
# クライアントは直接認証できないのが望ましいんでしょうけど。私の環境はリスナーの認証設定をきちんと整備していないので
　直接認証できないと接続ができないことがしばしばあります。
?

HTTPS を公開することでいろいろなサービスが享受できるようになりますね。

ISA 2006 でも同じだと思います。

検証環境の Exchange Server 2010 の OWA は TMG 2010 の後ろに配置しています。
帰宅の電車の中で時間があったので、Outlook Anywhere を設定しようとしていたのですが、プロファイル設定時に
サーバーに接続することができませんでした。

TMG 2010 のログを確認していたところ、OWA 用のアクセスルールで賄えていないパスに対してアクセスされていました。

そういえば、Outlook Anywhere は [/rpc] に対してアクセスできる必要がありましたね。
Outlook Anywhere での ISA Server の使用

私が使用していたルールでは以下のパスしか設定されていませんでした。

なんでだろうと考えていたところ、作成するときに使用していたのが、[Outlook Web Access] だったからのようでした。
[Outlook Anywhere (RPC/HTTP)] でルールを作成すると Outlook Anywhere 用に [rpc] が設定されているルールが作成されました。

[Outlook Web Access] 用のルールに [/rpc/*] のパスを追加することで、TMG 2010 経由で Outlook Anywhere を
使用することができるようになりました。

最近は SQL Server ではなく、Exchange Server の引き合いに関わることが多くなってきました。
昔、話題に上がることのあった、Exchange のストレージエンジンの SQL Server への変更が行われるのであれば、
Exchange Server に携わることで SQL Server のスキルアップもできて一挙両得なんですけどね。
実際に、ESE が SQL Server に変わる日は来るのでしょうかね～。