第 4 章データ読み込みのシナリオ

この章では、アカウント情報を Identity Manager に読み込むための準備をするときに考慮すべきヒントを紹介します。遭遇する可能性のあるいくつかの問題について解説するためにシナリオ例も示します。

環境を評価する

Identity Manager へのユーザーアカウント情報の読み込みを開始する前に、次の質問の中で自分の環境に該当するものがあるかどうかを判断してください。

すべてのユーザー ID に対して、アイデンティティー情報の源泉として信頼性の高いリソースが存在しますか。

重複しているが相関キーが存在するリソースから、ユーザーの完全なリストを取得できますか。

重複していて相関キーが存在しないリソースからユーザーのリストを取得できますか。

これらすべての質問に対して答えが「いいえ」の場合、アカウントを読み込むプロセスは難しくなります。可能な範囲でユーザーアカウントを読み込み、ほかの Identity Manager ユーザーの作成は部署の管理者またはエンドユーザーに委任することを検討してください。

最初のリソースを選択する

Identity Manager にアカウントを読み込むために使用する最初のリソースは、次の特徴を備えていることが理想的です。

広範囲のユーザーの集合を参照していること。最初の読み込みの目的は、できるかぎり多くのアカウントを Identity Manager に取り込むことです。したがって、次のアプリケーションが選択肢として適しています。

PeopleSoft や SAP などの人事アプリケーション (アプリケーションに契約社員やその他の臨時職員のデータが含まれていない場合は、それらの従業員のアカウントを別途読み込むようにしてください)。

LDAP や Active Directory などのディレクトリベースアプリケーション。多くの場合、大半のユーザーが中央の組織または組織単位に定義されます。

Identity Manager のアカウント ID を構築するための十分な情報を保持していること。個々の Identity Manager アカウント ID は一意である必要があります。一意性が保証されており、Identity Manager のアカウント ID として使用できる属性がリソースに存在していることが理想的です。そのような属性の例としては、従業員 ID や Active Directory の sAMAccountName 属性などがあります。姓と名を組み合わせてアカウント ID を作成することもできますが、この方法では一意の Identity Manager アカウントが作成されることを保証できません。



注	現在、Lighthouse アカウントは Identity Manager アカウントと呼ばれています。カスタムカタログを使用することによって、この名前の変更を上書きできます。カスタムカタログの詳細については、付録 B 「国際化サポートを有効にする」を参照してください。

相関キーとして使用できるユーザー属性を格納していること。Identity Managerでリソースアカウントをリンクするには、複数のリソースにまたがって同じ値を持つ属性が必要です。二次リソースでの値が常に、最初のリソースでの値と完全に一致するのが理想的です。さらに、二次リソースでの値がそのリソース内で一意であればなお理想的です。最も適した属性としては従業員 ID やフルネームがありますが、それら以外でも、すでにあるもので、複数のリソース間で値が一貫していればどのような属性でも使用できます。

アイデンティティー情報の源泉として信頼性が高いとみなせるデータを保持していること。ユーザーが自分自身のアカウントデータを編集できる場合、システム間でデータの一貫性が失われる可能性があります。

次の図は、3 種類のリソースが存在するある会社のシナリオを例示したものです。この会社のほとんどの従業員は、PeopleSoft や SAP などの人事アプリケーションで定義されています。ただし、この会社では契約社員の情報を人事アプリケーションに入力しないため、このアプリケーションを使用して Identity Manager に契約社員のデータを読み込むことはできません。Active Directory でもほとんどのユーザーを定義していますが、すべてを網羅しているわけではありません (コンピュータへのアクセスを必要としない工場従業員などがこれに該当する場合がある)。このように、大部分のユーザーは両方のリソースで定義されていますが、どちらのリソースもすべてのユーザーを網羅しているわけではありません。一部の従業員は UNIX アカウントも持っています。

どのリソースを最初のリソースとして選択すべきでしょうか。UNIX リソースはごく少数のユーザーしか網羅していないため、問題なく検討から外すことができます。Active Directory と人事アプリケーションにはほとんど同数のユーザーが登録されているため、どちらにも明確な利点はありません。

Active Directory と人事アプリケーションのどちらのリソースを最初に読み込むべきかの判断材料となる要素として、次の点が挙げられます。

Identity Manager 内でアカウントを管理する緊急性。人事アプリケーションでのみ定義され Active Directory では定義されていない従業員に、UNIX やその他のシステムのアカウントなど、追加のリソースアカウントが一切付与されていない場合、人事アプリケーションは Active Directory リソースほどには重要でない可能性があります。

相関キー。UNIX アカウントにも存在する複数の属性が一方のリソースに存在する場合、その属性がより適切な選択肢である場合があります。

Identity Manager ログイン名。一方のリソースが、Identity Manager のログイン名としてより適切な名前を生成する場合、これが決定的な要因となる可能性があります。

最初のデータ読み込みプロセスを選択する

ユーザーデータを Identity Manager に読み込むために最初に使用するリソースを選択したあとは、使用するプロセスを決定する必要があります。次の表は、各種のデータ読み込みプロセスの長所と短所をまとめたものです。それぞれのデータ読み込みプロセスについては、次節以降で詳しく検討します。

表 4-1 データ読み込みプロセスの概要
データ読み込みプロセス	長所	短所
ファイルから読み込み	最も高速な読み込みプロセス。どの属性を読み込むかの制御が容易。調整よりも設定が容易で高速。	顧客側にリソースから CSV ファイルを生成する時間が必要。本稼働環境への投入前に完全調整が必要。アカウントの更新には使用できない。
リソースから読み込み	すべてのリソースに対して有効調整よりも設定が容易	読み込むリソースアカウントを自由に選択できない。本稼働環境への投入前に完全調整が必要。
一括処理の作成	1 名の Identity Manager ユーザーに複数のアカウントを同時に追加できます。	リソースからの読み込みや調整と比べて低速。リソースから CSV ファイルを容易に生成できない。この機能を十分に活用するには Identity Manager の詳細な知識が必要。本稼働環境への投入前に完全調整が必要。
調整	調整ポリシーのすべての側面を実装可能事前の調整を使用することで最終段階での不測の事態を回避できる	読み込むリソースアカウントを自由に選択できない。大規模環境 (従業員が 50,000 名を超える) では全アカウントの読み込みに膨大な時間がかかる可能性がある
ActiveSync	アカウント情報を読み込む手段として ActiveSync を選ぶことは可能なかぎり避けてください。ActiveSync は変更を検出するように設計されており、結果として初回の読み込みは低速です。

ファイルから読み込み

「ファイルから読み込み」プロセスは、Identity Manager アカウントにアカウント ID、姓、名、電子メールアドレスなどの基本的な値を割り当てます。アカウント ID は唯一の必須属性です。

「ファイルから読み込み」プロセスでは、CSV (Comma-Separated Value) ファイルの内容を Identity Manager にインポートします。このファイルの先頭行には、属性名のリストをコンマ区切りで記述します。それ以降の行には、対応する一連の属性値を記述します。すべての属性はコンマで区切る必要があります。

CSV ファイル内のデータは多くの場合、リソースからエクスポートされたものです。たとえば、Microsoft 管理コンソール (MMC) の「Active Directory ユーザーとコンピュータ」では、組織単位の内容を CSV ファイルに直接エクスポートすることができます。組織単位に定義されているすべてのユーザーが、表示されている属性とともにエクスポートされます。したがって、「Active Directory ユーザーとコンピュータ」MMC でエクスポートを実行するときは、Identity Manager によって管理される属性だけが表示されていることを確認してください。不必要な属性が含まれていると、読み込みにかかる時間が長くなります。

リソースの中には、ユーザーアカウント情報を CSV 形式に直接エクスポートできないものもあります。そのようなリソースからデータを読み込む場合、別途プログラムを使用して情報を抽出したり、手動でデータを追加したりするなどの手順が必要な場合があります。

たとえば、CSV ファイルの最初の 3 行が次のようになっているとします。


注	「ファイルから読み込み」では XML ファイルからの読み込みも可能ですが、XML ファイルの構文が、「ファイルへ抽出」機能によって生成されるファイルの構文と一致している必要があります。この形式について、ここでは詳しく説明しません。

CSV ファイルに記述されている属性が、ユーザービューの属性としてあらかじめ定義されている必要があります。accountId、email、password、confirmpassword などの基本属性はあらかじめ定義されています。その他の属性は、拡張ユーザー属性設定オブジェクトで定義されます。このオブジェクトはデフォルトで、firstname、lastname、fullname を利用可能な属性のリストに追加します。

Identity Manager の定義済みでない従業員 ID などの属性値を保持したい場合、拡張ユーザー属性設定オブジェクトにそれらの属性を追加する必要があります。

「ファイルから読み込み」プロセスの設定ページでは、相関規則と確認規則の指定を求められます。これが最初のデータ読み込みであるため、「アカウント ID と一致するユーザー名」相関規則を選択します。確認規則は不要です。

重要な点として、CSV ファイルに含まれているデータは Identity Manager アカウントを構成する目的のみに使用されます。たとえば、データが Active Directory から直接エクスポートされた場合でも、そのデータはどの Active Directory アカウントまたは Active Directory リソースにもリンクされません (リンクを行うことを目的としたカスタムユーザーフォームを作成した場合を除く)。カスタムユーザーフォームがない場合、リソースのアカウントデータを Identity Manager のユーザーとリンクするには、別のデータ読み込み機構を使用する必要があります。ユーザーフォームについては「ユーザーフォームを割り当てる」で簡単に説明します。

リソースから読み込み

「リソースから読み込み」プロセスと「ファイルから読み込み」プロセスの設定ページはほとんど同じ内容ですが、「リソースから読み込み」は機能的には調整に似ています。「リソースから読み込み」プロセスと調整プロセスでは、データをリソースから抽出したあとで、見つかったアカウントを Identity Manager に追加します。したがって、これらの処理を実行する前にアダプタを設定する必要があります。

「リソースから読み込み」は調整と比べて初回の実行が高速ですが、アカウントインデックスに値が設定されません。差分モードでの 2 回目の実行時の調整プロセスは、「リソースから読み込み」よりも高速です。調整が長期的なソリューションとして望ましいツールである場合は、ユーザーの初回読み込みに調整を使用してください。


注	「ファイルから読み込み」プロセスでは、Identity Managerアカウントインデックスにエントリが追加されません。したがって、Identity Manager の配備が完了する前に、完全調整またはユーザーの更新を実行する必要があります。また、「ファイルから読み込み」では、Identity Manager でのユーザー作成時にワークフローは一切実行されません。

ユーザーフォームは、アカウント ID の設定、組織へのユーザーの配置、ユーザー作成に関連するその他のタスクの実行に使用できます。詳細については、「ユーザーフォームを割り当てる」を参照してください。

最初に読み込むリソースに対して、「リソースから読み込み」を使用して Identity Manager アカウントに属性値を割り当てるとき、相関規則と確認規則はそれほど重要な意味を持ちません。「アカウント ID と一致するユーザー名」相関規則を選択します。確認規則は不要です。

一括処理の作成

一括処理の作成では、CSV ファイルからデータを読み込みます。一括処理の作成では「ファイルから読み込み」プロセスと異なり、Identity Manager に固有の属性、グローバル属性、リソースアカウント属性などを含む、任意の書き込み可能な属性をユーザービューで定義することができます。この柔軟性の代償として、一括処理用の CSV ファイルの作成は多くの場合、多少手順が複雑になります。複数のリソースを一括処理で処理する場合、リソースデータを単一の CSV ファイルにマージする方法を探す必要があります。ただし、一括処理用の比較的単純なファイルを定義し、あとで更新処理を使用してデータを Identity Manager ユーザーアカウントに読み込むという方法もあります。

一括処理では、作成、更新、削除の各処理に対してデフォルトのワークフローを実行します。これによりユーザーアカウントの読み込み処理の速度は低下しますが、柔軟性が大きく向上します。

次の例では、一括処理の作成のみを使用します。command 属性と user 属性は必須です。

次の例は、2 つの個別のファイルで一括処理の作成と一括更新処理を使用する方法を示しています。


注	「リソースから読み込み」プロセスでは、Identity Manager アカウントインデックスにエントリが追加されません。したがって、Identity Manager の配備が完了する前に、完全調整またはユーザーの更新を実行する必要があります。また、「ファイルから読み込み」では、Identity Manager でのユーザー作成時にワークフローは一切実行されません。

command,user,waveset.resources,password.password,password.confir mPassword,accounts[MyAD].description,

Create,John Doe,MyAD,changeit,changeit,John Doe,John Doe

Create,Jane Smith,MyAD,changeit,changeit,
Jane Smith

command,user,waveset.resources,password.password,password.confir mPassword,accounts[MySolaris].comment

Update,John Doe,MySolaris,changeit,changeit,John Doe

Update,Jane Smith,MySolaris,changeit,changeit,Jane Smith

調整

多くの場合、リソースの初回の調整には 2 回目以降の調整よりも長い時間がかかります。一般的に、リソースの初回の調整では多数のアカウントインデックスエントリが追加されます。


注	一括処理を使用してアカウントを作成しても、Identity Manager のアカウントインデックスにエントリは追加されません。したがって、Identity Manager の配備が完了する前に完全調整を実行する必要があります。

データ読み込みの準備を行う

Identity Manager へのアカウント情報の読み込みプロセスを開始する前に、次の各項の内容を確認してください。

アダプタを設定する

アカウント ID ポリシーとパスワードポリシーを設定する

データ読み込み用のアカウントを作成する

フォームを割り当てる

アダプタを設定する

リソース上のアカウントを管理するには、アカウント情報のソースごとにアダプタを設定する必要があります。「ファイルから読み込み」プロセスまたは一括処理を使用する場合、アダプタの設定は調整の準備ができた時点で行えば問題ありません。それ以外の場合は、Identity Manager にデータを読み込む前にアダプタを設定する必要があります。

アダプタの設定についての全般的な情報は、『Identity Manager 管理ガイド』を参照してください。個別のアダプタに関する詳しい情報は、『Identity Manager リソースリファレンス』またはオンラインヘルプを参照してください。

アカウント ID ポリシーとパスワードポリシーを設定する

「リソースから読み込み」、調整、または Active Sync によってリソースからアカウントデータを読み込むとき、Identity Manager はリソースからパスワードを取得しません。リソースからパスワードが渡された場合は、リソース上のセキュリティーが侵害される可能性があります。したがって、Identity Manager アカウントのパスワードは、リソース上のパスワードと同じにはなりません。デフォルトでは、Identity Manager によってランダムのパスワードが生成され、このパスワードを再設定する必要があります。ただし、ユーザーフォームのパスワードビューを使用して、全ユーザーに共通の、または Identity Manager アカウント ID と同一のリテラル文字列などを一時パスワードとして指定することもできます。詳細については、「ユーザーフォームを割り当てる」と、「Identity Manager のビュー」の章を参照してください。

一括処理および「ファイルから読み込み」では、パスワード値を CSV ファイルで指定できます。これらのパスワードは、ユーザーが変更しなければならない一時パスワードとして考えるべきです。

ポリシーは Identity Manager アカウントに適用される制限を設定し、次のように分類されます。

Identity Manager アカウントポリシー -- ユーザー、パスワード、および認証のポリシーオプションを設定するために使用します。Identity Manager のアカウントポリシーは組織またはユーザーに割り当てられます。

リソースパスワードおよびアカウント ID ポリシー -- 長さ規則、文字タイプ規則、使用可能な単語および属性値を設定または選択するために使用します。

デフォルトポリシーを更新する場合は必ず、Identity Manager へのアカウント情報の読み込みを開始する前に行ってください。

次の表は、Identity Manager に用意されているポリシーとそのデフォルト設定の一覧です。

表 4-2 デフォルトの Identity Manager ポリシー
ポリシー名	デフォルト特性
アカウント ID ポリシー	アカウント ID の長さは 4 文字以上 16 文字以下である必要があります。
デフォルトの Lighthouse アカウントポリシー	アカウント ID ポリシーを「アカウント ID ポリシー」に、パスワードポリシーを「パスワードポリシー」に設定します。パスワードはユーザーではなく Identity Manager によって生成されます。
パスワードポリシー	パスワードの長さは 4 文字以上 16 文字以下である必要があります。パスワードにはユーザーの電子メールアドレス、姓、名、またはフルネームを含めることはできません。
Windows 2000 パスワードポリシー	パスワードの長さは 6 文字以上である必要があります。パスワードには次の文字タイプのうち 3 種類以上が含まれている必要があります。数字 (1) 大文字のアルファベット (1) 小文字のアルファベット (1) 特殊文字 (1) また、パスワードにはアカウント ID を含めることはできません。

アカウントポリシーとパスワードポリシーの詳細については、『Identity Manager 管理ガイド』の「Identity Manager ユーザー」の章を参照してください。

データ読み込み用のアカウントを作成する

次の理由により、データ読み込みを実行するための管理者アカウントを別途作成することをお勧めします。

監査を有効にしたときにデータ読み込み処理の追跡が容易になります。

すべての Identity Manager 管理者に、Identity Manager ユーザーを作成および編集するユーザーフォームが割り当てられます。データ読み込み用のアカウントを作成すると、デフォルトのフォームよりも実行が高速な簡易形式のフォームを指定できます。詳細については、次の項を参照してください。

アカウントの作成の詳細については、『Identity Manager 管理ガイド』を参照してください。

ユーザーフォームを割り当てる

データ読み込みのコンテキストでは、ユーザーフォームはバックグラウンド処理を実行する目的で使用されます。たとえば、フォームとリソースアダプタを一緒に使用して、外部リソースから得た情報を処理し、Identity Manager リポジトリにこれを保存できます。ユーザーフォームは、入力ユーザーデータに基づいて正しい組織にユーザーを配置する目的にも使用できます。

ユーザービューは、Identity Manager ユーザーの利用可能な全情報が含まれるデータ構造です。このビューには、以下の項目が含まれます。

Identity Manager リポジトリに格納される属性

リソースアカウントからフェッチされる属性

リソース、ロール、および組織など、ほかのソースから取得される情報

ビューには多くの属性があり、ビュー属性はビュー内にある名前を付けられた値です (たとえば、waveset.accountId は、Identity Manager アカウント名を値とする、ユーザービュー中の属性)。

ほとんどのフォームフィールドの名前は、ビュー属性と関連付けられています。フォームフィールドの名前として、ビュー属性の名前を指定することで、フィールドとビュー属性を関連付けます。ユーザービューの全属性の参照情報など、ユーザービューの詳細については、「Identity Manager のビュー」の章を参照してください。

ユーザーを読み込むユーザーフォームには、多くの場合次のフィールドが含まれます。

firstname (名)

lastname (姓)

fullname (フルネーム)

email (電子メール)

waveset.accountId

waveset.organization

EmployeeId (従業員 ID)

waveset.accountId および waveset.organization は、Identity Manager に固有の値です。EmployeeId 属性はカスタマイズした属性です。その用途については、「カスタム相関キーを定義する」で例示しています。

Identity Manager には、システムにインストール済みの多数のフォームが用意されています。また、追加のフォームが $WSHOME/sample/forms ディレクトリに収められています。このディレクトリ内のフォームの多くは、リソース固有の内容になっています。Identity Manager IDE を使用してこれらのフォームを確認し、本稼働環境で使用するかどうかを判断することができます。

一括処理中のパフォーマンスを向上させるために、管理者に割り当てられるユーザーフォームはできるだけ簡易なものにしてください。データ読み込み用のフォームを作成する場合、データ表示のために記述されたコードは削除できます。フォーム簡易化の別の例は、一括追加処理を使用する場合です。CSV ファイルでは、firstname や lastname などの基本属性を定義できます。これらの属性は、あとで管理者のユーザーフォームから削除できます。フォームの作成と編集の詳細については、「Identity Manager のフォーム」の章を参照してください。


注	Identity Manager に用意されているフォームを直接修正しないでください。代わりに、これらのフォームのコピーを作成して一意の名前を付け、このファイル名を変更したコピーフォームを編集するようにしてください。こうすることにより、カスタマイズしたコピーがアップグレードやサービスパックの更新の際に上書きされるのを防止できます。

ほかのリソースへアカウントをリンクする

Identity Manager では、相関規則と確認規則を使用してアカウントどうしをリンクします。相関規則は、アカウントを所有している可能性がある Identity Manager ユーザーを検索します。相関規則で定義された条件に一致するユーザーのリストが返されます。確認規則は、ユーザーが実際にアカウントを所有しているかどうかを確認するために、アカウントに対して Identity Manager ユーザーをテストします。true または false の値が返されます。所有者候補をすばやく検索したり (名前または属性に基づいて)、負担の大きなチェックの実行を所有者候補だけに制限したりするので、この 2 段階のアプローチによって、Identity Manager は相関を最適化することができます。

相関規則と確認規則の使用を開始する前に、最初のデータ読み込みの時点から含まれるデータを確認しておく必要があります。Identity Managerの accountId 属性は常に含まれます。「ファイルから読み込み」または一括処理の作成を実行した場合、CSV ファイルの先頭行に記述された属性値も含まれます。「リソースから読み込み」または調整を実行した場合、リソース上の一部のキー属性は含まれますが、ほかの属性は明示的に保存された場合にのみ含まれます。

また、二次リソース上に格納されたアカウントデータについても確認しておく必要があります。二次リソースには、Identity Manager にすでに存在するデータと重複するデータが含まれているのが理想的です。

これは意外に難しい条件である場合があります。多くの場合、異なるリソース間ではユーザーアカウントについての要件も異なります。例として、次の表では Windows のアカウント名と Solaris のアカウント名について要件および制限を比較しています。

表 4-3 Windows アカウント名と Solaris アカウント名の要件の比較
特性	Windows	Solaris
最大長	20 文字	8 文字
使用できる特殊文字	" / ¥ [ ] : ; \| = , + * ? < > を除くすべて	ピリオド (.)、下線 (_)、ハイフン (-) のみ
フルネームを指定可能	あり	コメントフィールドが 1 つあり。このコメントフィールドには伝統的にユーザーのフルネームを記述することになっていますが、その他の情報が含まれている可能性があります。
従業員 ID などの追加コメントを指定できるか	あり

Windows と Solaris のアカウント名の違いから、アカウントのリンクに伴ういくつかの問題が明らかになります。

最大長の違いが理由で、これら 2 つのシステムではアカウント名が異なるのが一般的です。Windows では、ユーザーが自分の姓および名と一致するアカウント名を持つことがよくあります。Solaris では、名の先頭の文字と、名の先頭から 7 文字を組み合わせたものをアカウント名として使用する場合があります。したがって、アカウント ID を比較する相関規則は、Solaris アカウントを Windows アカウントとリンクする手段として確実ではありません。

Windows でユーザーアカウントを作成するとき、管理者は表示名を指定する必要があります。Solaris のユーザーアカウントには表示名は不要ですが、オプションの GECOS フィールドを使用してユーザーの名前を指定できます。このフィールドの内容または形式についてのガイドラインはありません。ユーザーの GECOS フィールドは空にすることも、Windows の表示名とは関係のないテキストを入れることもできます。したがって、フルネームを比較する相関規則は、一般的に考えられているほど多くは利用されません。

アカウントをリンクするための準備をするときは、次の質問の答えを検討してください。

Mary A. Jones と Mary B. Jones、または John Doe Jr. と John Doe III などの、よく似た名前を持つユーザーがいますか。答えが「はい」の場合、それらのユーザーをどのようにして区別しますか。

各リソース上でアカウント名を定義する方法は共通化されていましたか。答えが「はい」の場合、Identity Manager に格納される値を使用してリソース上のアカウント ID を比較する規則を容易に定義できます。

リソースのアカウントデータを編集する機能がユーザーに許可されていましたか。答えが「はい」の場合、そのデータは、ユーザーが変更できないシステム上に格納される値と一致しない可能性があります。

カスタム相関キーを定義する

規則では、値がシステムに格納されないかぎり、リソース上のアカウントの値を Identity Manager の値と比較することはできません。accounts[Lighthouse] 属性にはこれらの値の多くが格納されますが、それら以外の値は、拡張ユーザー属性設定オブジェクトを使用して追加する必要があります。設定オブジェクトに登録されていない属性はシステムに保存されません。

デフォルトでは、次の属性が拡張ユーザー属性として含まれています。

firstname (名)

lastname (姓)

fullname (フルネーム)



注	拡張ユーザー属性 fullname は、QueryableAttrNames のリストに追加する必要があります。

これまでに述べた以外の、従業員 ID などの属性を相関規則の一部として使用したい場合、その属性を拡張ユーザー属性設定オブジェクトに追加する必要があります。追加は次の手順で行います。

Identity Manager のデバッグページ (http://PathToIDM/debug) にアクセスします。「System Settings」ページが表示されます。

「List Objects」プルダウンメニューから「Configuration」を選択します。「List Objects of type: Configuration」ページが表示されます。

「User Extended Attributes」の「edit」リンクを選択します。

次の例のように、List 要素に新しい属性を追加します。

<String>EmployeeId</String>

リソースの「アカウント属性 (スキーママップ)」ページで、属性を Identity Manager 属性として定義する必要があります。

変更を保存します。Identity Manager の「System Settings」デバッグページに戻ります。

カスタム属性は、UserUIConfig 設定オブジェクトの QueryableAttrNames 要素にも追加する必要があります。

「List Objects」プルダウンメニューから「Configuration」を選択します。「List Objects of type: Configuration」ページが表示されます。

「UserUIConfig」の「edit」リンクを選択します。

次の例のように、<QueryableAttrNames><List> 要素に新しい属性を追加します。

<String>EmployeeId</String>

変更を保存します。Identity Manager の「System Settings」デバッグページに戻ります。

アプリケーションサーバーを再起動します。

カスタム規則を作成する

Identity Manager は、いくつかの相関規則と確認規則を sample/reconRules.xml 内で事前に定義しています。これらは、独自の規則を作成するためのベースとして使用できます。規則には SUBTYPE_ACCOUNT_CORRELATION_RULE または SUBTYPE_ACCOUNT_CONFIRMATION_RULE のサブタイプを割り当てる必要があります。

次の規則は、二次リソースで定義された属性である account.EmployeeId を、以前に Identity Manager に読み込まれた属性である EmployeeId と比較します。二次リソースに account.EmployeeId の値が存在する場合、EmployeeId と一致するユーザーのリストが相関規則によって返されます。

<Rule subtype='SUBTYPE_ACCOUNT_CORRELATION_RULE' name='Correlate Employee IDs'

<cond>

<ref>account.EmployeeId</ref>

<list>

<s>EmployeeId</s>

<s>equals</s>

<ref>account.EmployeeId</ref>

</new>

</list>

</cond>

</Rule>

この例では、EmployeeId 属性はあらかじめユーザー拡張属性設定オブジェクトおよび UserUIConfig 設定オブジェクトに追加されています。リソースの側でデフォルトの Identity Manager 属性名にこの属性が含まれていなかった場合、リソースのスキーママップでこの属性を追加または編集する必要もあります。

相関規則は見つかった一致のリストを返します。従業員 ID のように、結果で 1 つの一致しか返されないことが予想される場合、確認規則は必要ありません。一方で、複数の一致が考えられる場合 (たとえば、姓名が一致する複数のアカウントが相関規則で検出された場合など) は、一致をさらに検証するための確認規則が必要です。

規則を Identity Manager に追加する方法には、Identity Manager IDE を使用する方法、XML ファイルをインポートする方法、デバッグページで既存の規則を編集してその名前を変更する方法があります。

手動でアカウントをリンクする

Identity Manager には、相関規則および確認規則で一致が見つからないときにアカウントを割り当てるために使用できる複数の機構が用意されています。

アカウントインデックスを使用する

アカウントインデックスには、Identity Manager が認識している各リソースアカウントの最新の状態が記録されています。このインデックスは主に調整によって管理されますが、Identity Manager のほかの機能でも必要に応じてアカウントインデックスの更新が行われます。

アカウントインデックスを確認するには、「リソース」タブをクリックし、左側の「アカウントインデックス」リンクをクリックします。リソースへ移動すると、対象のリソース上のすべてのアカウントの状態が表示されます。

相関のないアカウント (「アカウントインデックス」テーブルで、状況が「UNMATCHED」、所有者が「_UNKNOWN_」として表示される) を右クリックすると、Identity Manager のメニューが表示されます。このメニューから、新しい Identity Manager ユーザーアカウントの作成、リソースに対して有効な調整ポリシーを使用した単一アカウントに対する調整の実行、所有者の指定、リソースアカウントの削除または無効化などの処理を実行できます。「所有者の指定」オプションを選択すると、Identity Manager は、指定された条件に一致する所有者を検索するための画面を表示します。詳細については、『Identity Manager 管理ガイド』を参照してください。

自己検索を有効にする

Identity Manager のユーザーが自分自身のリソースアカウントの検索を行えるように、Identity Manager のユーザーインタフェースを設定することができます。つまり、Identity Manager の ID を持つユーザーはこの機能によって、既存のまだ関連付けられていないリソースアカウントに自分の ID を関連付けることができます。自己検索を有効にすることができるリソースは、パススルー認証をサポートするリソースに限られます。

自己検索を有効にするには、エンドユーザーリソース設定オブジェクトを編集して、ユーザーによるアカウント検索を許可するリソースの名前をそれぞれこのオブジェクトに追加する必要があります。次の手順で実行します。


注	「リソースから読み込み」、「ファイルから読み込み」、および一括処理では、アカウントインデックスの更新は行われません。

Identity Manager のデバッグページ (http://PathToIDM/debug) にアクセスします。「System Settings」ページが表示されます。

「List Objects」プルダウンメニューから「Configuration」を選択します。「List Objects of type: Configuration」ページが表示されます。

「End User Resources」の「edit」リンクを選択します。

<List> 要素のあとに、<String>Resource</String> を追加します。ここで、Resource はリポジトリ内のリソースオブジェクトの名前です。たとえば、ユーザーがリソース AD および Solaris 上のアカウントを自己検索できるようにするには、<List> 要素を次のように編集します。

<List>

<String>Solaris</String>

</List>

変更を保存します。Identity Manager の「System Settings」デバッグページに戻ります。

自己検索を有効にすると、Identity Manager のユーザーインタフェースに新しいメニュー項目 (「他のアカウントについてアイデンティティーシステムに知らせる」)が追加されます。ユーザーはこの領域で、利用可能なリストからリソースを選択し、リソースアカウント ID とパスワードを入力して、アカウントを自分の Identity Manager ID とリンクすることができます。

シナリオの例

この項では、1 つまたは複数のリソースからアカウントを読み込むプロセスを例示するシナリオを提供します。次のシナリオでは、さまざまな環境で発生する可能性がある問題について検討します。

Active Directory、SecurID、および Solaris

LDAP、PeopleSoft、および Remedy

高速一括追加

Active Directory、SecurID、および Solaris

ある会社で、Identity Manager を使用して Active Directory、SecurID、および Solaris のアカウントを管理することを検討しています。すべての従業員が Active Directory アカウントを、ほとんどの従業員が SecurID アカウントを持っています。ごく一部の従業員が Solaris アカウントを持っています。各リソース上のアカウントデータを検証したあとで、Identity Manager 管理者は、相関キーとして次の属性を使用できると判断しました。

表 4-4 相関キーの候補
相関キーの候補	Active Directory	SecurID	Solaris
アカウント ID が AD と一致	N/A	あり	なし
従業員 ID	あり	なし	なし
フルネーム	あり	あり	使用可 (Description 属性)

すべての従業員が Active Directory アカウントを持っているため、最初のデータ読み込みリソースには Active Directory を使用します。SecurID リソース上のアカウント ID は Active Directory 上のアカウント ID と一致するため、SecurID リソースを 2 番目に読み込みます。アカウント ID は常に一意であることから、フルネームよりも相関キーとして適しています。Active Directory アカウントおよび SecurID アカウントの間には、問題なく相関が成立すると考えられます。

Solaris アカウントについては、相関の成立は難しくなります。Solaris アカウントに存在する属性のうち、唯一の相関属性はユーザーのフルネームです。Solaris アカウントには、姓と名を定義するための独立した属性はありません。結果として、相関規則では、Solaris の useradd -c コマンドで定義される文字列と、Active Directory の fullname の値を比較することになります。この比較は、ニックネームの使用や不必要なスペースまたは句読文字が原因で、よく失敗します。

ユーザーの例

このシナリオでは、次のユーザーが存在する環境で、アカウントの読み込み時に発生する可能性があるいくつかの問題の例を示します。

表 4-5 データ読み込みのシナリオ: アカウントの読み込み時に発生する可能性のある問題
従業員名	AD および SecurID ログオン名	AD フルネーム	Solaris アカウント名	Solaris の Description
Anthony Harris	AJ Harris	Anthony J Harris	ajharris	A.J. Harris
Isabelle Moreno	Isabelle Moreno	Isabelle Moreno	imoreno	Isabelle Moreno
John Thomas (Sr.)	John Thomas	John Thomas	jthomas	John Thomas
John Thomas (Jr.)	John P. Thomas	John P. Thomas	jthomas2	John Thomas
Robert Blinn	Robert Blinn	Bob Blinn	rblinn	Bob Blinn
Theodore Benjamin	Theodore Benjamin	Theodore Benjamin	tbenjami	Ted Benjamin

Active Directory アカウントを読み込む

調整を使用して Active Directory アカウントを Identity Manager に読み込むためのガイドラインとして、次の手順を使用します。

管理者インタフェースの「リソース」ページで、「新規リソース」プルダウンメニューから「Windows 2000 / Active Directory」リソースを選択します。次に、アダプタを設定します。

Identity Manager のユーザー属性 accountId または fullname をスキーママップから削除しないように注意してください。また、アイデンティティーテンプレートが正しいことを確認してください。アダプタの設定の詳細については、オンラインヘルプおよび『Identity Manager リソースリファレンス』を参照してください。

(オプション) アカウントポリシーとパスワードポリシーを必要に応じて変更します。詳細については、「アカウント ID ポリシーとパスワードポリシーを設定する」を参照してください。

(オプション) 調整に使用するユーザーフォームを作成します。詳細については、「ユーザーフォームを割り当てる」を参照してください。

(オプション) データ読み込みを実行するための Identity Manager ユーザーを作成します。前の手順で作成したユーザーフォームをユーザーに割り当てます。

リソースの調整ポリシーを設定します。最初のリソースについては、相関規則は重要ではなく、確認規則は Identity Manager ユーザーの作成時には使用されません。これは最初のリソースであるため、 UNMATCHED 状況に対する応答オプションには「リソースアカウントに基づく新規ユーザーの作成」を割り当てるのが適切と考えられます。

データ読み込みを実行するためのユーザーを作成したら、そのユーザーとしてログインします。調整の場合はこの手順は不要ですが、「ファイルから読み込み」、「リソースから読み込み」、または一括処理の場合は必要です。

Active Directory リソースを調整します。

結果

デフォルトの Identity Manager アカウントポリシーとデフォルトの Active Directory アイデンティティーテンプレートを使用した場合、Theodore Benjamin の名前が 16 文字を超えているため、Identity Manager はこのユーザーの Active Directory アカウントにリンクする Identity Manager ユーザーを作成しません。これを回避するために、この例では、アカウント ID ポリシーを 25 文字に設定しました。

Identity Manager は、状況が CONFIRMED 状態であるすべてのリソースアカウントに対してユーザーアカウントを作成します。パスワードポリシーとアカウント ID ポリシーをパスしたすべてのユーザーがこれに該当します。ユーザーフォームでほかの設定を指定した場合を除き、Identity Manager のアカウント名は Active Directory のログイン名と同じになります。

SecurID アカウントを読み込む

SecurID を実装するとき、SecurID のユーザーレコードは通常、Microsoft セキュリティーアカウントマネージャー (SAM) データベースまたは LDAP サーバーからインポートされます。その結果、SecurID のアカウント ID はインポートソースのアカウント ID と一致します。SecurID アカウントと Active Directory アカウントの間には 1 対 1 の相関が成立するため、ユーザー間の相関確立は比較的容易になります。これらのアカウントを迅速にリンクする目的で、「アカウント ID と一致するユーザー名」の相関規則を使用できます。

SecurID アダプタを設定しているときは、Identity Manager のユーザー属性である accountId を削除しないように注意してください。

調整ポリシーを次のように設定します。

相関規則を「アカウント ID と一致するユーザー名」に設定します。

Active Directory はアイデンティティー情報の源泉として信頼性の高いリソースと考えられ、SecurID は Active Directory のアカウント情報に依存するため、UNMATCHED 状況時の動作オプションを「リソースアカウントの削除」または「リソースアカウントの無効化」に設定することをお勧めします。UNASSIGNED 状況は「Identity Manager ユーザーへリソースアカウントをリンク」に設定します。

結果

すべての SecurID アカウントについて、Active Directory アカウントとの相関が確立されます。必要に応じて、UNMATCHED または DISPUTED 状況を解決するための手順を追加します。

Solaris アカウントを読み込む

このシナリオでは、fullname 属性が唯一の相関キーです。スペースや句読文字などの違いにより確実に一致が失敗するため、これは弱い相関キーです。また、ユーザーは自分の表示名を Solaris の chfn コマンドで変更できます。フルネームが当初一致していたとしても、ユーザーが chfn コマンドを実行したことが原因で相関を確立できない可能性があります。

デフォルトでは、fullname 属性はクエリー可能ではありません。クエリー可能にするには、UserUIConfig 設定オブジェクトを編集し、fullname 属性を <QueryableAttrNames><List> 要素に追加する必要があります。詳細については、「カスタム相関キーを定義する」を参照してください。

fullname 属性どうしを相関させるためのカスタム規則を作成する必要もあります。この例では、「Correlate Full Names」という名前の規則を作成して相関処理を実行させます。この規則では、Solaris リソースの account.Description 属性の値を、Active Directory から読み込まれたシステム属性である fullname 属性と比較します。

<Rule subtype='SUBTYPE_ACCOUNT_CORRELATION_RULE' name='Correlate Full Names'

<cond>

<ref>account.Description</ref>

<list>

<s>fullname</s>

<s>equals</s>

<ref>account.Description</ref>

</new>

</list>

</cond>

</Rule>

この規則では、Solaris リソースからの Description 属性を、Identity Manager の fullname 属性と比較します。2 つの属性が一致する場合、アカウント間に相関が成立し、状況が CONFIRMED に変化します。

Solaris アダプタを設定しているときは、Identity Manager のユーザー属性である accountId または Description を削除しないように注意してください。

調整ポリシーを次のように設定します。

相関規則を「Correlate Full Names」(サンプル規則) に設定します。

すでに Identity Manager に読み込まれているアカウントと相関のない Solaris アカウントが数多く存在する可能性があります。UNASSIGNED 状況時の動作オプションを「リソースアカウントをユーザーにリンク」設定します。UNMATCHED 状況はほとんどの場合、「何もしない」に設定するのが適切です。一致しないユーザーを削除または無効化すると、データの消失や生産性の低下を招く可能性があります。

結果

表 4-6 データ読み込みのシナリオのユーザー例
従業員名	AD フルネーム	Solaris アカウント名	Solaris の Description
Anthony Harris	Anthony J Harris	ajharris	A.J. Harris
Isabelle Moreno	Isabelle Moreno	imoreno	Isabelle Moreno
John Thomas (Sr.)	John Thomas	jthoma	John Thomas
John Thomas (Jr.)	John P. Thomas	jthomas2	John Thomas
Robert Blinn	Bob Blinn	rblinn	Bob Blinn
Theodore Benjamin	Theodore Benjamin	tbenjami	Ted Benjamin

この例では、Isabelle Moreno のアカウントのみに相関が成立することが予測されます。

Active Directory の fullname 属性は Solaris の Description 属性と完全には一致しないため、Anthony Harris、John Thomas (Jr.)、Robert Blinn、および Theodore Benjamin のアカウントについては相関が成立しません。これらのアカウントの状況は UNMATCHED となります。このシナリオでは、Solaris のアカウント名は名のイニシャルと姓の組み合わせで構成されます。John Thomas のアカウントの例外を除き、これら不一致の Solaris アカウントの割り当ては簡単です。

Solaris アカウント jthomas および jthomas2 は、DISPUTED の状況となります。これらのアカウントは Description の値がともに John Thomas です。Solaris アカウント jthomas および jthomas2 がどのユーザーに属するのかを決定する別の手段を見つける必要があります。確認規則を使用して 2 つのアカウントを区別できれば理想的です。しかしながら、Solaris アカウントと Active Directory アカウントには、確認規則を作成するための十分な共通属性が含まれていません。

LDAP、PeopleSoft、および Remedy

このシナリオでは、理論的に LDAP リソースまたは PeopleSoft リソースが一次リソースとなりえます。

すべての従業員および契約社員が PeopleSoft で追跡される場合、このアプリケーションをアイデンティティー情報の源泉として信頼性の高いリソースとして考えることができます。

すべての従業員が LDAP アカウントを持つ場合、LDAP をアイデンティティー情報の源泉として信頼性の高いリソースとして考えることができます。

Remedy アカウントを持つ従業員の割合はごく限られているため、Remedy は一次リソースの候補とはなりません。

複数のアイデンティティー情報の源泉として信頼性の高いリソースが存在する場合、それらのうちどのリソースを最初に読み込んでもかまわないケースがほとんどです。ただし、PeopleSoft コンポーネントアダプタは ActiveSync 機能のみを実行します。別の PeopleSoft アダプタも利用できますが、範囲は限定されています。PeopleSoft コンポーネントアダプタは調整を実行しないため、結果的に、リソースに対して調整ポリシーを設定できません。利用可能な相関規則がないため、PeopleSoft アカウントを最初に読み込む必要があります。Identity Manager アカウント名は、PeopleSoft の EMPLID (従業員 ID) の値と一致します。

PeopleSoft の従業員 ID は、システムで定義されるすべてのユーザーについて一意であるため、相関キーとして理想的です。LDAP の inetOrgPerson オブジェクトには employeeNumber 属性が含まれます。従業員 ID は、Description などのラベルが付いた属性、またはカスタム属性に格納することもできます。このシナリオでは、LDAP の employeeNumber 属性が使用されていると想定します。

Remedy アダプタにはデフォルト属性が用意されていません。環境に合わせてアダプタをカスタマイズする必要があります。Remedy アプリケーションは、システムが要求を受け取ったときに電子メールを送信するように設定されることが多いため、電子メール属性が利用可能であると想定されます。LDAP の inetOrgPerson オブジェクトにもメール属性が含まれます。したがって、電子メールアドレスが相関キーとなります。

次の表は、このシナリオにおける各リソースの相関キーの一覧です。

表 4-7 データ読み込みのシナリオ: 各リソースの相関キー
相関キーの候補	PeopleSoft	LDAP	Remedy
従業員 ID	あり	あり	なし
電子メールアドレス	なし	あり	あり

ユーザーの例

このシナリオでは、次のユーザーが存在する環境で、アカウントの読み込み時に発生する可能性があるいくつかの問題の例を示します。

表 4-8 配備シナリオ: アカウントの読み込み時に発生する可能性のある問題
従業員名	PeopleSoft EMPLI	LDAP 従業員番号	LDAP 電子メール (@example.com)	Remedy 電子メール (@example.com)
Robert Blinn	945	945	Bob.Blinn	bblinn
William Cady	なし	なし	William.Cady	William.Cady
Eric D柊ngelo	1096	1096	Eric.D柊ngelo	Eric.D柊ngelo
Ren#233;e LeBec	891	なし	なし	なし
Josie Smith	1436	1463	Josie.Smith	なし
John Thomas	509	509	John.Thomas	なし
John P. Thomas	なし	なし	John.P.Thomas	John.P.Thomas

PeopleSoft ユーザーを読み込む

ActiveSync を使用する PeopleSoft アカウントを、調整を使用して Identity Manager に読み込むためのガイドラインとして、次の手順を使用します。

Identity Manager 管理者インタフェースの「リソース」ページで、「新規リソース」プルダウンメニューから「PeopleSoft コンポーネント」リソースを選択します。このリソースが表示されない場合、「管理するリソースの設定」ボタンをクリックし、カスタムリソースとして com.waveset.adapter.PeopleSoftComponentActiveSyncAdapter を追加します。このアダプタは、PeopleSoft が提供する JAR ファイルのインストールを必要とします。詳細については、『Identity Manager リソースリファレンス』を参照してください。

アダプタを設定します。Identity Manager のユーザー属性 accountId または fullname をスキーママップから削除しないように注意してください。また、アイデンティティーテンプレートが正しいことを確認してください。

(オプション) データの読み込みに使用するユーザーフォームを作成します。$WSHOME/sample/forms/PeopleSoftForm.xml ファイルをベースとして使用できます。詳細については、「ユーザーフォームを割り当てる」を参照してください。

PeopleSoft アダプタ上で ActiveSync を開始します。

結果

ユーザーフォームでアカウントを読み込まないよう指示された場合を除き、Identity Manager はすべてのユーザーを読み込みます。このシナリオで、Ren#233;e LeBec は LDAP アカウントと Remedy アカウントを持っていません。この人物はすでに会社を退職していると考えられます。デフォルトの PeopleSoft フォームを使用した場合、Identity Manager によって、退職した従業員の PeopleSoft アカウントは無効にされます。

William Cady および John P. Thomas は PeopleSoft システムで定義されていないため、これらのユーザーのアカウントは作成されません。

LDAP ユーザーを読み込む

このシナリオでは、LDAP の inetOrgPerson オブジェクトの employeeNumber 属性が相関キーです。この属性は LDAP アダプタのスキーママップにデフォルトで入っていないため、手動で追加する必要があります。この例の場合、属性 EmployeeId をスキーママップの「Identity Manager ユーザー属性」の側に、employeeNumber を「リソースユーザー属性」の側に追加します。


注	PeopleSoft アダプタは、Identity Manager の属性名 EmployeeId をデフォルトで使用します。LDAP と PeopleSoft の間で一貫性を保つためにこの値を選択しましたが、これは必須ではありません。

電子メールアドレスは Remedy リソースの相関キーとなりますが、LDAP アカウントを読み込む前に設定しておく必要があります。inetOrgPerson オブジェクトには、Remedy アカウントを読み込むための相関キーとなる mail 属性が含まれます。mail 属性もスキーママップに追加する必要があります。email 属性をスキーママップの「Identity Manager ユーザー属性」の側に、mail 属性を「リソースユーザー属性」の側に追加します。email は事前に定義された Identity Manager 属性であるため、この属性を使用するほうが、ユーザー拡張属性設定オブジェクトまたは UserUIConfig 設定オブジェクトを編集して mail 属性を追加するよりも簡単です。

Identity Manager では、アカウント ID は User オブジェクトの resourceAccountIds 属性に格納されます。これは複数の値をとる属性であり、各値の形式は accountId@objectId です。LDAP の EmployeeId の値を PeopleSoft の accountId と比較する、次のような規則を作成できます。

コード例 4-1 LDAP の EmployeeId 値と PeopleSoft の accountId の比較


<Rule subtype='SUBTYPE_ACCOUNT_CORRELATION_RULE' name='Correlate EmployeeId with accountId'> <cond> <ref>account.EmployeeId</ref> <list> <new class='com.waveset.object.AttributeCondition'> <s>resourceAccountIds</s> <s>startsWith</s> <concat> <ref>account.EmployeeId</ref> <s>@</s> </concat> </new> </list> </cond> </Rule>


注	このシナリオでは、accountId および email 属性はシステム上で常に利用可能であるため、ユーザー拡張属性設定オブジェクトまたは UserUIConfig 設定オブジェクトに属性を追加する必要はありません。

管理者インタフェースの「リソース」ページで、「新規リソース」プルダウンメニューから「LDAP」リソースを選択します。その後、アダプタを次のように設定します。

Identity Manager のユーザー属性 EmployeeId および email を追加します。

Identity Manager のユーザー属性である accountId をスキーママップから削除しないように注意してください。

アイデンティティーテンプレートが正しいことを確認します。

アダプタの設定の詳細については、オンラインヘルプおよび『Identity Manager リソースリファレンス』を参照してください。

リソースの調整ポリシーを次のように設定します。

相関規則を「Correlate EmployeeId with accountId」に設定します。

次の状況の値を設定します。

UNASSIGNED 状況時の動作オプションを「Identity Manager ユーザーへリソースアカウントをリンク」に設定します。

UNMATCHED 状況のオプションを適切な処理に設定します。ほかのリソース上に検出されたユーザーを追加できるかどうかについては、PeopleSoft 管理者への確認が必要な場合があります。「リソースアカウントに基づく新規ユーザーの作成」オプションを選択する場合、Identity Manager ユーザーにはデフォルトで、LDAP の cn 属性に基づくアカウント名が付与されます。

LDAP リソースを調整します。

結果

このシナリオでは、William Cady、Josie Smith、および John P. Thomas のアカウントは UNMATCHED 状態になります。Josie Smith については、従業員 ID の値が PeopleSoft リソース上と LDAP リソース上で一致しません。従業員 ID は PeopleSoft によって生成されるため、LDAP リソース側の値が正しくありません。誤りを訂正し、もう一度調整を行ってください。

William Cady および John P. Thomas は PeopleSoft で定義されていません。LDAP アカウントの読み込み手順の手順 2 の記述に従って、アカウントを PeopleSoft に追加する必要があるかどうかを検討してください。

Remedy ユーザーを読み込む

Remedy アダプタには事前に定義されたアカウント属性はありません。これらの属性をスキーママップに追加する必要があります。Remedy では、追跡する各属性を一意に識別するために整数を使用します。たとえば、Remedy のアカウント ID には 1002000100 のような値が割り当てられる場合があります。これらの Remedy 属性番号を、スキーママップのリソースユーザー属性に追加する必要があります。最低限、次の Identity Manager ユーザー属性を追加する必要があります。

accountId

email (相関キー)

USER_EMAIL_MATCHES_ACCOUNT_EMAIL_CORR 相関規則は、Remedy アカウントを Identity Manager アカウントにリンクします。

Identity Manager 管理者インタフェースの「リソース」ページで、「新規リソース」プルダウンメニューから「Remedy」リソースを選択します。その後、アダプタを次のように設定します。

最低限、Identity Manager のユーザー属性 accountId および email を追加します。ほかの属性を追加することもできます。

アダプタの設定の詳細については、オンラインヘルプおよび『Identity Manager リソースリファレンス』を参照してください。

リソースの調整ポリシーを次のように設定します。

相関規則を USER_EMAIL_MATCHES_ACCOUNT_EMAIL_CORR に設定します。

次の状況の値を設定します。

UNASSIGNED 状況時の動作オプションを「リソースアカウントをユーザーにリンク」に設定します。

UNMATCHED 状況を適切な処理に設定します。

Remedy リソースを調整します。

結果

William Cady、Eric D'Angelo、および John P. Thomas の Remedy アカウントについては、LDAP と Remedy で定義されている電子メールアドレスが一致したため、正常に相関が確立されました。Robert Blinn の Remedy アカウントについては、相関を確立できませんでした。Remedy 上の電子メールアドレスが別名で設定されていたことが原因です。このシナリオのほかのユーザーは Remedy アカウントを持っていません。

高速一括追加のシナリオ

次の手順は、「作成」処理を使用して、数名のユーザーを Identity Manager に迅速に追加する方法を示します。CSV ファイルをシステムに読み込む前に、CSV ファイルで参照されるすべてのリソースが Identity Manager 内で定義されている必要があります。

一括処理の作成を実行するために必要な情報を格納した CSV ファイルを生成します。CSV ファイルの形式の詳細については、「一括処理の作成」を参照してください。

CSV ファイルにパスワードが含まれていない場合、デフォルトのパスワードポリシーオプションを設定し、パスワードがシステムによって生成されるようにします。これを行うには、「設定」タブをクリックし、左側の「ポリシー」をクリックします。「Default Lighthouse Account Policy」リンクをクリックします。次に、「パスワード提供者」ドロップダウンメニューから「生成」オプションを選択します。

デフォルトの「ユーザー作成」プロビジョニングタスクに基づいて、新しいプロビジョニングタスクを作成します。

XML 画面で、TaskDefinition タグの resultLimit パラメータの値を 0 に編集します。この値は、タスクの結果を保持する秒数を指定します。

次に、タスクから次のセクションを削除します。

...

</Activity>

...

</Activity>



注	プロビジョナを呼び出すアクティビティーは残す必要があります。

残っていないと、ユーザーが正しく作成されません。タスクの名前を「Fast Create User」のような値に忘れずに変更してください。

デフォルトのユーザーフォームに基づく新しいフォームを作成します。

XML 画面で、<Form>... </Form> 構造全体を次のように置き換えます。

<s>Fast Create User</s>

</Expansion>

</Field>

</Form>

「Fast User Form」のようにユーザーフォームの名前を忘れずに変更してください。

アカウントを Identity Manager に読み込むために使用する Identity Manager アカウントを作成します。手順 4で作成したユーザーフォームをこのユーザーに割り当てます。

前の手順で作成したアカウントを使用して、Identity Manager にログインします。

一括処理の作成を実行します。

前へ目次索引次へ
Sun™ Identity Manager 8.0 配備に関する技術概要