Oracle Unified Directory provides a comprehensive user management model that includes identity mapping, and account status notification. This chapter describes how to configure these elements by using the command-line utilities and by using the Oracle Directory Services Manager (ODSM) interface.
The chapter includes the following sections:
For information about user passwords, see Chapter 30, "Managing Password Policies."
User accounts are essentially user entries that you create, modify, or remove in your directory.
Before you begin to manage user accounts, ensure that you have the appropriate password policies set up on the directory server. For more information, see Chapter 30, "Managing Password Policies."
This section describes how to manage user accounts and passwords by using the manage-account
and ldappasswordmodify
command-line utilities. The section includes the following topics:
Directory administrators are often asked to create, reset, or remove passwords for other users. The ldappasswordmodify
utility enables you to change or reset a user's password with the LDAP password modify extended operation. You can specify authorization IDs with the --authzid
option by prefixing dn:
, u:
, or by specifying the full DN.
This section describes how to manage passwords, and contains the following topics:
Section 19.1.1.1, "Changing the Directory Manager's Password"
Section 19.1.1.2, "Resetting and Generating a New Password for a User"
Use the ldappasswordmodify
command, as shown in the following example:
$ ldappasswordmodify -h localhost -p 1389 \ --authzID "dn:cn=Directory Manager" \ --currentPassword mypassword --newPassword mynewpassword The LDAP password modify operation was successful
This example assumes that the user does not remember the existing password.
Use the ldappasswordmodify
command, as shown in the following example:
$ 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
This example assumes that the user remembers the existing password. The new password is passed to the server in a specified file.
Use the ldappasswordmodify
command, as shown in the following example:
$ 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
You can use the manage-account
command to display information about the user's account and any password policy that is applied to the user. You can also use this command to enable or disable a user's account. The manage-account
command accesses the server over SSL through the administration port. For more information, see Section 17.4, "Managing Administration Traffic to the Server."
This section describes how to manage a user's account information, and covers the following topics:
The manage-account
command returns the DN of the password policy in effect on a user account, as well as the account status, and password and login related information
To display all available information on a user account, use the manage-account
command with the get-all
subcommand, as shown in the following example:
$ 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:
To display just a single property of the account, substitute the get-all
subcommand with the subcommand corresponding to the property you want to view.
For example, to view just the password history, run the following command:
$ manage-account -D "cn=directory manager" -j pwd-file get-password-history \ --targetDN "uid=kvaughan,ou=People,dc=example,dc=com"
For a complete list of subcommands, run the following command:
$ manage-account --help
You can use the manage-account
command to assess whether an account is enabled or disabled.
Use the manage-account
command with the get-account-is-disabled
subcommand, as shown in the following example:
$ 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
Use the manage-account
command with the set-account-is-disabled
subcommand, as shown in the following example:
$ 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
Use the manage-account
command with the clear-account-is-disabled
subcommand, as shown in the following example:
$ 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
To enable Oracle Unified Directory using orclIsEnabled
, complete the following steps:
Create and enable a new workflow element as follows:
$ 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
Assign the new workflow element to the default workflow, as follows:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -X -n / set-workflow-prop --workflow-name userRoot0 --set workflow-element:fawe
You can control search operations on the server for each client account by assigning resource limits to the entry. Resource limits are assigned by adding specific operational attributes to the user entry. The directory server then enforces the limits based on the account that the client uses to bind to the directory.
The resource limits that you set on specific user accounts take precedence over the resource limits set in the server-wide configuration. For details of all the configurable resource limit properties, see "Global Configuration" in the Configuration Reference for Oracle Unified Directory.
The following limits can be set:
Look-through limit. Specifies the maximum number of entries examined for a search operation. Use the ds-rlim-lookthrough-limit
operational attribute.
Size limit. Specifies the maximum number of entries returned in response to a search operation. use the ds-rlim-size-limit
operational attribute.
Time limit. Specifies the maximum time spent processing a search operation. Use the ds-rlim-time-limit
operational attribute.
Note:
The Directory Manager can use unlimited resources by default.Modify the entry in an LDIF file, adding the operational attributes, as shown here:
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
Use the ldapmodify
command to apply the changes, as shown here:
$ 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
A root user is a special user whose account can bypass access controls and other restrictions that might be enforced for regular users. You can define multiple root users, each with their own set of credentials, to control access at a fine-grained level. For example, you can assign privileges to a user who needs root access for a particular task, but does not need the full set of root user privileges. Oracle Unified Directory enables you to configure each root user to have his own strong authentication mechanism (such as GSSAPI SASL), his own specific password policy, and his own resource limits.
A set of global root user privileges is defined by default. These privileges apply to all configured root users, including the default root user, unless you modify the privilege in the root user entry. You can change the global root user privileges that are inherited by all root users.
During the setup process, a default root user with full administrative rights is created. The DN proposed by the setup for this root user is "cn=directory manager",
so if you do not change the defaults proposed by the setup, a root user with the DN "cn=directory manager,cn=Root DNs,cn=config"
is configured.
You can manage root users and their privileges, by using the procedures outlined in the following sections.
You can view and edit the global root user properties by using the dsconfig
command. To create and manage additional root users, you must use the ldapmodify
command to add the user entries to the server configuration. The following sections describe how to manage root users by using the command line.
To display the global root user privileges, run the following dsconfig
command:
$ 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
To change the global root user privileges, run the following dsconfig command run the dsconfig set-root-dn-prop
command with the --add
or --remove
option.
The following example removes the default privilege of root users to perform a backup or restore operation on the server.
$ 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
For a complete list of the privileges and an explanation of each privilege, see Section 11.2, "Privilege Subsystem."
To create a new root user, create the user entry in an LDIF file, then use the ldapmodify
command to add the entry to the cn=Root DNs,cn=config
branch in the server configuration.
Note:
Thecn=config
suffix is an administrative suffix and, as such, must be accessed using the administration connector. For more information see Section 17.4, "Managing Administration Traffic to the Server."Suppose, for example, that you want to give a particular user the right to backup and restore a database, but no other administrative privileges.
Create an LDIF file that defines the root user entry with the correct privileges.
The following sample LDIF file (add-backup-admin.ldif
) defines a root user with the DN "cn=backup-admin"
who has these privileges, but no other privileges on the server configuration.
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
Use the ldapmodify command with the --useSSL option to add the LDIF file to the server configuration.
$ ldapmodify -h localhost -p 4444 -D "cn=directory manager" -j pwd-file \ --useSSL -X -f add-backup-admin.ldif
For a complete list of the privileges and an explanation of each privilege, see Section 11.2, "Privilege Subsystem."
To edit an existing root user, use the ldapmodify
command to change the attributes of the user entry under the cn=Root DNs,cn=config
branch in the server configuration.
Note:
Thecn=config
suffix is an administrative suffix and, as such, must be accessed using the administration connector. For more information see Section 17.4, "Managing Administration Traffic to the Server."The following example removes the capability of the root user created in the previous example to perform a restore operation.
$ 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
You can view and edit the default root user, and create and manage additional root users, by using the ODSM interface. This section covers the following topics:
A set of global root user privileges is defined by default. These privileges apply to all configured root users, unless you modify the privilege in the root user entry.
To modify the global root user privileges by using ODSM, follow these steps:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Configuration tab.
Under the General Configuration item, select Root Users.
The global root user privileges are displayed in the right hand pane.
A check mark next to a privilege indicates that root users have that privilege by default.
To add a privilege to the list of global root user privileges, check the box next to that privilege.
To remove a privilege, uncheck the box next to that privilege.
For a complete list of the privileges and an explanation of each privilege, see Section 11.2, "Privilege Subsystem."
When you have made the modifications that you require, click Apply.
You can create a new root user by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Configuration tab.
From the Create menu, select Root User.
In the General Properties region, enter the following details:
In the Name field, type a name for the root user that you want to create.
In the Alternative Bind DNs region, click Add to specify one or more alternative DNs that can be used when this root users binds to the server.
For example, the alternative bind DN for the default root user is "cn=Directory Manager"
. This allows you to bind as "cn=Directory Manager"
instead of having to use "cn=Directory Manager,cn=Root DNs,cn=config"
, which is the actual entry DN.
The alternative bind DN must be unique among all root users.
If you do not want to specify an alternative bind DN for the new root user, leave the table empty.
In the Password field, enter a password for the root user.
In the Confirm Password field, retype the password for the root user.
In the Privileges region, select the settings for the different privileges that must be applied to this new root user.
For each privilege, you can select one of the following:
Enable
. The privilege is enabled for this root user.
Disable
. The privilege is disabled for this root user.
Default Privilege (enable)
or Default Privilege (disable
. The user inherits the default setting for this privilege, as defined in the global privilege configuration
Click Create.
The following confirmation message appears:
Root User created successfully
.
You can edit an existing root user by using ODSM, as follows:
Connect to the directory server from ODSM, as described in Section 16.2, "Connecting to the Server Using ODSM."
Select the Configuration tab.
Under the General Configuration item, expand the Root Users item.
Select the root user whose configuration you want to change.
The properties of the root user are displayed in the right hand pane.
Edit the required properties and click Apply.
You are prompted to save the new configuration. Click Yes.
Oracle Unified Directory supports groups, which are collections of entries that are manageable as a single object. Typically, directory administrators configure groups of printers, groups of software applications, groups of employees, and so forth. Groups are especially useful when assigning special access privileges to a set of users. For example, you could configure a group of access managers and assign privileges that enables them to view confidential employee data, but restricts anyone else in the company from accessing that data.
The following group types are supported:
Static groups. A static group defines its membership by providing explicit sets of distinguished names (DNs) using the groupOfNames
, groupOfUniqueNames
, or groupOfEntries
object class. Static groups are well supported by external clients and provide good performance.
For more info, see Section 19.3.1, "Defining Static Groups."
Dynamic groups. A dynamic group defines its membership using a set of search criteria in the form of an LDAP URL, using the groupOfUrls
object class. Dynamic groups handle large numbers of members well (millions of entries). As entries are updated, all parent groups are updated automatically.
A disadvantage of dynamic groups is that not all clients support them. Performance also is adversely affected if you must query the whole list of entries. Thus, dynamic groups are best suited for groups with a very large number of entries or for clients that need to determine specific group membership for an entry.
For more info, see Section 19.3.2, "Defining Dynamic Groups."
Virtual static groups. A virtual static group appears and behaves like a static group to external clients, except that each member is represented by a virtual attribute that defines its membership as needed from another dynamic group.
For more info, see Section 19.3.3, "Defining Virtual Static Groups."
A static group is one whose entry contains a membership list of explicit DNs. Many clients support static groups, but static groups are difficult to manage as the number of members in a group increases in size. For example, if you have a member entry that requires a DN change, then you must change that user's DN for each group to which that user belongs.
The directory server supports the following three types of static groups, divided according to the object class they use:
groupOfNames
. You can define a static group by using the groupOfNames
object class and by explicitly specifying the member DNs using the member
attribute.
Note:
RFC 4519 (https://www.ietf.org/rfc/rfc4519.txt
) requires that the member
attribute be mandatory within the groupOfNames
object class. This membership requirement has traditionally caused data management problems when an administrator attempted to delete the last member in the group. The directory server solves this problem by allowing the member
attribute to be optional. The optional membership requirement allows you to have an empty object class when you delete the last member of the group.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
. You can define a static group by using the groupOfUniqueNames
object class and by explicitly specifying the member DNs using the uniqueMember
attribute. The groupOfUniqueNames
object class differs from the groupOfNames
object class in that you can enumerate the group's members by specifying a unique DN plus an optional identifier. The identifier ensures that the unique objects can be identified when adding, deleting, or renaming any object.
For example, you could delete or move an employee (cn=Tom Smith
) and add a new employee who has the same name (cn=Tom Smith
) to the directory. To distinguish the two, you must add a separate identifier by using a bit string. The following example shows two users with the same name, but the second uniqueMember
has an optional identifier.
uniqueMember: uid=tsmith,ou=People,dc=example,dc=com uniqueMember: uid=tsmith,ou=People,dc=example,dc=com#'0111101'B
Note:
Few LDAP applications actually use the optional UID identifier.RFC 4519 (https://www.ietf.org/rfc/rfc4519.txt
) requires that the uniqueMember
attribute be mandatory within the groupOfUniqueNames
object class. This membership requirement has historically caused data management problems when an administrator tried to delete the last member in the group. Oracle Unified Directory solves this problem by allowing the uniqueMember
attribute to be optional. The optional membership requirement allows you to have an empty object class when you delete the last member of the group.
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
. You can define a static group using the groupOfEntries
object class. Based on the original specifications (RFC 4519 (http://www.rfc-editor.org/rfc/rfc4519.txt
) and draft-findlay-ldap-groupofentries-00.txt
, which expired in March, 2008), the groupOfEntries
object class differs from the groupOfNames
and groupOfUniqueNames
object classes in that attributes are optional, which enables you to specify an empty object class without any members.
Note:
Oracle Unified Directory supports thegroupOfEntries
draft but also allows empty groupOfNames
and groupOfUniqueNames
object classes. As a result, you can create empty groups of any type (groupOfEntries
, groupOfNames
, and groupOfUniqueNames
).
dn: cn=Example Static Group 3,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfEntries cn: Example Static Group 3
This section contains the following topics:
Section 19.3.1.1, "Creating a Static Group With groupOfNames
"
Section 19.3.1.2, "Creating a Static Group With groupOfUniqueNames
"
Section 19.3.1.3, "Creating a Static Group With groupOfEntries
"
Section 19.3.1.5, "Viewing All Static Groups of Which a User Is a Member"
Section 19.3.1.6, "Determining Whether a User is a Member of a Group"
groupOfNames
Create the group entry in LDIF, including the group name (cn
) and the groupOfNames
object class.
This example shows an LDIF file, named static-group1.ldif
, that defines the new group.
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
Add the group by using ldapmodify
to apply the LDIF file.
$ 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
Verify the change by using ldapsearch
and the isMemberOf
attribute.
$ ldapsearch -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --baseDN dc=example,dc=com "(uid=ttully)" isMemberOf dn: uid=ttully,ou=People,dc=example,dc=com isMemberOf: cn=Directory Administrators,ou=Groups,dc=example,dc=com
groupOfUniqueNames
Create the group entry in LDIF, including the group name (cn
) and the groupOfUniqueNames
object class.
This example shows an LDIF file, named static-group2.ldif
, that defines the new group.
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
Add the group by using ldapmodify
to apply the LDIF file.
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename static-group2.ldif
Verify the change by using ldapsearch
and the isMemberOf
attribute.
$ 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
Create the group entry in LDIF, including the group name (cn
) and the groupOfEntries
object class.
This example shows an LDIF file, named static-group3.ldif
, that defines the new group.
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
Add the group by using ldapmodify
to apply the LDIF file.
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename static-group3.ldif
Verify the change by using ldapsearch
and the isMemberOf
attribute.
$ 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
You can use the isMemberOf
virtual attribute to search for a group. The attribute is added to the user entry at the start of the search and then removed after the search has finished. This functionality provides easy management of groups with fast read access.
Use the ldapsearch
command with the virtual attribute isMemberOf
.
This example searches for all users who are members of the group "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
Search using ldapsearch
and the virtual attribute cn=IsMemberOf,
as shown in the following example:
$ 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
Search using ldapsearch
, as shown in the following example:
$ 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
A dynamic group is one whose membership, rather than being maintained explicitly in a list, is determined by search criteria using an LDAP URL. For example, suppose that you want to send an email to all managers in the dc=example,dc=com
naming context. To do this, you create a dynamic group in which you specify cn=Managers,ou=Groups,dc=example,dc=com
. You further specify that you want only email addresses returned. When the email application queries the directory for that particular group, the directory server computes the membership dynamically and returns the corresponding list of email addresses.
Dynamic groups use the groupOfURLs
object class and the memberURL
attribute to define LDAP URLs with the criteria (search base, scope, and filter) to be used for determining members of the group. The mechanism for determining whether a user is a member of a dynamic group is a constant-time operation, so it is just as efficient for groups with millions of members as it is for a group with only a few members. However, care must be taken when specifying the search criteria as it can adversely affect performance if searching over a large set of data.
Figure 19-1 Structure of a Dynamic Group
This section describes the following topics:
Section 19.3.2.3, "Viewing All Dynamic Groups of Which a User Is a Member"
Section 19.3.2.4, "Determining Whether a User Is a Member of a Dynamic Group"
Create an LDIF file that specifies the group.
This example specifies the dynamic group for employees located at 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)
Add the group by using ldapmodify
to process the LDIF file.
$ 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
This procedure illustrates the use of the virtual attribute isMemberOf
. Do not use this procedure for very large groups, because it adversely affects the directory server's performance.
Search using ldapsearch
and the virtual attribute 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)...
Search using ldapsearch
and the virtual attribute 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
Search using ldapsearch
and the virtual attribute 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
A virtual static group allows access to dynamic groups by clients that can only support static groups. In a virtual static group, each entry behaves like a static group entry by using virtual attributes. The virtual attributes are dynamically determined when invoked, and the operations that determine group membership are passed to another group, such as a dynamic group, as shown in the following diagram.
Virtual static groups should include either the groupOfNames
or groupOfUniqueNames
object class but should not include the member
or uniqueMember
attribute. Virtual static groups should also contain the ds-virtual-static-group
auxiliary object class and the ds-target-group-dn
attribute. The ds-target-group-dn
attribute is used to reference the actual group to mirror as a virtual static group and is used in place of the member
or uniquemember
attribute. For example:
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
Virtual static groups are most efficient when the application issues a search targeted at the membership attribute but does not actually retrieve the entire set of members. It is common for applications to use a filter such as the following to attempt to determine whether a user is a member of a given group:
(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=john.doe,\ ou=People,dc=example,dc=com))
For applications that retrieve the set of members, virtual static groups might not be ideal because the process of constructing the entire member list can be expensive.
This section describes the following topics:
Section 19.3.3.2, "Viewing All Members of a Virtual Static Group"
Section 19.3.3.3, "Viewing All Virtual Static Groups of Which a User Is a Member"
Section 19.3.3.4, "Determining Whether a User is a Member of a Virtual Static Group"
Create an LDIF file that specifies the group.
This sample file, virtual-static.ldif
, specifies a virtual static group named 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
Add the group by using ldapmodify
to process the LDIF file.
$ 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
Virtual static groups are best used in cases where the search is targeted at the membership attribute. This procedure is therefore not recommended but is included to show how to access the list.
This example uses the dynamic group, cupertinoEmployees
that was created in the previous example.
Search using ldapsearch
and the virtual attribute 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)...
Search using ldapsearch
and the virtual attribute 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
Search using ldapsearch
and the uniqueMember
attribute.
$ 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
Groups can be nested, where one group is defined as a child group entry whose DN is listed within another group, its parent. The nesting of groups allows you to set up inherited group memberships when performance is not a priority. You can add zero or more member attributes with their values set to the DNs of nested child groups, including both static and dynamic groups.
This example procedure creates a nested group using one static group and one dynamic group.
Create an LDIF file that specifies a static group.
This example file, static-group.ldif
, specifies a virtual static group named 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
Add the group by using ldapmodify
to process the LDIF file.
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename static-group.ldif
Create an LDIF file that specifies a dynamic group.
This example file, dynamic-group.ldif
, specifies a dynamic group named 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)
Add the group by using ldapmodify
to process the LDIF file.
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename dynamic-group.ldif
Create an LDIF file that specifies a nested static group.
This example file, nested-group.ldif
, specifies a nested group named 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
Add the group by using ldapmodify
to process the LDIF file,
$ ldapmodify -h localhost -p 1389 -D "cn=Directory Manager" -j pwd-file \ --defaultAdd --filename nested-group.ldif
Referential integrity is a database mechanism for ensuring that all references are properly maintained after delete, rename, or move operations. For example, if an entry is removed from the directory, the directory server also removes the entry from any groups of which the entry is listed as a member.
The referential integrity mechanism is configured as a plug-in the directory server and can be enabled using the dsconfig
command. For more information, see Section 17.1, "Managing the Server Configuration Using dsconfig
."
This section describes referential integrity, and contains the following topics:
Section 19.4.1, "Overview of the Referential Integrity Plug-In"
Section 19.4.2, "Enabling the Referential Integrity Plug-In"
By default, the referential integrity plug-in is disabled. When you enable the plug-in by using dsconfig
, it performs integrity updates on the member
and uniquemember
attributes after a delete, rename, or move operation.
Referential integrity plug-in can be configured to do the processing either in background or foreground mode based on update-interval
configuration parameter. See ”Referential Integrity Plugin” in Fusion Middleware Configuration Reference for Oracle Unified Directory for more information. By default, the value of update-interval
is 0. If the update-interval
value is 0, then the updates are made synchronously in the foreground. If the update-interval
value is set to > 0, then it runs in the background mode.
When referential integrity plug-in is configured to run in the background mode, if you delete, rename, or move a user or group entry in the directory, the operation is logged to the referential integrity log file, INSTANCE_DIR/OUD/logs/referint
.
After a specified time, known as the update-interval
, the server performs a search on the specified attributes and matches the results with the DNs of the deleted or modified entries recorded in the log. Then the server modifies the attributes based on the result of the match. The referint
log is only updated when the value of update-interval
is >0. The DN log is removed after the update-interval
time elapses, and then the user DN is removed from other entries based on the referential integrity plug-in parameter config
.
You can configure the following referential integrity plug-in properties to suit your requirements:
Enabled. Turn on the referential integrity plug-in.
plugin type. By default, the delete, rename, and move operations are set. You can change a plug-in type to only delete, for example.
Attribute type. By default, the attribute types are set to member,uniquemember
but can be changed to some other attribute. If you use or define attributes containing DN values, you can use the referential integrity plug-in to monitor these attributes.
Base-DN. By default, the scope is to use all public naming contexts but this can be changed to a specific context.
Log file. By default, logs/referint
is the log file. You can record the referential integrity updates in a different file. For example, if you want to record changes in a replicated environment, you can write to the changelog file on a replication server, so that it can be replicated to a consumer server.
Update-interval. By default, the update-interval
is set to 0 seconds, which will run referential integrity immediately after a delete, rename, or move operation. To minimize the impact of the updates on system performance, increase the amount of time between updates. Typical update intervals are as follows:
0 seconds, update immediately
90 seconds (updates every 90 seconds)
3600 seconds (updates every hour)
10,800 seconds (updates every 3 hours)
28,800 seconds (updates every 8 hours)
86,400 seconds (updates once a day)
604,800 seconds (updates once a week)
To enable referential integrity by using dsconfig
, set the enabled
property of the plug-in to 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) includes a roles subsystem that is used to provide a specialized type of grouping mechanism. This capability is not included directly in Oracle Unified Directory, because it is based on nonstandard functionality, uses Netscape-proprietary schema elements, and is not widely used in LDAP-enabled applications.
However, Oracle Unified Directory does provide all of the functionality offered by ODSEE roles, and this functionality is available for use with standard grouping mechanisms. If you have an application that was specifically written to rely on the roles functionality available in ODSEE and cannot work with standard grouping mechanisms, you can configure Oracle Unified Directory to simulate ODSEE roles to satisfy such applications.
Note:
If your application needs to create and destroy role entries (for example, an entry containing one of the subordinates of thensRoleDefinition
object class), that functionality is currently not available in Oracle Unified Directory.This section contains the following topics:
Section 19.5.1, "Determining Whether a User is a Member of a Role"
Section 19.5.2, "Altering Membership Using the nsRoleDN
Attribute"
If the application only needs to determine whether a user is a member of a given role, it should only need to look at the nsRole
attribute in the target user's entry to determine whether the DN of the appropriate role is present. In this case, you can simulate role functionality by following the steps described in this section.
After completing these steps are completed, the nsRole
virtual attribute appears as an operational attribute in user entries, and should include the DNs of all groups in which that user is a member.
Note:
ThensRole
attribute is an operational attribute, and you must explicitly request that it returned in search results. You must also ensure that the authenticated user has permission to see that attribute.Update the directory server to include the necessary schema for the ODSEE roles implementation.
This schema is provided in the LDIF file, 03-dsee-roles.ldif
, as follows:
# 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' )
Either copy the file into the config/schema
directory of the directory server implementation and restart the server, or
Use the add schema file
task to cause the server to load the schema file into a running server instance.
Create a static or dynamic group to define role membership.
Ensure that the group has an appropriate set of members.
Create a new instance of the isMemberOf
virtual attribute to provide the nsRole
virtual attribute.
The nsRole
attribute will include a list of the DNs of all groups in which the target user is a member. Use the dsconfig
command to create the virtual attribute, as follows:
$ 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
AttributeFollow this procedure if the application you are using expects to be able to alter membership by placing the name of the corresponding role in the nsRoleDN
virtual attribute in a user's entry.
After these steps are completed, any user entry that contains an nsRoleDN
value of "cn=Test Role,ou=Roles,dc=example,dc=com"
also has that DN present in the nsRole
operational attribute.
Create a dynamic group entry with the DN of the desired role.
Configure the group to include members that contain an nsRoleDN
attribute with a value equal to the DN of the target role.
For example, if the application is going to add an nsRoleDN
value of "cn=Test Role,ou=Roles,dc=example,dc=com"
, add the following entry:
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)