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: password42ldapmodify -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.
Ludo Sketches 
Can you restrict where these admins can bind from? We wanted to restrict Directory Manager from binding to our Sun DS5.2 instance from anywhere other than our server networks – Sun said it wasn’t possible.
ACIs didn’t work as Directory manager bypasses them. They suggested Sun directory proxy might help – but that seemed rather overkill!
We have thousands of students who need access to the ldap instance, but would never need to bind as admin so blocking it seemed like an obvious (but unachievable) solution.
Possible with OpenDJ?
Hi,
OpenDJ doesn’t have, for now, rules enforced during the authentication phase other than those of the Password Policy (locked account, password expiration…).
As a result, it is not possible to block authentication based on the IP addresses.
ACIs are only applicable after the authentication has been performed. With OpenDJ, the “Directory Manager” has the “bypass-acl” privilege which mean that access controls based on IP addresses cannot be used either. However, when defining new administrative accounts, it is possible to remove them the “bypass-acl” privilege and thus to enforce IP based rules in access controls. You could as well remove that “bypass-acl” privilege from the “Directory Manager” but need to make sure ACIs are properly set so that the account is still able to administer the server.
Ludo
How are you ?
How does opendj compares with unboundid [features/performance] ?
Regards