29 Managing Administrative Users
Topics:
29.1 About Privilege Subsystem
Oracle Unified Directory provides a flexible Privilege Subsystem that allows you to configure root users, Global Administrators, and administrators for your server. You can configure multiple root users and assign different root privileges to each administrator. For administrative domains, you can also configure multiple Global Administrators to manage administrative domains in your network or in a replicated environment.
Before you start using the procedures provided in this chapter, you must determine the following guidelines for your server:
-
Number of root users, their privileges, and resource limits, if any.
-
Number of administrators, their privileges, and resource limits, if any.
-
Guidelines for user accounts on your system.
-
Password policies for the server and for specific groups of users.
29.2 Defining Root Users
Review these topics for descriptive information about root users and the privilege subsystem.
29.2.1 About Root User
Oracle Unified Directory provides one default root DN or root user, "cn=Directory Manager"
. The default root DN is a user entry assigned with specialized privileges including full read and write access to all data in the server.
Comparable to a UNIX root user or superuser, the root DN can bypass access controls to perform tasks on the server. The root user is defined below the "cn=Root DNs,cn=config"
branch of the server at cn=Directory Manager,cn=Root DNs,cn=config
.
Root users differ from regular user entries in the following ways:
-
Configuration. Root users are the only user accounts that can exist in the server configuration (
cn=config
). -
Privilege inheritance. Root users automatically inherit the set of default root user privileges. Regular users do not automatically receive any privileges unless explicitly granted. You can grant privileges using real, virtual root-privilege-name attributes, or both in the entry.
-
Lockdown mode. Root users are the only users who can cause the server to enter or leave lockdown mode, and only over the loopback interface.
29.2.2 About Multiple Root Users
The server supports multiple root users who have their own entries and their own set of credentials on the server. This allows you to 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.
With each entry, you can assign strong authentication such as the GSSAPI SASL mechanism, password policies, or add resource limits (if your schema allows it) to one root user while having a completely different configuration for another root user.
The Privilege Subsystem supports the configuration of multiple root users.
29.2.3 Root Users and the Privilege Subsystem
The Privilege Subsystem allows you to assign refined privileges to users who might require only a specific set of root user access privileges. Root users are automatically granted a set of privileges defined in the default-root-privilege-name
attribute in the "cn=Root DNs,cn=config"
subtree.
The Privilege Subsystem is independent from the Access Control Subsystem, but some operations might be subject to access controls.
The following table lists a set of privileges that are automatically assigned to the root user.
Privilege | Description |
---|---|
|
Allows the user to request the back-end backup task. |
|
Allows the user to request the back-end restore task. |
|
Allows the user to bypass access control evaluation. |
|
Allows the associated user to bypass server lockdown mode. |
|
Allows the user to cancel arbitrary client requests. |
|
Allows the user to have read access to the server configuration. |
|
Allows the user to have write access to the server configuration. |
|
Allows the user to terminate arbitrary client connections. |
|
Allows the user to request the LDIF export task. |
|
Allows the user to request the LDIF import task. |
|
Allows the user to make changes to access control instructions defined in the server. |
|
Allows the user to reset the user passwords. |
|
Allows the user to change the set of privileges assigned to a user, or to change the set of default root privileges. |
|
Allows the user to request the server restart task. |
|
Allows the user to request the server shutdown task. |
|
Allows the associated user to perform LDAP subentry write operations. |
|
Allows the user to request unindexed search operations. |
|
Allows the user to update the server schema. |
The following table lists the privileges that can be assigned to the root user.
Privilege | Description |
---|---|
|
Allows the user to subscribe to JMX notifications. |
|
Allows the user to read JMX attribute values. |
|
Allows the user to update JMX attribute values. |
|
Allows the user to use the proxied authorization control or to request an alternate SASL authorization ID. |
29.3 Managing Root Users With dsconfig
Use the dsconfig
command to manage root users.
For more information, see Managing the Server Configuration Using dsconfig.
The following topics list the tasks to manage root users using dsconfig
command:
29.3.1 Viewing the Default Root User Privileges
The default root user has various privileges, which are stored as values of the default-root-privilege-name
property.
View the default root user privileges by running the following dsconfig
command:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ get-root-dn-prop Property : Value(s) ----------------------------:-------------------------------------------------- default-root-privilege-name : backend-backup, backend-restore, bypass-acl, : cancel-request, config-read, config-write, : disconnect-client, ldif-export, ldif-import, : modify-acl, password-reset, privilege-change, : server-restart, server-shutdown, : unindexed-search, update-schema
29.3.2 Editing the Default Root User Privileges
You can add or remove privileges for the default root user or add or remove the values of the default-root-privilege-name
property. The easiest way to manage root user privileges is to use dsconfig
in interactive mode. Interactive mode walks you through the root user configuration, and is therefore not documented here.
The default-root-privilege-name
property holds the following values:
-
backend-backup
-
backend-restore
-
bypass-acl
-
cancel-request
-
config-read
-
config-write
-
disconnect-client
-
jmx-notify
-
jmx-read
-
jmx-write
-
ldif-export
-
ldif-import
-
modify-acl
-
password-reset
-
privilege-change
-
proxied-auth
-
server-restart
-
server-shutdown
-
unindexed-search
-
update-schema
The following example adds the jmx-notify
privilege to the default root user, by using dsconfig
in non-interactive mode.
Run the dsconfig
command as follows:
$ dsconfig -h localhost -p 4444 -D "cn=directory manager" -j pwd-file -n \ set-root-dn-prop --add default-root-privilege-name:jmx-notify
29.3.3 Creating a Root User
Use the ldapmodify
command to create a new root user and to create the entry in LDIF. Root users are stored below the entry cn=Root DNs,cn=config
.
Note:
The cn=config
suffix is available only through the administration connector, and must therefore be accessed over SSL, through the administration port.
Root users automatically inherit the set of default root user privileges on the server.
To create a root user:
For information about adding or removing privileges for a specific root user, see Changing a Root User's Privileges.
29.3.4 Changing a Root User's Password
Use the ldappasswordmodify
client command to change the password of a root user.
To change a root user's password:
29.3.5 Changing a Root User's Privileges
If you want to have a different set of privileges for a specific root user, add the ds-privilege-name
attribute to that root user's entry.
The following example gives the root user "cn=MyRootUser,cn=Root DNs,cn=config"
the ability to use proxied authorization. The example removes the ability to change user privileges or access the configuration. The minus sign before the privilege indicates that the privilege is being removed rather than granted.
Apply the following LDIF statement to the root user's entry:
dn: cn=MyRootUser,cn=Root DNs,cn=config changetype: modify add: ds-privilege-name ds-privilege-name: proxied-auth ds-privilege-name: -config-read ds-privilege-name: -config-write
In this example, the root user "cn=MyRootUser,cn=Root DNs,cn=config"
would inherit all privileges automatically granted to root users with the exception of the config-read
and config-write
privileges. The user would also be given the proxied-auth
privilege.
29.4 Setting Root User Resource Limits
You can set resource limits on the server for search operations by using the operational attributes on the client application that is binding to the server.
The following resource limits are available:
-
Look-through limit. Specify the maximum number of entries that can be examined during a single search operation. Use the
ds-rlim-lookthrough-limit
operational attribute. -
Size limit. Specify the maximum number of entries that can be returned in a single search operation. Use the
ds-rlim-size-limit
operational attribute. -
Time limit. Specify the maximum length of time in seconds that the server can spend processing a search operation. Use the
ds-rlim-time-limit
operational attribute.
The following LDIF update statement sets resource limits for the new root user created in the previous section. This statement should be applied to the root user's entry.
dn: cn=MyRootUser,cn=Root DNs,cn=config 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
To set a particular resource limit to unlimited, set the value of the corresponding attribute to 0
(zero).
29.5 Managing Administrators
An administrator generally has broader rights and permissions than most users. By default, administrators are not replicated because they are stored in the OUD configuration. You can create several administrators, each with different access controls and resource limits.
When you set up replication servers using the graphical installer or the dsreplication
command, you are prompted to set a user name and password for the Global Administrator. The Global Administrator is responsible for managing and maintaining administrative server domains in replicated environments.
Note:
Only root users can bind to the administration port because administrative binds are resolved with rootdns
from cn=config
.
More information on administrators is explained in the following sections:
29.5.1 Viewing the Global Administrator Entry
The Global Administrator created for the replication exists in the cn=Administrators,cn=admin data
subtree, so it is replicated and can be used with every OUD instance of a replicated topology.
To view the Global Administrator entry, run the following ldapsearch
command:
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -j pwd-file \ --useSSL -b "cn=Administrators,cn=admin data" -s sub "(objectclass=*)" dn: cn=Administrators,cn=admin data objectClass: top objectClass: groupofurls description: Group of identities which have full access. cn: Administrators memberURL: ldap:///cn=Administrators,cn=admin data??one?(objectclass=*) dn: cn=admin,cn=Administrators,cn=admin data objectClass: person objectClass: top userPassword: {SSHA}+ed1wbhcWjxtv2zJ6OHEA2TuE9n1qIJGnuR94w== description: The Administrator that can manage all the OUD instances. cn: admin
29.5.2 Creating Administrators with Limited Privileges
The Global Administrator created for the replication has the full set of administrator privileges. In some situations, it might be useful to create additional administrators having only a subset of administrator rights. For example, a Monitor Administrator would have the privilege to read the OUD configuration, but would not be able to modify it. Custom administrators are stored in a replicated suffix cn=admin data
. Like Global Administrators, custom administrators are replicated.
To create an administrator with limited privileges, create your own administrator container node in the cn=admin data
suffix:
./ldapmodify -a -p 4444 -Z -X -D "cn=directory manager" -w **** dn: cn= my admins,cn=admin data objectclass: top objectClass: ds-cfg-branch dn: cn=monitor,cn=my admins,cn=admin data objectClass: person cn: monitor sn: monitor userpassword: ****
At this stage, it is possible to use these credentials (cn=monitor,cn=my admins,cn=admin data
) with dsconfig
. The dsconfig
command can authenticate that user, however the administrator won't be able to read the configuration because the administration does not have the privilege to do so. The dsconfig
command reports the following error during navigation in the configuration:
The Administration Connector could not be modified because you do not have the correct authorization
You must assign the appropriate privileges giving the administrator the right to perform the desired actions. In the previous example, the administrator must be assigned the config-read
privilege. The bypass-acl
privilege is also required so that the administrator can perform privileged actions on the configuration.
./ldapmodify -p 4444 -Z -X -D "cn=directory manager" -w **** dn: cn=monitor,cn=my admins,cn=admin data changetype: modify add: ds-privilege-name ds-privilege-name: bypass-acl ds-privilege-name: config-read
Now the administrator can read the configuration using dsconfig
. However, any attempt to modify the configuration would result in the following error:
The Configuration could not be modified because you do not have the correct authorization.