DRAでは、会社のセキュリティ確保とデータ破壊防止に役立つさまざまなポリシーが設定できます。これらのポリシーは動的セキュリティモデルのコンテキスト内で機能し、ポリシーの強制が会社の変化に自動的に対応するようになっています。命名規則、ディスク使用量の制限、プロパティ検証などのポリシーを確立することで、企業データの整合性の維持を助けるルールを強制できます。
DRAでは、次に示す企業管理領域に対し、ポリシーのルールが素早く定義できます。
Microsoft Exchange
Office 365
ホームディレクトリ
パスワード生成
DRAは、グループ、ユーザアカウント、およびコンピュータに関する組み込みポリシーも提供します。
ポリシーを管理または定義するには、DRA管理者の役割またはManage Policies and Automation Triggersという役割に含まれている権限のような、適切な権限が必要です。ポリシーの管理を助けるために、DRAはPolicy Detailsレポートを提供しています。このレポートは以下の情報を提供します。
ポリシーが有効になっているかどうか
関連付けられた操作のリスト
当該ポリシーによって制御されるオブジェクトのリスト
ポリシー適用範囲の詳細
このレポートを使用すれば、ポリシーが適切に定義されているかどうかを確認できます。また、このレポートを使用してポリシーのプロパティを比較し、競合を把握することにより、会社全体にポリシーをより適切に強制することもできます。
各タスク(つまり管理操作)を1つ以上のポリシーと関連付けることができます。ポリシーに関連した操作を実行すると、管理サーバがそのポリシーを実行し、指定されたルールを強制します。サーバはポリシー違反を検出すると、エラーメッセージを返します。ポリシー違反を検出しなかった場合、サーバはその操作を完了します。ポリシーを特定のActiveViewグループまたはアシスタント管理者グループに関連付けることにより、ポリシーの適用範囲が制限できます。
操作が複数のポリシーと関連している場合、管理サーバはそれらのポリシーをアルファベット順に強制します。つまり、ポリシーAは、指定されたルールに関係なくポリシーBより先に強制されます。
ポリシーどうしが互いに競合しないようにするために、以下のガイドラインを使用してください。
各ポリシーが正しい順序で実行されるように、各ポリシーの名前を付けてください。
各ポリシーが他のポリシーによって実行される検証またはアクションに干渉しないことを確認してください。
カスタムポリシーは、本番環境に実装する前に徹底的にテストしてください。
管理サーバは、ポリシーが実行されるたびにそのポリシーのステータスを監査ログに記録します。これらのログエントリは、戻りコード、関連する操作、操作対象オブジェクト、およびカスタムポリシーの実行が成功したかどうかを記録します。
警告:ポリシーは、管理サービスアカウントを使って実行されます。サービスアカウントは管理者権限を持っているので、ポリシーはすべての会社データへの完全なアクセス権を持っています。したがって、Manage Policies and Automation Triggersという組み込み役割に関連付けられたアシスタント管理者は、意図より大きな権限を持つことになる可能性があります。
組み込みポリシーは、管理サーバのインストール時に実装されます。これらのポリシーに対する操作を行うときには、以下の用語を理解しておく必要があります。
DRAがポリシーを適用するオブジェクトまたはプロパティを定義します。たとえば、一部のポリシーは、特定のActiveView内の特定のアシスタント管理者に対して適用できます。ユーザアカウントやグループなど、異なるクラスのオブジェクトから適用対象を選択できるポリシーもあります。
管理対象ドメイン内にある指定されたクラスまたはタイプのすべてのオブジェクトに対してポリシールールを強制します。グローバルポリシーでは、ポリシーが適用されるオブジェクトの適用範囲を制限することはできません。
ポリシーが他のポリシーとともに適用されるか、それとも単独で適用されるかを定義します。ポリシーの関係を確立するには、同じアクションに適用される複数のルールを定義し、ポリシーグループオプションのメンバーを選択します。操作のパラメータかプロパティがいずれかのルールと一致すると、その操作は成功します。
組み込みポリシーは、一般的なセキュリティとデータ整合性の問題に対処するビジネスルールとなります。これらのポリシーはデフォルトのセキュリティモデルの一部ですので、企業の既存のシステム構成にDRAのセキュリティ機能を統合することができます。
DRAには、ポリシーを強制する手段が2つあります。カスタムポリシーを作成するという方法と、組み込みポリシーの中から選択するという方法です。込み込みポリシーを利用すれば、カスタムスクリプトを開発しなくても、簡単にポリシーを適用できます。カスタムポリシーを実装する必要がある場合は、既存の組み込みポリシーをニーズに合わせてカスタマイズすることができます。ほとんどのポリシーでは、エラーメッセージのテキストの変更、ポリシーの名前変更、説明の追加、ポリシーの適用方法の指定ができます。
DRAをインストールしたときに、いくつかの組み込みポリシーが有効になります。以下のポリシーがデフォルトで実装されます。これらのポリシーを強制させない場合は、そのポリシーを無効にすることも削除することもできます。
|
ポリシー名 |
デフォルト値 |
説明 |
|---|---|---|
|
$ComputerNameLengthPolicy |
64 15 (Windows 2000以前と互換) |
コンピュータ名の文字数またはWindows 2000以前と互換のコンピュータ名を制限します。 |
|
$GroupNameLengthPolicy |
64 20 (Windows 2000以前と互換) |
グループ名またはWindows 2000以前と互換のグループ名の文字数を制限します。 |
|
$GroupSizePolicy |
5000 |
グループのメンバー数を制限します。 |
|
$NameUniquenessPolicy |
なし |
Windows 2000以前と互換の名前と共通名がすべての管理対象ドメイン内で他と重複しないようにします。 |
|
$SpecialGroupsPolicy |
なし |
環境内で権限が勝手に格上げされることを防ぎます。 |
|
$UCPowerConflictPolicy |
なし |
User Clone権限とUser Create権限を相互に排他的にすることで、権限の格上げを防ぎます。 |
|
$UPNUniquenessPolicy |
なし |
UPN名がすべての管理対象ドメイン内で一意であるようにする |
|
$UserNameLengthPolicy |
64 20 (ダウンレベルのログイン名) |
ユーザログイン名またはダウンレベルログイン名の文字数を制限します。 |
DRAには、独自のセキュリティモデル用にカスタマイズできるポリシーがいくつかあります。
メモ:現在はDRAのユーザインタフェースから利用できないプロパティに関し入力を求めるポリシーを作成することも可能です。ポリシーが入力を必要とし、その値(たとえば新しいユーザカウントの部門名など)を入力するためのフィールドがユーザインタフェース内に存在しない場合は、そのオブジェクトを作成することも管理することもできません。この問題を回避するために、ユーザインタフェースからアクセスできるプロパティのみ要求するポリシーを設定してください。
スクリプトまたは実行ファイルをDRAまたはExchangeの操作にリンクさせることができます。カスタムポリシーを使用すれば、任意の操作を検証できます。
ユーザアカウント、グループ、OU、連絡先、またはコンピュータの名前の最大長をグローバルに強制することができます。
名前コンテナ(共通名、またはcn)とWindows 2000以前と互換の名前(ユーザログオン名)をポリシーでチェックします。
グループのメンバー数をグローバルに制限することができます。
Windows 2000以前と互換の名前がすべての管理対象ドメイン内で重複していないことを検証します。Microsoft Windowsドメインでは、Windows 2000以前と互換の名前はドメイン内で一意でなければなりません。このグローバルポリシーによってこのルールがすべての管理対象ドメインで強制されます。
UPN (User Principal Names)がすべての管理対象ドメイン内で重複していないか検証します。Microsoft Windowsドメインでは、UPNはドメイン内で他と重複しない固有の名前でなければなりません。このポリシーは、このルールをすべての管理対象ドメインにわたって強制します。これはグローバルポリシーなので、DRAがポリシー名、説明、およびポリシーの関係を提供しています。
管理者グループのメンバー以外はその管理者グループのメンバーを管理できないようにします。このグローバルポリシーは、デフォルトで有効になっています。
管理者グループのメンバーに対するアクションを制限する場合、Create Policyウィザードは追加情報を要求しません。独自のエラーメッセージを指定できます。これはグローバルポリシーなので、DRAがポリシー名、説明、およびポリシーの関係を提供しています。
権限のエスカレーションを防ぎます。このポリシーが有効になっている場合、1人の管理者がユーザアカウントの作成とクローン作成のいずれかを行うことはできますが、その両方の権限を持つことはできません。このグローバルポリシーは、同一人物が同じActiveView内でアカウントの作成とクローン作成の両方を行うことはできないようにします。
このポリシーは、追加情報を必要としません。
特定のアシスタント管理者、ActiveView、およびオブジェクトクラス(ユーザアカウントやグループなど)に適用される命名規則を確立できます。
このポリシーによって監視する名前を正確に指定することもできます。
OUまたはアカウントオブジェクトのプロパティを検証するためのポリシーを作成できます。デフォルト値、プロパティの形式マスク、および有効な値と範囲を指定できます。
このポリシーは、特定のオブジェクトのプロパティが作成、クローン作成、または変更が行われたときに特定の入力フィールドを検証することによってデータの整合性を確保するために使用します。このポリシーは、さまざまなプロパティフィールドについて、入力を検証するための大きな柔軟性と力を提供し、デフォルトの入力を提供し、入力の選択肢を制限します。このポリシーを使用すれば、タスクが完了する前に正しい入力が行われるように強制することができるので、すべての管理対象ドメインにおいてデータの整合性を維持できます。
たとえば、製造、営業、および管理という3部門があるとします。DRAがこの3つの値しか受け付けないように、入力を制限することができます。また、このポリシーを使用して、正しい電話番号形式を強制したり、有効なデータの範囲を提示したり、電子メールアドレスフィールドの入力を要求することもできます。(123)456 7890と456 7890のように電話番号に複数の形式マスクを指定する場合は、プロパティ形式マスクを「(###)### ####,### ####」と定義してください
Active Directoryグループのメンバーシップに基づいてOffice 365ライセンスを割り当てるためのポリシーが作成できます。このポリシーは、メンバーを関連のActive Directoryグループから削除するときに Office 365ライセンスの削除の強制も行います。
クラウドと同期していないユーザがActive Directoryグループに追加される場合、そのユーザの同期化が、Office 365ライセンスがそのユーザに割り当てられる前に行われます。
ポリシーの作成時に、ポリシーの名前や、このポリシーに違反するアクションをアシスタント管理者が試みたときに表示されるエラーメッセージの内容など、いくつかのプロパティと設定を指定できます。
デフォルトでは、DRAの外で変更が行われた場合、テナントプロパティページでライセンス更新スケジュールも有効にしていない限り、Office 365のライセンス強制のために作成するポリシーが適用されません。
組み込みポリシーはデフォルトセキュリティモデルの一部であり、これらのポリシーを使用して現在のセキュリティモデルを強制することも、ニーズに合わせて組み込みポリシーを変更することもできます。いくつかの組み込みポリシーについては、その名前、ルール設定、適用範囲、ポリシーの関係、エラーメッセージを変更できます。組み込みポリシーは、それぞれ有効または無効にすることができます。
また、簡単に新しいポリシーを作成することもできます。
カスタムポリシーを使用すると、デフォルトのセキュリティモデルの能力と柔軟性をフルに活用できます。カスタムポリシーを使用することで、DRAを既存の企業コンポーネントと統合しつつ、同時に独自ルールも強制することができます。カスタムポリシー機能を利用して、会社のポリシーを拡張できます。
実行ファイルまたはスクリプトを管理操作と関連付けることにより、カスタムポリシーを作成および強制します。たとえば、ポリシースクリプトをUserCreateという操作に関連付けることによって、指定された従業員が存在するかどうかを人事データベースでチェックすることが可能です。人事データベース内にその従業員が存在し、既存のアカウントを持っていない場合、そのスクリプトはデータベースから従業員ID、姓、および名を取得します。操作は正常に完了し、ユーザアカウントのプロパティウィンドウに適切な情報が表示されます。ただし、従業員がすでにアカウントを持っている場合には、この操作は失敗します。
スクリプトは大きな柔軟性と能力を提供します。独自のポリシースクリプトを作成するには、Directory Resource AdministratorのADSI Provider (ADSIプロバイダ)、ソフトウェア開発キット(SDK)、およびPowerShellのコマンドレットが使用できます。独自のポリシースクリプトの作成の詳細については、DRAマニュアルのサイトでリファレンスセクションを参照してください。
さらに安全な環境を実現するために、DRAは与えられた権限をMicrosoft Windowsの組み込みセキュリティグループに制限できます。グループメンバーシップ、組み込みセキュリティグループのプロパティ、またはグループメンバーシップのプロパティを変更できることはセキュリティ的に重要な意味合いがあります。たとえば、サーバオペレータグループ内のユーザのパスワードを変更できる場合、そのユーザとしてログオンでき、この組み込みセキュリティグループに委任された権限を行使します。
DRAは、ネーティブの組み込みセキュリティグループとそのメンバーに対してどのような権限を持っているかを検証するポリシーを用意することで、このセキュリティの問題を防止します。この検証では、要求したアクションによって権限が増すことがないことを確認しています。このポリシーを有効にした後は、サーバオペレータグループなど、組み込みセキュリティグループのメンバーであるアシスタント管理者は、同じグループの他のメンバーの管理のみできます。
次に示すMicrosoft Windows組み込みセキュリティグループの権限を、DRAのポリシーで制限することができます。
アカウントオペレータ
管理者
バックアップオペレータ
証明書の発行元
DNS管理者
ドメイン管理者
企業管理者
グループポリシー作成元の所有者
プリントオペレータ
スキーマ管理者
メモ:DRAは内部識別子で組み込みのセキュリティグループを参照します。その結果、グループ名が変更されても、DRAがこれらのグループをサポートします。この機能により、さまざまな国々で異なる名前を使った組み込みセキュリティグループをDRAがサポートします。たとえば、DRAは管理者グループと、同じ内部IDのAdministratorenというグループを参照します。
DRAはポリシーを使用してネーティブの組み込みセキュリティグループとそのメンバーが実行できる権限を制限することができます。このポリシーは、$SpecialGroupsPolicyと呼ばれ、ネーティブの組み込みセキュリティグループのメンバーが他のメンバーまたは他のネーティブの組み込みセキュリティグループに対して実行できるアクションを制限します。DRAではデフォルトでこのポリシーが有効になります。ネーティブの組み込みセキュリティグループとそのメンバーに対するアクションを制限したくない場合は、このポリシーを無効にすることができます。
このポリシーを有効にすると、DRAは次に示す検証テストを使用して、ネーティブの組み込みセキュリティグループまたはそのメンバーに対してのアクションが許可されているかどうかを判断します。
Microsoft Windowsの管理者の人であれば、適切な権限のあるネーティブの組み込みセキュリティグループとそのメンバーに対しアクションを実行できます。
組み込みのセキュリティグループのメンバーであれば、適切な権限を持っている限り、同じ組み込みセキュリティグループとそのメンバーに対してアクションを実行できます。
組み込みセキュリティグループのメンバーでない人は、組み込みのセキュリティグループやそのメンバーを変更することができません。
たとえば、適切な権限を持ち、サーバオペレータグループとアカウントオペレータグループのメンバーの人であれば、サーバオペレータのメンバーに、アカウントオペレータのグループのメンバーに、または両グループのメンバーに対してアクションを実行できます。ただし、その人はプリントオペレータグループとアカウントオペレータグループのメンバーのユーザアカウントに対してアクションを実行できません。
DRAはネーティブの組み込みセキュリティグループに対し次に挙げる操作の実行を制限します。
グループのクローン作成
グループの作成
グループの削除
グループへのメンバー追加
グループからのメンバー削除
OUのグループへの移動
グループのプロパティ変更
メールボックスのコピー
メールボックスの削除
ユーザアカウントのクローン作成
ユーザアカウントの作成
ユーザーアカウントの削除
OUへのユーザアカウントの移動
ユーザアカウントのプロパティ変更
DRAは、あるオブジェクトに対しユーザが権限を獲得しないように、アクションも制限します。たとえば、あるユーザアカウントをグループに追加するときに、それがそのグループのメンバーであるため、DRAがその操作をした人がそのユーザアカウントに対し追加の権限を獲得しないようチェックします。この検証は権限格上げの防止に役立ちます。
Policy and Automation Managementノードを通じて、Exchangeポリシー、ホームディレクトリポリシー、組み込みポリシー、およびカスタムポリシーにアクセスできます。以下の一般的なタスクを使用して、会社のセキュリティとデータの整合性を向上させることができます。
Microsoft Exchangeの設定、メールボックスポリシー、自動命名、およびプロキシ生成ルールを定義することができます。これらのルールは、アシスタント管理者がユーザアカウントを作成、変更、または削除したときに、メールボックスがどのように管理されるかを定義できます。
ディレクトリ同期の失敗を防ぐために、無効な文字と文字長のポリシーを規定することができます。
Office 365ルールにより、ユーザアカウントの作成および削除時のExchange OnlineによるOffice 365のメールボックスの管理方法を指定できます。
アシスタント管理者によってユーザアカウントが作成、名前変更、または削除されたときに、ホームディレクトリおよびホーム共有を自動的に作成、名前変更、または削除することができます。ホームディレクトリポリシーを使って、Microsoft WindowsのサーバおよびWindowsではないサーバのホームディレクトリについてディスククォータのサポートを有効または無効にすることもできます。
DRAによって生成されたパスワードの要件を定義できます。
Exchangeには、Microsoft Exchangeのオブジェクトをより効率的に管理するために役立つポリシーがいくつか用意されています。Microsoft Exchangeのポリシーを使用すれば、メールボックス管理の自動化、エイリアスとメールボックスストアの命名規則適用、および電子メールアドレスの自動生成が可能です。
これらのポリシーは、ワークフローの整理統合とデータの整合性の維持に役立ちます。たとえば、ユーザカウントが作成、変更、または削除されたときにExchangeがメールボックスをどう管理するのかを指定することができます。Microsoft Exchangeポリシーを設定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。
電子メールアドレスのデフォルトのポリシーを指定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。また、使用しているライセンスがExchangeをサポートしている必要があります。
デフォルトの電子メールアドレスポリシーを指定するには:
［Policy and Automation Management>［Configure Exchange Policies (Exchangeポリシーを設定)］>［Proxy Generation (プロキシの生成)］の順に選択します。
Microsoft Exchangeサーバのドメインを指定します。
［参照］をクリックします。
必要に応じて追加の検索条件を指定し、［Find Now (今すぐ検索)］をクリックします。
設定するドメインを選択して［OK］をクリックします。
選択されたドメインに対するプロキシ生成ルールを指定します。
［追加］をクリックします。
プロキシタイプを選択します。たとえば、［インターネットアドレス］をクリックします。
デフォルトの値を受け入れるか、新しいプロキシ生成ルールをタイプ入力してから、［OK］をクリックします。
プロキシ生成ルールで使用できる置換文字列の詳細については、「委任およびクライアントのクライアントのポリシー」を参照してください。
［カスタム属性］をクリックして、カスタムメールボックスプロパティのカスタム名を編集します。
属性を選択して［編集］ボタンをクリックします。
［Attribute Properties (属性プロパティ)］ウィンドウで［Custom name (カスタム名)］フィールドに属性名を入力し、［OK］をクリックします。
［OK］をクリックします。
メモ:Microsoft Exchangeのポリシー内のカスタム属性を変更するには、DRAのポリシー管理者がManage Custom Toolsという権限を持っている必要があります。
メールボックスルールを使用すれば、アシスタント管理者によってユーザアカウントが作成、クローン作成、変更、または削除されたときにExchangeにメールボックスをどのように管理させるかを指定することができます。メールボックスルールは、関連付けられたユーザアカウントをアシスタント管理者がどのように管理したかに基づいて、Microsoft Exchangeメールボックスを自動的に管理します。
メモ:Microsoft Windowsドメインで［Do not allow Assistant Admins to create a user account without a mailbox (メールボックス無しのユーザアカウントの作成をアシスタント管理者に許可しない)］というオプションを有効にする場合、確実にアシスタント管理者にユーザアカウントの作成またはクローン作成のいずれかを行う権限を付与してください。このオプションを有効にするには、アシスタント管理者がメールボックスを持つWindowsユーザアカウントを作成できる必要があります。
Microsoft Exchangeのメールボックスのルールを指定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。また、使用しているライセンスがExchange製品をサポートしている必要があります。
Exchangeのメールボックスルールを指定するには:
［Policy and Automation Management>［Configure Exchange Policies (Exchangeポリシーを設定)］>［Mailbox Rules (メールボックスルール)］の順に選択します。
ユーザアカウントを作成または変更したときにExchangeに強制させるメールボックスポリシーを選択します。
［OK］をクリックします。
Office 365のメールボックスポリシーを指定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。使用しているライセンスがMicrosoft Exchangeをサポートしている必要もあります。
無効な文字および文字長をOffice 365と同期するプロパティで制限するには、［Office 365 Rules (Office 365ルール)］をクリックし、［Enforce online mailbox policies for invalid characters and character lengths (無効な文字と文字長についてオンラインメールボックスポリシーを強制する)］チェックボックスを選択します。
DRAにOffice 365のライセンスの管理を許可する場合は、次の操作を行う必要があります。
ライセンス強制ポリシーを作成する
テナントプロパティのページで［ライセンスの更新スケジュール］を有効にします。
Office 365ライセンスを強制するポリシーを作成するには、Delegation and Configurationコンソールで［Policy and Automation Management］ノードをクリックし、［New Policy (新規のポリシー)］>［Create New Policy to Enforce Office 365 Licenses (Office 365のライセンスを強制する新規のポリシーを作成)］の順に選択します。
ポリシーが強制されユーザがActive Directoryに追加されているときは、DRAがグループメンバーシップを使用してOffice 365のライセンスをユーザに自動的に割り当てます。
Office 365のライセンス強制に作成するポリシーは、テナントプロパティページで［License update schedule (ライセンス更新スケジュール)］も有効にしていない限り、変更がDRAの外で行われたときは適用されません。ライセンス更新ジョブでは、ユーザに割り当てられたOffice 365のライセンスがOffice 365のライセンスポリシーと一致することを確認しています。
ライセンス更新ジョブとOffice 365のライセンスポリシーが連携し合って、すべての管理対象ユーザが確実に各自の持つべきOffice 365ライセンスのみに割り当てられるようにします。
メモ:
DRAでは、オンライン専用のユーザアカウントに関してはOffice 365ライセンスを管理しません。Office 365ライセンスを持つユーザをDRAに管理させるには、そのようなユーザとActive Directoryとを同期化する必要があります。
DRAを使用してOffice 365ライセンスを管理することを選択した場合、DRAの外で行われたOffice 365ライセンスへの手動による変更が、次回ライセンス更新ジョブが実行されるときにすべてDRAによって上書きされます。
Office 365のライセンスポリシーが正しく設定されているか確認する前にOffice 365ライセンス更新ジョブを有効にすると、ライセンス更新ジョブの実行後に、割り当てられたライセンスが正しくなくなる可能性があります。
多数のユーザアカウントを管理する場合、それらのホームディレクトリおよび共有を作成して管理するには長い時間がかかり、セキュリティエラーの原因になる可能性があります。その後も、ユーザが作成、名前変更、または削除されるたびに、追加の保守が必要になります。ホームディレクトリポリシーは、ホームディレクトリとホーム共有の保守管理を助けます。
DRAでは、ユーザホームディレクトリの作成と保守を自動化できます。たとえば、ユーザアカウントが作成されたときに管理サーバがホームディレクトリを作成するように、DRAを設定することができます。このケースでは、ユーザアカウントを作成したときにホームディレクトリパスを指定すると、サーバがそのパスに自動的にホームディレクトリを作成します。パスを指定しなかった場合、ホームディレクトリは作成されません。
DRAは、許容される親パス内のユーザについて、ユーザのホームディレクトリの作成時や、ホームディレクトリポリシーの設定時に、DFS (Distributed File System)のパスをサポートします。NetappフィルタおよびDFSパスまたはパーティション上でのホームディレクトリの作成、名前変更、削除を実行できます。
ホームディレクトリ、共有、ボリュームディスククォータのポリシーを設定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。各ポリシーは、関連付けられたユーザアカウントをどのように管理するかに基づいて、ホームディレクトリ、共有、およびボリュームディスククォータを自動的に管理します。
ホームディレクトリのポリシーを設定するには、［Policy and Automation Management］>［Configure Home Directory Policies (ホームディレクトリのポリシーを設定)］の順に選択してください。
ホームディレクトリ
ホーム共有
ホームボリュームディスククォータ
ホーム共有を作成する必要がある各コンピュータに対して、管理サーバサービスアカウントまたはアクセスアカウントがそのコンピュータの管理者になっているか、対応するドメイン内でAdministratorsグループのメンバーになっている必要があります。
管理共有(C$やD$)は、DRAがホームディレクトリを管理および保存する各ドライブに存在している必要があります。DRAは管理共有を使用して、一部のホームディレクトリおよびホーム共有自動化タスクを実行します。これらの共有が存在しないと、DRAはホームディレクトリおよびホーム共有の自動化を提供できません。
NetAppフィルタに許容可能な親パスを設定する手順は次のとおりです。
［Policy and Automation Management］>［Configure Home Directory Policies (ホームディレクトリのポリシーを設定)］の順に選択します。
［Allowable parent paths (指定可能な親パス)］テキストボックスに、次の表に示す指定可能なパスのいずれかを入力します。
|
共有の種類 |
指定可能なパス |
|---|---|
|
Windows |
(\\ファイル名\adminshare:\ボリュームのルートパス\ディレクトリパス) |
|
Windows以外 |
(\\non-windows\share) |
［追加］をクリックします。
ホームディレクトリポリシーを適用する許容可能な親パスのそれぞれに手順1～3を繰り返します。
適切なMicrosoft Windowsセキュリティポリシーと矛盾しないように、DRAはディレクトリレベルでのみアクセス制御の制限を作成します。共有名レベルとファイルまたはディレクトリオブジェクトレベルの両方でアクセス制御の制限を課すると、多くの場合、管理者およびユーザーにとって混乱を招くアクセススキームとなります。
ホーム共有に対するアクセス制御の制限を変更しても、DRAはそのディレクトリに対する既存のセキュリティを変更しません。この場合は、変更者が、ユーザアカウントが自分自身のホームディレクトリに対して適切なアクセス権を持つように設定する必要があります。
DRAは、ユーザアカウントが変更されたときにホームディレクトリを管理することにより、ホームディレクトリ保守タスクを自動化します。DRAは、ユーザアカウントが作成、クローン作成、変更、名前変更、または削除されたときに、それぞれ異なるアクションを実行できます。
ホームディレクトリポリシーを適切に実装するために、以下のガイドラインを使用してください。
正しい形式でパスを指定してください。
単一のホームディレクトリのパスを指定するには、次の表に示すテンプレートのうち1つを使用してください。
|
共有の種類 |
パスのテンプレート |
|---|---|
|
Windows |
\\computer\share\. たとえば、server01というコンピュータ上のHome Shareというフォルダ内にホームディレクトリをDRAに自動的に作成させたい場合、「\\server01\Home Share\」とタイプ入力します。 |
|
Windows以外 |
\\non-windows\share |
対応するホーム共有のルートディレクトリに対するホームディレクトリ管理を標準化するためには、汎用命名規則(Universal Naming Convention)の構文を使用してください。たとえば、「\\サーバ名\C:\ルートディレクトリへのパス」のような形式です。
入れ子になったホームディレクトリのパスを指定するには、次の表に示すテンプレートのうち1つを使用してください。
|
共有の種類 |
パスのテンプレート |
|---|---|
|
Windows |
\\computer\share\最初のディレクトリ\2番目のディレクトリ\ たとえば、server01というコンピュータ上のHome Shareというフォルダ内にあるJSmith\Homeという既存ディレクトリに自動的にホームディレクトリが作成されるようにしたい場合は、「\\server01\Home Share\JSmith\Home」とタイプ入力します。 |
|
Windows以外 |
\\non-windows\share\最初のディレクトリ\2番目のディレクトリ\ |
メモ:DRAは「\\computer\share\ユーザ名」および「\\computer\share\%ユーザ名%」という形式もサポートしています。どちらの場合も、DRAは関連付けられたユーザアカウントのホームディレクトリを自動的に作成します。
NetApp Filer上のホームディレクトリを管理するためにポリシーまたは自動化トリガを定義する際には、異なる形式でディレクトリを指定する必要があります。
NetAppファイラを使用している場合は、親ディレクトリを次の形式で指定します。\\ファイル名\adminshare:\ボリュームのルートパス\ディレクトリパス
adminshareという変数は、c$などのように、NetAppファイラ上のルートボリュームにマップする非表示の共有です。たとえば、NetAppファイラの共有がusfilerという名前で、そのローカルパスがc$\vol\vol0\mydirectoryだった場合、そのNetAppファイラのルートパスを「\\usfiler\c:\vol\vol0\mydirectory」に指定することができます。
ユーザのホームディレクトリを作成するとき、またはユーザのためにホームディレクトリのポリシーを設定するときにDFSパスを指定するには、「\\サーバ\ルート\<リンク>という形式を使用してください。ここで、ルートは管理対象ドメインでも、「\\ファイル名\adminshare:\ボリュームのルートパス\ディレクトリパス」という形式であればスタンドアロンのルートディレクトリでも構いません。
このユーザカウントのホームディレクトリを保存する共有ディレクトリを作成してください。
パス内で参照されているコンピュータまたは共有にDRAがアクセスできるようにしてください。
このルールは、DRAが新しいユーザアカウントに対してホームディレクトリを自動的に作成できるようにします。DRAがホームディレクトリを作成するとき、管理サーバは［ユーザの作成］ウィザードの［ホームディレクトリ］フィールドで指定されたパスを使用します。ユーザプロパティウィンドウの［プロファイル］タブを使ってこのパスを後で変更でき、DRAはホームディレクトリを新しい場所に移動します。これらのフィールドに値を指定しなかった場合、そのユーザアカウントのホームディレクトリは作成されません。
DRAは、［Home directory permissions (ホームディレクトリ権限)］という選択されたオプションに基づいて新しいディレクトリのセキュリティを設定します。これらのオプションを使用することで、すべてのホームディレクトリに対する一般的なアクセスを制御できます。
たとえば、各自のユーザホームディレクトリが属している共有に対して、管理者グループのメンバーはフルコントロール権限を持ち、ヘルプデスクグループのメンバーは読み込みアクセス権限を持つように指定することができます。その後DRAがユーザホームディレクトリを作成すると、その新しいホームディレクトリは親ディレクトリからこれらの権限を継承できます。したがって、管理者グループのメンバーはすべてのユーザホームディレクトリに対してフルコントロール権限を持ち、ヘルプデスクグループのメンバーはすべてのユーザホームディレクトリに対して読み込みアクセス権限を持つことになります。
すでに存在するホームディレクトリを指定した場合、新しいホームディレクトリは作成されず、既存のディレクトリに対する権限は変更されません。
このルールは、DRAが以下のアクションを自動的に実行できるようにします。
新しいホームディレクトリパスが指定されたときにホームディレクトリを作成する
ホームディレクトリパスが変更されたときにホームディレクトリの内容を移動する
ユーザカウントの名前が変更されたときにホームディレクトリの名前を変更する
ユーザカウントの名前を変更すると、新しいアカウント名に基づいて既存のホームディレクトリの名前も変更されます。既存のホームディレクトリが使用中の場合は、新しいホームディレクトリが作成され、既存のホームディレクトリは変更されません。
元のホームディレクトリと新しいホームディレクトリの名前と場所が同じ場合は、ホームディレクトリの名前を変更できます。ただし、ディレクトリの名前変更が失敗すると、新しいホームディレクトリが作成され、元のホームディレクトリの内容が新しいホームディレクトリに移動されて、元のホームディレクトリは削除されます。
ホームディレクトリのパスを変更すると、指定したホームディレクトリが新しく作成され、元のホームディレクトリの内容が新しい場所に移動されます。また、元のホームディレクトリから内容を移動せずにホームディレクトリを作成するように、ホームディレクトリのポリシーを設定することもできます。元のディレクトリで割り当てられていたACLも、新しいディレクトリに適用されます。すでに存在するホームディレクトリを指定した場合、新しいホームディレクトリは作成されず、既存のディレクトリに対する権限は変更されません。元のホームディレクトリがロックされていなければ、そのディレクトリは削除されます。
DRAがホームディレクトリの名前変更に失敗した場合、DRAは新しい名前で新しいホームディレクトリを作成し、元のホームディレクトリの内容を新しいホームディレクトリにコピーしようとします。その後、元のホームディレクトリを削除しようと試みます。元のホームディレクトリの内容を新しいホームディレクトリにコピーしないようにDRAを設定し、元のホームディレクトリの内容を手動で新しいホームディレクトリに移動することもできます。これにより、開いているファイルをコピーするなどの問題を回避できます。
DRAが元のホームディレクトリを削除する際には、元のホームディレクトリから読み取り専用ファイルおよびサブディレクトリを削除するための明示的な権限を必要とします。元のホームディレクトリを読み取り専用ファイルおよびサブディレクトリを削除する権限を、DRAに明示的に与えることができます。
DRAでは、ファイルサーバ上のホーム共有について、許可される親ディレクトリまたはパスを指定できます。指定するディレクトリまたはファイルサーバパスが多い場合は、それらのパスをCSVファイルにエクスポートして、DRAコンソールを使ってCSVファイルからDRAにパスを追加することができます。DRAは、以下のことを保証するために、［Allowable parent paths (指定可能な親パス)］というフィールドに入力された情報を使用します。
アシスタント管理者がユーザアカウントとユーザアカウントのホームディレクトリを削除したときに、DRAはファイルサーバ上の親ディレクトリを削除しない。
ユーザアカウントの名前が変更されるか、ユーザアカウントのホームディレクトリパスが変更されたときに、DRAがホームディレクトリを有効な親ディレクトリまたはファイルサーバ上のパスに移動する。
このルールは、ユーザアカウントが削除されたときに、それに関連付けられたホームディレクトリをDRAが自動的に削除できるようにします。ごみ箱が有効になっている場合には、ユーザアカウントがごみ箱から削除されるまでは、ホームディレクトリは削除されません。DRAがホームディレクトリを削除する際には、そのホームディレクトリから読み取り専用ファイルおよびサブディレクトリを削除するための明示的な権限を必要とします。元のホームディレクトリを読み取り専用ファイルおよびサブディレクトリを削除する権限を、DRAに明示的に与えることができます。
DRAは、ユーザアカウントが変更されるかホームディレクトリが管理されたときにホーム共有を管理することによって、ホーム共有保守タスクを自動化します。DRAは、ユーザアカウントの作成、クローン作成、変更、名前変更、または削除が行われたときに、それぞれ異なるアクションを実行できます。
適切なMicrosoft Windowsセキュリティポリシーと矛盾しないように、DRAは共有名レベルではアクセス制御の制限を作成しません。代わりに、ディレクトリレベルでのみアクセス制御の制限を作成します。共有名レベルとファイルまたはディレクトリオブジェクトレベルの両方でアクセス制御の制限を課すると、多くの場合、管理者およびユーザにとって混乱を招くアクセススキームとなります。
メモ:指定する場所は、HOMEDIRSのような共通のホーム共有をホームディレクトリの1レベル上に持っている必要があります。
たとえば、次のパスは有効です。\\HOUSERV1\HOMEDIRS\%username%
次のパスは無効です。\\HOUSERV1\%username%
共有ホームディレクトリの自動化ルールを定義するときに、自動的に作成される各共有ホームディレクトリについてプレフィックスおよびサフィックスを指定できます。プレフィックスまたはサフィックスを指定することにより、共有ホームディレクトリに命名規則を強制できます。
たとえば、Create home directoryおよびCreate home shareという自動化ルールを有効にしたとします。さらに、共有ホームディレクトリについて、プレフィックスとしてアンダスコア(_)、サフィックスとしてドル記号($)を指定したとします。TomSという名前のユーザを作成するとき、このユーザの新しいディレクトリをUドライブにマッピングして、ディレクトリパスとして\\HOUSERV1\HOMEDIRS\%username%と指定します。この例では、DRAが_TomS$という名前のネットワーク共有を作成し、それが\\HOUSERV1\HOMEDIRS\TomSというディレクトリが指しています。
DRAがホーム共有を作成すると、管理サーバは［ユーザの作成］ウィザードの［ホームディレクトリ］フィールドで指定されたパスを使用します。その後、ユーザプロパティウィンドウの［プロファイル］タブを使ってこのパスを変更できます。
DRAは、プレフィックスとサフィックスが指定されていれば、それらをユーザ名に付け加えて共有名を作成します。長いユーザカウント名が使用された場合は、指定されたホーム共有プレフィックスおよびサフィックスを付け加えられないことがあります。プレフィックスとサフィックス、および許可される接続の数は、選択されたホーム共有作成オプションに基づいて決められます。
新しく作成されたユーザアカウント名から生成された共有ホームディレクトリ名がすでに存在する場合、DRAは既存の共有を削除して、指定されたホームディレクトリに対して新しい共有を作成します。
ユーザアカウントのクローンを作成するときには、既存のユーザアカウントの共有名が存在していなければなりません。ユーザアカウントのクローンが作成されると、DRAはホームディレクトリ情報のクローンも作成して、その情報を新しいユーザ用にカスタマイズします。
ホームディレクトリの場所を変更すると、既存の共有は削除され、新しいホームディレクトリに対して新しい共有が作成されます。元のホームディレクトリが空の場合、元のディレクトリは削除されます。
ユーザアカウントの名前を変更すると、既存のホーム共有は削除され、新しいアカウント名に基づいて新しい共有が作成されます。新しい共有ディレクトリは、既存のホームディレクトリをポイントします。
ユーザアカウントを永久に削除すると、その共有ホームディレクトリも削除されます。
DRAでは、ホームボリュームのディスククォータを管理できます。このポリシーは、Microsoft Windowsコンピュータにある、ホームディレクトリが存在するネーティブドメイン内で実装できます。このポリシーを実装する場合は、十分な領域を確保するために、ディスククォータを少なくとも25MBに指定する必要があります。
この機能では、DRAの生成するパスワードのポリシー設定を指定することができます。DRAはユーザ作成のパスワードに対するこれらの設定を強制しません。パスワードポリシーのプロパティを設定する場合、パスワードの長さを6文字以上で127文字以下にする必要があります。パスワード長以外のすべての値がゼロに設定できます。
パスワード生成ポリシーを設定するには、［Policy and Automation Management］>［Configure Password Generation Policies (パスワード生成ポリシーを設定)］の順に選択し、［Enable Password Policy (パスワードポリシーを有効にする)］チェックボックスを選択してください。［Password Settings (パスワード設定)］をクリックし、パスワードポリシーのプロパティを設定します。
ポリシーを消去、有効化、無効化するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。
これらのアクションのいずれかを実行するには、［Policy and Automation Management］>［ポリシー］の順に選択します。右側のペインで削除、有効化、または無効化するポリシーを右クリックし、目的のアクションを選択します。
組み込みポリシーを実装にするには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。組み込みのポリシーの詳細については、「組み込みポリシーについて」を参照してください。
メモ:組み込みポリシーをアシスタント管理者およびActiveViewと関連付ける前に、まずそのアシスタント管理者がそのActiveViewに割り当てられているか確認してください。
組み込みポリシーを実装するには:
［Policy and Automation Management］>［ポリシー］の順に選択します。
［タスク］メニューで［New Policy (新規のポリシー)］をクリックし、作成する組み込みポリシーのタイプを選択します。
各ウィザードウィンドウで適切な値を指定して［次へ］をクリックします。たとえば、この新しいポリシーを特定のActiveViewに関連付けて、そのActiveViewに含まれるオブジェクトにこのポリシーが強制されるようにすることができます。
サマリの内容を確認し［完了］をクリックします。
カスタムポリシーを実装するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。
カスタムポリシーを正しく実装するには、特定の操作(管理タスク)の最中に実行されるスクリプトを作成する必要があります。カスタムポリシースクリプトの中では、アクションがポリシーに違反したときに表示されるエラーメッセージを定義できます。また、Create Policyウィザードでデフォルトのエラーメッセージを指定することもできます。
カスタムポリシーの作成方法、管理操作のリスト、および引数配列の使用方法については、SDKを参照してください。詳細については、「カスタムポリシースクリプトまたは実行ファイルの作成」を参照してください。
メモ:
カスタムポリシーをアシスタント管理者およびActiveViewと関連付ける前に、まずそのアシスタント管理者がそのActiveViewに割り当てられているか確認してください。
カスタムポリシースクリプトまたは実行ファイルのパスにスペースが含まれている場合は、パス全体を引用符(")で囲んでください。
カスタムポリシーを実装するには:
ポリシースクリプトまたは実行ファイルを作成します。
管理対象ドメイン内でManage Policies and Automation Triggersという組み込みの役割を割り当てられているアカウントを使って、DRAのクライアントコンピュータにログオンします。
Delegation and Configurationコンソールを起動します。
プライマリ管理サーバに接続します。
左側のペインで、Policy and Automation Managementを展開します。
［ポリシー］をクリックします。
［タスク］メニューで［New Policy (新規のポリシー)］>［Create a Custom Policy (カスタムポリシーを作成)］の順にクリックします。
各ウィザードウィンドウで適切な値を指定して［次へ］をクリックします。たとえば、この新しいポリシーを特定のActiveViewに関連付けて、そのActiveViewに含まれるオブジェクトにこのポリシーが強制されるようにすることができます。
サマリの内容を確認し［完了］をクリックします。
ポリシーのプロパティを変更するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。
ポリシーのプロパティを変更するには:
［Policy and Automation Management］>［ポリシー］の順に選択します。
変更するポリシーを右クリックして［プロパティ］を選択します。
このポリシーについて適切なプロパティと設定を変更します。
カスタムポリシースクリプトまたは実行ファイルの作成方法については、SDKを参照してください。
SDKにアクセスする手順は、次のとおりです。
コンピュータにSDKがインストールされていることを確認します。セットアッププログラムがDirectory and Resource Administratorプログラムグループの中にSDKのショートカットを作成しています。詳細については、「DRA管理サーバのインストール」のインストール時チェックリストを参照してください。
Directory and Resource Administratorプログラムグループ内のSDKのショートカットをクリックします。
SDKの詳細については、DRAマニュアルのサイトで『DRA REST Services Guide
』を参照してください。
自動命名ポリシーには、ExchangeポリシーのうちのDelegation and Configurationのクライアント専用のポリシー設定が3つ含まれます。これはクライアント側のポリシーであることを意味します。
自動命名ポリシーを使用すると、メールボックスの特定のプロパティについて、自動化された命名ルールを指定することができます。これらのオプションを使用すると、命名規則を確立し、表示名、ディレクトリ名、およびエイリアスのプロパティの標準値を迅速に生成することができます。Exchangeでは、いくつかの自動命名オプションとして、%Firstや%Lastなどの置換文字列が指定できます。
Exchangeは、ディレクトリ名またはエイリアスを生成するときに、生成された値が他と重複しない固有のものであるかどうかをチェックします。生成された値が他と重複する場合、Exchangeはその値を固有の値にするために値の最後にハイフン(-)と2桁の番号を付け加えます(そのような値は-01から始まる)。Exchangeは、表示名を生成するときに、その値が他と重複しない固有のものであるかどうかをチェックしません。
Exchangeは、自動命名ポリシーとプロキシ生成のポリシーに関し、次に挙げる置換文字列をサポートしています。
|
%最初の列 |
関連付けられたユーザアカウントのFirst name（名）プロパティの値を示します。 |
|---|---|
|
%最終 |
関連付けられたユーザアカウントのLast name（姓）プロパティの値を示します。 |
|
%Initials |
関連付けられたユーザアカウントのInitials（頭文字）プロパティの値を示します。 |
|
%別名 |
メールボックスプロパティAlias（エイリアス）の値を示します。 |
|
%DirNam |
メールボックスプロパティDirectory name（ディレクトリ名）の値を示します。Exchangeは、Microsoft Exchangeのメールボックス用に電子メールアドレスを生成する際に、変数%DirNameを指定するプロキシ生成文字列をサポートしません。 |
|
%ユーザ名 |
関連付けられたユーザアカウントのUser name（ユーザ名）プロパティの値を示します。 |
パーセント記号(%)と置換文字列名の間に数値を指定することもできます。その数値は、置換文字列のうち何文字まで含めるかを示します。たとえば%2Firstは、ユーザアカウントの「First」という名前プロパティの文字列の最初の2文字を示します。
各自動命名ルールまたはプロキシ生成ポリシーには、1つ以上の置換文字列を含めることができます。また、各ルールの中で文字を特定の置換文字列のプレフィックスまたはサフィックスとして指定することもできます。たとえば、置換文字列%Initialsの後に付けるピリオドとスペース(. )などです。Exchangeでは、置換文字列のプロパティが空白の場合、そのプロパティのサフィックスを含めません。
たとえば、名前プロパティのDisplayに関して、次に示す自動命名ルールについて考えてみましょう。
%First %1Initials. %Last
名前プロパティのFirstがSusan、InitialsがMay、LastがSmithだった場合、Exchangeは名前プロパティのDisplayを「Susan M. Smith」に設定します。
名前プロパティのFirstがMichael、Initialsが空白、LastがJonesだった場合、Exchangeは名前プロパティのDisplayを「Michael Jones」に設定します。
メールボックス自動命名オプションを指定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。また、ご使用のライセンスがExchange製品をサポートしている必要があります。
メールボックス自動命名ポリシーを指定するには:
［Policy and Automation Management］>［Configure Exchange Policies (Exchangeポリシーを設定)］>［Alias naming (エイリアスの命名)］の順に選択します。
適切な名前生成情報を指定します。
［Enforce alias naming rules during mailbox updates (メールボックスの更新中にエイリアス命名ルールを強制する)］を選択します。
［OK］をクリックします。
リソース自動命名オプションを指定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。また、使用しているライセンスがExchange製品をサポートしている必要があります。
リソースの命名ポリシーを指定するには:
［Policy and Automation Management］>［Configure Exchange Policies (Exchangeポリシーを設定)］>［Resource naming (リソースの命名)］の順に選択します。
適切なリソース名生成情報を指定します。
［Enforce resource naming rules during mailbox updates (メールボックスの更新中にリソース命名ルールを強制する)］を選択します。
［OK］をクリックします。
アーカイブ自動命名オプションを指定するには、Manage Policies and Automation Triggersという組み込みの役割に含まれている権限のような、適切な権限が必要です。また、使用しているライセンスがExchange製品をサポートしている必要があります。
アーカイブの命名ポリシーを指定するには:
［Policy and Automation Management］>［Configure Exchange Policies (Exchangeポリシーを設定)］>［Archive naming (アーカイブの命名)］の順に選択します。
ユーザアカウントに対する適切なアーカイブ名生成情報を指定します。
［Enforce archive naming rules during mailbox updates (メールボックスの更新中にアーカイブ命名ルールを強制する)］を選択します。
［OK］をクリックします。