Oracle Unified Directoryは、アイデンティティ・マップおよびアカウント・ステータス通知を含め、包括的なユーザー管理モデルを提供します。この項では、コマンド行ユーティリティおよびOracle Directory Services Managerインタフェースを使用して、これらの要素を構成する方法を説明します。
この章の内容は次のとおりです:
ユーザー・パスワードの詳細は、第27章「パスワード・ポリシーの管理」を参照してください。
ユーザー・アカウントは基本的に、ディレクトリで作成、変更または削除するユーザー・エントリです。
ユーザー・アカウントの管理を開始する前に、ディレクトリ・サーバーに適切なパスワード・ポリシーが設定されていることを確認してください。詳細は、第27章「パスワード・ポリシーの管理」を参照してください。
この項では、manage-account
およびldappasswordmodify
コマンド行ユーティリティを使用して、ユーザー・アカウントおよびパスワードを管理する方法を説明します。この項の内容は次のとおりです:
ディレクトリ管理者は、他のユーザーのパスワードの作成、リセットまたは削除を求められることがよくあります。ldappasswordmodify
ユーティリティを使用すると、LDAPパスワード変更拡張操作でユーザーのパスワードを変更またはリセットできます。--authzid
オプションを使用して、dn:
またはu:
を接頭辞として付けるか、または完全なDNを指定することによって、認可IDを指定できます。
この項では、パスワードを管理する方法を説明します。この項の内容は次のとおりです:
次の例で示しているように、ldappasswordmodify
コマンドを使用します:
$ ldappasswordmodify -h localhost -p 1389 \ --authzID "dn:cn=Directory Manager" \ --currentPassword mypassword --newPassword mynewpassword The LDAP password modify operation was successful
この例では、ユーザーは既存のパスワードを覚えていないことが前提となっています。
次の例で示しているように、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
この例では、ユーザーは既存のパスワードを覚えていることが前提となっています。新規パスワードは、指定したファイルでサーバーに渡されます。
次の例で示しているように、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
ユーザーのアカウントおよびそのユーザーに適用されているパスワード・ポリシーに関する情報を表示するには、manage-account
コマンドを使用できます。このコマンドを使用して、ユーザーのアカウントを有効または無効にすることもできます。manage-account
コマンドは、管理ポート経由でSSLを使用してサーバーにアクセスします。詳細は、第17.3項「サーバーへの管理トラフィックの管理」を参照してください。
この項では、ユーザーのアカウント情報を管理する方法を説明します。この項の内容は次のとおりです:
manage-account
コマンドは、ユーザー・アカウントに適用されているパスワード・ポリシーのDN、アカウント・ステータス、およびパスワードとログイン関連情報を返します。
特定のユーザー・アカウントに関して入手可能な情報をすべて表示するには、次の例に示しているように、manage-account
コマンドをget-all
サブコマンドとともに使用します:
$ manage-account -D "cn=directory manager" -j pwd-file get-all \ --targetDN uid=kvaughan,ou=People,dc=example,dc=com Password Policy DN: cn=Default Password Policy,cn=Password Policies,cn=config Account Is Disabled: false Account Expiration Time: Seconds Until Account Expiration: Password Changed Time: 19700101000000.000Z Password Expiration Warned Time: Seconds Until Password Expiration: 432000 Seconds Until Password Expiration Warning: 0 Authentication Failure Times: Seconds Until Authentication Failure Unlock: Remaining Authentication Failure Count: Last Login Time: Seconds Until Idle Account Lockout: Password Is Reset: false Seconds Until Password Reset Lockout: Grace Login Use Times: Remaining Grace Login Count: 4 Password Changed by Required Time: Seconds Until Required Change Time: Password History:
特定のアカウントの1つのプロパティのみを表示するには、get-all
サブコマンドのかわりに、表示するプロパティに対応するサブコマンドを使用します。
たとえば、パスワード履歴のみを表示するには、次のコマンドを実行します:
$ manage-account -D "cn=directory manager" -j pwd-file get-password-history \ --targetDN "uid=kvaughan,ou=People,dc=example,dc=com"
サブコマンドの全リストを表示するには、次のコマンドを実行します:
$ manage-account --help
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
次の例で示しているように、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
次の例で示しているように、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
orclIsEnabled
を使用してアカウントを有効にするにはorclIsEnabled
を使用してOracle Unified Directoryを有効にするには、次の手順を実行します:
次のように新規ワークフロー要素を作成して有効にします:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n / create-workflow-element --element-name fawe --type fa \ --set enabled:true --set next-workflow-element:userRoot
次のように、新規ワークフロー要素をデフォルトのワークフローに割り当てます:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n / set-workflow-prop --workflow-name userRoot0 --set workflow-element:fawe
リソース制限をエントリに割り当てることによって、クライアント・アカウントごとにサーバー上での検索操作を制御できます。リソース制限は、特定の操作属性をユーザー・エントリに追加することによって割り当てられます。その上で、ディレクトリ・サーバーで、クライアントがディレクトリへのバインドに使用するアカウントに基づいて制限が施行されます。
特定のユーザー・アカウントに対して設定したリソース制限は、サーバー規模の構成で設定したリソース制限より優先されます。リソース制限の構成可能なプロパティすべての詳細は、Oracle Unified Directory構成リファレンスのグローバル構成に関する項を参照してください。
設定できる制限は次のとおりです:
検索制限。検索操作で調べるエントリの最大数が指定されます。ds-rlim-lookthrough-limit
操作属性を使用します。
サイズ制限。検索操作のレスポンスとして返されるエントリの最大数が指定されます。ds-rlim-size-limit
操作属性を使用します。
時間制限。検索操作の処理に費やせる最大時間が指定されます。ds-rlim-time-limit
操作属性を使用します。
注意: デフォルトで、ディレクトリ・マネージャでは無制限にリソースを使用できます。 |
次に示しているように、操作属性を追加することによって、LDIFファイル内のエントリを変更します:
dn: uid=kvaughan,ou=people,dc=example,dc=com changetype: modify add: ds-rlim-lookthrough-limit ds-rlim-lookthrough-limit: 1000 - add: ds-rlim-size-limit ds-rlim-size-limit: 500 - add: ds-rlim-time-limit ds-rlim-time-limit: 300
次に示しているように、ldapmodify
コマンドを使用して、変更を適用します:
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --filename add_resource.ldif Processing MODIFY request for uid=kvaughan,ou=people,dc=example,dc=com MODIFY operation successful for DN uid=kvaughan,ou=people,dc=example,dc=com
ルート・ユーザーは、アクセス制御および通常のユーザーに施行されている可能性のあるその他の制限をバイパスできるアカウントを持つ特別なユーザーです。複数のルート・ユーザーを定義して、各ルート・ユーザーに個別の資格証明セットを指定し、ファイングレイン・レベルでアクセスを制御できます。たとえば、特定のタスクに対するルート・アクセス権が必要だが、完全なルート・ユーザー権限セットは必要ではないユーザーに権限を割り当てることができます。各ルート・ユーザーが独自の強固な認証メカニズム(GSSAPI SASLなど)、固有のパスワード・ポリシーおよび独自のリソース制限を持つように各ルート・ユーザーを構成できます。
デフォルトで、一連のグローバル・ルート・ユーザー権限が定義されます。これらの権限は、ルート・ユーザー・エントリの権限を変更しないかぎり、デフォルトのルート・ユーザーを含めて、すべての構成済ルート・ユーザーに適用されます。すべてのルート・ユーザーに継承されるグローバル・ルート・ユーザー権限を変更できます。
セットアップ・プロセス中に、完全な管理権限を持つデフォルトのルート・ユーザーが作成されます。このルート・ユーザーに対してセットアップで提示されるDNは"cn=directory manager"
であるため、セットアップで提示されるデフォルト値を変更しないと、DNが"cn=directory manager,cn=Root DNs,cn=config"
のルート・ユーザーが構成されます。
次の各項で説明している各プロシージャを使用して、ルート・ユーザーおよびその権限を管理できます。
dsconfig
コマンドを使用して、グローバル・ルート・ユーザーのプロパティを表示および編集できます。追加のルート・ユーザーを作成および管理するには、ldapmodify
コマンドを使用して、ユーザー・エントリをサーバー構成に追加する必要があります。次の各項では、コマンド行を使用してルート・ユーザーを管理する方法を説明します。
グローバル・ルート・ユーザーの権限を表示するには、次の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
権限の全リストおよび各権限の説明は、第11.2項「特権サブシステム」を参照してください。
新規ルート・ユーザーを作成するには、LDIFファイルにユーザー・エントリを作成してから、ldapmodify
コマンドを使用して、そのエントリをサーバー構成のcn=Root DNs,cn=config
ブランチに追加します。
cn=config
接尾辞は、管理接尾辞であるため、管理コネクタを使用して評価する必要があります。詳細は、第17.3項「サーバーへの管理トラフィックの管理」を参照してください。
たとえば、特定のユーザーにデータベースのバックアップおよびリストアを行う権限を付与するが、その他の管理権限は付与しない場合、次のように実行します。
適切な権限が指定されたルート・ユーザー・エントリを定義するLDIFファイルを作成します。
次のサンプルのLDIFファイル(add-backup-admin.ldif
)では、サーバー構成でこれらの権限を持つがその他の権限は持たない、DNが"cn=backup-admin"
のルート・ユーザーが定義されます。
dn: cn=backup-admin,cn=Root DNs,cn=config changetype: add objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: ds-cfg-root-dn-user objectClass: top cn: backup-admin sn: backup-admin ds-cfg-alternate-bind-dn: cn=backup-admin userPassword: secret ds-privilege-name: backend-backup ds-privilege-name: backend-restore ds-privilege-name: -bypass-acl ds-privilege-name: -bypass-lockdown ds-privilege-name: -cancel-request ds-privilege-name: -config-read ds-privilege-name: -config-write ds-privilege-name: -disconnect-client ds-privilege-name: -ldif-export ds-privilege-name: -ldif-import ds-privilege-name: -modify-acl ds-privilege-name: -password-reset ds-privilege-name: -privilege-change ds-privilege-name: -server-restart ds-privilege-name: -server-shutdown ds-privilege-name: -subentry-write ds-privilege-name: -unindexed-search ds-privilege-name: -update-schema
ldapmodifyコマンドを--useSSLオプションを指定して使用し、このLDIFファイルをサーバー構成に追加します。
$ ldapmodify -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL -X -f add-backup-admin.ldif
権限の全リストおよび各権限の説明は、第11.2項「特権サブシステム」を参照してください。
既存のルート・ユーザーを編集するには、ldapmodify
コマンドを使用して、サーバー構成のcn=Root DNs,cn=config
ブランチにあるユーザー・エントリの属性を変更します。
cn=config
接尾辞は、管理接尾辞であるため、管理コネクタを使用して評価する必要があります。詳細は、第17.3項「サーバーへの管理トラフィックの管理」を参照してください。
次の例では、前述の例で作成したルート・ユーザーのリストア操作を実行する機能が削除されます。
$ 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
ODSMインタフェースを使用して、デフォルトのルート・ユーザーを表示および編集したり、追加のルート・ユーザーを作成および管理したりできます。この項の内容は次のとおりです:
デフォルトで、一連のグローバル・ルート・ユーザー権限が定義されます。これらの権限は、ルート・ユーザー・エントリの権限を変更しないかぎり、すべての構成済ルート・ユーザーに適用されます。
ODSMを使用してグローバル・ルート・ユーザーの権限を変更するには、次の手順に従います:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」項目の「ルート・ユーザー」を選択します。
右側のペインに、グローバル・ルート・ユーザーの権限が表示されます。
権限の横のチェック・マークは、ルート・ユーザーにその権限がデフォルトで付与されていることを示します。
グローバル・ルート・ユーザーの権限のリストに権限を追加するには、追加する権限の横のチェック・ボックスを選択します。
権限を削除するには、その権限の横のチェック・ボックスを選択解除します。
権限の全リストおよび各権限の説明は、第11.2項「特権サブシステム」を参照してください。
必要な変更を加えたら、「適用」をクリックします。
次のように、ODSMを使用して新規ルート・ユーザーを作成できます:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「作成」メニューから、「ルート・ユーザー」を選択します。
「一般プロパティ」リージョンで、次の詳細を入力します:
「名前」フィールドに、作成するルート・ユーザーの名前を入力します。
「代替バインド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)
: グローバル権限構成で定義されているとおりに、ユーザーは、この権限のデフォルトの設定を継承します。
「作成」をクリックします。
次の確認メッセージが表示されます:
ルート・ユーザーは正常に作成されました。
次のように、ODSMを使用して、既存のルート・ユーザーを編集できます:
第21.2項「Oracle Directory Services Managerからサーバーへの接続」の説明に従って、ODSMからディレクトリ・サーバーに接続します。
「構成」タブを選択します。
「一般構成」項目の「ルート・ユーザー」項目を開きます。
構成を変更するルート・ユーザーを選択します。
右側のペインに、対象のルート・ユーザーのプロパティが表示されます。
必要なプロパティを編集して、「適用」をクリックします。
新しい構成の保存を求められます。「はい」をクリックします。
Oracle Unified Directoryでは、単一オブジェクトとして管理可能な、エントリのコレクションであるグループがサポートされます。通常、ディレクトリ管理者は、プリンタのグループ、ソフトウェア・アプリケーションのグループ、従業員のグループなどを構成します。グループは、一連のユーザーに特別なアクセス権を割り当てる場合に特に有用です。たとえば、アクセス・マネージャに、従業員データに対する権限を割り当てる一方で、これらの同じ権限を社内の他のユーザーに対しては制限することができます。
次のグループ・タイプがサポートされています:
静的グループ: 静的グループでは、groupOfNames
、groupOfUniqueNames
またはgroupOfEntries
オブジェクト・クラスを使用して、識別名(DN)の明示的セットを指定することによって、メンバーシップが定義されます。静的グループは、外部クライアントで適切にサポートされ、良好なパフォーマンスを実現します。
静的グループの短所は、グループのメンバーシップが増加するにつれ、簡単だったデータの管理がだんだん難しくなっていくことです。変更されるエントリごとに、その変更されたエントリが含まれるすべてのグループも変更する必要があります。このタスクは、グループのメンバーの数が多くなるにつれ、難しくなっていきます。このため、静的グループは、あまり頻繁には変更されない比較的小規模のグループに使用することが最適です。
詳細は、第22.3.1項「静的グループの定義」を参照してください。
動的グループ: 動的グループでは、groupOfUrls
オブジェクト・クラスを使用して、LDAP URLの形式で一連の検索基準を使用し、グループのメンバーシップが定義されます。静的グループと比較して、動的グループでは、多数のメンバー(数百万のエントリ)が適切に処理されます。エントリが更新されると、すべての親グループが自動的に更新されます。
動的グループの短所は、一部のクライアントでサポートされないことです。また、エントリの全リストに問合せを実行する必要がある場合、パフォーマンスに悪影響を与えます。このため、動的グループは、エントリ数が多大なグループの場合、または1つのエントリに対して特定のグループ・メンバーシップを指定する必要があるクライアントの場合に最適です。
詳細は、第22.3.2項「動的グループの定義」を参照してください。
仮想静的グループ: 仮想静的グループは、各メンバーが、別の動的グループからその場でメンバーシップを定義する仮想属性によって表されることを除いて、外部クライアントに対して静的グループと外観および動作が同様です。仮想静的グループは、多数のエントリを管理しつつ、静的グループのみをサポートするクライアントのスケーラビリティの問題を回避する効率的な方法を提供します。
詳細は、第22.3.3項「仮想静的グループの定義」を参照してください。
静的グループは、エントリに明示的なDNのメンバーシップ・リストが含まれるグループです。多くのクライアントで静的グループがサポートされますが、グループ内のメンバー数が多くなってくると、静的グループの管理は難しくなってきます。たとえば、DN変更が必要なメンバー・エントリがある場合、そのエントリの所属先の各グループのユーザーDNを変更する必要があります。
静的グループには明示的なメンバーDNのリストが含まれるため、メンバーシップ・リストが大きくなると、データベースのフットプリントも大きくなります。このため、静的グループは、エントリが頻繁には変更されない小規模のグループ(10,000未満)に最適です。大規模な静的グループを使用すると、パフォーマンスに有害な影響を与える可能性があります。グループ・メンバーシップ数が10,000を超えることがわかっている場合は、かわりに動的グループの使用を検討してください。
ディレクトリ・サーバーでは、使用するオブジェクト・クラスに応じて分類された、次の3つのタイプの静的グループがサポートされます:
groupOfNames
: groupOfNames
オブジェクト・クラスを使用し、member
属性を使用してメンバーDNを明示的に指定することによって、静的グループを定義できます。
注意: RFC 4519( |
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( |
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(http://ietfreport.isoc.org/idref/draft-findlay-ldap-groupofentries/
) (2008年3月に失効))に基づいて、groupOfEntries
オブジェクト・クラスは、groupOfNames
およびgroupOfUniqueNames
オブジェクト・クラスとは、属性がオプションである点において異なっています。これによって、メンバーが含まれない空のオブジェクト・クラスを指定できます。
注意: Oracle Unified Directoryでは、 dn: cn=Example Static Group 3,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfEntries cn: Example Static Group 3 |
この項には次のトピックが含まれます:
groupOfNames
を使用して静的グループを作成するにはLDIFに、グループ名(cn
)およびgroupOfNames
オブジェクト・クラスを含めたグループ・エントリを作成します。
次の例は、新規グループを定義するstatic-group1.ldif
という名前のLDIFファイルを示しています。
dn: cn=Directory Administrators,ou=Groups,dc=example,dc=com cn: Directory Administrators objectclass: top objectclass: groupOfNames ou: Groups member: uid=ttully,ou=People,dc=example,dc=com member: uid=charvey,ou=People,dc=example,dc=com member: uid=rfisher,ou=People,dc=example,dc=com
ldapmodify
を使用してグループを追加し、このLDIFファイルを適用します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename static-group1.ldif Processing ADD request for cn=Directory Administrators,ou=Groups,dc=example,dc=com ADD operation successful for DN cn=Directory Administrators,ou=Groups,dc=example,dc=com
groupOfUniqueNames
を使用して静的グループを作成するにはLDIFに、グループ名(cn
)およびgroupOfUniqueNames
オブジェクト・クラスを含めたグループ・エントリを作成します。
次の例は、新規グループを定義するstatic-group2.ldif
という名前のLDIFファイルを示しています。
dn: cn=Directory Administrators2,ou=Groups,dc=example,dc=com cn: Directory Administrators2 objectclass: top objectclass: groupOfUniqueNames ou: Groups uniquemember: uid=alangdon,ou=People,dc=example,dc=com uniquemember: uid=drose,ou=People,dc=example,dc=com uniquemember: uid=polfield,ou=People,dc=example,dc=com
ldapmodify
を使用してグループを追加し、このLDIFファイルを適用します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename static-group2.ldif
ldapsearch
およびisMemberOf
属性を使用して変更を確認します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --baseDN dc=example,dc=com "(uid=rdaugherty)" isMemberOf dn: uid=alangdon,ou=People,dc=example,dc=com isMemberOf: cn=Directory Administrators2,ou=Groups,dc=example,dc=com
groupOfEntries
を使用して静的グループを作成するにはLDIFに、グループ名(cn
)およびgroupOfEntries
オブジェクト・クラスを含めたグループ・エントリを作成します。
次の例は、新規グループを定義するstatic-group3.ldif
という名前のLDIFファイルを示しています。
dn: cn=Directory Administrators3,ou=Groups,dc=example,dc=com cn: Directory Administrators3 objectclass: top objectclass: groupOfEntries ou: Groups member: uid=bfrancis,ou=People,dc=example,dc=com member: uid=tjames,ou=People,dc=example,dc=com member: uid=bparker,ou=People,dc=example,dc=com
ldapmodify
を使用してグループを追加し、このLDIFファイルを適用します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename static-group3.ldif
ldapsearch
およびisMemberOf
属性を使用して変更を確認します。
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --baseDN dc=example,dc=com "(uid=bparker)" isMemberOf dn: uid=bparker,ou=People,dc=example,dc=com isMemberOf: cn=Directory Administrators3,ou=Groups,dc=example,dc=com
グループの検索に、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.com
次の例で示しているように、ldapsearch
および仮想属性cn=virtualStatic
を使用して検索します。
$ 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
次の例で示しているように、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
動的グループは、メンバーシップがリストで明示的に保持されるのではなく、LDAP URLを使用して検索基準によって決定されるグループです。たとえば、dc=example,dc=com
ネーミング・コンテキスト内のすべてのマネージャに電子メールを送信するとします。これを行うには、cn=Managers,ou=Groups,dc=example,dc=com
と指定した動的グループを作成します。また、電子メール・アドレスのみが返されるように指定します。電子メール・アプリケーションから特定グループのディレクトリの問合せがあると、ディレクトリ・サーバーでは、メンバーシップが動的に計算され、対応する電子メール・アドレスのリストが返されます。
動的グループでは、groupOfURLs
オブジェクト・クラスおよびmemberURL
属性を使用して、LDAP URLおよびグループのメンバーの特定に使用する基準(検索ベース、スコープおよびフィルタ)が定義されます。ユーザーが動的グループのメンバーかどうかを判別するメカニズムは、定数時間の操作であるため、メンバーが数百万のグループを複数対象とする場合でも、メンバーが数個のグループを1つのみ対象とする場合と同じく効率的に実行されます。ただし、大量のデータに対して検索を行う場合はパフォーマンスに悪影響を及ぼす可能性があるため、検索基準を指定する際には注意が必要です。
この項の内容は次のとおりです:
グループを指定するLDIFファイルを作成します。
次の例では、Cupertinoに配置されている従業員の動的グループが指定されます。
dn: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com cn: CupertinoEmployees objectclass: top objectclass: groupOfURLs ou: Groups memberURL: ldap:///ou=People,dc=example,dc=com??sub?(l=Cupertino)
ldapmodify
を使用してグループを追加し、LDIFファイルを処理します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename dynamic_group.ldif Processing ADD request for cn=cupertionEmployees,ou=Groups,dc=example,dc=com ADD operation successful for DN cn=cupertionEmployees,ou=Groups,dc=example,dc=com
次のプロシージャでは、仮想属性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)...
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
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.com
仮想静的グループでは、静的グループのみをサポートするクライアントのスケーラビリティが効率的に管理されます。仮想静的グループでは、各エントリが仮想属性を使用することによって静的グループのように動作します。次の図で示しているように、仮想属性は、起動時に動的に指定され、グループ・メンバーシップを指定する操作が動的グループなどの別のグループに渡されます。
仮想静的グループには、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))
メンバー・セットを取得するアプリケーションでは、完全なメンバー・リストを構築するプロセスで負荷がかかる可能性があるため、仮想静的グループは理想的ではない場合があります。
この項の内容は次のとおりです:
グループを指定するLDIFファイルを作成します。
次のサンプル・ファイルvirtual-static.ldif
では、cupertinoEmployees
という名前の仮想静的グループが指定されます。
dn: cn=virtualStatic,ou=Groups,dc=example,dc=com cn: Virtual Static objectclass: top objectclass: groupOfUniqueNames objectclass: ds-virtual-static-group ou: Groups ds-target-group-dn: cn=cupertinoEmployees,ou=Groups,dc=example,dc=com
ldapmodify
を使用してグループを追加し、LDIFファイルを処理します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename virtual-static.ldif Processing ADD request for cn=virtualStatic,ou=Groups,dc=example,dc=com ADD operation successful for DN cn=virtualStatic,ou=Groups,dc=example,dc=com
仮想静的グループの使用は、検索のターゲットがメンバーシップ属性の場合に最適です。このため、次のプロシージャはお薦めできませんが、リストにアクセスする方法を示すために記載しています。
この例では、前の例で作成した動的グループ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)...
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
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
グループをネストすることができます。その場合、DNが別のグループ(親)内にリストされる子グループ・エントリとして、1つのグループが定義されます。グループをネストすると、パフォーマンスが優先されない場合に、継承グループ・メンバーシップを設定できます。0個以上のメンバー属性を、静的グループおよび動的グループを含め、ネストされた子グループのDNにそのメンバー属性の値を設定して追加できます。
このプロシージャ例では、1つの静的グループと1つの動的グループを使用してネストされたグループが作成されます。
静的グループを指定するLDIFファイルを作成します。
次の例のファイルstatic-group.ldif
では、Dev Contractors
という名前の仮想静的グループが指定されます。
dn: cn=Contractors,ou=Groups,dc=example,dc=com cn: Dev Contractors objectclass: top objectclass: groupOfUniqueNames ou: Dev Contractors Static Group uniquemember: uid=wsmith,ou=Contractors,dc=example,dc=com uniquemember: uid=jstearn,ou=Contractors,dc=example,dc=com uniquemember: uid=pbrook,ou=Contractors,dc=example,dc=com uniquemember: uid=njohnson,ou=Contractors,dc=example,dc=com uniquemember: uid=sjones,ou=Contractors,dc=example,dc=com
ldapmodify
を使用してグループを追加し、LDIFファイルを処理します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename static-group.ldif
動的グループを指定するLDIFファイルを作成します。
次の例のファイルdynamic-group.ldif
では、Developers
という名前の動的グループが指定されます。
dn: cn=Developers,ou=Groups,dc=example,dc=com cn: Developers objectclass: top objectclass: groupOfURLs ou: Groups memberURL: ldap:///ou=People,dc=example,dc=com??sub?(ou=Product Development)
ldapmodify
を使用してグループを追加し、LDIFファイルを処理します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename dynamic-group.ldif
ネストされた静的グループを指定するLDIFファイルを作成します。
次の例のファイルnested-group.ldif
では、Developers Group
という名前のネストされたグループが指定されます。
dn: cn=DevelopersGroup,ou=Groups,dc=example,dc=com cn: Developers Group objectclass: top objectclass: groupOfUniqueNames ou: Nested Static Group uniquemember: cn=Contractors,ou=Groups,dc=example,dc=com uniquemember: cn=Developers,ou=Groups,dc=example,dc=com
ldapmodify
を使用してグループを追加し、LDIFファイルを処理します。
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename nested-group.ldif
参照整合性とは、削除操作、名前変更操作または移動操作の後にすべての参照が適切に保持されるようにするためのデータベース・メカニズムです。たとえば、1つのエントリをディレクトリから削除した場合、ディレクトリ・サーバーではそのエントリがメンバーとしてリストされていたすべてのグループからもそのエントリが削除されます。
参照整合性メカニズムは、ディレクトリ・サーバーのプラグインとして構成され、dsconfig
コマンドを使用して有効化できます。詳細は、第17.1項「dsconfig
を使用したサーバー構成の管理」を参照してください。
この項では、参照整合性について説明します。この項の内容は次のとおりです:
デフォルトでは、参照整合性プラグインは無効となります。dsconfig
を使用してこのプラグインを有効にすると、削除操作、名前変更操作または移動操作の直後に、member
属性およびuniquemember
属性で整合性の更新が実行されます。ディレクトリ内のユーザー・エントリまたはグループ・エントリを削除、名前変更または移動すると常に、その操作は、参照整合性ログ・ファイルINSTANCE_DIR/OUD/logs/referint
に記録されます。
指定された時間(更新間隔)の経過後に、サーバーでは指定された属性に対して検索が実行され、ログに記録されている削除済エントリまたは変更済エントリのDNに検索結果が照合されます。ログ・ファイルで、エントリが削除されていることが確認されたら、対応する属性が削除されます。ログ・ファイルで、エントリが変更されていることが確認されたら、それに従って対応する属性値も変更されます。
要件に合うように参照整合性プラグインのプロパティを構成できます。次のプロパティを構成できます:
有効: 参照整合性プラグインをオンにします。
プラグイン・タイプ: デフォルトで、削除操作、名前変更操作および移動操作が設定されます。たとえば、削除のみにするなど、プラグイン・タイプを変更できます。
属性のタイプ: デフォルトで、属性のタイプはmember,uniquemember
に設定されますが、他の属性に変更できます。DN値が含まれる属性を使用または定義すると、参照整合性プラグインを使用してこれらの属性を監視できます。
ベースDN: デフォルトで、すべてのパブリック・ネーミング・コンテキストをスコープで使用するよう設定されますが、これは特定のコンテキストに変更できます。
ログ・ファイル: デフォルトで、ログ・ファイルはlogs/referint
です。別のファイルに参照整合性の更新を記録できます。たとえば、レプリケートした環境での変更を記録する場合は、レプリケーション・サーバー上のchangelogファイルに書き込むことができ、コンシューマ・サーバーにその変更をレプリケートできるようになります。
更新間隔: デフォルトで、更新間隔は0秒に設定されます。これは、削除操作、名前変更操作または移動操作の直後に参照整合性が実行されることを意味します。更新がシステム・パフォーマンスに与える影響を最小限に抑えるには、更新間隔を長くします。一般的な更新間隔は次のとおりです:
0秒(すぐに更新)
90秒(90秒ごとに更新)
3600秒(1時間ごとに更新)
10,800秒(3時間ごとに更新)
28,800秒(8時間ごとに更新)
86,400秒(1日に1回更新)
604,800秒(1週間に1回更新)
dsconfig
を使用して参照整合性を有効にするには、プラグインのenabled
プロパティをtrueに設定します。
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-plugin-prop --plugin-name "Referential Integrity" --set enabled:true
Oracle Directory Server Enterprise Edition (ODSEE)には、特化されたタイプのグループ・メカニズムの提供に使用されるロール・サブシステムが含まれます。この機能はOracle Unified Directoryには含まれていません。これは、非標準の機能に基づいており、Netscape固有のスキーマ要素が使用され、LDAP対応アプリケーションでは一般的に使用されていないためです。
ただし、Oracle Unified Directoryでは、ODSEEロールによって提供されるすべての機能を使用でき、この機能を標準のグループ化メカニズムに使用することができます。ODSEEで使用可能なロール機能に依存することを目的として作成されており、標準のグループ化メカニズムを使用できないアプリケーションを使用している場合は、そのようなアプリケーションの要件を満たすためにODSEEロールをシミュレートするようOracle Unified Directoryを構成できます。
注意: 使用しているアプリケーションでロール・エントリを作成して破棄することが必要な場合(たとえば、 |
この項には次のトピックが含まれます:
アプリケーションで、ユーザーが所定のロールのメンバーかどうかの判別のみが必要な場合は、ターゲット・ユーザーのエントリのnsRole
属性を確認して、該当するロールのDNが含まれているかどうかを判別するだけです。この場合、次の手順に従って、ロール機能をシミュレートできます。
これらの手順を完了したら、nsRole
仮想属性がユーザー・エントリの操作属性として表示され、ユーザーがメンバーになっているすべてのグループのDNが含まれているはずです。nsRole
は操作属性であり、検索結果で返されるよう明示的にリクエストされる必要があることに注意してください。また、認証ユーザーに必ずその属性を表示する権限が付与されるように設定しておく必要もあります。
ODSEEロールの実装に必要なスキーマが含まれるようにディレクトリ・サーバーを更新します。
このスキーマは、03-dsee-roles.ldif
と言う名前のLDIFファイルで提供されます。
このファイルをディレクトリ・サーバー実装の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
nsRoleDN
属性を使用してメンバーシップを変更するには使用しているアプリケーションで、ユーザーのエントリのnsRoleDN
仮想属性に、対応するロールの名前を配置することによってメンバーシップを変更できるようにする必要がある場合は、次の手順に従います。
この手順が完了したら、"cn=Test Role,ou=Roles,dc=example,dc=com"
というnsRoleDN
値が含まれるユーザー・エントリすべてのnsRole
操作属性にそのDNが含まれるようになります。
目的のロールのDNを指定して動的グループ・エントリを作成します。
値がターゲット・ロールのDNに等しいnsRoleDN
属性が含まれるメンバーを含めるようこのグループを構成します。
たとえば、アプリケーションで"cn=Test Role,ou=Roles,dc=example,dc=com"
というnsRoleDN
値を追加する場合、次のエントリを追加します:
dn: cn=Test Role,ou=Roles,dc=example,dc=com objectClass: top objectClass: groupOfURLs cn: Test Role memberURL: ldap:///dc=example,dc=com??sub?(nsRoleDN=\ cn=Test Role,ou=Roles,dc=example,dc=com)