前回はFIM Synchronization Serviceの設定を行ったところまでやりましたので、今回はFIM Serviceの設定から始めます。
FIM Serviceを構成する
本ガイドのシナリオではプロビジョニングポリシーを構成する必要があります。
このプロビジョニングポリシーの目的は契約社員をADユーザの発信同期規則のスコープに入れることです。
リソースを同期規則のスコープに入れると設定に従い同期エンジンはAD DSにリソースをプロビジョニングします。
FIM Serviceを構成するには、Internet Exploreでhttp://localhost/identitymanagementに移動します。
プロビジョニングポリシーを作成するためには、FIMポータルページの[管理]セクションから関連するページへ移動します。
構成を確認するには、同期構成を出力するPowerShellスクリプトを実行します。
同期ルールを作成する
次の表はFabrikamプロビジョニング同期ルールに必要な構成を示しています。
リソースを同期規則のスコープに入れると設定に従い同期エンジンはAD DSにリソースをプロビジョニングします。
FIM Serviceを構成するには、Internet Exploreでhttp://localhost/identitymanagementに移動します。
プロビジョニングポリシーを作成するためには、FIMポータルページの[管理]セクションから関連するページへ移動します。
構成を確認するには、同期構成を出力するPowerShellスクリプトを実行します。
同期ルールを作成する
次の表はFabrikamプロビジョニング同期ルールに必要な構成を示しています。
| 同期規則の構成 | ||
| 表示名 | AD User Outbound Synchronization Rule | |
| 説明 | ||
| 優先順位 | 1 | |
| データフローの方向 | 送信 | |
| 依存関係 | ||
| スコープ | ||
| メタバースリソースの種類 | person | |
| 外部システム | Fabrikam ADMA | |
| 外部システムリソースの種類 | user | |
| リレーションシップ | ||
| 外部システム内にリソースを作成する | True | |
| デプロビジョニングを有効にする | False | |
| リレーションシップ条件 | ||
| MetaverseObject:person(属性) | ConnectedSystemObject:user(属性) | |
| accountNamae | sAMAccountName | |
| 初回の送信属性フロー | ||
| NULLを許可 | 宛先 | ソース |
| False | dn | +("CN=",displayName,",OU=FIMObjects,DC=fabrikam,DC=com") |
| False | userAccountControl | 数値: 512 |
| False | unicodePwd | 文字列: Pa$$W0rd |
| 永続的な送信属性フロー | ||
| NULLを許可 | 宛先 | ソース |
| False | sAMAccountName | accountName |
| False | displayName | displayName |
| False | givenName | firstName |
| False | sn | lastName |
| ステップ6 |
| 上記の表のとおりに同期規則を作成します |
| 重要）dnをターゲットとした属性フローは初回のみを選択したことを確認してください |
ワークフローを作成する
AD プロビジョニング ワークフローの目的は、Fabrikamのプロビジョニング同期規則にリソースを追加することです。
次の表は、構成を示しています。
管理ポリシールールを作成する
必要な管理ポリシールール（MPR）はSet Transisionタイプであり、リソースがすべての契約社員というセットのメンバとなったことを契機に動作します
次の表は、構成を示しています。
環境を初期化する
初期化フェーズの目的は
・同期規則をメタバースに格納する
・Active Directoryの構成をActive Directoryコネクタスペースに格納する
ことです。
次の表は初期化フェーズの実行プロファイルを示します。
構成をテストする
このセクションの目的は、実際の構成をテストすることです。 構成をテストするには、
・サンプルユーザをFIMポータルで作成
・サンプルユーザのプロビジョニング要件を確認
・サンプルユーザをAD DSへプロビジョニング
・ユーザがAD DSに存在することを確認
を行います。
・サンプルユーザをFIMポータルで作成
次の表は、サンプルのユーザのプロパティの一覧です。
サンプルユーザのプロビジョニング要件を確認
サンプルユーザをAD DSへプロビジョニングするには、2つの前提条件が満たされている必要があります。
１．All ContractorsのSETのメンバであること
２．発信同期規則のスコープ内であること
ユーザがAll Contractorsのメンバかどうかを確認するには、SETを開き[メンバを表示]をクリックします。
ユーザが同期規則のスコープ内にあるかどうかを確認するには、ユーザのプロパティページを開き、プロビジョニングタブ内にあるExpected Rules List属性を見ます。
Expected Rules List属性の値ははAD User Outbound Synchronization Ruleになっているはずです。
次の図で確認方法の例を示します。
この時点では同期規則のステータスはペンディングです。
つまり、同期規則はまだユーザに適用されていません。
サンプルのユーザの同期
テストオブジェクトの初回の同期サイクルを開始する前に、テスト計画の中で各実行プロファイルを実行後のあるべき姿をトラッキングしておく必要があります。
テスト計画はオブジェクトのあるべき次の状態（作成、更新、削除）と属性値を含んでいるべきです。
テスト計画を使用して、期待されるテスト結果を確認します。
もしステップが期待通りの結果を返さない場合は、あるべき結果と実際の結果の不一致を解決するまでは次のステップへ進まないでください。
期待通りに動いているかを確認するには、最初の指標として同期の統計情報を利用することができます。
例えば、新しいオブジェクトがコネクタスペースにステージングされることを期待していたのに、インポートの統計の中の[Add]が0件だった場合、明らかに何か期待通りに動いていないものがあるということになります。
AD プロビジョニング ワークフローの目的は、Fabrikamのプロビジョニング同期規則にリソースを追加することです。
次の表は、構成を示しています。
| ワークフロー構成 | |
| 表示名 | AD User Provisioning Workflow |
| 説明 | |
| ワークフロータイプ | Action |
| ポリシー更新時に実行 | False |
| 同期規則 | |
| 名前 | AD User Outbound Synchronization Rule |
| 動作 | 追加 |
| ステップ7 |
| 上記の表のとおりにワークフローを作成します |
管理ポリシールールを作成する
必要な管理ポリシールール（MPR）はSet Transisionタイプであり、リソースがすべての契約社員というセットのメンバとなったことを契機に動作します
次の表は、構成を示しています。
| 管理ポリシー規則構成 | |
| 表示名 | AD User Provisioning Management Policy Rule |
| 説明 | |
| 型 | セット移行 |
| 権限の付与 | False |
| 無効化 | False |
| 移行の定義 | |
| 移行の種類 | セットへの移行 |
| 移行セット | All Contractors |
| ポリシーワークフロー | |
| タイプ | 表示名 |
| Action | AD User Provisioning Workflow |
| ステップ8 |
| 上記の表のとおりに管理ポリシールールを作成します |
環境を初期化する
初期化フェーズの目的は
・同期規則をメタバースに格納する
・Active Directoryの構成をActive Directoryコネクタスペースに格納する
ことです。
次の表は初期化フェーズの実行プロファイルを示します。
| 順序 | 管理エージェント | 実行プロファイル |
| 1 | Fabrikam FIMMA | フルインポート |
| 2 | ||
| 3 | エクスポート | |
| 4 | 差分インポート | |
| 5 | Fabrikam ADMA | フルインポート |
| 6 |
| ステップ9 |
| 上記の表のとおりに実行プロファイルを実行します |
| 注）発信同期規則が正常にメタバースに投影されていることを確認してください。 |
構成をテストする
このセクションの目的は、実際の構成をテストすることです。 構成をテストするには、
・サンプルユーザをFIMポータルで作成
・サンプルユーザのプロビジョニング要件を確認
・サンプルユーザをAD DSへプロビジョニング
・ユーザがAD DSに存在することを確認
を行います。
・サンプルユーザをFIMポータルで作成
次の表は、サンプルのユーザのプロパティの一覧です。
| 属性 | 値 |
| 名 | Britta |
| 名前 （姓） | Simon |
| 表示名 | |
| AccountName | BSimon |
| ドメイン | Fabrikam |
| 契約者 |
| ステップ10 |
| 上記の表のとおりにサンプルユーザを作成します |
サンプルユーザのプロビジョニング要件を確認
サンプルユーザをAD DSへプロビジョニングするには、2つの前提条件が満たされている必要があります。
１．All ContractorsのSETのメンバであること
２．発信同期規則のスコープ内であること
ユーザがAll Contractorsのメンバかどうかを確認するには、SETを開き[メンバを表示]をクリックします。
| ステップ11 |
| ユーザがAll Contractorsのメンバであることを確認します。 |
ユーザが同期規則のスコープ内にあるかどうかを確認するには、ユーザのプロパティページを開き、プロビジョニングタブ内にあるExpected Rules List属性を見ます。
Expected Rules List属性の値ははAD User Outbound Synchronization Ruleになっているはずです。
次の図で確認方法の例を示します。
この時点では同期規則のステータスはペンディングです。
つまり、同期規則はまだユーザに適用されていません。
| ステップ12 |
| ユーザがADユーザ発信同期規則のスコープ内であることを確認します。 |
サンプルのユーザの同期
テストオブジェクトの初回の同期サイクルを開始する前に、テスト計画の中で各実行プロファイルを実行後のあるべき姿をトラッキングしておく必要があります。
テスト計画はオブジェクトのあるべき次の状態（作成、更新、削除）と属性値を含んでいるべきです。
テスト計画を使用して、期待されるテスト結果を確認します。
もしステップが期待通りの結果を返さない場合は、あるべき結果と実際の結果の不一致を解決するまでは次のステップへ進まないでください。
期待通りに動いているかを確認するには、最初の指標として同期の統計情報を利用することができます。
例えば、新しいオブジェクトがコネクタスペースにステージングされることを期待していたのに、インポートの統計の中の[Add]が0件だった場合、明らかに何か期待通りに動いていないものがあるということになります。
同期の統計情報でシナリオが期待どおりに機能しているかについての初期情報を確認することができますが、Synchronization Service Managerのコネクタスペースの検索とメタバースの検索機能を使って属性の値が予測された通りになっているかどうかを確認してください。
AD DSユーザを同期するには、以下の手順を実行します。
１．ユーザをFIM MAコネクタスペースにインポートします。
２．ユーザをメタバースへ投影します。
３．ユーザをActive Directoryコネクタスペースへプロビジョニングします。
４．FIMにステータス情報をエクスポートします。
５．ユーザをAD DSにエクスポートします。
６．ユーザの作成状況を確認します。
これらのタスクを完遂するためには、次の実行プロファイルを実行します。
FIMサービスのデータベースからのインポート後、Britta Simonと、BrittaをAD User Outbound Synchronization RuleにリンクするExpectedRulesEntryオブジェクトがFabrikam FIMMAのコネクタスペースにステージングされます。
コネクタスペースのBrittaのプロパティをみると、FIMポータルで設定した属性値とともにEREオブジェクトへの参照が設定されているのがわかります。
次のスクリーンショットがこの例です。
AD DSユーザを同期するには、以下の手順を実行します。
１．ユーザをFIM MAコネクタスペースにインポートします。
２．ユーザをメタバースへ投影します。
３．ユーザをActive Directoryコネクタスペースへプロビジョニングします。
４．FIMにステータス情報をエクスポートします。
５．ユーザをAD DSにエクスポートします。
６．ユーザの作成状況を確認します。
これらのタスクを完遂するためには、次の実行プロファイルを実行します。
| 管理エージェント | 実行プロファイル |
| Fabrikam FIMMA | １．デルタ インポート |
| ２．デルタ同期 | |
| ３．エクスポート | |
| ４．デルタ インポート | |
| Fabrikam ADMA | １．エクスポート |
| ２．デルタ インポート |
FIMサービスのデータベースからのインポート後、Britta Simonと、BrittaをAD User Outbound Synchronization RuleにリンクするExpectedRulesEntryオブジェクトがFabrikam FIMMAのコネクタスペースにステージングされます。
コネクタスペースのBrittaのプロパティをみると、FIMポータルで設定した属性値とともにEREオブジェクトへの参照が設定されているのがわかります。
次のスクリーンショットがこの例です。
Fabrikam FIMMAでのデルタ同期の目的は、下記のいくつかの操作を実行することです。
・投影 - 新しいユーザオブジェクトおよび関連するExpected Rule Entryオブジェクトをメタバースに投影
・プロビジョニング - 新しく投影されたBiritta SimonのオブジェクトをFabrikam ADMDのコネクタスペースにプロビジョニング
・属性フローのエクスポート - 両方の管理エージェントで発生する属性フローをエクスポート。Fabrikam ADMAでは新しくプロビジョニングされたBritta Simonオブジェクトは新しい属性値で設定され、Fabrikam FIMMAでは既存のBritta Simmonオブジェクトおよび関連付けられたExpectedRuleEntryオブジェクトは投影結果により属性値が更新されます。
・投影 - 新しいユーザオブジェクトおよび関連するExpected Rule Entryオブジェクトをメタバースに投影
・プロビジョニング - 新しく投影されたBiritta SimonのオブジェクトをFabrikam ADMDのコネクタスペースにプロビジョニング
・属性フローのエクスポート - 両方の管理エージェントで発生する属性フローをエクスポート。Fabrikam ADMAでは新しくプロビジョニングされたBritta Simonオブジェクトは新しい属性値で設定され、Fabrikam FIMMAでは既存のBritta Simmonオブジェクトおよび関連付けられたExpectedRuleEntryオブジェクトは投影結果により属性値が更新されます。
既に同期統計情報により示されたように、プロビジョニングのアクティビティはFabrikam ADMAのコネクタスペースで行われます。
メタバースの中のBritta Simonのプロパティをみると、それらのアクティビティがExpectedRulesList属性値に正しく参照が割り当てらていることによりわかります。
メタバースの中のBritta Simonのプロパティをみると、それらのアクティビティがExpectedRulesList属性値に正しく参照が割り当てらていることによりわかります。
続くFabrikam FIMMAでのエクスポートにおいて、Britta Simonの同期規則の状態はペンディングから適用へ更新されます。それは発信同期規則がメタバース中のオブジェクトに対してアクティブになったことを示しています。
新しいオブジェクトがADMAコネクタスペースにプロビジョニングされたため、この管理エージェントではペンディングエクスポートが追加されます。
「Windows PowerShellを使って管理エージェントのエクスポート状態を表示する」というスクリプトを使うことによりFabrikam ADMAへ追加されるペンディングエクスポートを表示することができます。
FIMでは、エクスポート操作を完了するには、各エクスポートの実行毎に次のデルタインポートの実行の必要があります。
エクスポートの後に実行されるデルタインポートは確認のためのインポートと呼ばれます。
確認のためのインポートはFIM Synchronizationサービスが同期を成功させるために必要な適切な更新を行うために必要です。
新しいオブジェクトがADMAコネクタスペースにプロビジョニングされたため、この管理エージェントではペンディングエクスポートが追加されます。
「Windows PowerShellを使って管理エージェントのエクスポート状態を表示する」というスクリプトを使うことによりFabrikam ADMAへ追加されるペンディングエクスポートを表示することができます。
FIMでは、エクスポート操作を完了するには、各エクスポートの実行毎に次のデルタインポートの実行の必要があります。
エクスポートの後に実行されるデルタインポートは確認のためのインポートと呼ばれます。
確認のためのインポートはFIM Synchronizationサービスが同期を成功させるために必要な適切な更新を行うために必要です。
| ステップ13 |
| 上記の表のとおりに実行プロファイルを実行します。 |
| 注）各実行プロファイルがエラー無く完了する必要があります。 |
AD DSにユーザがプロビジョニングされていることを確認する
サンプルユーザがAD DSにプロビジョニングされていることを確認するには、FIMObjects OUを開きます。
Britta Simonが存在するはずです。
| ステップ14 |
| サンプルユーザがFIMObjects OUに存在することを確認します。 |
まとめ
このドキュメントの目的は、AD DSとFIMのユーザを同期するためのメインのビルドブロックに紹介することです。
初期のテストでは、タスクを完了するのに必要な最小数の属性で開始し、一般的な手順が正常に機能したら複数の属性をシナリオに追加してください。
複雑さを最小限に維持することがトラブルシューティングプロセスを簡素化します。
構成をテストする際、新しいテストオブジェクトを削除して再作成することがしばしば発生します。
ExpectedRulesList属性が設定されたオブジェクトにとってこれらの操作はExpectedRuleEntryの孤立を発生させます。
「孤立したExpectedRuleEntryオブジェクトを削除する方法」という記事はそれらのオブジェクトをテスト環境から削除する方法を説明しています。
同期先としてAD DSを含む典型的なシナリオにおいて、FIMはオブジェクトのすべての属性について権威を持っていません。例えば、AD DS内のユーザオブジェクトをFIMを使って管理する際、最低でもドメインとobjectSID属性はAD DS管理エージェントによって作成されます。アカウント名、ドメイン、ibjectSID属性はFIMポータルへログインを有効にする際に必要となります。AD DSからそれらの属性を設定するには、AD DSコネクタスペースに追加の着信同期規則を設定する必要があります。また、属性値に複数のソースを持つオブジェクトを管理するためには、属性フローの優先順位を正しく構成する必要があります。もし属性フローの優先順位が正しく構成されていない場合、同期エンジンが設定されたソースからの属性値をブロックしてしまいます。属性フローの優先順位の詳細については属性フローの優先順位についての記事を参照してください。
読むことを推奨する文書
・設計コンセプト：FIMを使ってActive Directoryのアカウントを有効化もしくは無効化する
・設計コンセプト：参照属性について
・FIM MAアカウントをどのように管理すればよいですか？
・権威のないアカウントを発見する - パート１：予測
・設計コンセプト：コネクタ検出のメカニズム
・設計コンセプト：ADMAアカウントを設定する
・孤立したExpectedRuleEntryオブジェクトを削除する方法
・属性フローの優先順位について
・エクスポートについて
投稿
0 件のコメント:
コメントを投稿