Microsoft Identity Manager 2016 のベストプラクティス

2025-04-08

このトピックでは、Microsoft Identity Manager 2016 (MIM) の展開と運用のベストプラクティスについて説明します

SQL のセットアップ

注

SQL を実行するサーバーをセットアップするための次の推奨事項は、FIMService 専用の SQL インスタンスと FIMSynchronizationService データベース専用の SQL インスタンスを前提とします。統合環境で FIMService を実行している場合は、構成に適した調整を行う必要があります。

構造化クエリ言語 (SQL) サーバーの構成は、最適なシステムパフォーマンスに不可欠です。大規模な実装で最適な MIM パフォーマンスを実現するには、SQL を実行するサーバーのベストプラクティスの適用に依存します。詳細については、SQL のベストプラクティスに関する次のトピックを参照してください。

データファイルとログファイルを事前サイズ設定する

自動拡張に依存しないでください。代わりに、これらのファイルの拡張を手動で管理します。安全上の理由から自動拡張を有効のままにすることはできますが、データファイルの増加を事前に管理する必要があります。 MIM データベースのサンプルサイズについては、FIM キャパシティプランニングガイドを参照してください。

SQL データファイルとログファイルを事前にサイズ変更するには

SQL Server Management Studio を起動します。
データベース FIMService に移動し、FIMService を右クリックし、[プロパティ] をクリックします。
[ファイル] ページで、データベースファイルを必要なサイズに展開します。

データファイルからログを分離する

SQL Server のベストプラクティスに従って、データベースのトランザクションログファイルとデータログファイルを分離して物理ディスクを分離します。

追加の tempdb ファイルを作成する

最適なパフォーマンスを得られるように、tempdb ファイルに CPU コアごとに 1 つのデータファイルを作成することをお勧めします。

追加の tempdb ファイルを作成するには

SQL Server Management Studio を起動します。
システムデータベースのデータベース tempdb に移動し、tempdb を右クリックし、[プロパティ] をクリックします。
[ファイル] ページで、CPU コアごとに 1 つのデータファイルを作成します。 tempdb データとログファイルは、必ず異なるドライブとスピンドルに分離してください。

ログファイル用の十分な領域を確保する

復旧モデルのディスク要件を理解することが重要です。システムの初期読み込み中にディスク領域の使用を制限するには単純復旧モードが適していますが、最新のバックアップの後に作成されたデータはデータ損失にさらされます。完全復旧モードを使用する場合は、ディスク領域の使用量が多くないように、トランザクションログの頻繁なバックアップを含むバックアップを使用してディスク使用量を管理する必要があります。詳細については、「復旧モデルの概要参照してください。

SQL サーバーのメモリを制限する

SQL サーバー上のメモリの量と、SQL サーバーを他のサービス (MIM 2016 サービスと MIM 2016 同期サービス) と共有する場合に応じて、SQL のメモリ消費量を制限できます。この制限は、次の手順で設定できます。

SQL Server Enterprise Manager を起動します。
[新しいクエリ] を選択します。

次のクエリを実行します。

USE master

EXEC sp_configure 'show advanced options', 1

RECONFIGURE WITH OVERRIDE

USE master

EXEC sp_configure 'max server memory (MB)', 12000--- max=12G RECONFIGURE
WITH OVERRIDE

この例では、12 ギガバイト (GB) 以下のメモリを使用するように SQL サーバーを再構成します。

次のクエリを使用して設定を確認します。

USE master

EXEC sp_configure 'max server memory (MB)'--- verify the setting

USE master

EXEC sp_configure 'show advanced options', 0

RECONFIGURE WITH OVERRIDE

バックアップと回復の構成

一般に、データベース管理者と協力して、バックアップと復旧の戦略を設計する必要があります。推奨事項には、次のようなものがあります。

組織のバックアップポリシーに従ってデータベースバックアップを実行します。
増分ログバックアップが計画されていない場合は、データベースを単純復旧モードに設定する必要があります。
バックアップ戦略を実装する前に、さまざまな復旧モデルの影響を理解していることを確認してください。これらのモデルのディスク領域の要件について説明します。完全復旧モデルでは、ディスク領域の使用量が多くならないように、頻繁なログバックアップが必要です。

詳細については、「復旧モデルの概要と FIM 2010 のバックアップと復元のガイドを参照してください。

インストール後に FIM サービスのバックアップ管理者アカウントを作成する

FIMService Administrators セットのメンバーには、MIM 展開の操作に不可欠な一意のアクセス許可があります。 Administrators セットの一部としてログオンできない場合の唯一の解決策は、システムの以前のバックアップにロールバックすることです。この状況を軽減するには、インストール後の構成の一部として、他のユーザーを FIM 管理セットに追加することをお勧めします。

FIM サービス

FIM サービスサービス Exchange メールボックスの構成

MIM 2016 サービスアカウント用に Microsoft Exchange Server を構成するためのベストプラクティスを次に示します。

サービスアカウントを構成して、内部電子メールアドレスからのみメールを受け入れるようにします。具体的には、サービスアカウントメールボックスが外部 SMTP サーバーからメールを受信できないようにする必要があります。

サービスアカウントを構成するには

Exchange 管理コンソールで、FIM サービスアカウントを選択します。
[プロパティ] を選択し、[メールフローの設定] を選択し、[メール配信の制限 選択します。
[すべての送信者が認証されることを要求する ] チェックボックスをオンにします。

詳細については、「メッセージ配信制限の構成」を参照してください。

サイズが 1 MB を超えるメールを拒否するようにサービスアカウントを構成します。ベストプラクティスに従って、メールボックスまたは Mail-Enabled パブリックフォルダーのメッセージサイズ制限を構成します。
メールボックスストレージクォータが 5 GB になるようにサービスアカウントを構成します。最適な結果を得るには、「メールボックスの記憶域クォータの構成に関するページに記載されているベストプラクティスに従ってください。

MIM ポータル

SharePoint のインデックス作成を無効にする

Microsoft Office SharePoint® のインデックス作成を無効にすることをお勧めします。インデックスを作成する必要があるドキュメントはありません。インデックス作成により、多くのエラーログエントリと MIM の潜在的なパフォーマンスの問題が発生します。 SharePoint のインデックス作成を無効にするには、次の手順を実行します。

MIM 2016 ポータルをホストするサーバーで、[スタート] をクリックします。
[すべてのプログラム] をクリックします。
[すべてのプログラム] の一覧で、[管理ツール] をクリックします。
[管理ツール] の [SharePoint サーバーの全体管理] をクリックします。
[サーバーの全体管理] ページで、[操作] をクリックします。
[操作] ページの [グローバル構成] で、[タイマージョブの定義] をクリックします。
[タイマージョブの定義] ページで、[SharePoint Services 検索の更新] をクリックします。
[タイマージョブの編集] ページで、[無効] をクリックします。

MIM 2016 の初期データ読み込み

このセクションでは、外部システムから MIM への初期データ読み込みのパフォーマンスを向上させる一連の手順を示します。これらの手順の多くは、システムの初期作成中にのみ実行されることを理解しておくことが重要です。これらは、読み込み完了時にリセットする必要があります。これらの手順は、継続的な同期ではなく、1 回限りの操作用です。

重要

このガイドの SQL セットアップセクションで説明されているベストプラクティスが適用されていることを確認します。

手順 1: 初期データ読み込み用に SQL サーバーを構成する

データの初期読み込みには、時間の長いプロセスが考えられる場合があります。最初に大量のデータを読み込む予定の場合は、MIM 2016 管理エージェント (FIM MA) のエクスポートが完了した後にフルテキスト検索を一時的にオフにして再度有効にすることで、データベースの設定にかかる時間を短縮できます。

フルテキスト検索を一時的に無効にするには:

SQL Server Management Studio を起動します。
[新しいクエリ] を選択します。
次の SQL ステートメントを実行します。

ALTER FULLTEXT INDEX ON [fim].[ObjectValueString] SET CHANGE_TRACKING = MANUAL
ALTER FULLTEXT INDEX ON [fim].[ObjectValueXml] SET CHANGE_TRACKING = MANUAL

重要

これらの手順を実装しないと、ディスク領域の使用率が高くなり、ディスク領域が不足する可能性があります。このトピックの詳細については、「復旧モデルの概要」参照してください。 FIM のバックアップと復元のガイドには、追加情報が含まれています。

手順 2: 読み込みプロセス中に必要最小限の MIM 構成を適用する

初期読み込みプロセス中は、管理ポリシー規則 (MPR) と設定定義に必要な最小構成のみを FIM 構成に適用する必要があります。データの読み込みが完了したら、デプロイに必要な追加セットを作成します。アクションワークフローの Run-On ポリシー更新設定を使用して、読み込まれたデータにさかのぼってこれらのポリシーを適用します。

手順 3: FIM サービスを構成し、外部 ID データを設定する

この時点で、「Active Directory Domain Services から FIM にユーザーを同期する方法」ガイドで説明されている手順に従って、システムを構成し、Active Directory のユーザーと同期する必要があります。グループ情報を同期する必要がある場合、そのプロセスの手順については、「Active Directory Domain Services から FIM にグループを同期する方法」ガイドを参照してください。

同期シーケンスとエクスポートシーケンス

パフォーマンスを最適化するには、同期の実行後にエクスポートを実行すると、コネクタスペースで多数の保留中のエクスポート操作が実行されます。次に、影響を受けるコネクタスペースに関連付けられている管理エージェントで、確認インポート実行を実行します。たとえば、初期データ読み込みの一環として複数の管理エージェントで同期実行プロファイルを実行する必要がある場合は、個々の同期の実行後にエクスポートを実行してから差分インポートを実行する必要があります。初期化サイクルの一部であるソース管理エージェントごとに、次の手順を実行します。

ソース管理エージェントでの完全インポート。
ソース管理エージェントでの完全同期。
段階的なエクスポート操作を使用して、影響を受けるすべてのターゲット管理エージェントでエクスポートします。
段階的なエクスポート操作を使用して、影響を受けるすべてのターゲット管理エージェントに対する差分インポート。

手順 4: MIM の完全な構成を適用する

初期データの読み込みが完了したら、デプロイに完全な MIM 構成を適用する必要があります。

シナリオによっては、この手順に追加のセット、MPR、ワークフローの作成が含まれる場合があります。システム内のすべての既存のオブジェクトにさかのぼって適用する必要があるポリシーについては、アクションワークフローの実行時ポリシー更新設定を使用して、読み込まれたデータにさかのぼってこれらのポリシーを適用します。

手順 5: SQL を以前の設定に再構成する

SQL 設定を通常の設定に変更することを忘れないでください。これらの変更には、次のものがあります。

フルテキスト検索を有効にする
組織のポリシーに従ってバックアップポリシーを更新する

最初のデータ読み込みが完了したら、フルテキスト検索をもう一度有効にする必要があります。次の SQL ステートメントを実行して、フルテキスト検索を再度有効にします。

ALTER FULLTEXT INDEX ON [fim].[ObjectValueString] SET CHANGE_TRACKING = AUTO

ALTER FULLTEXT INDEX ON [fim].[ObjectValueXml] SET CHANGE_TRACKING = AUTO

単純復旧モードに切り替える必要がある場合は、組織のバックアップポリシーに従ってバックアップスケジュールを再構成してください。 FIM バックアップスケジュールの詳細については、「FIM のバックアップと復元のガイド」を参照してください。

構成の移行

表示名の変更を避ける

MPR などの多くのオブジェクトの種類では、syncproduction.ps1 スクリプトは、表示名を 2 つのシステム間の唯一のアンカー属性として使用します。そのため、既存の MPR の表示名を変更すると、既存の MPR が削除され、新しい MPR が作成されます。この結果は、参加条件が変更された MPR に移行プロセスが正常に参加できないために発生します。この問題を回避するには、すべての構成オブジェクトの種類にカスタム属性をバインドし、その属性を結合条件として使用します。このプロセスを使用すると、移行プロセスに影響を与えずに表示名を変更できます。

中間ファイルの内容を変更しないようにする

低レベルオブジェクトのファイル形式とアプリケーションプログラミングインターフェイス (API) はパブリックであり、操作は開発者によってサポートされていますが、移行中に中間形式の内容を変更することはお勧めしません。ただし、changes.xml から ImportObject 全体を削除したり、pilot.xml に対して検索操作と置換操作を実行して、実稼働 DNS 情報のバージョン番号またはパイロットドメインネームシステム (DNS) 情報を置き換える必要がある場合があります。

バージョン間で移行する場合は、pilot.xml でバージョン番号が正しいことを確認します

バージョン番号間の移行は推奨またはサポートされていませんが、パイロットバージョン番号を pilot.xmlの実稼働バージョン番号に置き換えることで、この移行を行うことができます。具体的には、WorkflowDefinition と

ActivityInformationConfiguration オブジェクトでは、運用環境のワークフローアクティビティを正確に参照するためにバージョン番号が必要です。バージョン番号を置き換えられなかった場合、Compare-FIMConfig コマンドレットは WorkflowDefinitions の Extensible Object Markup Language (XOML) 属性とパイロットのバージョン番号の移行の違いを識別します。実稼働 FIM サービスは、正しくないバージョン番号でワークフローアクティビティを開始できない場合があります。

循環参照を回避する

一般に、MIM 構成では循環参照は推奨されません。ただし、セット A がセット B を参照し、セット B がセット A を参照する場合に、サイクルが発生することがあります。循環参照の問題を回避するには、セット A またはセット B の定義を変更して、両方が相互に参照しないようにする必要があります。次に、移行プロセスを再起動します。循環参照があり、Compare-FIMConfig コマンドレットの結果としてエラーが発生する場合は、手動でサイクルを中断する必要があります。 Compare-FIMConfig コマンドレットは優先順位の順に変更の一覧を出力するため、構成オブジェクトの参照間にサイクルが存在しない必要があります。

安全

MIM MA アカウント

MIM MA アカウントはサービスアカウントとは見なされず、通常のユーザーアカウントである必要があります。 FIM Synchronization Service サービスアカウントが偽装できるようにするには、アカウントがローカルでログオンできる必要があります。

MIM MA アカウントがローカルでログオンできるようにするには

[スタート] をクリックし、[管理ツール] をクリックし、[ローカルセキュリティポリシー] をクリックします。
[ローカルポリシー] ノードを開き、[ユーザー権利の割り当て] をクリックします。
[ローカルログオンを許可する] ポリシーで、FIM MA アカウントが明示的に指定されていることを確認するか、既にアクセス権が付与されているグループのいずれかに追加します。

FIM 同期サービスと FIM サービスアカウント

MIM サーバーコンポーネントを実行するサーバーをセキュリティで保護された方法で構成するには、サービスアカウントを制限する必要があります。前の手順を使用して MIM MA アカウントを有効にし、FIM 同期サービスアカウントと FIM サービスアカウントに次の制限を設定します。

バッチジョブとしてのログオンを拒否する
ローカルでのログオンを拒否する
ネットワークからのこのコンピューターへのアクセスを拒否する

サービスアカウントは、ローカル管理者グループのメンバーにすることはできません。

FIM 同期サービスサービスアカウントは、FIM 同期サービスへのアクセスを制御するために使用されるセキュリティグループのメンバーにすることはできません (FIMSync 以降のグループ (FIMSyncAdmins など)。

重要

両方のサービスアカウントで同じアカウントを使用するオプションを選択し、FIM サービスと FIM 同期サービスを分離する場合、mms Synchronization Service サーバー上のネットワークからこのコンピューターへのアクセスを拒否するを設定することはできません。 FIM サービスが FIM 同期サービスに接続して構成を変更し、パスワードを管理することを禁止するアクセスが拒否された場合。

キオスクのようなコンピューターに展開されたパスワードリセットでは、仮想メモリのページファイルをクリアするようにローカルセキュリティを設定する必要があります

キオスクを目的としたワークステーションに FIM パスワードリセットを展開する場合は、承認されていないユーザーがプロセスメモリからの機密情報を使用できないように、Shutdown: Clear virtual memory pagefile ローカルセキュリティポリシー設定をオンにすることをお勧めします。

FIM ポータルの SSL の実装

クライアントとサーバーの間のトラフィックをセキュリティで保護するには、FIM ポータルサーバーでセキュリティで保護されたソケットレイヤー (SSL) を使用することを強くお勧めします。

SSL を実装するには:

MIM ポータルサーバーで、IIS マネージャーを開きます。
ローカルコンピューター名をクリックします。
[サーバー証明書] をクリックします。
[証明書要求の作成] をクリックします。
[共通名] テキストボックスに、サーバーの名前を入力します。
[次へ] をクリックし、[次へ] をクリックします。
ファイルを任意の場所に保存します。この場所には、以降の手順でアクセスする必要があります。
https://servername/certsrv. に移動しますサーバー名を、証明書を発行するサーバーの名前に置き換えます。
[新しい証明書の要求] をクリックします。
[詳細要求の送信] をクリックします。
base-64 エンコードを使用して[証明書要求の送信]をクリックします。
前の手順で保存したファイルの内容を貼り付けます。
証明書テンプレートで、[Web サーバー] を選択します。
[送信] をクリックします。
証明書をデスクトップに保存します。
IIS マネージャーで、[認定要求の完了] をクリックします。
IIS マネージャーで、デスクトップに保存した証明書をポイントします。
[フレンドリ名] に、サーバーの名前を入力します。
[サイト] をクリックし、[SharePoint – 80] を選択します。
[バインド] をクリックし、[追加] をクリックします。
https を選択します。
証明書の場合は、サーバーと同じ名前の証明書 (先ほどインポートした証明書) を選択します。
[OK] をクリックします。
HTTP バインディングを削除します。
[SSL 設定] をクリックし、[SSL が必要] をオンにします。
設定を保存します。
[スタート] をクリックし、[管理ツール] をクリックし、[SharePoint 3.0 サーバーの全体管理] をクリックします。
[操作] をクリックし、[代替アクセスマッピング] をクリックします。
[https://servername.] をクリックします
https://servername を https://servernameに変更し、[OK] をクリックします。
[スタート] をクリックし、[実行] をクリックし、「iisreset」と入力して、[OK] をクリックします。

パフォーマンス

最適なパフォーマンス構成の場合:

このドキュメントの「SQL セットアップ」セクションの説明に従って、SQL セットアップのベストプラクティスを適用します。
MIM ポータルサイトで SharePoint インデックス作成を無効にします。詳細については、「SharePoint インデックス作成を無効にする」セクションを参照してください。

機能固有のベストプラクティス

要求管理

既定では、MIM 2016 は期限切れのシステムオブジェクトを消去します。これには、関連付けられた承認、承認応答、ワークフローインスタンスを含む完了した要求が 30 日間隔で含まれます。組織で要求履歴を長くする必要がある場合は、MIM から要求をエクスポートし、補助データベースに格納して、30 日間の期間を超えて保持する必要があります。 30 日間の要求削除ウィンドウは構成可能ですが、このウィンドウを拡張すると、システム内の追加オブジェクトが原因でパフォーマンスに悪影響を与える可能性があります。

管理ポリシールール

適切な MPR の種類を使用する

MIM には、要求と設定の切り替えという 2 種類の MPR が用意されています。

要求 MPR (RMPR)
- リソースに対する作成、読み取り、更新、または削除 (CRUD) 操作のアクセス制御ポリシー (認証、承認、およびアクション) を定義するために使用されます。
- MIM のターゲットリソースに対して CRUD 操作が発行されたときに適用されます。
- ルールで定義されている一致条件 (つまり、CRUD が規則の適用を要求する条件) によってスコープが設定されます。
遷移 MPR の設定 (TMPR)
- オブジェクトが遷移セットによって表される現在の状態に入った方法に関係なく、ポリシーを定義するために使用します。 TMPR を使用してエンタイトルメントポリシーをモデル化します。
- リソースが関連するセットに出入りするときに適用されます。
- セットのメンバーにスコープを設定します。

注

詳細については、「ビジネスポリシールールの設計を参照してください。

必要に応じて MPR のみを有効にする

構成を適用するときは、最小特権の原則を使用します。 MPR は、MIM デプロイへのアクセスポリシーを制御します。ほとんどのユーザーが使用する機能のみを有効にします。たとえば、すべてのユーザーがグループ管理に MIM を使用するわけではないため、関連付けられているグループ管理 MPR を無効にする必要があります。既定では、MIM には、ほとんどの管理者以外のアクセス許可が無効になっています。

直接変更するのではなく、組み込みの MPR を複製する

組み込みの MPR を変更する必要がある場合は、必要な構成で新しい MPR を作成し、組み込みの MPR をオフにする必要があります。この新しい MPR を作成すると、アップグレードプロセスによって導入される組み込み MPR に対する将来の変更が、システム構成に悪影響を与えないことを保証します。

エンドユーザーのアクセス許可では、ユーザーのビジネスニーズを対象とする明示的な属性リストを使用する必要がある

明示的な属性リストを使用すると、属性がオブジェクトに追加されるときに、特権のないユーザーに権限が誤って付与されるのを防ぐことができます。管理者は、アクセス権を削除するのではなく、新しい属性へのアクセス権を明示的に付与する必要があります。

データへのアクセスは、ユーザーのビジネスニーズにスコープを設定する必要があります。たとえば、グループメンバーは、メンバーであるグループのフィルター属性にアクセスすることはできません。フィルターによって、ユーザーが通常アクセスできない組織データが誤って表示される可能性があります。

MPR は、システム内の有効なアクセス許可を反映する必要があります

ユーザーが使用できない属性にアクセス許可を付与することは避けてください。たとえば、objectType などのコアリソース属性を変更するアクセス許可を付与しないでください。 MPR にもかかわらず、リソースの作成後にリソースの種類を変更しようとすると、システムによって拒否されます。

読み取りアクセス許可は、MPR で明示的な属性を使用する場合は、変更と作成のアクセス許可とは別にする必要があります

MPR で属性を明示的に一覧表示する場合、作成と変更に必要な属性は、通常、読み取りで使用できる属性とは異なります。たとえば、Creator や objectId などのシステム属性に対して読み取りを許可できますが、システム属性に対して作成または変更を指定することはできません。

ルールで明示的な属性を使用する場合、作成アクセス許可は [アクセス許可の変更] とは別にする必要があります

作成操作では、ユーザーが操作の一部として objectType を選択する必要があります。この属性は、作成操作の後に変更できないコアシステム属性です。

同じアクセス要件を持つすべての属性に対して 1 つの要求 MPR を使用する

変更が期待されない同じアクセス要件を持つ属性の場合、効率を高めるためにそれらを 1 つの要求 MPR に結合できます。

選択したプリンシパルグループに対しても無制限のアクセス権を付与しないようにする

MIM では、アクセス許可は肯定的なアサーションとして定義されます。 MIM は拒否アクセス許可をサポートしていないため、リソースへの無制限のアクセス権を付与すると、アクセス許可に除外を提供することが複雑になります。ベストプラクティスとして、必要なアクセス許可のみを付与します。

TMPR を使用してカスタムエンタイトルメントを定義する

RMPR の代わりに Set Transition MPR (TMPR) を使用して、カスタムエンタイトルメントを定義します。 TMPR は、定義された遷移セットまたはロールのメンバーシップ、および付随するワークフローアクティビティに基づいてエンタイトルメントを割り当てたり削除したりする状態ベースのモデルを提供します。 TMPR は、常にペアで定義する必要があります。1 つは移行中のリソース用、1 つはリソースが切り替わる場合です。さらに、各移行 MPR には、プロビジョニングおよびプロビジョニング解除アクティビティ用の個別のワークフローが含まれている必要があります。

注

プロビジョニング解除ワークフローでは、ポリシー更新時の実行属性が true に設定されていることを確認する必要があります。

最後に MPR で切り替えの設定を有効にする

TMPR ペアを作成する場合は、[MPR で切り替えを最後に設定] をオンにします。この順序により、イン MPR がオンになっている間に、OUT MPR が有効になる前にリソースがセットに追加されたり、セットから削除されたりした場合、そのリソースがエンタイトルメントに残らないようにします。

TMPR のワークフローでは、最初にターゲットリソースの状態を確認する必要があります

プロビジョニングワークフローでは、まず、権利に従ってターゲットリソースが既にプロビジョニングされているかどうかを確認する必要があります。もしあれば、それは何もするべきではありません。

プロビジョニング解除ワークフローでは、まず、ターゲットリソースがプロビジョニングされているかどうかを確認する必要があります。存在する場合は、ターゲットリソースのプロビジョニングを解除する必要があります。それ以外の場合は、何も行う必要はありません。

TMPR の [ポリシー更新時に実行] を選択する

この設定により、ポリシーの更新が実装されるときに正しいプロビジョニング動作が適用され、TMPR に関連付けられているアクションワークフローで RunOn ポリシー更新フラグが使用され、ポリシー定義の変更によってアクションワークフローが移行セットの新しいメンバーに適用されるようになります。

同じ権利を 2 つの異なる移行セットに関連付けないようにする

同じ権利を 2 つの異なる移行セットに関連付けることにより、リソースが一方のセットから別のセットに移動した場合、エンタイトルメントの不要な取り消しと再付与が発生する可能性があります。ベストプラクティスとして、関連付けられているエンタイトルメントを必要とするすべてのリソースが 1 つのセットに含まれていることを確認します。この手順により、移行セットとワークフローを許可するエンタイトルメントの間に 1 対 1 のリレーションシップが確保されます。

システム内の権利を削除するときに適切な一連の操作を使用する

システムの権利を削除するときに実行される手順の順序によって、2 つの異なる運用結果が得られます。目的の効果に適用される順序を理解していることを確認します。

エンタイトルメントをシステムから削除する (および現在エンタイトルメントを保持しているすべてのメンバーから権利を取り消すには):

T-In MPR を無効にします。この変更により、新しい許可が回避されます。
T-Set フィルターを削除するか、セットが空になるように変更します。これにより、既存のすべてのメンバーが移行され、資格に関連付けられている構成済みのプロビジョニング解除ワークフローを含む、移行アウトポリシーが適用されます。
T-Out MPR を無効にします。

エンタイトルメントを削除し、現在のメンバーだけを残すには (たとえば、MIM を使用して権利を管理するのをやめる)。

T-In MPR を無効にします。この変更により、新しい許可が回避されます。
T-Out MPR を無効にします。
T-Set フィルターを削除するか、セットが空になるように変更します。セットは TMPR に関連付けられなくなったため、プロビジョニング解除ワークフローは適用されません。

設定

セットのベストプラクティスを適用する場合は、最適化が管理容易性と将来の管理の容易さに与える影響を考慮する必要があります。これらの推奨事項を適用する前に、予想される運用スケールでの適切なテストを実行して、パフォーマンスと管理容易性の適切なバランスを特定する必要があります。

注

次のガイドラインはすべて、動的セットと動的グループに適用されます。

動的な入れ子の使用を最小限に抑える

これは、別のセットの ComputedMember 属性を参照するセットのフィルターを参照します。セットを入れ子にする一般的な理由は、多数のセット間でメンバーシップ条件が重複しないようにするためです。このアプローチにより、セットの管理性が向上する可能性がありますが、パフォーマンスのトレードオフがあります。セット自体を入れ子にするのではなく、入れ子になったセットのメンバーシップ条件を複製することで、パフォーマンスを最適化できます。

機能要件を満たすためにセットの入れ子を回避できない場合があります。これらは、セットを入れ子にする必要がある主な状況です。たとえば、従業員の所有者 Full-Time いないすべてのグループのセットを定義するには、セットの入れ子を次のように使用する必要があります。 /Group[not(Owner = /Set[ObjectID = ‘X’]/ComputedMember]。ここで、'X' は、すべてのフルタイム従業員のセットの ObjectID です。

負の条件の使用を最小限に抑える

負の条件は、次の演算子または関数を使用するメンバーシップ条件です。!=、not()、\<、\<=。パフォーマンスを最適化するには、可能な限り、負の条件としてではなく、複数の肯定的な条件で必要な条件を表します。

複数値の参照属性に基づいてメンバーシップ条件の使用を最小限に抑える

これらのセットの数が多い場合は、メンバーシップ条件で使用される属性に対する操作のパフォーマンスに影響を与える可能性があるため、複数値の参照属性に基づく条件の使用を最小限に抑える必要があります。

"パスワードのリセット"

パスワードリセットに使用されるキオスクのようなコンピューターでは、仮想メモリのページファイルをクリアするためにローカルセキュリティを設定する必要があります

キオスクを目的としたワークステーションに MIM パスワードリセットを展開する場合は、プロセスメモリからの機密情報を承認されていないユーザーが使用できないように、Shutdown: Clear virtual memory pagefile ローカルセキュリティポリシー設定をオンにすることをお勧めします。

ユーザーは、ログオンしているコンピューターでパスワードリセットに常に登録する必要があります

ユーザーが Web ポータルを使用してパスワードリセットの登録を試みると、MIM は、Web サイトにログオンしているユーザーに関係なく、ログオンしているユーザーに代わって常に登録を開始します。ユーザーは、ログオンしているコンピューターでパスワードのリセットに常に登録する必要があります。

AvoidPdcOnWan レジストリキーを true に設定しないでください

MIM 2016 パスワードリセットを使用する場合は、AvoidPdcOnWan レジストリキーを true に設定しないでください。

このレジストリキーが true に設定されている場合、ユーザーはパスワードゲートを通過し、プライマリドメインコントローラー (PDC) でパスワードのリセットを行い、ログオンを試みます。このレジストリキーのため、ローカルドメインコントローラーは PDC でセカンダリ検証を実行しないため、ログオン要求を拒否します。ユーザーが十分な時間拒否された場合は、ドメインからロックアウトされる可能性があり、サポートに電話する必要があります。

クリアテキストパスワードのログ記録を有効にしない

Windows で診断サービスレベルのトレースを有効にすると、クリアテキストパスワードをログに記録できます

Communication Foundation (WCF)。このオプションは既定ではオンになりません。運用環境ではオンにすることはお勧めしません。これらのパスワードは、ユーザーがパスワードリセットに登録するときに、暗号化された簡易オブジェクトアクセスプロトコル (SOAP) メッセージ内でクリアテキスト要素として表示されます。詳細については、「メッセージログの構成」を参照してください。

承認ワークフローをパスワードリセットプロセスにマップしない

パスワードリセット操作に承認ワークフローをアタッチしないでください。パスワードのリセットには、承認アクティビティが非同期であるなどのアクティビティを含む同期応答と承認ワークフローが必要です。

複数のアクションアクティビティをパスワードリセットにマップしない

パスワードリセット操作には、複数のアクションアクティビティを含むワークフローをアタッチしないでください。シナリオの例としては、2 つ目の AD DS パスワードリセットアクティビティをパスワードリセット MPR にアタッチします。このシナリオはサポートされません。

既存のワークフローでのアクティビティの追加、削除、または順序の変更時に再登録を要求する

既存のワークフローで認証アクティビティの追加、削除、または順序の変更を行う場合は、常に再登録を必要とするオプションを選択してください。アクティビティがワークフローに追加または削除された後、再登録する前に、パスワードリセットの認証を試みるユーザーは、望ましくない影響を受ける可能性があります。

ポータルの構成とリソースコントロールの表示の構成

ユーザープロファイルページにプライバシーに関する免責事項を追加することを検討する

MIM では、既定では、一部のユーザープロファイル情報が他のユーザーに表示される場合があります。管理者は、ユーザーへの提供として、会社のポリシーと一致するカスタムテキストを [ユーザープロファイル] ページに追加することを検討する必要があります。 MIM ポータルページへのカスタムテキストの追加の詳細については、「FIM ポータルのの構成とカスタマイズの概要」を参照してください。

スキーマ

個人またはグループのリソースの種類を削除しない

ユーザーとグループのリソースの種類はコアリソースの種類としてマークされていませんが、リソース自体またはそれらに割り当てられた属性は削除しないでください。 MIM ポータルのユーザーインターフェイス (UI) には、ユーザーとグループのリソースの種類とその属性が存在する必要があります。

コア属性を変更しない

すべてのリソースの種類に 13 個のコア属性が割り当てられます。リソースの種類に対するリレーションシップを何らかの方法で変更しないでください。 13 コア属性は次のとおりです。

CreatedTime
造物主
削除時間
説明
DetectedRulesList • DisplayName
ExpectedRulesList
有効期限
ロケール
MVObjectID
ObjectID
ObjectType
ResourceTime

監査要件に依存するスキーマリソースを削除しないでください

これらのリソースの監査要件がある場合は、スキーマリソースを削除しないでください。

正規表現の大文字と小文字を区別しない

MIM では、一部の正規表現で大文字と小文字を区別しないようにすると便利です。 ?!:を使用すると、グループ内の大文字と小文字を無視できます。たとえば、従業員の種類の場合は、

\^(?!:contractor\|full time employee)%.

メンバー属性の計算

同期エンジンに公開されている Member 属性は、実際には ComputedMembers にマップされます。これは、条件ベースのメンバーと手動で選択されたメンバーの組み合わせです。 3 つの属性 (Filter、ExplicitMembers、ComputedMembers) をすべて追加しても、メンバー属性の動的計算は、グループとセット以外のリソースの種類では行われません。

文字列内の先頭と末尾のスペースは無視されます

MIM では、先頭と末尾にスペースを含む文字列を入力できますが、MIM システムはこれらのスペースを無視します。先頭と末尾のスペースを含む文字列を送信すると、同期エンジンと Web サービスはこれらのスペースを無視します。

空の文字列が null と等しくない

MIM のこのリリースでは、空の文字列が null と等しくありません。空の文字列入力は有効な値と見なされます。存在しない場合は null と見なされます。

ワークフローと要求処理

MIM 2016 に付属している既定のワークフローは削除しないでください

次のワークフローは MIM に付属しており、削除しないでください。

有効期限のワークフロー
管理者向けのフィルター検証ワークフロー
管理者以外のフィルター検証ワークフロー
グループの有効期限通知ワークフロー
グループ検証ワークフロー
所有者承認ワークフロー
パスワードリセットアクションワークフロー
パスワードリセット認証ワークフロー
所有者承認を使用した要求者の検証
所有者承認なしの要求者の検証
登録に必要なシステムワークフロー

2 つ以上の ApprovalActivities を並列で実行しない

2 つ以上の ApprovalActivities を並列で実行しないでください。これを行うと、要求が承認フェーズで停止する可能性があります。複数の承認の場合は、承認に承認者の一覧を大きく含めるか、2 つのアクティビティを連続して並べて表示します。

承認アクティビティで MIM リソースデータを変更しないでください

承認ワークフローのワークフローの一部として、関数エバリュエーターアクティビティなどの MIM リソースを変更するアクティビティは使用しないでください。処理の承認ポイントで要求がコミットされていないため、要求が拒否される可能性があるにもかかわらず、ID 情報に対して実行されたすべての変更を適用できます。

FIM サービスパーティションについて

MIM の目的は、構成されたビジネスポリシーに従って、FIM 同期サービスやセルフサービスコンポーネントなど、さまざまな MIM クライアントによって開始できる要求を処理することです。設計上、各 FIM サービスインスタンスは、FIM サービスパーティションとも呼ばれる 1 つ以上の FIM サービスインスタンスで構成される論理グループに属します。すべての要求を処理するためにデプロイされた FIM サービスインスタンスが 1 つしかない場合は、待機時間の処理が発生する可能性があります。一部の操作は、セルフサービス操作に適した既定のタイムアウト値を超える場合もあります。 FIM サービスパーティションは、この問題に対処するのに役立ちます。

詳細については、「FIM サービスパーティションについて」を参照してください。