In a previous post, I’ve explained how to create multiple administrative accounts in the OpenDJ directory service. Today we’re going to look at restricting what applications can do with these administrative accounts.

In the OpenDJ directory service, there are 2 types of authorization systems :

• Privileges control who can perform which administrative tasks : backup, restore, stop and restart of the server, managing acl…
• Access Controls Lists govern the access to the data through LDAP operations.

Most operations involving sensitive or administrative data require that the user has both the privilege and authorization. This allows finer-grain authorization for specific data related action such as managing acl or reseting passwords.

The Privilege SubSystem

Privileges are assigned to users and apply globally to the directory service. Any user can be granted or denied any privilege and by default only the RootDN users are assigned a default set of privileges.

That set of privileges assigned to RootDN users is defined by the “default-root-privilege-name” property, which can be listed or modified using the dsconfig command.

To list the current default privileges assigned to all RootDN users :

bin/dsconfig -h localhost -p 4444 -X -D “cn=directory manager” -j /var/tmp/dmpassfile -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-lockdown,
                            : server-restart, server-shutdown, subentry-write,
                            : unindexed-search, update-schema

To make sure that all searches are done with proper indexes, you may want to remove the privilege to all Administrative Accounts to perform unindexed searches :

bin/dsconfig -h localhost -p 4444 -X -D “cn=directory manager” -j /var/tmp/dmpassfile -n set-root-dn-prop –remove default-root-privilege-name:unindexed-search

Note: Removing this privilege to all Administrative accounts including the default “cn=Directory Manager” may have side effects for certain internal operations such as group membership, referential integrity…

Whenever adding a new Administrative Account under the “cn=Root DNs,cn=config” container, it automatically inherits from those privileges. But each administrative account can then be denied or added specific privileges by adding values of the “ds-privilege-name” attribute directly in the user entry, in the form of the privilege name or a Minus sign followed by the privilege name.

For example, I can make sure that my newly added Administrative Account is subject to access controls and cannot modify access controls lists, I modify the entry as followed :

Create a temporary file modAdminPrivileges.ldif with the following LDIF modification statement:

dn: cn=Second Admin,cn=Root DNs,cn=config
changetype: modify
add: ds-privilege-name
ds-privilege-name: -bypass-acl
ds-privilege-name: -modify-acl
–

And then apply it to the directory service with the following command :

bin/ldapmodify -h localhost -p 4444 -X -Z -D “cn=directory manager” -j /var/tmp/dmpassfile -f modAdminPrivileges.ldif

Using similar commands and different privileges, one could completely separate the administrative tasks and restrict each Administrative Account to its specific tasks.

But the great thing about privileges is that they can also be granted to regular users part of the Directory Information Tree, allowing them to become administrators for very specific tasks.

The complete list of privileges supported in OpenDJ 2.4 is below:

• backend-restore: Ability to perform backend restore operations.
• bypass-acl: Ability to bypass access control evaluation.
• bypass-lockdown:Ability to bypass server lockdown mode.
• cancel-request: Ability to cancel arbitrary client requests.
• config-read: Ability to read the server configuration.
• config-write: Ability to update the server configuration.
• data-sync: Ability to participate in a data synchronization environment.
• disconnect-client: Ability to terminate arbitrary client connections.
• jmx-notify: Ability to subscribe to JMX notifications.
• jmx-read: Ability to perform read operations via JMX.
• jmx-write: Ability to perform write operations via JMX.
• ldif-export: Ability to perform LDIF export operations.
• ldif-import: Ability to perform LDIF import operations.
• modify-acl: Ability to modify access control rules.
• password-reset: Ability to reset user passwords.
• privilege-change: Ability to change the set of privileges for a user, or to change the set of privileges automatically assigned to a root user.
• proxied-auth: Ability to perform proxied authorization or request an alternate authorization identity.
• server-lockdown: Ability to lockdown a server.
• server-restart: Ability to request a server restart.
• server-shutdown: Ability to request a server shutdown.
• subentry-write: Ability to perform write operations on LDAP subentries.
• unindexed-search: Ability to perform an unindexed search
• update-schema: Ability to update the server schema.

Most of LDAP directory servers configure a single well known directory administrative account (cn=Directory Manager [,dc=example,dc=com]) which has full access to everything. While there is a need to have one special user to bootstrap the server, we are too often seeing that special account being used by all applications that have specific administrative needs : the provisioning application, the email management application, …

OpenDJ has different mechanisms to define multiple administrative accounts, but today, I’m going to focus on the “Root DNs” i.e. defining multiple Directory Managers.

The default administrative account is “cn=Directory Manager”, and is stored in the configuration under the “cn=Root DNs,cn=config” container entry.

Adding another administrative account is as simple as adding another entry under that container, with one specific objectClass : ds-cfg-root-dn-user.

Create a file newAdmin.ldif

dn: cn=Second Admin,cn=Root DNs,cn=config
cn: Second Admin
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: ds-cfg-root-dn-user
sn: Second Admin
ds-cfg-alternate-bind-dn: cn=Admin2,dc=example,dc=com
ds-pwp-password-policy-dn: cn=Root Password Policy,cn=Password Policies,cn=config
userPassword: password42

ldapmodify -a -D cn=Directory Manager -j /var/tmp/dmpassfile -f  newAdmin.ldif

Processing ADD request for cn=Second Admin,cn=Root DNs,cn=config
ADD operation successful for DN cn=Second Admin,cn=Root DNs,cn=config

If you prefer, you can choose not to set the password in the LDIF file, but set it in a secure way afterwards :

$ bin/ldappasswordmodify -p 1389 -D “cn=directory manager” -j /var/tmp/dmpassfile -a “”cn=Admin2,dc=example,dc=com” -N /var/tmp/newpw
The LDAP password modify operation was successful

Where /var/tmp/dmpassfile contains the password for “cn=directory manager” and /var/tmp/newpw the new password for Admin2.

Did you notice the “ds-cfg-alternate-bind-dn” attribute in the definition of the new administrative account ? This enables to authenticate to the directory server with the DN value specified in this attribute, while the entry still has a DN and is located under the “cn=config” suffix.

So now, don’t hesitate to create different administrative accounts for the various applications that need special access to the directory.

In a follow-up post, I will explain how to restrict what those administrative accounts can do in the OpenDJ directory service.