[PCNS] ILM 連携の際に使われるポートについて
みなさまこんにちは。ういこです。
金曜日、息子の保育園の袋の中にそっと入っていたのが発見されたのですが、このシチュエーションって明らかに本命。
いつも仲良くしている女の子からでした…。それで、他の子がいないときに御礼を言えと指令を土曜日に出したのですが、なにぶん、まだガンダムと女子なら、確実にガンダムを取るお年頃。みんなの前で元気にありがとう！といったとのこと。彼女の反応は、
「…それ、私じゃなくて入れたのママだから … 」
(涙) うう、彼女の気持ちを思うと涙が禁じえません。家で激しく「みんなの前で言うなというたろうが」と責め立ててやったところ、「だって、入れたのは●●ちゃんじゃなくて、ママだって言ってたよ！？関係ないからいいじゃん！」とキレられました。
どうやら彼は「モテ期」確率変動のビッグウエーブはつかめなかったようです…。
…息子よ！！君今のままだとモテないよ！！
さてそれはさておき今日のお題です。
今日は PCNS についてです。
ちなみに、PCNS はちょっと厄介なところがあります。なぜならば、PCNS 単体では、製品サポート提供対象としては微妙な立場なためです。
わたしたち ILM チームは、PCNS 単体では担当ではありません。(インストール時の EULA - 製品の約款を見ると、サポートの項にすごく微妙なことが書いてあります。お問い合わせをされる際はまずこちらをご参照ください)
ただし、たとえば「ILM と PCNS を使った場合、メモリリークっぽいのが起きる (※)」とか、「Biztalk と PCNS を連携させたら Biztalk の動きがおかしい (※)」とか、連携対象のプロダクトとからめてお問い合わせをすることは出来る場合があります。(※ これらの問題はあくまでも仮想的な例であり、実際にそうした問題があるということを意味するものではありません。)
お困りの方はお問い合わせの際に、サポート提供可能であるかご相談ください。
私たちのチームでお受けするとすれば、「ILM との連携に PCNS を使う」という場合です。PCNS の構成などについての判断は、お問い合わせにて承らせていただきます。ご不明の点などありましたらいつでもプロフェッショナル サポートなどのサービスをご利用いただければ幸いです。
【今日のお題】
PCNS と ILM の MIIS 機能を使用する際の利用ポート番号、種類、方向について
1. AD 管理エージョント (ADMA) が使用するポート
2. PCNS が ILM もしくは 他の AD にアクセスするときに使用するポート
これは、ずばり、以下のドキュメントに記載がありますが、英語です…。
Microsoft Identity Integration Server 2003 Technical Reference
ここからダウンロードできる、"MIIS_Ports_Rights_and_Permissions.doc" に記載があります。
1. ADMA が使用するポートとは？ (ILM → DC の場合 )
以下のポートが必要となります。
53 : TCP/UDP : DNS
88 : TCP/UDP : Kerberos 認証
389 : TCP/UDP : LDAP
464 : UDP : Kerberos Change Password
これに加え、NTLM 認証の場合は以下のポートも必要になります。
135 : TCP : RPC Endpoint Mapper
57500-57520 : TCP : Dynamic RPC ports (方向は双方向になります)
2. PCNS が ILM もしくは他の AD にアクセスするときに使用するポートとは？
DC 上の PCNS による通信の場合、動的に割り当てられたポートが使用されます。
PCNS 自体は、他の Active Directory に接続しませんが、ILM 上には動的なポート番号で RPC エンドポイントが作成されます。
PCNS は ILM に対して、この動的に割り当てられたポートを使用するためです。
加えて、DC 上に構築された PCNS から ILM に接続する場合は、AD で使用するためすべてのポートに加え、以下のポートが必要となります。
5000-5100 :TCP : Dynamic RPC ports (PCNS)
なお、構成の際は、これらのポートの開放に加え、ILM が存在するドメインと対象の AD には、双方向のフォレスト間信頼が必要となります。
ちなみに、試してみると、信頼関係が無くても ILM の機能 (MA の作成、Sync、Import / Export…) は動作するかと思います。
それでは、信頼関係が必要な場面は何か。
それは、ILM でパスワード同期機能をフォレストを超えて使用する場合です。
ILM とソースとなるドメインが同じフォレストであれば、特に信頼関係を結ぶ必要は無いです。
なぜフォレスト間双方向の信頼が必要なのか？
信頼関係が必要なのは、あくまでもパスワード同期機能をフォレストの境界を越えて使用する場合のみです。パスワード同期機能以外の ILM の機能のみを使用する場合も特に双方向の信頼は必要ありません。
ILM と PCNS が別フォレストの場合、なぜ双方向の信頼が必要なのか
ILM と PCNS が同一フォレストでなく、異なるフォレストにそれぞれいる場合に Kerberos 相互認証を行う際に、双方向のフォレストの信頼関係が必要になるのです。
PCNS は、各 DC 上で動作し、パスワードが変更されると、その内容を ILM に通知します。この通知の際に「正当な」パスワード変更要求として処理させる場合に以下の条件が生じます。
1. ILM にとって、パスワード変更内容を通知するサーバ (PCNS) が正当なものであること
2. PCNS にとって、パスワード変更内容を受信するサーバ (ILM) が正当なものであること
この二つの条件を満たすために、ILM <=> PCNS 間で Kerberos 相互認証が使用されます。
Kerberos 相互認証 … 端的にいえば通信を行う際、お互いのサービスの身元を確認する機能
この相互認証により、パスワード変更通知がターゲット以外のサーバに行ってしまったり、PCNS になりすましたサーバによる不正なパスワード変更を抑止することが出来ます。
一方、PCNS を使わない場合に ILM と連携先 AD がそれぞれ別フォレストにいる場合も動作する理由は何かということになりますが、これは ILM の管理エージェント (MA) は、作成時に対象のフォレストにログオンするために対象フォレストに存在し、適切な権限を持つアカウントの資格情報を使用しますが、この資格情報をつかって連携を行うためです。
よって、信頼関係が無くても、対象のフォレストに対してログオンすることができるため、双方向の信頼関係が無い場合でも動作することが出来るのです。
こんなわけで、ちょっと PCNS って特殊ですね。
今後も、単体でのサポート対象としては難しい PCNS について可能な限り取り上げていきたいとおもいます。
～ ういこう～