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

[アーティクル]
09/14/2023

このトピックでは、Microsoft Identity Manager 2016 (MIM) を展開および運用するためのベストプラクティスを説明します。

SQL の設定

注意

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

システムの最適なパフォーマンスには、SQL (構造化照会言語) サーバーの構成が重要です。大規模な実装での MIM のパフォーマンスの最適化は、SQL を実行するサーバーにベストプラクティスを適用できるかによります。詳細については、次の SQL のベストプラクティスについてのトピックを参照してください。

データファイルおよびログファイルのサイズを事前設定する

自動拡張には依存しないでください。代わりに、これらのファイルの拡張は手動で行ってください。自動拡張は安全のためにオンのままにできますが、データファイルの増加には、ユーザーが先を見越した管理を行う必要があります。 MIM データベースのサンプルサイズについては、「FIM Capacity Planning Guide」 (FIM 容量計画ガイド) を参照してください。

SQL のデータファイルおよびログファイルのサイズを事前設定するには

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

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

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

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

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

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

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

ログファイルに十分な容量を確保する

復旧モデルのディスク要件を理解しておくことが重要です。システムの初期ロード時、ディスク領域の使用を制限するには、単純な復旧モードを使用するのが適切ですが、これでは最後のバックアップ以降に作成されたデータが失われる可能性があります。完全復旧モードを使用する場合は、ディスク領域の使用率が高くなるのを防ぐために、トランザクションログの頻繁なバックアップを含むバックアップを使用してディスク使用量を管理する必要があります。詳細については、「Recovery Model Overview」 (復旧モデルの概要) を参照してください。

SQL Server のメモリを制限する

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

この例では、SQL サーバーを再構成して、メモリの使用を 12 GB 未満にします。

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

USE master

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

USE master

EXEC sp_configure 'show advanced options', 0

RECONFIGURE WITH OVERRIDE

バックアップおよび復旧を構成する

一般的に、バックアップと復旧の計画を策定するには、データベース管理者と連携する必要があります。以下のような点が推奨されます。

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

詳細については、「Recovery Model Overview」 (復旧モデルの概要) と「FIM 2010 Backup and Restore Guide」 (FIM 2010 のバックアップおよび復旧ガイド) を参照してください。

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

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

FIM サービス

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

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

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

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

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

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

サイズが 1 MB より大きいメールを拒否するように、サービスアカウントを構成します。メールボックスまたはメールが有効なパブリックフォルダーに、メッセージサイズの制限を構成する場合のベストプラクティスに従います。
メールボックスの記憶域のクォータが 5 GB となるようにサービスアカウントを構成します。最適な結果を得るには、「Configure Storage Quotas for a Mailbox」 (メールボックスの記憶域のクォータの構成) に記載されているベストプラクティスに従います。

MIM ポータル

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

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

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

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

重要

これらの手順を組み込まないと、ディスク領域が大量に使用されてしまい、領域がなくなる場合があります。このトピックの詳細については、「Recovery Model Overview」 (復旧モデルの概要) を参照してください。「The FIM Backup and Restore Guide」 (FIM のバックアップと復元のガイド) にも追加の情報があります。

手順 2: ロード時に MIM を必要最小限に構成する

初期ロード時には、FIM には管理ポリシー規則やセット定義に必要最小限の構成のみを行います。データのロードが完了したら、展開に必要な追加のセットを作成します。アクションワークフローで [ポリシー更新時に実行] 設定を使用し、それらのポリシーをロードされたデータにさかのぼって適用できます。

手順 3: 外部 ID データを使用して FIM サービスを構成および入力する

この時点で、「ユーザーを Active Directory Domain Services から FIM に同期する方法」ガイドで説明されている手順に従って、Active Directory のユーザーとシステムを構成して同期する必要があります。グループ情報を同期する必要がある場合は、そのプロセスの手順について、「How Do I Synchronize Groups from Active Directory Domain Services to FIM (グループを 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 Backup and Restore Guide」 (FIM バックアップと復元のガイド) を参照してください。

構成を移行する

表示名は変更しないようにする

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

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

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

異なるバージョン間で移行を行うときバージョン番号が pilot.xml で正しいことを確認する

バージョン番号間の移行は推奨もサポートもされていませんが、パイロットバージョン番号を pilot.xml の運用バージョン番号に置き換えることで、多くの場合、この移行を行うことができます。特に WorkflowDefinition と

ActivityInformationConfiguration のオブジェクトは、実稼働環境のワークフローアクティビティを正確に参照するためにバージョン番号を必要とします。バージョン番号を置き換えないと、Compare-FIMConfig コマンドレットにより WorkflowDefinitions の拡張可能なオブジェクトのマークアップ言語 (XOML) 属性間に違いがあることが識別され、パイロットのバージョン番号が移行されます。バージョン番号が不正な場合、実稼働環境の FIM サービスがワークフローアクティビティを開始できない場合があります。

循環参照を回避する

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

セキュリティ

MIM MA アカウント

MIM MA アカウントは、サービスアカウントとは見なされておらず、通常のユーザーアカウントである必要があります。このアカウントは、FIM 同期サービスのサービスアカウントが権限を借用できるようにローカルにログオンできる必要があります。

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

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

FIM 同期サービスおよび FIM サービスアカウント

安全な方法で MIM サーバーコンポーネントを実行しているサーバーを構成するには、サービスアカウントを制限する必要があります。 MIM MA アカウントを有効にする前の手順を使用して、FIM 同期サービスおよび FIM サービスアカウントに、次の制限を設定します。

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

サービスアカウントは、ローカルの Administrators グループのメンバーではないようにする必要があります。

FIM 同期サービスのサービスアカウントは、FIM 同期サービス (FIMSyncAdmins など FIMSync で始まるグループ) へのアクセスを制御するために使用するセキュリティグループのメンバーではないようにする必要があります。

重要

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

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

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

FIM ポータル用に SSL を実装する

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

SSL を実装するには:

MIM ポータルサーバーで IIS マネージャーを開きます。
ローカルコンピューター名をクリックします。
[サーバー証明書] をクリックします。
[証明書の要求の作成] をクリックします。
[共通名] テキストボックスに、サーバー名を入力します。
[次へ]、[次へ] を順にクリックします。
ファイルを任意の場所に保存します。この場所へは、以降の手順でアクセスする必要があります。
https://servername/certsrv. に移動しますサーバー名を、証明書を発行するサーバー名に置き換えます。
[Request a new Certificate (新しい証明書の要求)] をクリックします。
[Submit an Advanced Request (事前要求の送信)] をクリックします。
Base 64 エンコードを使用して [Submit a Certificate Request (証明書の要求の送信)] をクリックします。
前の手順で保存したファイルの内容を貼り付けます。
[証明書のテンプレート] で、[Web サーバー] を選択します。
[Submit] をクリックします。
証明書をデスクトップに保存します。
IIS マネージャーで [Complete Certification Request (証明書の要求の完了)] をクリックします。
IIS マネージャーをデスクトップに保存した証明書をポイントします。
[フレンドリ名] にはサーバー名を入力します。
[サイト] をクリックし [SharePoint – 80] を選択します。
[バインド]、[追加] を順にクリックします。
[HTTPS] を選択します。
[証明書] で、サーバーと同じ名前の証明書 (インポートした証明書) を選択します。
[OK] をクリックします。
HTTP バインディングを削除します。
[SSL 設定] をクリックし、[Require 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 には、Request と Set Transition の 2 種類の MPR が用意されています。

Request MPR (RMPR)
- リソースに対する作成、読み取り、更新、または削除 (CRUD) 操作のアクセス制御ポリシー (認証、承認、およびアクション) を定義するために使用されます。
- MIM のターゲットリソースに対して CRUD 操作が発行されたときに適用されます。
- 範囲は、CRUD が要求した規則に該当する、規則で定義されている一致する基準に限定されています。
Set Transition MPR (TMPR)
- オブジェクトがどのように遷移の設定が表す現在の状態になったかにかかわらず、ポリシーの定義に使用されます。 TMPR は権利ポリシーのモデル化に使用します。
- リソースが関連付けられたセットを入力または退出するときに適用されます。
- そのセットのメンバーに範囲は限定されています。

注意

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

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

構成を適用する場合、アクセス許可は最小限のみ適用するという原則に従ってください。 MPR は MIM の展開のアクセスポリシーを制御します。多くのユーザーが使用する機能のみを有効にします。たとえば、すべてのユーザーが MIM をグループ管理に使用するとは限らないので、関連付けられているグループ管理の MPR は無効にする必要があります。既定で MIM は、管理者以外の多くのアクセス許可が無効になって出荷されます。

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

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

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

明示的な属性のリストを使用すると、属性がオブジェクトに追加されるとき、アクセス許可のないユーザーに偶発的に権限を割り当ててしまうのを防ぎます。管理者は、アクセスを削除しようとするのではなく、新しい属性に明示的にアクセスを付与する必要があります。

データへのアクセスは、ユーザーのビジネスニーズの範囲にする必要があります。たとえば、グループのメンバーには、メンバーであるグループのフィルター属性へのアクセスは必要ありません。フィルターにより、ユーザーが通常はアクセスできない組織のデータが、意図せず公開されてしまうことがあります。

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

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

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

MPR で明示的に属性を指定する場合、作成および変更に必要な属性は、読み取りに使用できるものとは通常は異なります。たとえば、作成または変更はシステム属性には指定できないのに対し、読み取りは Creator または objectId などのシステム属性に付与できます。

規則で明示的な属性を使用するとき、作成のアクセス許可は変更のアクセス権とは別にする必要がある

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

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

変更される可能性のない同じアクセス要件を持つ属性は、効率化のために 1 つの要求 MPR に結合することができます。

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

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

カスタムの権利の定義に TMPR を使用する

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

注意

すべてのプロビジョニング解除のワークフローでは、[ポリシー更新時に実行] 属性を True に設定する必要があります。

Set Transition In MPR は最後に有効にする

TMPR のペアを作成する場合、Set Transition In MPR は最後にオンにします。この順序によって、Out MPR をオンにする前に、In MPR がオンになっているとき、リソースがセットに追加され削除される場合、それが権利に残されることがないことが保証されます。

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

プロビジョニングのワークフローでは、ターゲットリソースが権利に従って既にプロビジョニングされているかを最初に確認する必要があります。そのような場合、何も実行されないはずです。

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

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

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

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

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

システムで権利を削除するとき、正しい順序で行う

システムで権利を削除するときに使用する手順の順序によって、操作の結果が 2 とおりになる場合があります。希望する影響がどちらの順序であるか理解しておいてください。

システムから権利を削除するには (そしてその権利を現在保持しているすべてのメンバーから取り消すには):

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

権利は削除するが、現在のメンバーをそのままにする場合 (たとえば、権利の管理に MIM を使用するのをやめる):

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

セット

セットのベストプラクティスを適用する場合、管理容易性と今後の管理のしやすさから最適化が与える影響を考慮する必要があります。これらの推奨事項を適用する前に、予想される稼働環境の規模で適切なテスティングを行い、パフォーマンスと管理容易性のバランスを判断する必要があります。

注意

以下のすべてのガイドラインは動的なセットと動的なグループに該当します。

動的なネストの使用を最低限にする

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

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

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

否定条件とは、!=、not()、\<、\<= などの演算子や関数を使用するメンバーシップ条件です。可能な場合、パフォーマンスを最適化するには、否定条件ではなく、複数の肯定的な条件を使用して希望の条件を表現します。

複数の値を持つ参照属性を使用してメンバーシップ条件の使用を最小限にする

複数の値がある参照属性を使用して条件を使用することは最小限にする必要があります。このようなセットが多数ある場合、メンバーシップ条件で使用される属性の操作上のパフォーマンスに影響する可能性があります。

パスワードのリセット

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

キオスクを想定したワークステーションに MIM パスワードのリセットを展開するとき、シャットダウン:クリア仮想メモリページファイルローカルセキュリティポリシー設定をオンにし、未承認のユーザーがプロセスメモリの機密情報を使用できないようにすることを推奨します。

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

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

AvoidPdcOnWan レジストリキーは True に設定しない

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

レジストリキーを true に設定した場合、ユーザーはパスワードゲートを経て、プライマリドメインコントローラー (PDC) でパスワードをリセットして、ログオンしようとすることになります。このレジストリキーのため、ローカルのドメインコントローラーは PDC で二次認証を行わず、ログオン要求を拒否します。何度も拒否されると、ユーザーはドメインからロックアウトされ、サポートに連絡しなければならなくなります。

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

サービスレベルの診断トレースを Windows

Communication Foundation (WCF) でオンにするとき、クリアテキストのパスワードを記録できます。このオプションは既定では無効になっており、実稼働環境では有効にすることは推奨されません。これらのパスワードは、ユーザーがパスワードのリセットを登録するときに、暗号化された Simple Object Access Protocol (SOAP) メッセージで、クリアテキストの要素として表示されます。詳細については、「メッセージログの構成」を参照してください。

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

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

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

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

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

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

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

ユーザーのプロファイルページにプライバシーに関する免責事項を追加することを検討してください。

MIM では、既定で一部のユーザープロファイル情報が他のユーザーに表示される場合があります。管理者は、ユーザーへの礼儀として、ユーザープロファイルのページに企業のポリシーと一致するカスタムテキストを追加することを検討してください。 MIM のポータルページにカスタムテキストを追加する方法の詳細については、「Configuring and Customizing the FIM Portal」 (FIM ポータルの構成およびカスタマイズ) を参照してください。

スキーマ

Person または Group の種類のリソースは削除しない

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

Core 属性は変更しない

すべてのリソースの種類には 13 の Core 属性が割り当てられています。いかなる種類のリソースへも関係は変更しないでください。 13 の Core 属性は次のとおりです。

CreatedTime
Creator
DeletedTime
説明
DetectedRulesList • DisplayName
ExpectedRulesList
ExpirationTime
Locale
MVObjectID
ObjectID
ObjectType
ResourceTime

監査要件への依存関係を持つスキーマリソースを削除しない

そのリソースの監査要件がまだある場合、そのスキーマリソースは削除しないようにする必要があります。

正規表現の大文字小文字を区別する

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

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

メンバー属性の計算

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

文字列の先頭と末尾の空白は無視される

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

空の文字列は Null と同じではない

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

ワークフローおよび要求の処理

MIM 2016 に同梱されている既定のワークフローは削除しない

MIM では次のワークフローが同梱されており、削除されるべきではありません。

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

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

2 つ以上の ApprovalActivities は並列に実行しないようにする必要があります。実行すると、承認のフェーズで要求が動かなくなってしまう可能性があります。複数の承認には、より多数の承認者を承認に含めるか、2 つのアクティビティを連続して並べます。

承認アクティビティでは MIM リソースデータは変更されない

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

FIM サービスパーティションを理解する

MIM の目的は、さまざまな MIM クライアントで開始される、FIM 同期サービスや構成済みのビジネスポリシーに応じたセルフサービスコンポーネントなどの要求を処理することです。仕様により、各 FIM サービスインスタンスは、FIM サービスのパーティションとも呼ばれる、1 つ以上の FIM サービスインスタンスで構成されている論理グループに属します。すべての要求の処理に FIM サービスを 1 つのみ使用している場合、処理の遅延が発生する可能性があります。一部の処理はセルフサービスの操作に適した既定のタイムアウト値を超過する場合があります。この問題を解決するには、FIM サービスのパーティションが助けとなる場合があります。

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

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