Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Unified Directory
11g Release 2 (11.1.2)

Part Number E22648-05
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

19 Managing Users and Groups

Oracle Unified Directory provides a comprehensive user management model that includes identity mapping, and account status notification. This section describes how to configure these elements by using the command-line utilities and by using the Oracle Directory Services Manager interface.

The chapter covers the following topics:

For information about user passwords, see Chapter 24, "Managing Password Policies."

19.1 Managing User Accounts

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 24, "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 covers the following topics:

19.1.1 Changing Passwords

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:

19.1.1.1 To Change the Directory Manager's Password

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

19.1.1.2 To Reset and Generate a New Password for a User

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

19.1.1.3 To Change a User's Password

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

19.1.2 Managing a User's Account Information

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 via the administration port. For more information, see Section 14.3, "Managing Administration Traffic to the Server."

This section describes how to manage a user's account information, and covers the following topics:

19.1.2.1 To View a User's Account Information

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

  1. 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:
    
  2. 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
    

19.1.2.2 To View Account Status Information

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

19.1.2.3 To Disable an Account

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

19.1.2.4 To Enable an Account

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

19.1.2.5 To Enable an Account Using orclIsEnabled

To enable Oracle Unified Directory using orclIsEnabled, complete the following steps:

  1. 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
    
  2. 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
    

19.1.3 Setting Resource Limits on a User Account

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 Oracle Unified Directory Configuration Reference.

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.

19.1.3.1 To Set Resource Limits on an Account

  1. 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
    
  2. 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
    

19.2 Configuring Root Users

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 might need root access for a particular task but might not need the full set of root user privileges. You can 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.

19.2.1 Configuring Root Users by Using the Command-Line Utilities

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.

19.2.1.1 To Change the Global Root User Privileges

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 10.2, "Privilege Subsystem".

19.2.1.2 To Create a New Root User

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 that the cn=config suffix is an administrative suffix and, as such, must be accessed using the administration connector. For more information see Section 14.3, "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.

  1. 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
    
  2. 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 10.2, "Privilege Subsystem".

19.2.1.3 To Edit an Existing Root User

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 that the cn=config suffix is an administrative suffix and, as such, must be accessed using the administration connector. For more information see Section 14.3, "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

19.2.2 Configuring Root Users by Using ODSM

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:

19.2.2.1 Configure the Global Root User Privileges

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:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."

  2. Select the Configuration tab.

  3. 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.

  4. 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 10.2, "Privilege Subsystem".

  5. When you have made the modifications that you require, click Apply.

19.2.2.2 Create a New Root User

You can create a new root user by using ODSM, as follows:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."

  2. Select the Configuration tab.

  3. From the Create menu, select Root User.

  4. In the General Properties region, enter the following details:

    1. In the Name field, type a name for the root user that you want to create.

    2. 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.

    3. In the Password field, enter a password for the root user.

    4. In the Confirm Password field, retype the password for the root user.

  5. 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

  6. Click Create.

    The following confirmation message appears:

    Root User created successfully.

19.2.2.3 Edit an Existing Root User

You can edit an existing root user by using ODSM, as follows:

  1. Connect to the directory server from ODSM, as described in Section 18.2, "Connecting to the Server From Oracle Directory Services Manager."

  2. Select the Configuration tab.

  3. Under the General Configuration item, expand the Root Users item.

  4. Select the root user whose configuration you want to change.

    The properties of the root user are displayed in the right hand pane.

  5. Edit the required properties and click Apply.

  6. You are prompted to save the new configuration. Click Yes.

19.3 Defining Groups

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 can assign access managers the privileges to employee data while restricting those same privileges to others in the company.

The following group types are supported:

19.3.1 Defining 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 the user's DN for each group she belongs to.

Because a static group contains a list of explicit member DNs, its database footprint increases as the membership list grows. For this reason, a static group is best suited for small groups (less than 10,000) whose entries do not change frequently. Using large static groups can have a detrimental impact on performance. If you know that group membership will exceed 10,000, consider using dynamic groups instead.

Description of static_group.gif follows
Description of the illustration static_group.gif

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://opends.dev.java.net/public/standards/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://opends.dev.java.net/public/standards/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 (http://ietfreport.isoc.org/idref/draft-findlay-ldap-groupofentries/), which expired in March, 2008), the groupOfEntries object class differs from the groupOfNames and groupOfUniqueNames object classes in that attributes are optional. This allows you to specify an empty object class without any members.

    Note:

    Oracle Unified Directory supports the groupOfEntries 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:

19.3.1.1 To Create a Static Group With groupOfNames

  1. 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
    
  2. 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
    

19.3.1.2 To Create a Static Group With groupOfUniqueNames

  1. 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
    
  2. 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
    
  3. 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
    

19.3.1.3 To Create a Static Group With groupOfEntries

  1. 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
    
  2. 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
    
  3. 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
    

19.3.1.4 To List All Members of a Static Group

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

19.3.1.5 To List All Static Groups of Which a User Is a Member

Search using ldapsearch and the virtual attribute 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

19.3.1.6 To Determine Whether a User is a Member of a Group

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

19.3.2 Defining Dynamic Groups

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

Description of Figure 19-1 follows
Description of "Figure 19-1 Structure of a Dynamic Group"

This section describes the following topics:

19.3.2.1 To Create a Dynamic Group

  1. 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)
    
  2. 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
    

19.3.2.2 To List All Members of a Dynamic Group

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)...

19.3.2.3 To List All Dynamic Groups of Which a User Is a Member

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

19.3.2.4 To Determine Whether a User Is a Member of a Dynamic Group

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

19.3.3 Defining Virtual Static Groups

A virtual static group, efficiently manages scalability for 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.

Figure 19-2 Virtual Static Group

Description of Figure 19-2 follows
Description of "Figure 19-2 Virtual Static Group"

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:

19.3.3.1 To Create a Virtual Static Group

  1. 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
    
  2. 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
    

19.3.3.2 To List All Members of a Virtual Static Group

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 isMemberOf.

$ 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: 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.3.3 To List All Virtual Static Groups of Which a User Is a Member

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

19.3.3.4 To Determine Whether a User is a Member of a Virtual Static Group

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

19.3.4 Defining Nested Groups

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.

Figure 19-3 Nested Static Group

Description of Figure 19-3 follows
Description of "Figure 19-3 Nested Static Group"

19.3.4.1 To Create a Nested Group

This example procedure creates a nested group using one static group and one dynamic group.

  1. 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
    
  2. 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
    
  3. 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)
    
  4. 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
    
  5. 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
    
  6. 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
    

19.4 Maintaining Referential Integrity

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 14.1, "Managing the Server Configuration With dsconfig."

This section describes referential integrity, and contains the following topics:

19.4.1 Overview of 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 immediately after a delete, rename, or move operation. Whenever 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. If the log file shows that an entry was deleted, the corresponding attribute is deleted. If the log file shows that an entry was changed, the corresponding attribute value is modified accordingly.

You can configure the properties of the referential integrity plug-in to suit your requirements. The following properties can be configured:

  • 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)

19.4.2 To Enable the Referential Integrity Plug-In

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

19.5 Simulating ODSEE Roles in an Oracle Unified Directory Server

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 non-standard 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 the nsRoleDefinition object class), that functionality is currently not available in Oracle Unified Directory.

This section contains the following topics:

19.5.1 To Determine Whether a User is a Member of a Role

If the application needs only 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 these steps.

After 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 that nsRole is an operational attribute, and must be explicitly requested for it to be returned in search results. You must also ensure that the authenticated user has permission to see that attribute.

  1. Update the directory server to include the necessary schema for the ODSEE roles implementation.

    This schema is provided in the LDIF file named 03-dsee-roles.ldif.

    1. Either copy the file into the config/schema directory of the directory server implementation and restart the server, or

    2. Use the add schema file task to cause the server to load the schema file into a running server instance.

  2. Create a static or dynamic group to define role membership.

    Make sure that the group has an appropriate set of members.

  3. 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
    

19.5.2 To Alter Membership by Using the nsRoleDN Attribute

Follow 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.

  1. Create a dynamic group entry with the DN of the desired role.

  2. 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)