This chapter describe root user accounts and the privilege subsystem.
Most LDAP directory servers typically have a single superuser, which is much like the root account in traditional UNIX systems. This account can bypass access controls and other restrictions that might be enforced for regular users. In Oracle Unified Directory you can define multiple root users, and a privilege subsystem that makes it possible to control capabilities at a more fine-grained level.
This chapter includes the following sections:
Root user accounts are defined below the cn=Root DNs,cn=config branch in the server configuration. Each root account is defined as a regular user entry, except that it includes the ds-cfg-root-dn-user auxiliary object class. A root user entry can also have one or more values for the ds-cfg-alternate-bind-dn attribute. This attribute specifies alternate DNs that can be used to authenticate as that user (for example, so you can 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 ability to define multiple root users, each in its own entry, provides the following advantages:
Each administrator that needs root access to the directory server can have their own account with their own credentials. This makes it easier to keep an audit trail of who does what in the directory server than if all of the administrators shared a single root account.
Because each root user account has its own set of credentials, the credentials for one root user can be changed without impacting any of the other root users. It is not necessary to coordinate root password changes among all of the administrators because each of them has their own account. If an administrator leaves, that account can simply be deactivated or removed.
Because each root user has its own entry, and you can put whatever attributes and object classes you want into that entry (if it also has the ds-cfg-root-dn-user auxiliary object class), root users are capable of using strong authentication like the EXTERNAL or GSSAPI SASL mechanisms.
Root users are subject to password policy enforcement. This means that you can force root users to change their passwords on a regular basis, ensure that they are only allowed to authenticate or change their passwords using secure mechanisms, and ensure that they choose strong passwords. You can also use custom password policies for root users, so that they are subject to different sets of password policy requirements than other users in the directory.
You can define different resource limits for root users than for regular users. Because each root account has its own entry, operational attributes like ds-rlim-size-limit, ds-rlim-time-limit, and ds-rlim-lookthrough-limit work for root users just as they do with regular user accounts.
Only root users can bind to the administration port because administrative binds are resolved with root dns from cn=config. To create a root dn, see Section 29.3.3, "Creating a Root User."
As mentioned above, root user accounts in traditional directories are special because they can bypass access controls and other restrictions, and there are some kinds of operations that only root users can perform. This is much like the concept of root users in traditional UNIX operating systems. However, there might be cases in which a regular user needs to do something that only a root user can do. If users are given root access, they are given far more power than they actually need to do their job, and system administrators have to hope that they use this power responsibly and do not intentionally or unintentionally impact some other part of the system. Alternately, the user might not be given root access and either not be able to perform a vital function or have to rely on one of the system administrators to perform the task.
Solaris 10 and onward address this problem in UNIX systems by creating a privilege subsystem (also called "process rights management"). The engineers developing Solaris realized that it is dangerous and undesirable to be forced to give someone root access just to perform one specific task. For example, just because a user may need to start a process that listens on a port below 1024 does not mean that they should also be able to bypass filesystem permissions, change network interface settings, or mount and unmount file systems. With the privilege subsystem in Solaris 10, it is possible to give a user just the specific capability that they need, for example, the ability to bind to privileged ports, without giving them full root access. Similarly, it is possible to take away privileges that might otherwise be available. For example, an account that is only used to run a specific daemon does not need to be able to see processes owned by other users on the system.
Note:
Administrators should consider Oracle Privileged Account Management system to achieve the best security level.Oracle Unified Directory also has a privilege subsystem that defines distinct capabilities that users might need and makes it possible to give them just the level of access that they require. Regular users can be granted privileges that they would not otherwise have, certain privileges can be taken away from root users. The set of privileges currently defined in the directory server includes:
bypass-aclAllows the user to bypass access control evaluation
modify-aclAllows the user to make changes to the access controls defined in the server
config-readAllows the user to have read access to the server configuration
config-writeAllows the user to have write access to the server configuration
jmx-readAllows the user to read JMX attribute values
jmx-writeAllows the user to update JMX attribute values
jmx-notify* Allows the user to subscribe to JMX notifications
ldif-importAllows the user to request the LDIF import task
ldif-exportAllows the user to request the LDIF export task
backend-backupAllows the user to request the back end backup task
backend-restoreAllows the user to request the back end restore task
server-shutdownAllows the user to request the server shutdown task
server-restartAllows the user to request the server restart task
proxied-authAllows the user to use the proxied authorization control or request an alternate SASL authorization ID
disconnect-clientAllows the user to terminate arbitrary client connections
cancel-request* Allows the user to cancel arbitrary client requests
unindexed-searchAllows the user to request unindexed search operations
password-resetAllows the user to reset the passwords for other users
update-schemaAllows the user to update the server schema
privilege-changeAllows the user to change the set of privileges assigned to a user, or to change the set of default root privileges
Currently, the privileges marked with an asterisk (*) are not yet implemented in the server and therefore have no effect.
The privilege subsystem is largely independent of the access control subsystem. Unless the user also has the bypass-acl privilege, operations might still be subject to access control checking. For example, if a user has the config-read privilege, that user can see only those parts of the configuration that are allowed by access control. As a rule, whenever an operation is covered by both the privilege subsystem and access control, both mechanisms must allow that operation.
By default, normal users are not granted any of the privileges described previously. Therefore, if a user should be allowed to perform any of the associated operations, they must be granted the appropriate privileges. This can be done by adding the ds-privilege-name operational attribute to the user's entry.
Note:
Adding a privilege with a value such asmodify-acl is not sufficient for granting a user the right to add, replace, or delete an ACI. Appropriate access control for the user to modify the ACI for another entry is also required. See Appendix P, "ACI Syntax" for more information.ds-privilege-name is a multivalued attribute, and if a user is to be given multiple privileges, then a separate value should be used for each one. When the virtual attribute subsystem is in place, it should also be possible to grant privileges to groups of users automatically by making ds-privilege-name a virtual attribute in those user entries.
As an example, the following modification can be used to add the proxied-auth privilege to the user cn=Proxy User,dc=example,dc=com:
dn: cn=Proxy User,dc=example,dc=com changetype: modify add: ds-privilege-name ds-privilege-name: proxied-auth
Note:
If you want the modifications of the privileges of a user to take effect on an open connection after the first bind, then you must set themaintain-authenticated-users flag to true. By default, it is set to false.
For an open connection, which is bound with a determined authDN, importing that entry with dn: authDN using import-ldif command does not modify the properties (access rights, privileges, and so on) of that authDN in those already established connections. The new properties for the authDN as a result of import-ldif are effective only for new binds as authDN. In this scenario, setting maintain-authenticated-users:true does not help.
With the introduction of the privilege subsystem, the primary distinguishing characteristics of root users that separate them from other accounts in the server are that they exist in the configuration rather than in the user data, and that because they are root users they automatically inherit a certain set of privileges. The set of privileges automatically granted to root users is defined in the ds-cfg-default-root-privilege-name attribute of the cn=Root DNs,cn=config entry. By default, root users are automatically granted the following privileges:
bypass-acl
modify-acl
config-read
config-write
ldif-import
ldif-export
backend-backup
backend-restore
server-shutdown
server-restart
disconnect-client
cancel-request
unindexed-search
password-reset
update-schema
privilege-change
If you want to alter the set of privileges that are automatically assigned to root users, then you may do so by editing the ds-cfg-default-root-privilege-name attribute. Further, if you want to have a different set of privileges for a specific root user, then you can accomplish that using the ds-privilege-name attribute in that root user's entry, just like for a normal user. For example, the following modification may be used to give a specific root user (in this case cn=Test Root User,cn=Root DNs,cn=config) the ability to use proxied authorization while removing the ability to change user privileges or access the configuration. (The minus sign before the privilege indicates that it is being removed rather than granted.):
dn: cn=Test Root User,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 case, the cn=Test Root User,cn=Root DNs,cn=config user inherits all privileges automatically granted to root users with the exception of the config-read and config-write privileges and is also given the proxied-auth privilege.