ID同期を行う – 発信同期規則編(2)

あるところではお話ししたことですが、私には脱臼癖があり、天気が悪くなると肩が痛くなってきます。
今日も天気は下り坂。
なんか肩が痛むなあ。
これって、もしかして○十肩??

お待たせしました。今回は、いよいよ発信同期規則に関する設定をステップバイステップで見ていくことにします。 
おさらいですが、前回、発信同期を行うときは、次のステップに関してどのような値を設定するかを決めてくださいと
話をしましたね。

1.要求元
2.操作
3.ターゲットの初期状態
4.ターゲットの終了状態
5.権限
6.認証プロセス
7.承認プロセス
8.アクションプロセス
 
 
そして、1.から8.までの項目のうち、
 
■8.の部分は発信同期規則(OSR)で定義
■6.~8.の部分はワークフローで定義
■1.~8.の部分は管理ポリシーで定義
 
ということでしたね。ですので、今回はOSR、ワークフロー、管理ポリシー、の3つの設定方法について解説します。
さらに、管理ポリシーでは、要求元が誰か?ターゲットは誰か?などの情報をセットと呼ばれる情報で指定するので、
セットの設定方法も解説します。
今回は、MSILMデータベースに作成したユーザーをActive Directoryへレプリケート(同期)するという前提での
設定方法を見てみたいと思います。
 
■OSRの設定
ILMポータルサイト(http://xxxx/identitymanagement/)から「同期規則」をクリックします。
 
 
同期規則の一覧から、「新規」をクリックします。
 
全般的な情報タブでは、OSRの名前とフロータイプを指定します。
フロータイプは同期規則の種類を指定しますので、今回のケースでは「発信」になります。
 
 
 
スコープタブでは、メタバースのどのオブジェクトを、どの管理エージェントの、
どのオブジェクトとして同期させるか?を指定します。
今回のケースでは、
メタバースオブジェクト型:person
接続されたシステム:ADDSMA (=Active Directoryの管理エージェントを指定します)
接続されたオブジェクト型:user
 
 
リレーションシップタブでは、キーを指定します。
キーはメタバース側のキーと、コネクタスペース側のキーをそれぞれ指定します。
一意となる属性なら、何でもよいのですが、ここでは mailNickname属性→sAMAccountName属性をキーに設定します。
 
 
Outbound属性フロータブまで進み、メタバースに保存された属性とコネクタスペースに保存される属性の関連づけを設定します。
私のデモ環境では、下の図のような関連づけを設定しました。
 
 
ポイントは、unicodePwd属性(パスワードの属性)に初期パスワードとしてP@ssw0rdという文字列をいれていること、
userAccountControl属性には最初から有効なアカウントして使えるように512という数値を入れていることです。
userAccountControl属性は512だと有効なアカウント、514だと無効なアカウントという位置づけになります。
 
また、個々の関連づけは「新しい属性フロー」をクリックして、設定しますが、
DNのように文字列とメタバースの属性が組み合わさるような場合は、
「値の連結」をクリックすれば、文字列(String)と属性(このケースではmailNickname)を組み合わせた値を
コネクタスペースの属性として関連づけることができます。
 
 
ここまででOSRの設定は完了です。
 
 
■ワークフローの設定
続いて、ワークフローでは、認証、承認、アクションの処理を指定します。
ここでは、単純にOSRを実行するというアクションを実行します。
 
ILMポータルサイト(http://xxxx/identitymanagement/)から「ワークフロー」をクリックします。
 
 
ワークフローの一覧から「新規」をクリックします。
 
基本情報タブでは、ワークフローの名前と種類を指定します。
OSRを実行するように指定する場合、ワークフローの種類は「アクション」になります。
 
 
アクティビティタブでは、「同期規則アクティビティ」を選択します。
 
 
実行するOSRを選択する画面に変わりますので、「追加」が選択されている状態で、「保存」をクリックします。
 
 
すると、アクティビティタブの画面上に、OSRを実行するアクションが入ったことがわかります。
この画面、よく見ると、ワークフロー図になっていることがわかりますね。
ですので、単純なOSRを実行するアクションだけでなく、
OSRの実行後に作業完了のメールを送る(通知アクティビティを利用)、などのような複雑な処理もワークフローで
処理手順を指定しておくだけでできるのです。
 
 
ここまでで、ワークフローができあがりました。
なお、ひとつのワークフローでは、ひとつのワークフロー種類(認証、承認、アクション)しか選べません。
ですので、「管理者の承認がおりたら、OSRを実行する」のようなシナリオは、ひとつのワークフローの中で
まとめて指定することはできず、管理ポリシーで個々の処理を指定しなければなりません。
 
 
長くなってしまいましたね。
続き(セットと管理ポリシーの設定)は次の記事に書きます。
スポンサーリンク
  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存

コメントをどうぞ

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*