19 ユーザーおよびグループの管理
次の各トピックでは、コマンド行ユーティリティおよびOracle Unified Directory Services Manager (OUDSM)インタフェースを使用して、これらの要素を構成する方法を説明します。
ユーザー・パスワードの詳細は、「パスワード・ポリシーの管理」を参照してください。
19.1 ユーザー・アカウントの管理
ユーザー・アカウントは基本的に、ディレクトリで作成、変更または削除するユーザー・エントリです。コマンド行ユーティリティを使用して、ユーザー・アカウントおよびパスワードを管理できます。
ユーザー・アカウントの管理を開始する前に、ディレクトリ・サーバーに適切なパスワード・ポリシーが設定されていることを確認してください。詳細は、「パスワード・ポリシーの管理」を参照してください。
次の各トピックでは、manage-accountおよびldappasswordmodifyコマンド行ユーティリティを使用して、ユーザー・アカウントおよびパスワードを管理する方法を説明します。
19.1.1 パスワードの変更
ディレクトリ管理者は、他のユーザーのパスワードの作成、リセットまたは削除を求められることがよくあります。パスワードの変更は、ldappasswordmodifyユーティリティを使用して実行できます。
ldappasswordmodifyユーティリティを使用すると、LDAPパスワード変更拡張操作でユーザーのパスワードを変更またはリセットできます。--authzidオプションを使用して、dn:またはu:を接頭辞として付けるか、または完全なDNを指定することによって、認可IDを指定できます。
次の各トピックでは、パスワードの管理方法について説明します。
19.1.1.1 ディレクトリ・マネージャのパスワードの変更
ディレクトリ・マネージャのパスワードを変更するには、ldappasswordmodifyコマンドを使用します。
次の例で示しているように、ldappasswordmodifyコマンドを使用します:
$ ldappasswordmodify -h localhost -p 1389 \ --authzID "dn:cn=Directory Manager" \ --currentPassword password --newPassword mynewpassword The LDAP password modify operation was successful.
19.1.1.2 ユーザーの新規パスワードのリセットおよび生成
この例では、ユーザーは既存のパスワードを覚えていないことが前提となっています。
次の例で示しているように、ldappasswordmodifyコマンドを使用します:
$ ldappasswordmodify -h localhost -p 1389 -D "cn=Directory Manager" \ -j pwd-file --authzID u:jvedder The LDAP password modify operation was successful Generated Password: evx07npv
19.1.1.3 ユーザーのパスワードの変更
この例では、ユーザーは既存のパスワードを覚えていることが前提となっています。新規パスワードは、指定したファイルでサーバーに渡されます。
次の例で示しているように、ldappasswordmodifyコマンドを使用します:
$ ldappasswordmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --authzID uid=jvedder,ou=People,dc=example,dc=com \ --currentPassword password --newPasswordFile pwdFile The LDAP password modify operation was successful
19.1.2 ユーザーのアカウント情報の管理
ユーザーのアカウントおよびそのユーザーに適用されているパスワード・ポリシーに関する情報を表示するには、manage-accountコマンドを使用します。
manage-accountコマンドを使用して、ユーザーのアカウントを有効または無効にすることもできます。manage-accountコマンドは、管理ポート経由でSSLを使用してサーバーにアクセスします。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
次の各トピックでは、ユーザーのアカウント情報の管理方法について説明します。
19.1.2.1 ユーザーのアカウント情報の表示
manage-accountコマンドを使用して、ユーザーのアカウント情報を表示します。
manage-accountコマンドは、ユーザー・アカウントに適用されているパスワード・ポリシーのDN、アカウント・ステータス、およびパスワードとログイン関連情報を返します。
19.1.2.2 アカウント・ステータス情報の表示
アカウントが有効か無効かを評価するには、manage-accountコマンドを使用します。
次の例で示しているように、manage-accountコマンドをget-account-is-disabledサブコマンドとともに使用します:
$ manage-account -D "cn=directory manager" -j pwd-file get-account-is-disabled \ --targetDN "uid=kvaughan,ou=People,dc=example,dc=com" Account Is Disabled: false
19.1.2.3 アカウントの無効化
アカウントを無効にするには、manage-accountコマンドを使用します。
アカウントを無効にするには、次の例に示すように、manage-accountコマンドをset-account-is-disabledサブコマンドとともに使用します。
$ manage-account -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X \ set-account-is-disabled --operationValue true \ --targetDN "uid=kvaughan,ou=People,dc=example,dc=com" Account Is Disabled: true
19.1.2.4 アカウントの有効化
アカウントを有効にするには、manage-accountコマンドを使用します。
アカウントを有効にするには、次の例に示すように、manage-accountコマンドをclear-account-is-disabledサブコマンドとともに使用します。
$ manage-account -D "cn=directory manager" -j pwd-file clear-account-is-disabled \ --targetDN "uid=kvaughan,ou=People,dc=example,dc=com" Account Is Disabled: false
19.1.3 ユーザー・アカウントへのリソース制限の割当て
リソース制限は、特定の操作属性をユーザー・エントリに追加することによってユーザー・アカウントに割り当てられます。
次の各トピックでは、リソース制限の概念とそれらの制限をユーザー・アカウントに設定する方法について説明します。
19.1.3.1 ユーザー・アカウントへのリソース制限について
リソース制限をエントリに割り当てることによって、クライアント・アカウントごとにサーバー上での検索操作を制御できます。リソース制限は、特定の操作属性をユーザー・エントリに追加することによって割り当てられます。その上で、ディレクトリ・サーバーで、クライアントがディレクトリへのバインドに使用するアカウントに基づいて制限が施行されます。
特定のユーザー・アカウントに対して設定したリソース制限は、サーバー規模の構成で設定したリソース制限より優先されます。リソース制限の構成可能なプロパティすべての詳細は、『Oracle Unified Directory構成リファレンス』のグローバル構成に関する項を参照してください。
設定できる制限は次のとおりです:
-
検索制限。検索操作で調べるエントリの最大数が指定されます。
ds-rlim-lookthrough-limit操作属性を使用します。 -
サイズ制限。検索操作のレスポンスとして返されるエントリの最大数が指定されます。
ds-rlim-size-limit操作属性を使用します。 -
時間制限。検索操作の処理に費やせる最大時間が指定されます。
ds-rlim-time-limit操作属性を使用します。
ノート:
デフォルトで、ディレクトリ・マネージャでは無制限にリソースを使用できます。
19.2 ルート・ユーザーの構成
ルート・ユーザーの構成は、コマンド行ユーティリティおよびOUDSMインタフェースを使用して実行します。
19.2.1 ルート・ユーザーについて
ルート・ユーザーは、アクセス制御および通常のユーザーに施行されている可能性のあるその他の制限をバイパスできるアカウントを持つ特別なユーザーです。
複数のルート・ユーザーを定義して、各ルート・ユーザーに個別の資格証明セットを指定し、ファイングレイン・レベルでアクセスを制御できます。たとえば、特定のタスクに対するルート・アクセス権が必要だが、完全なルート・ユーザー権限セットは必要ではないユーザーに権限を割り当てることができます。Oracle Unified Directoryを使用すると、各ルート・ユーザーが独自の強固な認証メカニズム(GSSAPI SASLなど)、固有のパスワード・ポリシーおよび独自のリソース制限を持つように各ルート・ユーザーを構成できます。
デフォルトで、一連のグローバル・ルート・ユーザー権限が定義されます。これらの権限は、ルート・ユーザー・エントリの権限を変更しないかぎり、デフォルトのルート・ユーザーを含めて、すべての構成済ルート・ユーザーに適用されます。すべてのルート・ユーザーに継承されるグローバル・ルート・ユーザー権限を変更できます。
セットアップ・プロセス中に、完全な管理権限を持つデフォルトのルート・ユーザーが作成されます。このルート・ユーザーに対してセットアップで提示されるDNは"cn=directory manager"であるため、セットアップで提示されるデフォルト値を変更しないと、DNが"cn=directory manager,cn=Root DNs,cn=config"のルート・ユーザーが構成されます。
19.2.2 コマンド行ユーティリティを使用したルート・ユーザーの構成
コマンド行ユーティリティを使用して、グローバル・ルート・ユーザーのプロパティを表示および編集できます。
グローバル・ルート・ユーザーのプロパティを表示および編集するには、dsconfigコマンドを使用します。追加のルート・ユーザーを作成および管理するには、ldapmodifyコマンドを使用して、ユーザー・エントリをサーバー構成に追加する必要があります。次の各項では、コマンド行を使用してルート・ユーザーを管理する方法を説明します。
19.2.2.1 グローバル・ルート・ユーザーの権限の変更
dsconfigコマンドを使用して、グローバル・ルート・ユーザーの権限を変更できます。
グローバル・ルート・ユーザーの権限を表示するには、次のdsconfigコマンドを実行します:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \
get-root-dn-prop
Property : Value(s)
----------------------------:--------------------------------------------------
default-root-privilege-name : backend-backup, backend-restore, bypass-acl,
: bypass-lockdown, cancel-request, config-read,
: config-write, disconnect-client, ldif-export,
: ldif-import, modify-acl, password-reset,
: privilege-change, server-restart,
: server-shutdown, subentry-write,
: unindexed-search, update-schema
グローバル・ルート・ユーザーの権限を変更するには、dsconfig set-root-dn-propコマンドを--addオプションまたは--removeオプションを指定して実行します。
次の例では、サーバーでのバックアップまたはリストア操作を実行するための、ルート・ユーザーのデフォルトの権限が削除されます。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n \ set-root-dn-prop --remove default-root-privilege-name:backend-backup \ --remove default-root-privilege-name:backend-restore
権限の全リストおよび各権限の説明は、「特権サブシステムの理解」を参照してください。
19.2.2.2 新規ルート・ユーザーの作成
LDIFファイル内のエントリを使用して、新規ルート・ユーザーを作成できます。
新規ルート・ユーザーを作成するには、LDIFファイルにユーザー・エントリを作成してから、ldapmodifyコマンドを使用して、そのエントリをサーバー構成のcn=Root DNs,cn=configブランチに追加します。
ノート:
cn=config接尾辞は、管理接尾辞であるため、管理コネクタを使用してアクセスする必要があります。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
たとえば、特定のユーザーにデータベースのバックアップおよびリストアを行う権限を付与するが、その他の管理権限は付与しない場合、次のように実行します。
権限の全リストおよび各権限の説明は、「特権サブシステムの理解」を参照してください。
19.2.2.3 ldapmodifyコマンドを使用した既存のルート・ユーザーの編集
ldapmodifyコマンドを使用して、既存のルート・ユーザーを編集できます。
既存のルート・ユーザーを編集するには、ldapmodifyコマンドを使用して、サーバー構成のcn=Root DNs,cn=configブランチにあるユーザー・エントリの属性を変更します。
ノート:
cn=config接尾辞は、管理接尾辞であるため、管理コネクタを使用してアクセスする必要があります。詳細は、「サーバーへの管理トラフィックの管理」を参照してください。
次の例では、前述の例で作成したルート・ユーザーのリストア操作を実行する機能が削除されます。
$ ldapmodify -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL -X dn: cn=backup-admin,cn=root DNs,cn=config changetype: modify delete: ds-privilege-name ds-privilege-name: backend-restore
19.2.3 OUDSMを使用したルート・ユーザーの構成
OUDSMインタフェースを使用して、デフォルトのルート・ユーザーを表示および編集したり、追加のルート・ユーザーを作成および管理することができます。
次の各トピックでは、OUDSMインタフェースを使用してルート・ユーザーを構成する方法について説明します。
19.2.3.1 グローバル・ルート・ユーザーの権限の構成
デフォルトで、一連のグローバル・ルート・ユーザー権限が定義されます。これらの権限は、ルート・ユーザー・エントリの権限を変更しないかぎり、すべての構成済ルート・ユーザーに適用されます。
OUDSMを使用してグローバル・ルート・ユーザーの権限を変更するには:
19.2.3.2 新規ルート・ユーザーの作成
OUDSMを使用して、新規ルート・ユーザーを作成できます。
OUDSMを使用して新規ルート・ユーザーを作成するには:
-
「OUDSMを使用したサーバーへの接続」の説明に従って、OUDSMからディレクトリ・サーバーに接続します。
-
「構成」タブを選択します。
-
「作成」メニューから、「ルート・ユーザー」を選択します。
-
「一般プロパティ」リージョンで、次の詳細を入力します:
-
「名前」フィールドに、作成するルート・ユーザーの名前を入力します。
-
「代替バインドDN」リージョンで、「追加」をクリックして、対象のルート・ユーザーがサーバーにバインドする際に使用可能な1つ以上の代替DNを指定します。
たとえば、デフォルトのルート・ユーザーの代替バインドDNは、
"cn=Directory Manager"です。これを使用すると、実際のエントリDNである"cn=Directory Manager,cn=Root DNs,cn=config"を使用する必要なく、"cn=Directory Manager"としてバインドできます。代替バインドDNは、すべてのルート・ユーザーにおいて一意である必要があります。
新規ルート・ユーザーに代替バインドDNを指定しない場合は、表を空のままにしておきます。
-
「パスワード」フィールドに、このルート・ユーザーのパスワードを入力します。
-
「パスワードの確認」フィールドに、このルート・ユーザーのパスワードを再入力します。
-
-
「特権」リージョンで、この新規ルート・ユーザーに適用する必要のある様々な権限の設定を選択します。
権限ごとに、次のいずれかを選択できます:
-
Enable。このルート・ユーザーに対して、この権限を有効にします。 -
Disable。このルート・ユーザーに対して、この権限を無効にします。 -
Default Privilege (enable)またはDefault Privilege (disable):グローバル権限構成で定義されているとおりに、ユーザーは、この権限のデフォルトの設定を継承します。
-
-
「作成」をクリックします。
次の確認メッセージが表示されます:
ルート・ユーザーは正常に作成されました。
19.3 グループの定義
Oracle Unified Directoryを使用してグループを定義できます。Oracle Unified Directoryでは、単一オブジェクトとして管理可能な、エントリのコレクションであるグループがサポートされます。通常、ディレクトリ管理者は、プリンタのグループ、ソフトウェア・アプリケーションのグループ、従業員のグループなどを構成します。
グループは、一連のユーザーに特別なアクセス権を割り当てる場合に特に有用です。たとえば、アクセス・マネージャのグループを構成し、機密の従業員データを表示できる権限を割り当てる一方で、社内の他のユーザーにはそのデータへのアクセスを制限できます。
次のグループ・タイプがサポートされています:
-
静的グループ。詳細は、「静的グループの定義」を参照してください。
-
動的グループ。詳細は、「動的グループの定義」を参照してください。
-
仮想静的グループ。詳細は、「仮想静的グループの定義」を参照してください。
この項では、ネストされたグループについても説明します。詳細は、「ネストされたグループの定義」を参照してください。
19.3.1 静的グループの定義
静的グループでは、groupOfNames、groupOfUniqueNamesまたはgroupOfEntriesオブジェクト・クラスを使用して、識別名(DN)の明示的セットを指定することによって、メンバーシップが定義されます。静的グループは、外部クライアントで適切にサポートされ、良好なパフォーマンスを実現します。
この項では、次の項目について説明します。
19.3.1.1 静的グループの概要
静的グループは、エントリに明示的なDNのメンバーシップ・リストが含まれるグループです。多くのクライアントで静的グループがサポートされますが、グループ内のメンバー数が多くなってくると、静的グループの管理は難しくなってきます。
たとえば、DN変更が必要なメンバー・エントリがある場合、そのユーザーの所属先の各グループのユーザーDNを変更する必要があります。
ディレクトリ・サーバーでは、使用するオブジェクト・クラスに応じて分類された、次の3つのタイプの静的グループがサポートされます:
-
groupOfNames。groupOfNamesオブジェクト・クラスを使用し、member属性を使用してメンバーDNを明示的に指定することによって、静的グループを定義できます。ノート:
RFC 4519 (
https://www.ietf.org/rfc/rfc4519.txt)では、groupOfNamesオブジェクト・クラス内でmember属性を必須とすることが求められます。従来、このメンバーシップ要件によって、管理者がグループ内の最後のメンバーを削除しようとしたときにデータ管理上の問題が発生します。ディレクトリ・サーバーでは、member属性をオプションにできるため、この問題が解決されます。このオプションのメンバーシップ要件では、グループの最後のメンバーを削除するときに、オブジェクト・クラスを空にできます。dn: cn=Example Static Group 1,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfNames member: uid=user1,ou=People,dc=example,dc=com member: uid=user2,ou=People,dc=example,dc=com cn: Example Static Group 1
-
groupOfUniqueNames。groupOfUniqueNamesオブジェクト・クラスを使用し、uniqueMember属性を使用してメンバーDNを明示的に指定することによって、静的グループを定義できます。groupOfUniqueNamesオブジェクト・クラスでは、groupOfNamesオブジェクト・クラスとは異なり、一意のDNに加えてオプションの識別子を指定することによって、グループのメンバーを列挙できます。この識別子によって、いずれかのオブジェクトを追加、削除または名前変更したときに一意のオブジェクトを必ず識別できるようになります。たとえば、従業員(
cn=Tom Smith)を削除して、名前(cn=Tom Smith)が同じ新規従業員をディレクトリに追加するとします。2人を区別するには、ビット文字列を使用して個別の識別子を追加する必要があります。次の例では、2人のユーザーの名前は同じですが、2番目のuniqueMemberにはオプションの識別子が指定されています。uniqueMember: uid=tsmith,ou=People,dc=example,dc=com uniqueMember: uid=tsmith,ou=People,dc=example,dc=com#'0111101'B
ノート:
実際にオプションのUID識別子を使用するLDAPアプリケーションはほとんどありません。
RFC 4519 (
https://www.ietf.org/rfc/rfc4519.txt)では、groupOfUniqueNamesオブジェクト・クラス内でuniqueMember属性を必須とすることが求められます。以前より、このメンバーシップ要件は、管理者がグループ内の最後のメンバーを削除しようとした際にデータ管理上の問題を引き起こす要因となっています。Oracle Unified Directoryでは、uniqueMember属性をオプションにすることによって、この問題が解決されます。このオプションのメンバーシップ要件では、グループの最後のメンバーを削除するときに、オブジェクト・クラスを空にできます。dn: cn=Example Static Group 2,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames uniqueMember: uid=user1,ou=People,dc=example,dc=com uniqueMember: uid=user2,ou=People,dc=example,dc=com cn: Example Static Group 2
-
groupOfEntries。groupOfEntriesオブジェクト・クラスを使用して、静的グループを定義できます。元の仕様(RFC 4519 (http://www.rfc-editor.org/rfc/rfc4519.txt)およびdraft-findlay-ldap-groupofentries-00.txt(2008年3月に失効))に基づいて、groupOfEntriesオブジェクト・クラスは、groupOfNamesおよびgroupOfUniqueNamesオブジェクト・クラスとは、属性がオプションである、つまりメンバーなしで空のオブジェクト・クラスを指定できる点において異なっています。ノート:
Oracle Unified Directoryでは、
groupOfEntriesドラフトがサポートされますが、空のgroupOfNamesおよびgroupOfUniqueNamesオブジェクト・クラスも使用できます。このため、任意のタイプ(groupOfEntries、groupOfNamesおよびgroupOfUniqueNames)の空のグループを作成できます。dn: cn=Example Static Group 3,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfEntries cn: Example Static Group 3
19.3.1.2 groupOfNamesを使用した静的グループの作成
この手順では、groupOfNamesコマンドを使用して静的グループを作成する方法について説明します。
groupOfNamesをオブジェクト・クラスとして使用して静的グループを作成するには:
19.3.1.3 groupOfUniqueNamesを使用した静的グループの作成
この手順では、groupOfUniqueNamesをオブジェクト・クラスとして使用して静的グループを作成する方法について説明します。
groupOfUniqueNamesをオブジェクト・クラスとして使用して静的グループを作成するには:
19.3.1.4 groupOfEntriesを使用した静的グループの作成
この手順では、groupOfEntriesをオブジェクト・クラスとして使用して静的グループを作成する方法について説明します。
groupOfEntriesをオブジェクト・クラスとして使用して静的グループを作成するには:
19.3.1.5 静的グループのすべてのメンバーの表示
isMemberOf仮想属性を使用してグループを検索します。この属性は、検索の開始時にユーザー・エントリに追加され、検索の終了後に削除されます。この機能によって、読取りアクセスが高速になり、グループの管理が容易になります。
仮想属性isMemberOfとともに、ldapsearchコマンドを使用します。
次の例では、Accounting Managersというグループのメンバーとなっているすべてのユーザーが検索されます。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com \
"(isMemberOf=cn=Accounting Managers,ou=Groups,dc=example,dc=com)"
dn: uid=scarter,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Accounting
ou: People
sn: Carter
facsimiletelephonenumber: +1 408 555 9751
roomnumber: 4612
userpassword: {SSHA}3KiJ51sx2Ug7DxZoq0vA9ZY6uaomevbJUBm7OA==
l: Sunnyvale
cn: Sam Carter
telephonenumber: +1 408 555 4798
givenname: Sam
uid: scarter
mail: scarter@example.com
dn: uid=tmorris,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Accounting
ou: People
sn: Morris
facsimiletelephonenumber: +1 408 555 8473
roomnumber: 4117
userpassword: {SSHA}bjFFHv6k1kbI6fZoCEfqmTj9XOZxWR06gxpKpQ==
l: Santa Clara
cn: Ted Morris
telephonenumber: +1 408 555 9187
givenname: Ted
uid: tmorris
mail: tmorris@example.com19.3.1.6 ユーザーがメンバーになっているすべての静的グループの表示
この手順では、ユーザーがメンバーになっているすべての静的グループを表示する方法について説明します。
次の例で示しているように、ldapsearchおよび仮想属性cn=IsMemberOfを使用して検索します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com "(uid=scarter)" isMemberOf dn: uid=scarter,ou=People,dc=example,dc=com isMemberOf: cn=Accounting Managers,ou=groups,dc=example,dc=com
19.3.1.7 ユーザーがグループのメンバーであるかどうかを確認する方法
ldapsearchコマンドを使用して、ユーザーがグループのメンバーであるかどうかを確認できます。
次の例で示しているように、ldapsearchを使用して検索します:
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b "cn=Account Managers,ou=Groups,dc=example,dc=com" \ "(&(objectclass=groupOfUniqueNames) \ (uniquemember=uid=scarter,ou=People,dc=example,dc=com))" dn: cn=Accounting Managers,ou=groups,dc=example,dc=com objectClass: groupOfUniqueNames objectClass: top ou: groups description: People who can manage accounting entries cn: Accounting Managers uniquemember: uid=scarter, ou=People, dc=example,dc=com uniquemember: uid=tmorris, ou=People, dc=example,dc=com
19.3.2 動的グループの定義
動的グループでは、groupOfUrlsオブジェクト・クラスを使用して、LDAP URLの形式で一連の検索基準を使用し、グループのメンバーシップが定義されます。動的グループでは、多数のメンバー(数百万のエントリ)が適切に処理されます。エントリが更新されると、すべての親グループが自動的に更新されます。
動的グループの短所は、一部のクライアントでサポートされないことです。また、エントリのリスト全体に問合せを実行する必要がある場合、パフォーマンスに悪影響を与えます。このため、動的グループは、エントリ数が多大なグループの場合、または1つのエントリに対して特定のグループ・メンバーシップを指定する必要があるクライアントの場合に最適です。
この節では、以下のトピックについて説明します。
19.3.2.1 動的グループの概要
動的グループは、メンバーシップがリストで明示的に保持されるのではなく、LDAP URLを使用して検索基準によって決定されるグループです。
たとえば、dc=example,dc=comネーミング・コンテキスト内のすべてのマネージャに電子メールを送信するとします。これを行うには、cn=Managers,ou=Groups,dc=example,dc=comと指定した動的グループを作成します。また、電子メール・アドレスのみが返されるように指定します。電子メール・アプリケーションから特定グループのディレクトリの問合せがあると、ディレクトリ・サーバーでは、メンバーシップが動的に計算され、対応する電子メール・アドレスのリストが返されます。
動的グループでは、groupOfURLsオブジェクト・クラスおよびmemberURL属性を使用して、LDAP URLおよびグループのメンバーの特定に使用する基準(検索ベース、スコープおよびフィルタ)が定義されます。ユーザーが動的グループのメンバーかどうかを判別するメカニズムは、定数時間の操作であるため、メンバーが数百万のグループを複数対象とする場合でも、メンバーが数個のグループを1つのみ対象とする場合と同じく効率的に実行されます。ただし、大量のデータに対して検索を行う場合はパフォーマンスに悪影響を及ぼす可能性があるため、検索基準を指定する際には注意が必要です。
19.3.2.3 動的グループのすべてのメンバーの表示
次のプロシージャでは、仮想属性isMemberOfが使用されています。ディレクトリ・サーバーのパフォーマンスに悪影響を与えるため、このプロシージャは非常に大規模なグループには使用しないでください
ldapsearchおよび仮想属性isMemberOfを使用して検索します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b "dc=example,dc=com" \
"(isMemberOf=cn=cupertinoEmployees,ou=Groups,dc=example,dc=com)"
dn: uid=abergin,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Product Testing
ou: People
sn: Bergin
facsimiletelephonenumber: +1 408 555 7472
roomnumber: 3472
userpassword: {SSHA}YcDl0pHLxkd/ouW2jslAk1XaT5SiY4ium5qh8w==
l: Cupertino
cn: Andy Bergin
telephonenumber: +1 408 555 8585
givenname: Andy
uid: abergin
mail: abergin@example.com
...(more entries)...19.3.2.4 ユーザーがメンバーになっているすべての動的グループの表示
この手順では、ldapsearchコマンドを使用して、ユーザーがメンバーになっているすべての動的グループを表示する方法について説明します。
ldapsearchおよび仮想属性isMemberOfを使用して検索します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com "(uid=abergin)" isMemberOf dn: uid=abergin,ou=People,dc=example,dc=com isMemberOf: cn=QA Managers,ou=groups,dc=example,dc=com isMemberOf: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com
19.3.2.5 ユーザーが動的グループのメンバーであるかどうかを確認する方法
ldapsearchコマンドを使用して、ユーザーが動的グループのメンバーであるかどうかを確認します。
次に示すように、ldapsearchおよび仮想属性isMemberOfを使用して検索します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com \
"(&(uid=abergin)(isMemberOf=cn=cupertinoEmployees,ou=Groups,dc=example,dc=com))"
dn: uid=abergin,ou=People,dc=example,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: top
objectClass: organizationalPerson
ou: Product Testing
ou: People
sn: Bergin
facsimiletelephonenumber: +1 408 555 7472
roomnumber: 3472
userpassword: {SSHA}YcDl0pHLxkd/ouW2jslAk1XaT5SiY4ium5qh8w==
l: Cupertino
cn: Andy Bergin
telephonenumber: +1 408 555 8585
givenname: Andy
uid: abergin
mail: abergin@example.com19.3.3 仮想静的グループの定義
仮想静的グループは、各メンバーが、必要に応じて別の動的グループからメンバーシップを定義する仮想属性によって表されることを除いて、外部クライアントに対して静的グループと外観および動作が同様です。
次の各トピックでは、仮想静的グループについて説明します。
19.3.3.1 仮想静的グループの概要
仮想静的グループにより、静的グループのみをサポートするクライアントで動的グループにアクセスできます。
仮想静的グループでは、各エントリが仮想属性を使用することによって静的グループのように動作します。仮想属性は、起動時に動的に指定され、グループ・メンバーシップを指定する操作が動的グループなどの別のグループに渡されます。
仮想静的グループには、groupOfNamesまたはgroupOfUniqueNamesオブジェクト・クラスを含める必要がありますが、memberまたはuniqueMember属性を含めてはいけません。仮想静的グループには、ds-virtual-static-group補助オブジェクト・クラスおよびds-target-group-dn属性も含める必要があります。ds-target-group-dn属性は、実際のグループを参照して、仮想静的グループとしてミラー化するために使用され、memberまたはuniquemember属性のかわりに使用されます。たとえば:
dn: cn=Example Virtual Static Group,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfUniqueNames objectClass: ds-virtual-static-group cn: Example Virtual Static Group ds-target-group-dn: cn=Example Real Group,ou=Groups,dc=example,dc=com
仮想静的グループは、アプリケーションでメンバーシップ属性をターゲットとした検索が実行されるが、実際にはメンバー・セット全体は取得されない場合に最も効率的です。一般的に、アプリケーションでは次のようなフィルタを使用して、ユーザーが、指定のグループのメンバーかどうかの判別が試行されます:
(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=john.doe,\ ou=People,dc=example,dc=com))
メンバー・セットを取得するアプリケーションでは、完全なメンバー・リストを構築するプロセスで負荷がかかる可能性があるため、仮想静的グループは理想的ではない場合があります。
19.3.3.3 仮想静的グループのすべてのメンバーの表示
仮想静的グループの使用は、検索のターゲットがメンバーシップ属性の場合に最適です。このため、次のプロシージャはお薦めできませんが、リストにアクセスする方法を示すために記載しています。
この例では、前の例で作成した動的グループcupertinoEmployeesが使用されています。
ldapsearchおよび仮想属性cn=virtualStaticを使用して検索します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \
-b dc=example,dc=com "(isMemberOf=cn=virtualStatic,ou=Groups,dc=example,dc=com)"
dn: cn=virtualStatic,ou=Groups,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: ds-virtual-static-group
objectClass: top
cn: Virtual Static
uniqueMember: uid=abergin,ou=People,dc=example,dc=com
ds-target-group-dn: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com
ou: Product Testing
ou: People
sn: Bergin
facsimiletelephonenumber: +1 408 555 7472
roomnumber: 3472
userpassword: {SSHA}YcDl0pHLxkd/ouW2jslAk1XaT5SiY4ium5qh8w==
l: Cupertino
cn: Andy Bergin
telephonenumber: +1 408 555 8585
givenname: Andy
uid: abergin
mail: abergin@example.com
...(more entries)...19.3.3.4 ユーザーがメンバーになっているすべての仮想静的グループの表示
この手順では、ldapsearchコマンドを使用して、ユーザーがメンバーになっているすべての仮想静的グループを表示する方法について説明します。
ldapsearchおよび仮想属性isMemberOfを使用して検索します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b dc=example,dc=com "(uid=abergin)" isMemberOf dn: uid=abergin,ou=People,dc=example,dc=com isMemberOf: cn=QA Managers,ou=groups,dc=example,dc=com isMemberOf: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com isMemberOf: cn=virtualStatic,ou=Groups,dc=example,dc=com
19.3.3.5 ユーザーが仮想静的グループのメンバーであるかどうかを確認する方法
この手順では、ユーザーが仮想静的グループのメンバーであるかどうかを確認する方法について説明します。
ldapsearchおよびuniqueMember属性を使用して検索します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ -b "cn=virtualStatic,ou=Groups,dc=example,dc=com" \ "(&(objectclass=groupOfUniqueNames) \ (uniquemember=uid=abergin,ou=People,dc=example,dc=com))" dn: cn=virtualStatic,ou=Groups,dc=example,dc=com objectClass: groupOfUniqueNames objectClass: top objectClass: ds-virtual-static-group ou: Groups ds-target-group-dn: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com cn: Virtual Static cn: virtualStatic
19.3.4 ネストされたグループの定義
グループをネストすることができます。その場合、DNが別のグループ(親)内にリストされる子グループ・エントリとして、1つのグループが定義されます。
次の各トピックでは、ネストされたグループの概念とネストされたグループを作成する方法について説明します。
19.3.4.1 ネストされたグループについて
グループをネストすると、パフォーマンスが優先されない場合に、継承グループ・メンバーシップを設定できます。
グループをネストすることができます。その場合、DNが別のグループ(親)内にリストされる子グループ・エントリとして、1つのグループが定義されます。グループをネストすると、パフォーマンスが優先されない場合に、継承グループ・メンバーシップを設定できます。0個以上のメンバー属性を、静的グループおよび動的グループを含め、ネストされた子グループのDNにそのメンバー属性の値を設定して追加できます。
19.4 参照整合性の保持
参照整合性とは、削除操作、名前変更操作または移動操作の後にすべての参照が適切に保持されるようにするためのデータベース・メカニズムです。たとえば、1つのエントリをディレクトリから削除した場合、ディレクトリ・サーバーではそのエントリがメンバーとしてリストされていたすべてのグループからもそのエントリが削除されます。
参照整合性メカニズムは、ディレクトリ・サーバーのプラグインとして構成され、dsconfigコマンドを使用して有効化できます。詳細は、「dsconfigを使用したサーバー構成の管理」を参照してください。
次の各トピックでは、参照整合性プラグインについて説明します。
19.4.1 参照整合性プラグインの概要
デフォルトでは、参照整合性プラグインは無効となります。dsconfigを使用してこのプラグインを有効にすると、削除操作、名前変更操作または移動操作の後に、member属性およびuniquemember属性で整合性の更新が実行されます。
参照整合性プラグインは、update-interval構成パラメータに基づいて、バックグラウンド・モードでもフォアグラウンド・モードでも処理を実行するように構成できます。詳細は、Oracle Unified Directory構成リファレンスで「参照整合性プラグイン」を参照してください。デフォルトでは、update-intervalの値は0です。update-intervalの値が0の場合、更新はフォアグラウンドで同期的に実行されます。update-interval値が0より大きい場合は、バックグラウンド・モードで実行します。
参照整合性プラグインがバックグラウンド・モードで実行されるように構成されている場合、ディレクトリ内でユーザー・エントリまたはグループ・エントリを削除、名前変更または移動する場合、操作が参照整合性ログ・ファイルINSTANCE_DIR/OUD/logs/referintに記録されます。
指定された時間(update-interval)の経過後に、サーバーでは指定された属性に対して検索が実行され、ログに記録されている削除済エントリまたは変更済エントリのDNに検索結果が照合されます。その後、サーバーは一致した結果に基づいて属性を変更します。referintログは、update-intervalの値が0より大きい場合にのみ更新されます。update-intervalで指定した時間が経過し、参照整合性プラグインのパラメータconfigに基づいてユーザーDNが他のエントリから削除されると、DNログは削除されます。
要件に合うように次の参照整合性プラグインのプロパティを構成できます。
-
有効。参照整合性プラグインをオンにします。
-
プラグイン・タイプ。デフォルトで、削除操作、名前変更操作および移動操作が設定されます。たとえば、削除のみにするなど、プラグイン・タイプを変更できます。
-
属性のタイプ。デフォルトで、属性のタイプは
member,uniquememberに設定されますが、他の属性に変更できます。DN値が含まれる属性を使用または定義すると、参照整合性プラグインを使用してこれらの属性をモニターできます。 -
ベースDN。デフォルトで、すべてのパブリック・ネーミング・コンテキストをスコープで使用するよう設定されますが、これは特定のコンテキストに変更できます。
-
ログ・ファイル。デフォルトで、ログ・ファイルは
logs/referintです。別のファイルに参照整合性の更新を記録できます。たとえば、レプリケートした環境での変更を記録する場合は、レプリケーション・サーバー上のchangelogファイルに書き込むことができ、コンシューマ・サーバーにその変更をレプリケートできるようになります。 -
update-interval。デフォルトで、
update-intervalは0秒に設定されます。これは、削除操作、名前変更操作または移動操作の直後に参照整合性が実行されることを意味します。更新がシステム・パフォーマンスに与える影響を最小限に抑えるには、更新間隔を長くします。一般的な更新間隔は次のとおりです:-
0秒(すぐに更新)
-
90秒(90秒ごとに更新)
-
3600秒(1時間ごとに更新)
-
10,800秒(3時間ごとに更新)
-
28,800秒(8時間ごとに更新)
-
86,400秒(1日に1回更新)
-
604,800秒(1週間に1回更新)
-
19.5 Oracle Unified DirectoryサーバーでのODSEEロールのシミュレート
グループ・メカニズムの要件を満たすために、Oracle Directory Server Enterprise Edition (ODSEE)ロールをシミュレートするようにOracle Unified Directoryを構成できます。
19.5.1 Oracle Unified DirectoryサーバーでのODSEEロールについて
Oracle Directory Server Enterprise Edition (ODSEE)には、特化されたタイプのグループ・メカニズムの提供に使用されるロール・サブシステムが含まれます。この機能はOracle Unified Directoryに直接は含まれていません。これは、非標準の機能に基づいており、Netscape固有のスキーマ要素が使用され、LDAP対応アプリケーションでは一般的に使用されていないためです。
ただし、Oracle Unified Directoryでは、ODSEEロールによって提供されるすべての機能を使用でき、この機能を標準のグループ・メカニズムに使用することができます。ODSEEで使用可能なロール機能に依存することを目的として作成されており、標準のグループ・メカニズムを使用できないアプリケーションを使用している場合は、そのようなアプリケーションの要件を満たすためにODSEEロールをシミュレートするようOracle Unified Directoryを構成できます。
ノート:
使用しているアプリケーションでロール・エントリを作成して破棄することが必要な場合(たとえば、nsRoleDefinitionオブジェクト・クラスのいずれかの下位クラスが含まれるエントリ)、この機能は現在Oracle Unified Directoryでは使用できません。
19.5.2 ユーザーがロールのメンバーかどうかの確認
アプリケーションで、ユーザーが所定のロールのメンバーかどうかの判別のみが必要な場合は、ターゲット・ユーザーのエントリのnsRole属性を確認して、該当するロールのDNが含まれているかどうかを判別するだけです。この場合、この項で説明するステップに従って、ロール機能をシミュレートできます。
これらのステップを完了したら、nsRole仮想属性がユーザー・エントリの操作属性として表示され、ユーザーがメンバーになっているすべてのグループのDNが含まれているはずです。
ノート:
nsRoleは操作属性であり、検索結果で返されるよう明示的にリクエストする必要があることに注意してください。また、認証ユーザーに必ずその属性を表示する権限が付与されるように設定しておく必要もあります。
-
ODSEEロールの実装に必要なスキーマが含まれるようにディレクトリ・サーバーを更新します。
このスキーマは、LDIFファイルである
03-dsee-roles.ldifで次のように提供されます。# CDDL HEADER START # # The contents of this file are subject to the terms of the # Common Development and Distribution License, Version 1.0 only # (the "License"). You may not use this file except in compliance # with the License. # # You can obtain a copy of the license at # trunk/opends/resource/legal-notices/OpenDS.LICENSE # or https://OpenDS.dev.java.net/OpenDS.LICENSE. # See the License for the specific language governing permissions # and limitations under the License. # # When distributing Covered Code, include this CDDL HEADER in each # file and include the License file at # trunk/opends/resource/legal-notices/OpenDS.LICENSE. If applicable, # add the following below this CDDL HEADER, with the fields enclosed # by brackets "[]" replaced with your own identifying information: # Portions Copyright [yyyy] [name of copyright owner] # # CDDL HEADER END # # # This file contains schema definitions required to simulate DSEE role # functionality in OpenDS. dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema attributeTypes: ( 2.16.840.1.113730.3.1.574 NAME 'nsRole' DESC 'Sun ONE defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN 'Sun ONE Directory Server' ) attributeTypes: ( 2.16.840.1.113730.3.1.575 NAME 'nsRoleDN' DESC 'Sun ONE defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE directoryOperation X-ORIGIN 'Sun ONE Directory Server' )
-
このファイルをディレクトリ・サーバー実装の
config/schemaディレクトリにコピーしてサーバーを再起動するか、または -
add schema fileタスクを使用して、サーバーでスキーマ・ファイルが、実行中のサーバー・インスタンスにロードされるようにします。
-
-
静的グループまたは動的グループを作成して、ロール・メンバーシップを定義します。
グループに必ず適切なメンバー・セットが含まれるようにします。
-
isMemberOf仮想属性の新規インスタンスを作成して、nsRole仮想属性を指定します。nsRole属性には、ターゲット・ユーザーがメンバーになっているすべてのグループのDNのリストが含まれることになります。次のように、dsconfigコマンドを使用して、仮想属性を作成します:$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ create-virtual-attribute \ --type is-member-of --name nsRole --set attribute-type:nsRole --set enabled:true