NetIQ Directory and Resource Administrator管理者ガイド

3.3.1 DRA管理サーバ

3.3.2 DRA RESTサーバ

3.3.3 Webコンソール(IIS)

3.3.4 DRA Delegation and Administrationコンソール

3.3.5 ワークフローサーバ

3.5.1 ソフトウェアの必要条件

3.5.2 サーバドメイン

3.5.3 アカウント要件

3.5.4 最小特権DRAアクセスアカウント

ここには、各アカウントに必要な権限と特権、および実行する必要がある構成コマンドを記載します。

ドメインアクセスアカウントに、このオブジェクトおよびすべての子孫オブジェクトに対して、トップドメインレベルで次のActive Directory権限を付与します。

Azureアプリケーション: Azureアプリケーションには、次の役割とアクセス許可が必要です。

Azureテナントアクセスアカウント: Azureテナントアクセスアカウントには、次のアクセス許可が必要です。

Network access: Restrict clients allowed to make remote calls to SAM (ネットワークアクセス: SAMへのリモートコールを行うことができるクライアントを制限する)

この設定にアクセスするには、次の手順に従います。

詳細については、「Knowledge Base Article 7023292」を参照してください。

3.6.1 ソフトウェアの必要条件

4.1.1 対話型インストールのチェックリスト:

5.2.1 前バージョンのDRAを実行する専用ローカル管理サーバの使用

アップグレードの最中に、１つ以上のセカンダリ管理サーバをローカルで前バージョンのDRAを実行する専用のサーバとして使用すれば、ダウンタイムとリモートサイトへのコストのかかる接続を最小限に抑えることができます。この手順はオプションですが、これによってアシスタント管理者は、展開が完了するまでの間アップグレードプロセス全体を通じて、前バージョンのDRAを使用できるようになります。

以下のアップグレード要件のうち１つ以上があてはまる場合は、このオプションの使用を考慮してください。

新規のセカンダリ管理サーバをインストールすることも、前バージョンのDRAを実行している既存のセカンダリサーバを指定することもできます。このサーバをアップグレードする場合は、このサーバを最後にアップグレードしなければなりません。アップグレードしない場合は、アップグレードが正常に完了した後で、このサーバから完全にDRAをアンインストールします。

5.2.2 前バージョンのDRAサーバセットの同期

前バージョンのDRAのレジストリをバックアップする前、つまりアップグレードプロセスを開始する前に、サーバセットの同期をとって各管理サーバの設定およびセキュリティ設定を最新の状態にする必要があります。

5.2.3 管理サーバのレジストリのバックアップ

管理サーバのレジストリをバックアップすれば、確実に以前の構成に戻すことができます。たとえば、現バージョンのDRAを完全にアンインストールして前バージョンのDRAを使用しなければならなくなった場合、前のレジストリ設定のバックアップがあれば、前の構成とセキュリティ設定を簡単に復旧できます。

ただし、レジストリの編集には注意が必要です。レジストリ内にエラーがあると、管理サーバが予期したとおりに動作しない場合があります。アップグレードプロセス中にエラーが発生した場合は、レジストリ設定のバックアップを使用して、レジストリを復元できます。詳細については、『レジストリエディタのヘルプ』を参照してください。

5.3.1 プライマリ管理サーバのアップグレード

MMSの準備が整ったら、プライマリ管理サーバをアップグレードします。プライマリ管理サーバのアップグレードが完了するまでは、クライアントコンピュータ上のユーザインタフェースをアップグレードしないでください。詳細については、「DRAユーザインタフェースの展開」を参照してください。

アップグレードを始める前に、アップグレードの開始時期をアシスタント管理者に通知してください。セカンダリ管理サーバを前バージョンのDRAを実行するための専用サーバにした場合は、アシスタント管理者がアップグレード中に前バージョンのDRAを使い続けられるようにするために、そのサーバのことも知らせてください。

5.3.2 現バージョンのDRAのローカルセカンダリ管理サーバのインストール

ローカルサイトで現バージョンのDRAを実行する新規のセカンダリ管理サーバをインストールすれば、コストのかかるリモートサイトへの接続を最小限に抑えるとともに全体的なダウンタイムを短縮することができ、ユーザインタフェースの展開をより迅速に進められます。この手順はオプションですが、これによってアシスタント管理者は、展開が完了するまでの間アップグレードプロセス全体を通じて、現行バージョンと前バージョンの両方のDRAを使用できるようになります。

以下のアップグレード要件のうち１つ以上があてはまる場合は、このオプションの使用を考慮してください。

たとえば、ロンドンサイトにあるプライマリ管理サーバと東京サイトにあるセカンダリ管理サーバでMMSが設定されている場合は、東京サイトにセカンダリサーバをインストールして対応するMMSに追加するのが得策です。この追加されたサーバは東京での日常的な管理負荷のバランスをとり、アップグレードが完了するまでの間、どちらのサイトのアシスタント管理者も前バージョンのDRAと現バージョンのDRAの両方を使用できるようになります。さらに、現在のDRAのユーザインタフェースを即座に展開できるので、アシスタント管理者がダウンタイムを経験することもありません。ユーザインタフェースのアップグレードの詳細については、「DRAユーザインタフェースの展開」を参照してください。

5.3.3 DRAユーザインタフェースの展開

通常は、プライマリ管理サーバと１つのセカンダリ管理サーバをアップグレードした後で、現在のDRAのユーザインタフェースを展開しなければなりません。ただし、プライマリ管理サーバを使用する必要があるアシスタント管理者のクライアントコンピュータは、Delegation and Configuration console (委任および環境設定コンソール)をインストールして最初にアップグレードしてください。詳細については、「DRAアップグレードの計画」を参照してください。

CLI、ADSIプロバイダ、PowerShellを通じて頻繁にバッチ処理を実行する場合や、頻繁にレポートを生成する場合は、これらのユーザインタフェースを専用のセカンダリ管理サーバにインストールすることを考慮してください。それにより、MMS全体の負荷バランスが適切に保たれます。

DRAユーザインタフェースのインストールをアシスタント管理者に任せることも、グループポリシーを通じてこれらのインタフェースを展開することもできます。また、Webコンソールを複数のアシスタント管理者に簡単かつ迅速に配備できます。

5.3.4 セカンダリ管理サーバのアップグレード

セカンダリ管理サーバのアップグレードでは、管理上のニーズに合わせて各サーバを必要に応じてアップグレードできます。また、DRAユーザインタフェースのアップグレードと展開の計画についても検討してください。詳細については、「DRAユーザインタフェースの展開」を参照してください。

たとえば、典型的なアップグレードパスには、次の手順が含まれます。

アップグレードを始める前に、アップグレードの開始時期をアシスタント管理者に通知してください。セカンダリ管理サーバを前バージョンのDRAを実行するための専用サーバにした場合は、アシスタント管理者がアップグレード中に前バージョンのDRAを使い続けられるようにするために、そのサーバのことも知らせてください。このMMSのアップグレードが完了し、すべてのアシスタント管理者クライアントコンピュータがアップグレード済みのユーザインタフェースを実行するようになったら、残っている前バージョンのサーバをオフラインにしてください。

5.3.5 Webコンソール環境設定の更新 - インストール後

DRA環境に適用可能な場合は、アップグレードのインストール後に、以下のアクションのいずれかまたは両方を実行します。

<restService useDefault="Never">
<serviceLocation address="<REST server name>" port="8755"/>
</restService>

6.3.1 例1: ユーザのパスワード変更

アシスタント管理者がJSmithさんのユーザアカウントに新しいパスワードを設定しようとすると、管理サーバは 「JSmith」を含むActiveViewをすべて見つけます。この検索は、ワイルドカードルールまたはグループメンバーシップを通じて直接JSmithさんを指定するActiveViewを探します。あるActiveViewが他のActiveViewを含んでいる場合、管理サーバはこれらのActiveViewも追加で検索対象にしてください。これらのActiveViewのいずれかでそのアシスタント管理者がReset User Account Passwordという権限を持っているかどうかを管理サーバが判断します。アシスタント管理者がReset User Account Passwordという権限を持っている場合、管理サーバはJSmithさんのパスワードをリセットします。この権限がない場合、管理サーバが要求を拒否します。

6.3.2 例2: ActiveViewの重ね合わせ

権限は、管理対象ドメインまたはサブツリー内でアシスタント管理者が表示、変更、または作成できるオブジェクトプロパティを定義します。2つ以上のActiveViewが同じオブジェクトを含めることができます。この設定を「ActiveViewの重ね合わせ」と呼びます。

ActiveViewが重なり合うと、同じオブジェクトに対して異なる一連の権限を累積することができます。たとえば、1つのActiveViewでドメインにユーザアカウントが追加でき、別のActiveViewで同じドメインからユーザアカウントが削除できる場合、そのドメイン内のユーザアカウントを追加または削除できます。このようにして、特定のオブジェクトに対する権限が累積されます。

ActiveViewが重なり合ったり、これらのActiveViewに含まれるオブジェクトに対する権限が増したりすることを理解することが重要です。次の図に示すようなActiveViewの構成を検討します。

白いタブでは、ActiveViewを場所で識別します(ニューヨーク市とヒューストン)。黒いタブでは、ActiveViewを組織の機能で識別します(営業と拡販)。各ActiveViewに含まれるグループが各セルに表示されます。

NYC_SalesグループとHOU_Salesグループはどちらも営業のActiveViewに表示されています。営業ActiveViewへの権限を持っている場合、NYC_SalesグループとHOU_Salesグループのすべてのメンバーを管理できます。ニューヨーク市ActiveViewへの権限も持っている場合、これらの追加権限がNYC_Marketingグループに適用されます。この方法により、ActiveViewが重なり合うたびに権限が積み重なります。

ActiveViewの重ね合わせにより、強力で柔軟な委任モデルとなります。ただし、この機能は予期しない結果を生む可能性もあります。ActiveViewを慎重に計画し、各アシスタント管理者がユーザアカウント、グループ、OU、連絡先、またはリソースのそれぞれに対し本当に必要な権限のみ有している状態にしてください。

複数のActiveview内のグループ

この例では、NYC_Salesグループが複数のActiveViewに表示されます。NYC_Salesグループのメンバーは、そのグループ名がNYC_*というActiveViewルールと一致するため、ニューヨーク市ActiveViewに表示されています。このグループは、*_SalesというActiveViewルールと一致するため、営業ActiveViewにも含まれます。同じグループを複数のActiveViewに含めることで、同一のオブジェクトを別々に管理することを異なるアシスタント管理者に許可することができます。

複数のActiveViewでの権限使用

ニューヨーク市のActiveViewでModify General User Propertiesという権限を持つ「JSmith」というアシスタント管理者がいるとします。この最初の権限によってJSmithさんは、ユーザプロパティウィンドウの［全般］タブですべてのプロパティを編集することができます。JSmithさんは、営業ActiveViewでModify User Profile Propertiesという権限を持っています。2つ目の権限によってJSmithさんは、ユーザプロパティウィンドウの［プロファイル］タブですべてのプロパティを編集することができます。

次の図に、各グループでJSmithさんの持つ権限を示します。

JSmithさんには、次の権限があります。

• NYC_* ActiveViewの全般プロパティ

• *_Sales ActiveViewのプロファイルプロパティ

このような重なり合うActiveViewの権限委任により、JSmithさんはNYC_Salesグループの［全般］と［プロファイル］の各プロパティを変更できます。そのため、JSmithさんは、NYC_Salesグループを表示するすべてのActiveViewで付与された権限をすべて持っています。

7.1.1 組み込みのActiveViewへのアクセス

ActiveViewにアクセスして、デフォルトの委任モデルを監査したり、自分のセキュリティ設定を管理します。

7.1.2 組み込みのActiveViewの使用

組み込みのActiveViewは削除、クローン作成、変更ができません。ただし、これらのActiveViewを既存の委任モデルに組み込むことや、これらのActiveViewを使用して独自モデルの設計を行うことができます。

組み込みのActiveViewは次の方法で使用できます。

ダイナミック委任モデルの設計の詳細については、「ダイナミック委任モデルについて」を参照してください。

7.2.1 ActiveViewのルール

アクティブビューは、ユーザアカウント、グループ、OU、連絡先、リソース、コンピュータ、リソースメールボックス、共有メールボックス、ダイナミック配布グループ、グループ管理対象サービスアカウント、アクティブビュー、およびAzureユーザ、Azureゲストユーザ、Azureグループ、Azure連絡先などのAzureオブジェクトを含めるルール、または排除するルールで構成することができます。この柔軟性によりActiveViewがダイナミックになります。

このような一致を「ワイルドカード」と呼びます。たとえば、DOM*と一致する名前を持つすべてのコンピュータを含めるようなルールを定義することができます。このようにワイルドカードで指定すると、名前が文字列「DOM」で始まるコンピュータアカウントをすべて検索します。ワイルドカード一致では、アカウントがルールと一致したときにそれが自動的に含まれるため、管理がダイナミックなものになります。そのため、ワイルドカードを使用すると、組織変更があっても、ActiveViewを再設定する必要がありません。

もう1つの例は、グループメンバーシップに基づいたActiveViewの定義です。「NYC」の3文字で始まるグループメンバーをすべて含めるルールを定義することができます。その後で、メンバーがこのルールに一致するあらゆるグループに追加されたときに、これらのメンバーは自動的にこのActiveViewに含まれます。企業が改変されたり成長した際に、新しいオブジェクトを適切なActiveView内に含めるルール、またはそこから除外するルールをDRAが再び適用します。

8.1.1 Azure Active Directory管理

8.1.2 管理

8.1.3 詳細クエリの管理

8.1.4 監査管理

8.1.5 コンピュータ管理

8.1.6 Exchangeの管理

8.1.7 グループ管理

8.1.8 レポーティング管理

8.1.9 Resource Management

8.1.10 サーバ管理

8.1.11 ユーザアカウントの管理

8.1.12 WTSの管理

9.1.1 Azureの権限

次の権限を使用して、Azureユーザ、グループ、および連絡先の作成および管理を委任します。

Azure User Account Powers (Azureユーザアカウント権限):

Azure Group Powers (Azureグループの権限):

Azure連絡先の権限:

Azureゲストユーザアカウントの権限:

Azureユーザアカウントに一覧表示されている権限は、Azureゲストユーザアカウントにも適用されます。

Azureオブジェクトの詳細なレベルのプロパティを管理するには、特定のオブジェクト属性を選択することでカスタム権限を作成します。

11.3.1 マルチマスタセットの設定

MMS環境では、ドメインとメンバーサーバの同じセットを複数の管理サーバで管理します。MMSは、1つのプライマリ管理サーバと複数のセカンダリ管理サーバで構成されます。

管理サーバのデフォルトモードはプライマリです。セカンダリサーバをMMS環境に追加するときは、セカンダリ管理サーバが1つのサーバセットにしか所属できないので注意してください。

セット内の各サーバが確実に同じデータを管理できるようにするために、定期的に各セカンダリサーバをプライマリ管理サーバと同期させる必要があります。保守の手間を減らすために、ドメインフォレスト内のすべての管理サーバに対して同じサービスアカウントを使用してください。

11.3.2 クローン例外の管理

クローン例外とは、オブジェクト(ユーザ、グループ、連絡先、コンピュータ)のうち1つに対しクローンが作成されたときにコピーされないプロパティを定義することのできる機能です。

適切な権限を持つ人がクローン例外を管理することができます。Manage Clone Exceptionsという役割は、クローン例外を表示、作成、および削除する権限が与えられます。

既存のクローン例外の表示または削除、および新規のクローン例外の作成には、［環境設定管理］>［Clone Exceptions (クローン例外)］>［タスク］の順に選択するか、右クリックしてメニューから選択します。

11.3.3 ファイルのレプリケーション

カスタムツールを作成する場合は、それを実行する前にDRA Delegation and Configuration Console (委任および環境設定コンソール)コンピュータ上にカスタムツールが使用するサポートファイルのインストールが必要となることがあります。カスタムツールのサポートファイルは、DRAのファイルレプリケーション機能を使用してプライマリ管理サーバからMMS内のセカンダリ管理サーバやDRAクライアントコンピュータへと複製することができます。ファイルのレプリケーションは、プライマリサーバからセカンダリサーバにトリガスクリプトを複製するときにも使用できます。

カスタムツール機能とファイルレプリケーション機能は、Delegation and Configuration Console(委任および環境設定コンソール)でのみ使用できます。

カスタムツールとファイルレプリケーション機能を合わせて使用することにより、DRAのクライアントコンピュータが確実にカスタムツールファイルにアクセスすることができます。DRAがカスタムツールファイルをセカンダリ管理サーバに複製して、セカンダリ管理サーバに接続するDRAクライアントコンピュータがカスタムツールにアクセスできるようにします。

カスタムツールファイルは、MMSの同期処理中にDRAによってプライマリ管理サーバからセカンダリ管理サーバへと複製されます。DRAのクライアントコンピュータが管理サーバに接続するときに、DRAによってカスタムツールファイルがダウンロードされます。

{DRAInstallDir}\FileTransfer\Replicate 

{DRAInstallDir}\FileTransfer\Download 

11.3.4 Azure Sync

Azure Syncはディレクトリ同期の失敗を防ぐために、無効な文字と文字長のポリシーを規定することができます。このオプションを選択すると、Azure Active Directoryと同期されているすべてのプロパティで無効な文字が制限され、文字の長さの制限が適用されます。

11.3.5 グループに複数のマネージャを有効にする

複数のマネージャがグループを管理するためのサポートを有効にした場合、デフォルトの2つの属性のうち1つがグループのマネージャを保存するために使用されます。Microsoft Exchangeを実行するときの属性は、msExchCoManagedByLinkという属性です。Microsoft Exchangeを実行しないときのデフォルト属性は、nonSecurityMemberという属性です。2つ目のオプションは変更することができます。ただし、この設定を変更する必要がある場合は、技術サポートに連絡して適切な属性を決めることをお勧めします。

11.3.6 暗号通信

この機能では、Delegation and Configurationクライアントと管理サーバの間での暗号化通信の使用を有効または無効にできます。デフォルトでは、DRAはアカウントパスワードを暗号化します。この機能は、WebクライアントやPowerShellの通信の暗号化に対応しません。これは別個にサーバ証明書で処理されます。

暗号通信を使用すると、パフォーマンスに影響する場合があります。暗号通信は、デフォルトでは無効になっています。このオプションを有効にすると、ユーザインタフェースと管理サーバの間での通信中にデータが暗号化されます。DRAでは、リモートプロシージャコール(RPC)にMicrosoftの標準暗号を使用します。

通信の暗号化を有効にするには、［Configuration Management］>［Update Administration Server Options (管理サーバオプションを更新)］>［全般］タブの順に選択し、［Encrypted Communications (暗号化して通信)］チェックボックスを選択します。

11.3.7 仮想属性の定義

仮想属性を使用すると、新しいプロパティを作成して、それらをユーザ、グループ、ダイナミック配布グループ、連絡先、コンピュータ、およびOUに関連付けることができます。仮想属性を使用すると、Active Directoryスキーマを拡張しなくても新しいプロパティが作成できます。

仮想属性を使用して、Active Directory内のオブジェクトに新しいプロパティを追加できます。仮想属性の作成、有効化、無効化、関連付け、および関連付けの解除は、プライマリ管理サーバでしかできません。DRAは、作成された仮想属性をAD LDSに保存します。仮想属性は、MMS同期プロセス中にDRAによってプライマリ管理サーバからセカンダリ管理サーバへと複製されます。

適切な権限があれば、仮想属性を管理することができます。Manage Virtual Attributesという役割は、仮想属性を作成、有効化、関連付け、関連付け解除、無効化、および表示する権限を付与します。

11.3.8 キャッシュ動作の設定

管理サーバはアカウントキャッシュを構築および維持し、そこに管理対象ドメインのActive Directoryの一部が収められます。DRAはアカウントキャッシュを使用して、ユーザアカウント、グループ、連絡先、およびコンピュータアカウントを管理する際のパフォーマンスを向上させています。

キャッシュの更新をスケジュールするか、キャッシュステータスを表示するには、Configure Servers and Domainsという組み込みの役割に含まれる権限など、適切な権限が必要です。

11.3.9 Active Directoryのプリンタのコレクションの有効化

ADのプリンタコレクションはデフォルトで無効になっています。これを有効にするには、［Configuration Management］>［Update Administration Server Options (管理サーバオプションを更新)］>［全般］タブの順に選択し、［Collect Printers (プリンタを収集)］チェックボックスをオンにします。

11.3.10 AD LDS

スケジュールに従って特定のドメインに対してAD LDSのクリーンアップ更新が実行されるように設定できます。デフォルトでは、更新「しない」に設定されています。クリーンアップのステータスも、AD LDS (ADAM)の設定に関連した特定の情報も表示することができます。

スケジュールを設定するには、またはAD LDSクリーンアップのステータスを表示するには、［Account and Resource Management］>［すべての管理対象オブジェクト］ノードで目的のドメインを右クリックし、［プロパティ］>［Adlds Cleanup Refresh Schedule (AD LDSクリーンアップ更新スケジュール)］(または［Adlds Cleanup status (AD LDSクリーンアップステータス)］)の順に選択します。

AD LDS (ADAM)の設定情報を表示するには、［Configuration Management］>［Update Server Options (サーバオプションを更新)］>［ADAM Configuration (ADAMの設定)］の順に選択します。

11.3.11 ダイナミックグループ

ダイナミックグループとは、グループプロパティで設定しておいた定義済み条件セットに基づいてメンバーシップが変わるグループです。ドメインプロパティで特定のドメインに対し、スケジュールに従ってダイナミックグループの更新が実行されるように設定できます。デフォルトでは、更新「しない」に設定されています。更新のステータスを表示することもできます。

スケジュールを設定するためには、ダイナミックグループの更新のステータスを表示するには、［Account and Resource Management］>［すべての管理対象オブジェクト］ノードで目的のドメインを右クリックし、［プロパティ］>［Dynamic group refresh (ダイナミックグループの更新)］(または［Dynamic group status (ダイナミックグループのステータス)］)の順に選択します。

ダイナミックグループの詳細については、「DRAのダイナミックグループ」を参照してください。

11.3.12 ごみ箱の設定

ごみ箱をMicrosoft Windowsの各ドメインまたは各ドメイン内のオブジェクトに対し有効または無効に設定することができ、ごみ箱のクリーンアップの実行方法と時期も設定できます。

ごみ箱の使用の詳細については、「ごみ箱」を参照してください。

11.3.13 レポーティング環境設定

以下のセクションでは、DRA管理レポートと、有効にできるレポートコレクタについて概説します。コレクタが設定できるウィザードを表示するには、［Configuration Management］>［Update Reporting Service Configuration (レポーティングサービスの設定を更新)］の順に選択します。

11.3.14 ワークフロー自動化サーバの設定権限を委任する

ワークフローを管理するには、ワークフロー自動化サーバ管理の役割または次の該当する権限を管理者に割り当てます。

ワークフロー自動化サーバの設定権限を委任するには、次のようにします。

11.3.15 ワークフロー自動化サーバの設定

DRAでWorkflow Automationを使用するには、WindowsサーバでWorkflow Automation EngineをインストールしてからDelegation and Configuration console (委任および環境設定コンソール)を介してWorkflow Automationサーバを構成する必要があります。

ワークフロー自動化サーバを設定するには、次のようにします。

Workflow Automation Engineのインストールの詳細については、『DRAマニュアルサイト』の「Workflow Automation管理者ガイド」を参照してください。

11.3.16 LDAP検索権限を委任する

DRAでは、LDAPサーバからユーザ、連絡先、コンピュータ、グループ、およびOUなどのオンプレミスのActive Directoryドメインに含まれるLDAPオブジェクトを検索できます。DRAサーバは引き続き操作を処理し、検索が実行されるのはドメインコントローラです。検索フィルタを使用して、より効率的で効果的な検索を行うことができます。また、検索クエリを保存して後で使用することもできます。検索クエリをパブリッククエリとして共有したり、プライベートとしてマークすることで自分で使用したりできます。保存されているクエリを編集できます。LDAP詳細クエリ役割は、アシスタント管理者に、LDAP検索クエリを作成および管理する権限を与えます。次に示す権限を使用して、LDAP検索クエリの作成および管理を委任します。

LDAPクエリ権限を委任するには、次のようにします。

Webコンソールの検索機能にアクセスするには、［管理］ > ［LDAP検索］に移動します。

11.4.1 Change Guardian Windowsエージェントのインストール

DRAとCGの統合を開始する前に、Change Guardian Windowsエージェントをインストールします。詳細については、『Change Guardian Installation and Administration Guide』を参照してください。

11.4.2 Active Directoryライセンスキーの追加

Change Guardianサーバと、監視する予定のアプリケーションまたはモジュールの両方にライセンスを追加する必要があります。詳細については、『Change Guardian Installation and Administration Guide』を参照してください。

11.4.3 Active Directoryの設定

Active Directoryを変更履歴用に設定するには、次のセクションを参照してください。

11.4.4 Active Directoryポリシーの作成と割り当て

事前設定なしで新規ポリシーを作成できます。

11.4.5 Active Directoryドメインの管理

DRA内のドメインを管理対象ドメインとして設定するには、「Active Directoryドメインの管理」を参照してください。

11.4.6 DRAでイベントスタンプを有効にする

ADのドメインサービスの監査を有効にすると、DRAのサービスアカウントまたはドメインアクセスアカウントが設定されていれば、そのいずれかによってイベントが発生したときに、DRAイベントが記録されます。この機能を応用したのがイベントスタンプです。イベントスタンプでは、ADのドメインサービスイベントを追加で生成し、それによってその操作を実行したアシスタント管理者を特定します。

このようなイベントを発生させるには、ADのドメインサービス監査を設定し、DRAの管理サーバでイベントスタンプを有効にしておく必要があります。イベントスタンプが有効になると、アシスタント管理者が加えた変更がChange Guardianイベントのレポート内に表示されます。

イベントスタンプの詳細については、「イベントスタンプの仕組み」を参照してください。

11.4.7 統合された変更履歴サーバの設定

統合された変更履歴(UCH)サーバ機能を使用すると、DRAの外部で行った変更についてのレポートを生成することができます。

11.4.8 統合された変更履歴レポートへのアクセス

Change Guardianを介して、Active Directoryオブジェクトに関する統合された変更履歴レポートを生成および表示するには、『Directory and Resource Administratorユーザガイド』の「変更履歴レポートの生成」を参照してください。

11.7.1 Webコンソールの起動

Webコンソールは、Webブラウザを実行していれば、どのコンピュータからでも、iOSやAndroidのデバイスからでも起動できます。コンソールを起動するには、適切なURLをWebブラウザのアドレスフィールドに指定してください。たとえば、WebコンポーネントをHOUserverというコンピュータにインストールした場合は、Webブラウザのアドレスフィールドにhttps://HOUserver/draclientとタイプ入力します。

11.7.2 自動ログアウト

何もせずに時間が経過したらWebコンソールを自動的にログアウトするように時間を設定することができます。 また、自動ログアウトしないように設定することもできます。

Webコンソールで自動ログアウトを設定するには、［管理］>［構成］>［自動ログアウト］の順に選択します。

11.7.3 DRAサーバへの接続

次のオプションのいずれかを使用して、Webコンソールにログインできます。ログイン時の各オプションの振る舞いは次の表に示されています。

WebコンソールでDRAサーバの接続を設定するには、［管理］>［構成］>［DRAサーバ接続］の順に選択します。

11.7.4 認証

このセクションには、Advanced Authenticationの統合を使用してスマートカード認証、Windows認証、および多要素認証を設定するための情報が記載されています。

12.1.1 管理対象ドメインおよびコンピュータを追加する

12.1.2 ドメインアクセスアカウントの指定

管理対象ドメインまたは管理対象サブツリーのそれぞれに、管理サーバのサービスアカウントの代わりに使うそのドメインへのアクセス用のアカウントを指定できます。この代替アカウントを「アクセスアカウント」と呼びます。アクセスアカウントを設定するには、Configure Servers and Domainsという組み込みの役割に含まれる権限など、適切な権限が必要です。

メンバーサーバに対しアクセスアカウントを指定するには、ドメインメンバーが存在するドメインを管理するためのパーミッションが必要です。管理サーバからアクセスできる管理対象ドメインの中にドメインメンバーが存在する場合、管理できるのはドメインメンバーのみです。

この最小特権アカウントの設定について詳細は、「最小特権DRAアクセスアカウント」を参照してください。

12.1.3 Exchangeのアクセスアカウントの指定

DRAの各ドメインに対し、DRAのドメインアクセスアカウントまたは別のExchangeアクセスアカウントを使用してExchangeオブジェクトを管理できます。Exchangeのアクセスアカウントを設定するには、Configure Servers and Domainsという組み込みの役割に含まれている権限など、適切な権限が必要です。

この最小特権アカウントの設定について詳細は、「最小特権DRAアクセスアカウント」を参照してください。

12.1.4 管理対象サブツリーの追加

管理サーバをインストールした後、管理対象サブツリーおよび欠けているサブツリーを特定のMicrosoft Windowsドメインから追加することができます。管理対象サブツリーを追加するには、Configure Servers and Domainsという組み込みの役割に含まれている権限など、適切な権限が必要です。

Microsoft Windowsのサポート対象バージョンについては、「DRA管理サーバおよびWebコンソールの要件」を参照してください。

Windowsのドメインのサブツリーを管理することにより、DRAを使って大規模な企業ドメイン内の部門のセキュリティを確保できます。

たとえば、SOUTHWESTドメイン内のHoustonサブツリーを指定して、ヒューストンOUとその子OUに属しているオブジェクトだけを安全に管理することができます。この柔軟性により、ドメイン全体に対する管理権限がなくても、1つまたは複数のサブツリーを管理することが可能になります。

12.1.5 信頼済みドメインの追加

信頼済みのドメインでは、管理対象の環境全体で管理対象システムでのユーザ認証が可能です。信頼済みドメインを追加すれば、管理対象ドメインと同じように、ドメインとExchangeアクセスアカウントの指定、キャッシュ更新のスケジュール、およびそのドメインのプロパティでの各種アクションの実行が可能です。

信頼済みドメインを追加するには:

12.2.1 SSL経由のLDAPを有効にする(LDAPS)

バージョン 9.xからDRA 10.xにアップグレードする場合は、次の手順に従います。DRAを新規インストール用に設定する場合は、「管理対象ドメインおよびコンピュータを追加する」を参照してください。

12.2.2 LDAPSの自動ディスカバリを設定する

自動ディスカバリは、使用可能なDRA環境に自動的に接続するためにクライアントが使用するメカニズムです。

セキュリティ保護されたActive Directoryが実行されている環境に対してDRAを設定するには、ClientSSLAllDomainsレジストリキーを設定します。

12.3.1 パブリックフォルダのドメインプロパティの表示と変更

パブリックフォルダのドメインプロパティを表示または変更するには:

12.3.2 パブリックフォルダの権限委任

権限を定義しパブリックフォルダの委任を管理するためにActiveViewを使用します。管理対象オブジェクトの追加、ドメインの選択、権限の割り当てのルールを指定し、それらのパブリックフォルダの権限をアシスタント管理者に委任することができます。

ActiveViewを作成して、パブリックフォルダの権限を委任するには:

パブリックフォルダの権限委任が完了したら、設定されたドメイン内のパブリックフォルダのプロパティに対して作成、読み取り、更新、削除の各操作を、認可されたユーザがWebコンソールから実行することができます。

12.5.1 新しいAzureテナントの追加

新しいAzureテナントを管理するには、DRAが提供するPowerShellスクリプトを使用して、オフラインでAzureアプリケーションを作成する必要があります。DRAは、テナント内のオブジェクトを管理するために必要な許可を、Azureアプリケーションに自動的に付与します。Azureアプリケーションで必要な許可のリストについては、「最小特権DRAアクセスアカウント」を参照してください。

DRA用のAzureアプリケーションを作成してAzureテナントを追加するには:

12.5.2 手動での証明書のアップロード

独自の証明書を使用する場合、または既存のカスタム証明書の有効期限が切れている場合に新しい証明書を指定する場合は、Azureテナントプロパティのページから証明書をアップロードできます。サポートされている証明書ファイル形式は、.pfxおよび.cerです。

証明書をアップロードするには:

12.5.3 10.2へのアップグレード後の、Azureアプリケーションの証明書ベース認証の設定

DRA 10.2にアップグレードした後、基本認証から証明書ベースの認証に切り替え、証明書ベースの認証を使用するようにAzureアプリケーションを設定できます。Azureアプリケーションでは、証明書ベースの認証に追加の許可が必要です。Azureアプリケーションに必要な許可を適用するには、UpdateDraAzureApplicationPermission.ps1スクリプトを実行する必要 があります。

アップグレード後に証明書ベースの認証を使用するようにAzureアプリケーションを設定するには、次の手順を実行します。

12.5.4 Azureアプリケーションのクライアントシークレットのリセット

Azureアプリケーションのクライアントシークレットをリセットする必要がある場合は、次の手順に従います。

Azureアプリケーションのクライアントシークレットをリセットするには:

12.5.5 Azureゲストユーザの招待の設定

AzureゲストユーザをAzure Active Directoryに招待すると、DRAは招待リンクを含むカスタマイズされたようこそメッセージとともに、電子メールをAzureゲストユーザに送信します。このようこそメッセージと、招待に表示する招待リンクまたはリダイレクトURLは設定が可能です。Azureゲストユーザは招待を受け入れると、設定済みのURLにリダイレクトされます。このURLで、Azureゲストユーザは資格情報を使用してログインすることができます。

ゲストユーザの招待を設定するには:

12.6.1 パスワードを手動でリセットする

Delegation and Configuration Console (委任および環境設定コンソール)を使用して、アクセスアカウントのパスワードを手動でリセットします。

アクセスアカウントのパスワードを手動でリセットするには、次の操作を行います。

12.6.2 パスワードをリセットするジョブのスケジュール

［パスワードのリセット］ジョブを事前定義された間隔で実行するようにスケジュールして、アクセスアカウントの期限切れパスワードをリセットすることができます。ジョブは、スケジュールされている次のジョブの実行の前に期限切れになるアクセスアカウントパスワードをリセットします。新しいパスワードは、パスワードポリシーに従って自動的に生成されます。

ジョブはデフォルトでは無効になっています。要件に応じて、1週間に1回、または特定の間隔でジョブをスケジュールできます。MMS環境で、プライマリサーバでジョブを設定する場合は、そのジョブがMMS内のすべてのサーバで設定されていることを確認します。

ジョブを設定する場合

13.2.1 組み込みポリシーについて

組み込みポリシーは、一般的なセキュリティとデータ整合性の問題に対処するビジネスルールとなります。これらのポリシーはデフォルトのセキュリティモデルの一部ですので、企業の既存のシステム構成にDRAのセキュリティ機能を統合することができます。

DRAには、ポリシーを強制する手段が2つあります。カスタムポリシーを作成するという方法と、組み込みポリシーの中から選択するという方法です。込み込みポリシーを利用すれば、カスタムスクリプトを開発しなくても、簡単にポリシーを適用できます。カスタムポリシーを実装する必要がある場合は、既存の組み込みポリシーをニーズに合わせてカスタマイズすることができます。ほとんどのポリシーでは、エラーメッセージのテキストの変更、ポリシーの名前変更、説明の追加、ポリシーの適用方法の指定ができます。

DRAをインストールしたときに、いくつかの組み込みポリシーが有効になります。以下のポリシーがデフォルトで実装されます。これらのポリシーを強制させない場合は、そのポリシーを無効にすることも削除することもできます。

13.2.2 使用可能なポリシー

DRAには、独自のセキュリティモデル用にカスタマイズできるポリシーがいくつかあります。

13.2.3 組み込みポリシーの使用

組み込みポリシーはデフォルトセキュリティモデルの一部であり、これらのポリシーを使用して現在のセキュリティモデルを強制することも、ニーズに合わせて組み込みポリシーを変更することもできます。いくつかの組み込みポリシーについては、その名前、ルール設定、適用範囲、ポリシーの関係、エラーメッセージを変更できます。組み込みポリシーは、それぞれ有効または無効にすることができます。

また、簡単に新しいポリシーを作成することもできます。

13.4.1 制限可能なネーティブの組み込みセキュリティグループ

次に示すMicrosoft Windows組み込みセキュリティグループの権限を、DRAのポリシーで制限することができます。

13.4.2 ネーティブの組み込みセキュリティグループに対するアクション制限

DRAはポリシーを使用してネーティブの組み込みセキュリティグループとそのメンバーが実行できる権限を制限することができます。このポリシーは、$SpecialGroupsPolicyと呼ばれ、ネーティブの組み込みセキュリティグループのメンバーが他のメンバーまたは他のネーティブの組み込みセキュリティグループに対して実行できるアクションを制限します。DRAではデフォルトでこのポリシーが有効になります。ネーティブの組み込みセキュリティグループとそのメンバーに対するアクションを制限したくない場合は、このポリシーを無効にすることができます。

このポリシーを有効にすると、DRAは次に示す検証テストを使用して、ネーティブの組み込みセキュリティグループまたはそのメンバーに対してのアクションが許可されているかどうかを判断します。

たとえば、適切な権限を持ち、サーバオペレータグループとアカウントオペレータグループのメンバーの人であれば、サーバオペレータのメンバーに、アカウントオペレータのグループのメンバーに、または両グループのメンバーに対してアクションを実行できます。ただし、その人はプリントオペレータグループとアカウントオペレータグループのメンバーのユーザアカウントに対してアクションを実行できません。

DRAはネーティブの組み込みセキュリティグループに対し次に挙げる操作の実行を制限します。

DRAは、あるオブジェクトに対しユーザが権限を獲得しないように、アクションも制限します。たとえば、あるユーザアカウントをグループに追加するときに、それがそのグループのメンバーであるため、DRAがその操作をした人がそのユーザアカウントに対し追加の権限を獲得しないようチェックします。この検証は権限格上げの防止に役立ちます。

13.5.1 Microsoft Exchangeポリシー

Exchangeには、Microsoft Exchangeのオブジェクトをより効率的に管理するために役立つポリシーがいくつか用意されています。Microsoft Exchangeのポリシーを使用すれば、メールボックス管理の自動化、エイリアスとメールボックスストアの命名規則適用、および電子メールアドレスの自動生成が可能です。

これらのポリシーは、ワークフローの整理統合とデータの整合性の維持に役立ちます。たとえば、ユーザカウントが作成、変更、または削除されたときにExchangeがメールボックスをどう管理するのかを指定することができます。Microsoft Exchangeポリシーを設定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。

13.5.2 Office 365ライセンスポリシー

Office 365のライセンスポリシーを指定するには、Manage Policies and Automation Triggersというビルトインの役割に含まれている権限のような、適切な権限が必要です。使用しているライセンスがMicrosoft Exchangeをサポートしている必要もあります。

13.5.3 ホームディレクトリポリシーの作成と実装

多数のユーザアカウントを管理する場合、それらのホームディレクトリおよび共有を作成して管理するには長い時間がかかり、セキュリティエラーの原因になる可能性があります。その後も、ユーザが作成、名前変更、または削除されるたびに、追加の保守が必要になります。ホームディレクトリポリシーは、ホームディレクトリとホーム共有の保守管理を助けます。

DRAでは、ユーザホームディレクトリの作成と保守を自動化できます。たとえば、ユーザアカウントが作成されたときに管理サーバがホームディレクトリを作成するように、DRAを設定することができます。このケースでは、ユーザアカウントを作成したときにホームディレクトリパスを指定すると、サーバがそのパスに自動的にホームディレクトリを作成します。パスを指定しなかった場合、ホームディレクトリは作成されません。

DRAは、許容される親パス内のユーザについて、ユーザのホームディレクトリの作成時や、ホームディレクトリポリシーの設定時に、DFS (Distributed File System)のパスをサポートします。NetappフィルタおよびDFSパスまたはパーティション上でのホームディレクトリの作成、名前変更、削除を実行できます。

13.5.4 パスワード生成機能の有効化

この機能では、DRAの生成するパスワードのポリシー設定を指定することができます。DRAはユーザ作成のパスワードに対するこれらの設定を強制しません。パスワードポリシーのプロパティを設定する場合、パスワードの長さは6文字未満で、127文字以下でなければなりません。パスワードの長さと上限を除き、すべての値を0に設定することができます。

パスワード生成ポリシーを設定するには、［Policy and Automation Management］>［Configure Password Generation Policies (パスワード生成ポリシーを設定)］の順に選択し、［Enable Password Policy (パスワードポリシーを有効にする)］チェックボックスを選択してください。［Password Settings (パスワード設定)］をクリックし、パスワードポリシーのプロパティを設定します。

13.5.5 ポリシーのタスク

ポリシーを消去、有効化、無効化するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。

これらのアクションのいずれかを実行するには、［Policy and Automation Management］>［ポリシー］の順に選択します。右側のペインで削除、有効化、または無効化するポリシーを右クリックし、目的のアクションを選択します。

13.6.1 メールボックス自動命名ポリシーの指定

メールボックス自動命名オプションを指定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。また、ご使用のライセンスがExchange製品をサポートしている必要があります。

13.6.2 リソースの命名ポリシーの指定

リソース自動命名オプションを指定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。また、使用しているライセンスがExchange製品をサポートしている必要があります。

13.6.3 アーカイブの命名ポリシーの指定

アーカイブ自動命名オプションを指定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。また、使用しているライセンスがExchange製品をサポートしている必要があります。

16.1.1 WindowsイベントログでのDRA監査の有効化/無効化

DRAをインストールしても、監査イベントはデフォルトではWindowsイベントログに記録されません。このタイプのログ記録は、レジストリキーを変更することによって有効にできます。

16.1.2 監査の整合性の確保

DRAは、すべてのユーザアクションが監査されるようにするために、製品がログ活動を検証できないときに代替ログ手段を提供します。DRAをインストールすると、次のアクションが実行されるようにするために、AuditFailsFilePathキーおよびパスがレジストリに追加されます。

ログアーカイブが使用不能の場合に書き込み操作を有効にするには、AllowOperationsOnAuditFailureキーのレジストリキー値も設定する必要があります。

16.2.1 Log Archive Viewerユーティリティの使用

ログアーカイブファイルに保存されたデータを表示するには、Log Archive Viewerユーティリティを使用します。NetIQ DRAのLARK (Log Archive Resource Kit)は、DRAでインストールするよう選択できますが、Log Archive Viewerユーティリティを提供します。詳細については、『NetIQ DRA Log Archive Resource Kit Technical Reference』を参照してください。

16.2.2 ログアーカイブファイルのバックアップ

ログアーカイブファイルとは、レコードブロックの集まりです。ログアーカイブファイルは物理データベースの外にある圧縮されたバイナリファイルなので、ログアーカイブをバックアップするのにMicrosoft SQL Server Management Studioを使用する必要はありません。自動化されたファイルバックアップシステムを使用している場合は、ログアーカイブファイルも他のファイルと同様に自動的にバックアップされます。

バックアップ戦略を計画するときには、次のベストプラクティスを頭に置いてください。

16.2.3 ログアーカイブのグルーミング設定の変更

DRAのインストール時に、ログアーカイブのグルーミングはデフォルトで無効にされます。ログアーカイブファイルの定期的なバックアップ手順を確立する場合は、ディスクスペースがいっぱいにならないようにログアーカイブのグルーミングを有効にする必要があります。ログアーカイブパーティションがグルーミングされるまでの日数は、Log Archive Configurationを使って変更できます。

17.1.1 コレクタのステータスの表示

［Collectors Status (コレクタのステータス)］タブで各データコレクタの詳細が確認できます。

17.1.2 レポート生成とデータ収集の有効化

DRA Reportingのコンポーネントをインストールした後に、Reporting Centerのレポートにアクセスするために、レポート生成のデータ収集を有効にして設定を行ってください。

特定のコレクタを設定する方法の詳細については、「レポーティング環境設定」を参照してください。

17.2.1 オブジェクトの変更に関するレポート

Activity Detailレポートを生成することで、ドメイン内のオブジェクトに関する変更情報をリアルタイムで確認できます。たとえば、指定した期間中にオブジェクトに対して加えられた変更、またはオブジェクトが加えた変更がリスト表示されます。Activity Detailレポートはエクスポートや印刷することもできます。

17.2.2 オブジェクトリストのレポート

オブジェクトのリストからデータをエクスポートおよび印刷することができます。この機能により、管理対象オブジェクトの一般情報に関するレポートの生成や配布が素早く簡単にできます。

オブジェクトリストをエクスポートする場合は、ファイルの場所、名前、および形式を指定することができます。DRAでは、HTML、CSV、XMLの各形式がサポートされています。オブジェクトの一般情報をデータベースアプリケーションにエクスポートすることも、リスト出力の結果をWebページに投稿することもできます。

17.2.3 オブジェクトの詳細に関するレポート

グループメンバーシップなど、オブジェクト属性をリスト表示する詳細タブからデータをエクスポートおよび印刷することができます。この機能により、特定のオブジェクトに関し必要な詳細情報を素早く簡単に頻繁にレポート生成および配布することができます。

オブジェクトの詳細のタブをエクスポートする場合は、ファイルの場所、名前、および形式を指定することができます。DRAでは、HTML、CSV、XMLの各形式がサポートされています。オブジェクトの一般情報をデータベースアプリケーションにエクスポートすることも、リスト出力の結果をWebページに投稿することもできます。