Webinar:What's new in ILM"2", Ask the exprts

昨日の夜中（1/29 2:00am-3:00am JST）にensynchのWebinarがあったので、参加しました。















Agendaは以下の通り。
■Identity Lifecycle Manager "2" general overview
・ILM Roadmap
・Managing Lifecylcle of Identities
・ILM 2 Features
・ILM Synchronization Service
・ILM Service Database
・ILM Web Service
・ILM 2 Portal "End User"
・Overview of what's new, features available -
　・Workflows
　・Management Policies
　・Codeless Provisioning
・Synch Rule
・Attribute Flow
・Easy Attribute Flow
・Functions
　・Group and Set Management
　・User Manaement
■Specific ILM " Scenarios and "Gotcha's"
・End User experience for Password Reset Registration
・Behind the Scenes - Policies and Workflows involved
・End user Password Reset Experience
・Behind the Scenes - Policies and Workflows involved
・What can you configure
　・Lockout
　・QA Gate
・Guidelines for Password Reset
・"Gotcha's" with Password Reset
■Question and Answer

彼ら（アリゾナ）の10:00am-11:00amという時間帯が設定されたおかげで日本では夜中・・・
眠い中でのLiveMeetingというあんまり良い環境ではなかったので、ざっくりしか聞けませんでしたが、まぁ一発目ということなのか本当に触りレベルの話ばっかりでした。
（しかも最初の15分は主催者側のオーディオの調子が悪かったみたいで、Toll Freeの電話番号が案内されて、スライドはWeb、音声は電話で。。みたいな話になってました。日本からもToll Free?なんて聞くのも馬鹿らしかったので、ノイジーなLiveMeeting環境でそのまま我慢しましたが）

製品概要の話は置いておいて、面白かったポイントを２，３あげると、
・参加者数
・パスワードリセット時にどんな質問（秘密の答え）が良いか？のアンケート結果
・参加者からの質問の内容からうかがえる参加者のプロファイル
です。USのILM事情を垣間見た気がしました。

まず、参加者数ですがMaxで50名くらいでした。Webinarという媒体とensynchという会社のプレゼンスとILM"2"への現段階での興味度合の複合された結果の数値だとは思いますが、USの事情がわからないだけに多いのか少ないのか微妙な感じでした。

次に、パスワードリセット時にどんな質問（秘密の答え）が良いか？のアンケート結果です。
LiveMeetingでは参加者にその場でアンケートを取ることが出来るので、こんなアンケートが出ました。
















選択肢が面白くて、こんな感じでした。カッコ内は回答。
・First kiss?(17%)
・What is your name?(3%)
・What is your quest?(10%)
・What is your favorite color?(28%)
・Airspeed of unladen swallow?(39%)

日本ではこの中だと「好きな色は？」が一番しっくりくるんだろうな～と思ったのですが、最後の「荷物を持たないツバメの飛行速度は？」というアーサー王ネタがトップになるあたりがお国柄？
日本だと「山？→川」見たいなものなんだと思います。「秘密の質問」っていう主旨忘れてます。完全に。

最後に、参加者からの質問の内容からうかがえる参加者のプロファイルです。
出た質問として、
・ライセンス関係の話
　→参加していたMSの方が回答していました。
　　あんまり聞き取れませんでしたが、未決だがCALモデルになりそう？みたいな感じでした。
・ILM2007からの移行の可否
　→既存のRulesExtensionはある程度そのまま持ってこれるだろうが、新しい実装（ISRやOSR）での再実装を奨めていました。
がありました。
ということで、想像ですが既存でILM2007をすでに持っているユーザさんもしくは管理者／開発者の方たちなんだろうな～と思いました。

また来週も同じ時間に今度はビジネス面からみたILM"2"というテーマでROIの話などを取り上げるそうなので、気力が持てば参加してみます。

識別、認証、認可におけるIdMの役割

たまにはプロダクトの話ではなく、IdMそのものについて書いてみようと思います。

さて、この手のシステムをやっているとお客様を含めついつい混同されがちなのが、識別と認証と認可というキーワードだと思います。そのような混同があるのでIdMツールを入れればシングルサインオンまで含め全部何とかなる、といった勘違いが起きるのだと思います。

そこで、今回は識別、認証、認可といったキーワードの定義とIdMはそれらのキーワードに対して何をしてくれるものなのか？について整理をしてみようと思います。

まずはそれぞれの言葉の定義を見てみましょう。

識別：物事の相違を見分けること
認証：何らかの知識を元に対象の正当性を確認すること
認可：認めて許すこと

たとえば、グリム童話の「7匹の子ヤギ」に当てはめてみましょう。（コンセプトはサルでもわかるIdMの役割！です）

■識別
オオカミ：お母さんだよ。扉を開けておくれ。
　→識別情報「お母さん」を与えている
子ヤギ　：（ああお母さんか）
　→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別①

■認証（失敗の例Ⅰ）
子ヤギ　：（本当にお母さんかな？声がおかしいぞ）
　→名乗った名前（お母さん）と声（オオカミの声）という属性を使って正当性を確認
子ヤギ　：お母さんはそんな声じゃない。おまえはお母さんじゃない！
　→認証失敗②

■認証（失敗の例Ⅱ）
オオカミ：（チョークを食べて声を変えて再び）お母さんだよ。扉を開けておくれ。
　→識別情報「お母さん」を与えている
子ヤギ　：（ああお母さんか）
　→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
　→ここまでは先ほどと同じ
子ヤギ　：（本当にお母さんかな？声はお母さんの声に似ているな。ん？扉から見える手が黒いぞ。おかしいぞ）
　→名乗った名前（お母さん）と手の色（オオカミの手）という属性を使って正当性を確認
子ヤギ　：お母さんの手はそんな色じゃない。おまえはお母さんじゃない！
　→認証失敗③

■認証（成功の例）
オオカミ：（手に白い粉を塗って）お母さんだよ。扉を開けておくれ。
　→識別情報「お母さん」を与えている
子ヤギ　：（ああお母さんか）
　→ドアの向こうの相手が「お母さん」という知っている対象を名乗っていると識別
子ヤギ　：（本当にお母さんかな？声はお母さんの声に似ているな。扉から見える手もお母さんの手に似ているな）
　→名乗った名前（お母さん）と手の色（白く塗ったオオカミの手）という属性を使って正当性を確認
子ヤギ　：（確かにお母さんだ）
　→認証成功④

■認可
子ヤギ　：（お母さんは家族だから扉を開けても良いな）お帰りなさい。（扉を開ける）
　→認可⑤


整理すると、
①で対象が与えた情報を元に子ヤギは対象を識別します。
ここで最初から「田中です」と言っても「誰やねん」という話になり子ヤギからは識別されませんので次のフェーズ（認証）へは物事は進みません。

次に②で子ヤギは対象が与えた情報（声）を元に本当に対象があらかじめ与えた識別情報と合致しているかどうかの正当性の検証を行います。
ここでは「声」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。

同様に③では、「声」に加えて対象が与えた情報（手の色）を元に正当性の検証を行います。
ここでも「手の色」が子ヤギの知っている「お母さん」のものとは異なるので認証失敗です。
ちなみに何故チョークを食べると声が優しくなるのかは不明です。。

続いて、④では対象が与えた「声」と「手の色」の両方が子ヤギの知っている「お母さん」のものと同じであることから子ヤギは対象の正当性を認めます。つまりやっと認証成功です。
いわゆる2要素認証ですね。

最後に、対象が正当に「お母さん」であることが確認されたので、「お母さん」の持つ属性（家族）を見てあらかじめ定義された行為（家に入ること）を許可します。
これが新聞屋だったら例え正当性が確認できても家に入れる、ということはしなかったでしょう。（つまり家族ではないので家に入ることは許可されない）


ちょっと回りくどかったと思いますが、上記が識別、認証、認可の定義です。
さて、やっとIdMの話です。

IdM（狭義のIdM=provisioning/synchronizationを中心としたもの）の役割は、
・管理対象レポジトリのエントリの追加／削除
・管理対象エントリ属性の変更
であると言うことができます。
ここにワークフローやセルフサービスが入ってきたとしてもそれはあくまでプロビジョニングの条件設定や属性変更の一手段にすぎません。

上記の童話に当てはめてみると、
・管理対象レポジトリ　　→　子ヤギの脳
・エントリ　　　　　　　→　知識（お母さんは知っている。田中さんは知らない）
・管理対象エントリ属性　→　お母さんの声は優しい。お母さんの手は白い。お母さんは家族だ。
となります。（なんかグロいですね・・・）

IdMは子ヤギが識別したり認証したり認可をしたりするために必要な情報の提供をしているだけで、実際に識別や認証や認可をしているのは子ヤギそのものなんです。
ですから、IdMシステムの定義をする際は、対象システムがどんな情報をベースに識別し認証し認可するのか、という情報の洗い出しを厳密に行うことが非常に大切です。

この例をベースに考えると、子ヤギ（システム）は、
・名前（お母さん）を識別機能に使う
・声と手の色を認証機能に使う
・続柄（家族）を認可機能に使う
という洗い出しをあらかじめしておいて、IdMシステムに対しては
・名前
・声
・手の色
・続柄
という4つの属性を子ヤギの脳（対象レポジトリ）の中で正しい状態に保つ、ということが求められる機能だ、という定義を行います。


実際は認証連携やシングルサインオンなど、他のシステムが認めたオブジェクトに対して認可を行ったりすることもあり機能の分割がややこしいのですが、よ～く考えると上記の機能分解ができるはずなので、じっくり考えてIdMで管理が必要な属性と同期先となるレポジトリの定義を整理して行きましょう。

ILM"2"の悩みどころ？（MPR、OSR）

先日の土曜日のTech Fieldersセミナーは土曜日にも関わらず結構な動員だったみたいですね。（私は別件があり、顔を出したら既にセッションはすべて終了、懇親会真っ最中でした。ビールを飲みに行ったようなものです(*´Д｀)

ということで私は内容を一切聞いていないので聴講された方がどのような理解をされたのかわかりませんが、個人的に初めてILM"2"に触られる方（特にMIIS/ILM2007経験者）が最も理解しにくい概念がMPR（Management Policy Rules）とOSR（Outbound Synchronization Rules）だと思います。

MIISやILM2007のように単純にMetaVerseにあるエントリをConnector Space上にプロビジョニングコードでストレートに吐き出してあげれば、後はExportすれば実際の同期対象システムにIDができるという考え方は、とてもわかりやすいのですが実際のユーザ環境ではそのまま使うには機能が足りません。（入力データの取り込みについてはとりあえず何でも取り込んでしまってもIdMの中の話なので、キー属性さえちゃんとしていればそれほど問題になりません）

ここで、同期対象のシステムへプロビジョニングを行う際に考えられる最低限の要件を考えてみると、
・誰（何）を
・どのような条件で
・どこに
・どのように
同期／プロビジョニングするのか？というのが最低限ルールとして定義されている必要があると言えると思います。

ILM"2"ではこの要件をある程度コーディングせずに実装するための仕組みとして、
・MPR（Management Policy Rules）
・SET
・WorkFlow
・OSR（Outbound Synchronization Rules）
という概念を実装してきました。
上記の、誰を、どのような条件で、どこに、どのようにという要件をこれらの概念に当てはめると、下の表と様になります。このセット自体のことをMPRと呼びます。

要件	関連する概念	解説
誰（何）を	SET	ILM"2"内で定義するオブジェクトのグループ（セット）。スタティックにメンバを決めることもできますし、オブジェクトの属性をベースに動的にメンバを決めることもできます。 例）EmployeeType属性がContractorのユーザオブジェクトのセット
どのような条件で＋どこに	WorkFlow	承認が必要な場合などを含め条件をWorkFlowで定義します。 特にOSRと紐付をするタイプのWorkFlowをActionWorkFlow（AW）といいます。 承認後、結果によって振る舞いを変える場合はAuthorization WorkflowとActionWorkflowを組み合わせることにより実現します。
どのように	OSR	ISRと同様にAttributeFlowなどを設定し属性のマッピング等を行います。

ILM"2"では、ILMSDB上のエントリに対してこのMPRを適用し、各オブジェクトに対して適用されるOSRが決定されます。（これが各オブジェクトのExpected Rules List（ERL）属性となります）
その後、ILMSDB MAのConnector Spaceへのimport/synchronizationを行うと属性に入っているERLを見て関連するOSRが実行され、実際のプロビジョニング／同期が実行されます。（ERLにはOSRオブジェクトへの参照が入ります）
最近の他社の製品には普通に実装されている機能なのですが、MIIS/ILM2007ユーザにはちょっとわかりにくいかと思うので、MIIS/ILM2007との機能対比を最後に書いておきます。

要件	MIIS/ILM2007	ILM"2"
だれを同期するか	MetaVerseのRules ExtensionのProvision関数内に条件分（IF、SWITCHなど）で実装	SETを利用
同期条件は何か		WorkFlowを利用
どこに同期するか		Action WorkflowにOSRを設定
どのように同期するか	同期対象MAの設定（Rules Extension含む）	OSRを利用

ちなみに、ILM"2"でもMAやMetaVerseのRules Extensionは従来通り利用可能なので、合わせて実装することも可能です。（切り分けが難しくなりそうなので、お勧めはしませんが）

ILM"2"組み込み関数一覧

コードレスプロビジョニングで使える関数の説明がまとめられているブログがあったので紹介します。

ILM Best Practives
http://www.ilmbestpractices.com/blog/2009/01/ilm-2-functions-explained.html

簡単に転記＆和訳しておきます。

関数名	引数	解説
BitAnd	1) マスク 型：Integer 2) フラグ 型：Integer	BitAndはマスクとフラグの論理積を行います。ActiveDirectoryのuserAccountControl属性あたりで活用できます。
BitOr	1) マスク 型：Integer 2) フラグ 型：Integer	BitAndはマスクとフラグの論理和を行います。※現状（RC0時点）では動作しないようです。
CRLF	なし	改行コード（CRLF）を返します。
DateTimeFormat	1)dateTimeString 型：String 2)フォーマット 型：:String	引数で与えた日付・時間の文字列をフォーマットに合わせて成型した文字列を返します。
ConvertSidToString	1) ObjectSID 型：Binary	Utils.ConvertSidToStringと同じ機能です。BYTE文字列形式のObjectSIDを文字列として出力します。
EscapeDNComponent	1) dnStr 型：String	ConnectedMA.EscapeDNComponentと同じ機能です。DNとして許可されていない文字をエスケープします。
IIF	1)式 型：Boolean 2)真の時の値 型：Object 3)偽の時の値 型：Object	式の結果が真であれば、真の時の値が、偽であれば偽の時の値を返します。
Left	1) 文字列 型：String 2) 文字数 型：Integer	文字列の左から文字数分の文字列を切り出して、返します。
LowerCase	1) 文字列 型：String	入力文字列を小文字に変換します。
LeftPad	1) 文字列 型：String 2) 文字列長 型：Integer 3)埋め文字 型：String	結果文字列の長さが第2パラメータで渡した文字列長になるように入力文字列の左側に埋め文字を付加します。
Mid	1)文字列 型：String 2)開始位置 型：String（Integerの間違い？） 3)文字列長 型：Integer	入力文字列を開始位置から文字列長分切り出した文字列へ整形します。
LTrim	1) 文字列 型：String	入力文字列の左側のスペースを除去します。
ProperCase	1) 文字列 型：String	各単語の最初の文字を大文字に、それ以外を小文字に変換します。
RandomNum	1)下限数 型：Integer 2)上限数 型：:Integer	下限数から上限数の間で乱数を返します。
Right	1) 文字列 型：String 2) 文字数 型：Integer	文字列の右から文字数分の文字列を切り出して、返します。
Trim	1) 文字列 型：String	入力文字列の左右のスペースを除去します。
RTrim	1) 文字列 型：String	入力文字列の右側のスペースを除去します。
RightPad	1) 文字列 型：String 2) 文字列長 型：Integer 3)埋め文字 型：String	結果文字列の長さが第2パラメータで渡した文字列長になるように入力文字列の右側に埋め文字を付加します。
UpperCase	1) 文字列 型：String	入力文字列を大文字に変換します。
Word	1) 文字列 型：:String 2)インデックス 型：:Integer 3)区切り文字 型：String	入力文字列を区切り文字で区切った結果の配列のインデックス個目の文字列を返します。

余談ですが、ブログ筆者の方（David Lundellさん。ILM MVP）はEnsynchというITコンサル屋さんに所属しています。
http://www.ensynch.com/pa_secure_ID_management.aspx
この会社、他にもBrad Turnerさん（http://www.identitychaos.com/）などILMのMVPの人が複数所属しているらしいです（どんな会社だ？）

Brad Turnerさんですがこの人はこの人で、「ILM_2_RC0_Workflow_Activity_Walkthrough」というILM"2"のカスタムワークフローの開発ガイドのようなドキュメントを書いていたりしますので、今後ILMにかかわる人は要チェックかと。

今週末、MSエバンジェリスト安納さんのセミナもありますし、やっと国内でもILMの立ち上げに本気になったんでしょうか？
http://blogs.technet.com/junichia/archive/2008/12/08/3164978.aspx

SAP NetWeaver Identity Management事始め（アーキテクチャ整理）

仕事で触ることになりそうなので、SAPに買収された後のバージョンに初めて触れてみます。
最新バージョンは7.1なのですが、現状一般にリリースされた状態ではないのでとりあえず入手可能なバージョンということで7.0sp2をベースに考えてみます。
※7.1からフロントエンドがこれまでIIS+PHPで動いていたのが、NetWeaver AS上で動作する様になり、見た目もより”SAP”になったそうなので、7.1が入手できればそちらでも検証が必要になりそうです。

さて、現行の7.0というバージョンに関しては旧MaXware Identity Center（MIC）と殆ど変わらない、と考えておいて問題ないと思います。

まず、基本アーキテクチャですが、Identity Centerは以下のコンポーネントで構成されます。
・Identity Center database
　この製品の特徴が中央に統合されたアイデンティティストアを持つことです。このあたりがSunのVirutal Identityとは異なる点です。（IDストアを持つべきか、持たざるべきかについては色々と議論を呼ぶところかと思いますが、私個人としてはデータの加工の容易さなどの点でIDストアを持った方が楽だと思っています。実装屋の意見ですね・・・）
　話がそれましたが、SAP IdMではこのデータベースにプロビジョニングやワークフローのタスクやジョブそのもの、スケジュール情報、タスクの状態や差分情報、監査ログなども格納されます。
　ちなみにdatabaseエンジンとしてはSQL ServerもしくはOralceが使用されます。
・Runtime components
　メインはdispatcherとevent agentです。
　・runtime engine
　　実際の同期やプロビジョニングを行う単位をSAP IdMではジョブと呼びますが、このジョブを実行するのがruntime engineです。旧MaXware時代はこのruntime engine部分が別製品のData Synchronization Engine（通称DSE）として販売されており、単純な同期・プロビジョニングの要件だけならこちらで十分対応できました。
　・dispatcher
　　様々なイベントに応じて適切なジョブをruntime engineで実行するのがdispatcherです。
　・event agent
　　上記のdispatcherは基本的にバッチの仕組みなので、リアルタイム性に欠けます。そこで登場するのがこのevent agentです。
　　データベーストリガーやLDAPのchange logを使って変更を検知し、ある程度リアルタイムに属性同期やプロビジョニングを行います。
　　また、ジョブ実行のスケジューリングも行います。
・Workflow UI
　利用者向けのWebインターフェイスです。
　ユーザ登録、セルフサービス、パスワードリセット、承認タスクなどが実施できます。
・Monitoring UI
　管理者向けのWebインターフェイスです。
　システム状態のモニタリングや監査ログの取得などが実施できます。
・Management console
　Identity Centerの構成を行うためのMMCインターフェイスです。
　この画面で同期やプロビジョニング、ワークフローなどのタスクやジョブを構成します。















ちなみに最後のManagement Console以外はUNIXプラットフォーム上でも動作します。（Java版）

ActiveDirectoryへのパスワード変更をフックする

IdM案件をやっていると、どうしても出てくるのがパスワード同期のお話。
基本的にIdM側のパスワード変更画面を使ってもらうのがベターなのですが（システム構造的にも、機能面でも）、中にはやっぱりCTRL+ALT+DELでのパスワード変更がやめられない！というユーザさんもいらっしゃるのかと。

恐らくそのような要件を満たすためにパッケージベンダ各社はいろいろな努力をしていると思います。
例えば、
・Microsoft(Identity Lifecycle Manager 2007)
・SunMicrosystems(Sun Java System Identity Manager)：
・SAP(NetWeaver Identity Management)
・エクスジェン・ネットワークス(LDAP Manager)
などではActiveDirectoryへのパスワード変更をIdM側へ取り込む機能を実装してきています。
※ILM"2"でのクライアント側へのモジュールインストールは反則かと・・・

今回はそのあたりの仕掛け（どうなっているのか？）をひも解いてみようと思います。
まず、Windowsのパスワード変更の仕組みを整理します。

ユーザからのパスワード変更要求があると、
１．Local Security Authority(LSA)が要求を受け付ける
２．レジストリに登録されているパスワードフィルタDLLでパスワード検査を行う
３．検査をパスしたらSecurity Account Manager(SAM)にパスワードを保管する
４．正常に保管できたらレジストリに登録されているパスワードフィルタDLLに変更通知を行う
という流れでパスワードが変更されます。













それぞれのプロセスを細かく見ていくと、以下のような流れになっています。

１．Local Security Authority(LSA)が要求を受け付ける
　　lsass.exeというサービスプロセスが要求を受け付けます。

２．レジストリに登録されているパスワードフィルタDLLでパスワード検査を行う
　　以下のレジストリに登録されているDLLに実装されているPasswordFilter()が順番に呼び出され、パスワードポリシーのチェックなどのフィルタリング処理が行われます。

　　[レジストリエントリ]
　　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages











　　この関数がFALSEを返すとその時点でパスワードポリシー違反としてユーザへ通知されます。







３．検査をパスしたらSecurity Account Manager(SAM)にパスワードを保管する
　　これは文字通りアカウントDBへのデータ更新です。

４．正常に保管できたらレジストリに登録されているパスワードフィルタDLLに変更通知を行う
　　これも２と同じく各DLLのPasswordChangeNotify()が呼び出されます。


最後のPasswordChangeNotify()の引数に対象ユーザのユーザ名とクリアテキストのパスワードがわたってくるのを利用して、あたかもActiveDirectoryのパスワードを吸い出しているような動きに見せている、というのが各IdM製品の実際の仕掛けです。（たぶん）
また、この動きを見るとわかりますが、あくまでlsass.exeがローカルのDLLに実装された関数を使うので、パスワード変更要求を受け付けるコンピュータ上にフィルタを配置する必要があります。
つまり、ローカルユーザのパスワードをフックする場合はローカルコンピュータ上に、ActiveDirectoryユーザの場合はすべてのドメインコントローラ上に配置する必要があります。

※ちなみに２のPasswordFilter()の引数にもユーザ名とパスワードはわたってきますが、実際にパスワードが更新される前ですし、他のライブラリを使ったパスワードポリシーチェックが完了していないのでこの段階で吸い出してもあまり意味がありません。


ということで、実際の動きをみるためにもDLLを実装してみました。（久しぶりにベタベタなアンマネージコードを書いたので恥ずかしいのですが・・・）

開発環境は、
・OS/AD：Windows Server 2003 R2
・開発ツール：Visual Studio 2005/VC++
です。

ビルドし、出来たDLLをC:\Windows\system32(%systemroot%\system32)以下にコピーし、上記のレジストリに出来上がったDLLの拡張子を除いたファイル名を登録してシステムを再起動すると配置完了です。
上手くいけばパスワードを変更するとCドライブ直下に「PasswordChangeLog.txt」というファイルが出来上がります。
中身は、
　sAMAccountName=変更したユーザ名,unicodePwd=新しいパスワード
という形で、パスワード変更がどんどん記録されていきます。
※悪用厳禁ですね。。。

以下、実際のコードです。

■PasswordHook.cpp

#include
#include
#include

#define LOGFILE "C:\\PasswordChangeLog.txt"

#ifndef STATUS_SUCCESS
#define STATUS_SUCCESS ((NTSTATUS)0x00000000L)
#endif

//
// ログ出力
//
void WriteToLog(const char* str)
{
　if (NULL == str)
　{
　　return;
　}
　FILE* log;
　log = fopen(LOGFILE, "a+");
　if (NULL == log)
　{
　　return;
　}
　fprintf(log, "%s\r\n", str);
　fclose(log);
　return;
}

//
// パスワードの変更・保管に成功した際に呼び出される
//
NTSTATUS NTAPI PasswordChangeNotify(
　　PUNICODE_STRING UserName,
　　ULONG RelativeId,
　　PUNICODE_STRING NewPassword
)
{
　int nLen=0;

　// 文字列変換（ワイド文字列→マルチバイト文字列）
　// UserName
　nLen = wcslen(UserName->Buffer)+1;
　LPSTR username = (LPSTR)malloc(nLen * sizeof(CHAR));
　ZeroMemory(username,nLen);
　wcstombs(username, UserName->Buffer, nLen);

　// NewPassword
　nLen = wcslen(NewPassword->Buffer)+1;
　LPSTR password = (LPSTR)malloc(nLen * sizeof(CHAR));
　ZeroMemory(password,nLen);
　wcstombs(password, NewPassword->Buffer, nLen);

　// 記録用文字列生成
　LPSTR LogEntry = (LPSTR)malloc(strlen(username)+strlen(password)+28);
　ZeroMemory(LogEntry,sizeof(LogEntry));
　sprintf(LogEntry,"sAMAccountName=%s,unicodePwd=%s",username,password);
　WriteToLog(LogEntry);

　return STATUS_SUCCESS;
}

//
// パスワード変更要求があった際に呼び出される
// パスワードポリシー等のフィルタがある場合はここに記載する
//
BOOL NTAPI PasswordFilter(
　　PUNICODE_STRING AccountName,
　　PUNICODE_STRING FullName,
　　PUNICODE_STRING Password,
　　BOOLEAN SetOperation
)
{
　return TRUE;
}

//
// DLLロード時に呼び出される（lsass.exeより呼び出される）
//
BOOL NTAPI InitializeChangeNotify(void)
{
　return TRUE;
}


■PasswordHook.def

LIBRARY "PasswordHook"

EXPORTS
　InitializeChangeNotify
　PasswordChangeNotify
　PasswordFilter

ILM"2" RC0環境構築「同期ルール設定編その３～OSR」（12/28 追記）

さて、前回はCSVファイルからILM"2"へのユーザの取り込み設定を行いましたが、今回はCSVから取り込んだユーザをActive Directoryへ同期してみます。また、同時にILM"2"ポータル上でユーザ情報を編集した場合もCSVファイル上のユーザ情報と合わせてActive Directoryへ同期できるようにします。

１．Identity Lifecycle Manager用MAの設定
　前回のISR設定時に定義したILMSDB MAに逆方向（ILM"2" ポータル上で作成したユーザもMetaverseに取り込みたいので）の属性フローを設定します。　ただ、RC0では既存のMAのプロパティを変更して保存しようとするとエラーが出るので、Export Management Agent→手動でXMLファイルの編集→Update Management Agentをするか、MA自体を再作成します。（私の環境の問題かも知れませんが・・・）
12/28 connectサイトにMicrosoft Identity Integration Serverサービスを再起動すれば直るとの情報がありました。試してみると確かに治ります。が、何をトリガーに事象が発生するのかは依然不明です・・・








　変更箇所はAttribute Flow部分です。前回はExportのみを設定しましたが、今回は同じ属性についてImportも設定します。
　Configure Attribute Flow
　　Datasource(ILMSDB) Metaverse
　　AccountName → accountName
　　LastName → sn
　　FirstName → givenName
　　DisplayName → displayName
　　Email → email
　　Department → department
　　JobTitle → title
　　Manager → manager














２．Active Directory Domain Service用MAの作成

　以下の通りMAを作成します。
　　MA名：ADDS MA
　　Connect to Active Directory Forest
　　　Forest name：ilm2.local
　　　User name：Administrator
　　　Password：xxx
　　　Domain：ilm2.local
　　Configure Directory Partitions
　　　Select directory partitions：DC=ilm2,DC=local
　　　Select containers for this partition：OU=ilm2users,DC=ilm2,DC=local
　　Select Object Types
　　　userを追加でチェック
　　Select Attributes
　　　displayName
　　　givenName
　　　mail
　　　manager
　　　sAMAccountName
　　　sn
　　　title
　　　unicodePwd
　　　userAccountControl

　次に以下の実行プロファイルを作成しておきます。
　　Full Import
　　Full Synchronization
　　Export

３．Outbound Synchronization Rule（OSR）の作成

　次はILM"2"ポータルの管理画面よりOSRを作成します。操作方法は前回のISR作成時とほぼ同じです。

　General Information
　　Name：OSR ADDS
　　Flow Type：Outbound
　Scope
　　Metaverse Object Type：person
　　Connected System：ADDS MA
　　Connected Object Type：user
　Relationship
　　Relationship Criteria
　　　MetaverseObject:person(Attribute)：accountName
　　　ConnectedSystemObject:user(Attribute)：sAMAccountName
　　Object Creation in Connected System:True
　Outbound Attribute Flow
　　Metaverse　　　　ADDSコネクタ空間
　　○accountName　→　sAMAccountName
　　○"CN="+accountName+",ou=ilm2users,dc=ilm2,dc=local"　→　dn
　　○512(数値)　→　userAccountControl
　　○"P@ssw0rd"　→　unicodePwd
　　　email　→　mail
　　　sn　→　sn
　　　givenName　→　givenName
　　　manager　→　manager
　　　displayName　→　displayName
　　　department　→　department
　　　title　→　title
　　※○は初期同期のみ











４．同期対象ユーザセットの作成

　同期対象のユーザを絞り込むため、オブジェクトセットを作成します。　ここではシステムユーザ以外は全員対象としたいので、ilm2adminとBuilt-inユーザ以外でセットを作成します。

　Basic Info
　　Name：[SET]NonSystemUsers
　Dynamic Membership
　　対象：people
　　条件：match all
　　　　　Display Name is not ilm2admin
　　　　　Display Name not starts with Built-in
　　　→Display Nameがilm2adminではなく、Built-inで始まらないユーザのみを対象とします。










５．OSR適用フローの作成（Action Flow）

　OSRを実際に実行するためのアクションフローを作成します。
　Basic Information
　　Workflow Name：AW ADDS
　　Workflow Type：Action
　Activities
　　Activity Picker：Synchroniozation Rule Activity
　　Synchronization Rule：OSR ADDS
　　Action Selection：Add











６．管理ポリシールール（Management Policy Rule/MPR）の作成

　４て定義したオブジェクトセットに５で定義したアクションフローが実行できるようにMPRを作成します。

　General Information
　　Display Name：MPR ADDS
　Requesters and Operations
　　Requesters：Specific Set of Requesters：[SET]NonSystemUsers
　　Operation：Create resource、Modify resource attributes
　Target Resources
　　Target Resource Definition Before Request：
　　　Specific Set of Objectes：[SET]NonSystemUsers
　　Target Resource Definition After Request：
　　　Specific Set of Objectes：[SET]NonSystemUsers
　Policy Workflows
　　Action：AW ADDS


７．同期の実行

　実際に定義したルールを動かしてみます。
　まず、Active Directoryのツリー構造を一旦コネクタ空間へ取り込むため、ADDS MAのFull Importを実行します。
　次にILMSDBのFull Importを行い、先ほど作成した同期ルールを含む情報をコネクタ空間へ取り込みます。
　その状態でILMSDBのコネクタ空間とMetaverseの同期を行います。　すると、OSRが実行されるので、ADDS MA(CS)へユーザが追加されます。
　そこまで来たら後はADDS MAでExportすればAD上へユーザが作成されます。

８．AD上のユーザ確認

　ドメインコントローラにログインし、ActiveDirectoryユーザとコンピュータでユーザが作成されていることが確認できます。






















これで基本的に入方向と出方向の両方の同期ができました。
他にもパスワードの同期や承認フローの設定など色々と試すことがあるので、いずれ解説したいと思います。（それよりもMPR、AW、SETの考え方、ERL属性の仕組みを整理した方が全体の理解が進むかもしれませんが。。。このあたりがこの製品をややこしくしている根源な気がします）