Administrative roles
The server setup process creates one directory superuser account. The directory superuser has unrestricted access to manage the directory service and data.
For any directory service with more than one administrator, one account is not enough. Instead, grant appropriate access to each administrator, based on their duties.
Administrative access
Only the directory superuser should have all the default access and privileges of that account. Directory service administrators should have limited access, as outlined in the following table:
| Tasks | Required Access(1) and Privileges(2) |
|---|---|
Install and upgrade servers |
Access to file system. Access to run server commands. |
Delegate administration |
Access to write administration-related attributes on others' entries. DS server privileges: |
Manage server processes (start, restart, stop) |
Access to run the DS server privileges: |
Manage changes to server configuration, including global and default settings |
Access to read and write to DS server privileges: |
Manage containers for user data, including backends and indexes |
File system access for backup data and exported LDIF. Access to create entries under DS server privileges: |
Manage changes to server schemas |
Access to write to File system access to add schema files. DS server privilege: |
Manage directory server data replication |
File system access to read Access to read and write to Access to run the DS server privileges: |
Monitor the directory service |
Access to read DS server privileges: |
Back up and restore directory data |
File system access for backup data and exported LDIF. Access to create entries under DS server privileges: |
Troubleshoot problems with the directory service |
File system access to read log messages. Write access to create entries under Access to read DS server privileges: |
(1) Access control is covered in Access control.
(2) Privileges are covered in Administrative privileges.
Directory data administrators should have limited access, as outlined in the following table:
| Tasks | Required Access(1) and Privileges(2) |
|---|---|
Manage changes to users, groups, and other accounts for their organizations |
Access to read and write to others' entries. |
Delegate administration within their organizations |
Access to write administration-related attributes on others' entries. DS server privileges: |
Update administrative user data, such as subentry password policies and access controls |
Access to write administration-related attributes on others' entries. DS server privileges: |
Help users who are locked out, or have forgotten or lost their password |
Access to use the Access to request a password modify extended operation. Access to update passwords on user entries. DS server privilege: |
Assist users and application developers who access the directory service |
Access to read (and potentially write to) others' entries. If performing operations on behalf of other users, access to request proxied authorization. DS server privilege: |
(1) Access control is covered in Access control.
(2) Privileges are covered in Administrative privileges.
Administrative accounts
|
Limit use of the To bootstrap the system, the default directory superuser account is not subject to access control. It has privileges to perform almost every administrative operation, including increasing its own privileges. Treat this account as you would the UNIX |
Use a non-default superuser account
The following steps replace the directory superuser account:
-
Create an administrator account that duplicates the default directory superuser account.
Show details
The default administrator account is
uid=admin. It is stored in its own backend,rootUser. TherootUserLDIF backend holds the filedb/rootUser.ldif.The following example shows the LDIF for an alternative directory superuser:
dn: uid=altadmin objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Alternative Superuser givenName: Alternative sn: Superuser ds-rlim-size-limit: 0 ds-rlim-time-limit: 0 ds-rlim-idle-time-limit: 0 ds-rlim-max-candidate-set-size: 100000 ds-pwp-password-policy-dn: cn=Root Password Policy,cn=Password Policies,cn=config ds-privilege-name: bypass-lockdown ds-privilege-name: bypass-acl ds-privilege-name: modify-acl ds-privilege-name: config-read ds-privilege-name: config-write ds-privilege-name: ldif-import ds-privilege-name: ldif-export ds-privilege-name: backend-backup ds-privilege-name: backend-restore ds-privilege-name: server-lockdown ds-privilege-name: server-shutdown ds-privilege-name: server-restart ds-privilege-name: disconnect-client ds-privilege-name: cancel-request ds-privilege-name: password-reset ds-privilege-name: update-schema ds-privilege-name: privilege-change ds-privilege-name: unindexed-search ds-privilege-name: subentry-write ds-privilege-name: changelog-read ds-privilege-name: monitor-read uid: altadmin userPassword: passwordDo not use
altadmin, since it shows up here in the documentation. -
Create a private backend to store the new directory superuser account.
Show details
The following example creates an LDIF backend to store the entry. Before creating the backend, create a separate directory to hold the backend files:
$ mkdir /path/to/opendj/db/altRootUser $ dsconfig \ create-backend \ --hostname localhost \ --port 4444 \ --bindDN uid=admin \ --bindPassword password \ --backend-name altRootUser \ --type ldif \ --set enabled:true \ --set base-dn:uid=altadmin \ --set ldif-file:db/altRootUser/altRootUser.ldif \ --set is-private-backend:true \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --no-prompt -
Import the new directory superuser entry into the new backend:
Show details
$ import-ldif \ --hostname localhost \ --port 4444 \ --bindDN uid=admin \ --bindPassword password \ --backendID altRootUser \ --ldifFile /tmp/alt-root.ldif \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin -
Remove the backend database and the unused LDIF files for the default superuser account:
Show details
$ dsconfig \ delete-backend \ --hostname localhost \ --port 4444 \ --bindDN uid=admin \ --bindPassword password \ --backend-name rootUser \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --no-prompt $ rm -rf /path/to/opendj/db/rootUserIn this example,
uid=altadminnow has the same rights as the original superuser. -
Repeat these steps for other DS servers.
The account is not replicated by default.
Make users administrators
You can assign access and privileges to any directory account:
-
Adjust the resource limits to as needed.
For details, see Resource limits.
-
Assign any necessary administrative privileges.
For details, see Administrative privileges.
-
Add any necessary ACIs.
For details, see Access control.
Administrative privileges
Privileges provide access control for server administration independently from ACIs.
The default directory superuser, uid=admin, is granted the privileges marked with an asterisk (*):
| Privilege | Description |
|---|---|
|
Request a task to back up data, or to purge backup files. |
|
Request a task to restore data from backup. |
|
Perform operations without regard to ACIs. |
|
Perform operations without regard to lockdown mode. |
|
Cancel any client request. |
|
Read the changelog (under |
|
Read the server configuration. |
|
Change the server configuration. |
|
Perform data synchronization. |
|
Close any client connection. |
|
Subscribe to JMX notifications. |
|
Read JMX attribute values. |
|
Write JMX attribute values. |
|
Export data to LDIF. |
|
Import data from LDIF. |
|
Change ACIs. |
|
Read metrics under |
|
Reset other users' passwords. |
|
Change the privileges assigned to users, including their own privileges. |
|
Use the LDAP proxied authorization control. |
|
Put the server into and take the server out of lockdown mode. |
|
Request a task to restart the server. |
|
Request a task to stop the server. |
|
Perform LDAP subentry write operations. |
|
Search using a filter with no corresponding index. |
|
Change LDAP schema definitions. |
Assign individual account privileges
Specify privileges as values of the ds-privilege-name operational attribute:
-
Determine the privileges to add.
Kirsten Vaughan has access to modify user entries. Kirsten lacks privileges to read the server configuration, and reset user passwords:
$ ldapsearch \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" \ --bindPassword bribery \ --baseDN cn=config \ "(objectclass=*)" # The LDAP search request failed: 50 (Insufficient Access Rights) # Additional Information: You do not have sufficient privileges to perform search operations in the Directory Server configuration $ ldappasswordmodify \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" \ --bindPassword bribery \ --authzID "dn:uid=scarter,ou=People,dc=example,dc=com" \ --newPassword chngthspwd The LDAP password modify operation failed: 50 (Insufficient Access Rights) Additional Information: You do not have sufficient privileges to perform password reset operations -
Apply the change as a user with the
privilege-changeprivilege, and give Kirsten access to readcn=config:$ ldapmodify \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword password << EOF dn: uid=kvaughan,ou=People,dc=example,dc=com changetype: modify add: ds-privilege-name ds-privilege-name: config-read ds-privilege-name: password-reset EOF $ dsconfig \ set-access-control-handler-prop \ --hostname localhost \ --port 4444 \ --bindDN uid=admin \ --bindPassword password \ --add "global-aci:(target=\"ldap:///cn=config\")(targetattr=\"*||+\")\ (version 3.0; acl \"Config read for Kirsten Vaughan\"; allow (read,search,compare)\ userdn=\"ldap:///uid=kvaughan,ou=People,dc=example,dc=com\";)" \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --no-promptKirsten can perform the operations now:
Show details
$ ldapsearch \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" \ --bindPassword bribery \ --baseDN cn=config \ "(objectclass=*)" dn: cn=config $ ldappasswordmodify \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" \ --bindPassword bribery \ --authzID "dn:uid=scarter,ou=People,dc=example,dc=com" \ --newPassword chngthspwd The LDAP password modify operation was successful
Assign group privileges
Use a collective attribute subentry to assign privileges to a group:
-
Create an LDAP subentry that specifies the collective attributes:
$ ldapmodify \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword password << EOF dn: cn=Administrator Privileges,dc=example,dc=com objectClass: collectiveAttributeSubentry objectClass: extensibleObject objectClass: subentry objectClass: top cn: Administrator Privileges ds-privilege-name;collective: config-read ds-privilege-name;collective: config-write ds-privilege-name;collective: ldif-export ds-privilege-name;collective: modify-acl ds-privilege-name;collective: password-reset ds-privilege-name;collective: proxied-auth subtreeSpecification: {base "ou=people", specificationFilter "(isMemberOf=cn=Directory Administrators,ou=Groups,dc=example,dc=com)" } EOFFor details, see Collective attributes, and About Subentry Scope.
-
The change takes effect immediately:
Show details
$ ldappasswordmodify \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN "uid=hmiller,ou=people,dc=example,dc=com" \ --bindPassword hillock \ --authzID "dn:uid=scarter,ou=People,dc=example,dc=com" The LDAP password modify operation was successful Generated Password: <password>
Limit inherited privileges
Privileges assigned by collective attributes are inherited by every target account.
To limit effective privileges, override the privilege in the account
by preceding the privilege attribute value with a -.
This examples shows how to prevent Kirsten Vaughan from using the privilege to reset passwords:
-
Check the privilege settings for the account:
$ ldapsearch \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword password \ --baseDN dc=example,dc=com \ "(uid=kvaughan)" \ ds-privilege-name dn: uid=kvaughan,ou=People,dc=example,dc=com ds-privilege-name: config-read ds-privilege-name: password-reset -
Use the override to deny the privilege:
$ ldapmodify \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN uid=admin \ --bindPassword password << EOF dn: uid=kvaughan,ou=people,dc=example,dc=com changetype: modify add: ds-privilege-name ds-privilege-name: -password-reset EOF -
The change takes effect immediately:
Show details
$ ldappasswordmodify \ --hostname localhost \ --port 1636 \ --useSsl \ --usePkcs12TrustStore /path/to/opendj/config/keystore \ --trustStorePassword:file /path/to/opendj/config/keystore.pin \ --bindDN "uid=kvaughan,ou=people,dc=example,dc=com" \ --bindPassword bribery \ --authzID "dn:uid=scarter,ou=People,dc=example,dc=com" The LDAP password modify operation failed: 50 (Insufficient Access Rights) Additional Information: You do not have sufficient privileges to perform password reset operations
Identity management
DS software lets you manage user and administrator accounts individually or in groups. If the deployment calls for provisioning and workflow capabilities, or custom tools, then consider using identity management software, such as ForgeRock Identity Management. For details, see the IDM documentation.
Simple or local deployments might require a GUI for generic or system-specific administrative operations. DS software’s support for standards like LDAP v3 makes it interoperable with many third-party tools.