LDAP: Administrative users

Introduction

In an UnboundID LDAP directory server, the “Root DN” (root user) accounts have an extensive set of privileges in the default distribution of the server products; therefore the root DN account(s) should not be used in normal operation except where a task can only be performed by an root user. The number of administrators with root user DNs and passwords should be as small as is practicable.

An “administrative account” or “administrative user” is a distinguished name which has access and privileges beyond those granted to other users. Typically, an administrative user has access to all attributes of all entries on the server, including the administrative sections of the server. Administrative accounts are superior to root DN accounts because they are replicated and because they can be restricted by privilege assignment. For example, an administrative user can be created that has the privilege of “backup”, but no other privileges. The UnboundID product suite uses this extremely flexible access and privilege mechanism instead of a simplistic brute force access control system.

Root user accounts are not replicated whereas administrator accounts created in a replicated backend can be used on each server in a replicated topology. This is a tremendous disadvantage of a Root DN.

LDIF for an Administrative User

User

Following is an example LDIF for an administrative account/user. This example uses the naming context c=us. The DN of this administrative user is cn=admin,c=us. It makes no difference what the DN of the administrative user is, as long as it is hosted in a replicated backend. The password is a horrible one, I trust you’ll use a password generator to generate a better one. The server will encrypt the password or create a cryptographic hash when the entry is added with ldapmodify. How the password is hashed or encrypted is decided by the password policy to which the user is subject.

The administrative user given below has a number of privileges that will prove useful when operating the server. For example, this administrative user has the privilege of reading and writing the configuration of the server – a must when tasked with operating the server. The UnboundID Directory Server supports “privileges” which are required to perform certain tasks and are a adjunct to access controls. Access controls must also exist as a complement to privileges. This is far more flexible model than the brute force model used in other directory servers.

dn: cn=admin,c=us
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: admin
sn: admin
userPassword: password
ds-privilege-name: backend-backup
ds-privilege-name: backend-restore
ds-privilege-name: config-read
ds-privilege-name: config-write
ds-privilege-name: jmx-notify
ds-privilege-name: jmx-read
ds-privilege-name: jmx-write
ds-privilege-name: ldif-export
ds-privilege-name: ldif-import
ds-privilege-name: lockdown-mode
ds-privilege-name: password-reset
ds-privilege-name: privilege-change
ds-privilege-name: soft-delete-read
ds-privilege-name: unindexed-search
ds-privilege-name: update-schema

Group

Next, create the LDIF change records for a group the members of which are administrative users. Grouping users together by type is an effective technique and makes creating access control easier. The DN of the group for administrators is give as cn=Directory Administrators,ou=groups,c=us, of course, this is an arbitrary name.

dn: ou=groups,c=us
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: groups
userPassword: password

dn: cn=Directory Administrators,ou=groups,c=us
changetype: add
objectClass: top
objectClass: groupOfUniqueNames
cn: Directory Administrators
uniqueMember: cn=admin,c=us

Access Controls

Create an LDIF change records containing access controls that are necessary for an administrative user. For the bind rule, use the DN of the group given above. This will cause the access controls created to apply to all members of the group. Only users requiring administrative access should be members of the group because the access controls grant access to all attributes of all entries. The controls listed are:

• 1.2.840.113556.1.4.319: simple paged results request control
• 2.16.840.1.113730.3.4.9: virtual list view request control
• 1.2.840.113556.1.4.473: server-side sort request control

dn: c=us
changetype: modify
add: aci
aci: (targetattr="*||+")
 (version 3.0;
 acl "Access to all attributes by members of the Directory Administrators group.";
 allow(all) groupdn="ldap:///cn=directory administrators,ou=groups,c=us";)
aci: (targetcontrol="1.2.840.113556.1.4.319||2.16.840.1.113730.3.4.9||1.2.840.113556.1.4.473")
 (version 3.0;
 acl "Access to selected controls for cn=admin,c=us";
 allow (read) groupdn="ldap:///cn=directory administrators,ou=groups,c=us";)

Next, the global access controls. These access controls allow administrative users to view entries in operational sections of the server. Use dsconfig to add these global access controls. The operational servers to which access is allowed are:

• config – the configuration of this server
• tasks – tasks that can be added to the server for execution
• monitor – real-time operational data, for example, number of BIND operations performed
• schema – The server schema in which are defined attribute types and object classes recognized by the server
• alerts – administrative alerts generated by the server; these alerts are used by operators to respond to events associated with the operation and status of the server

dsconfig set-access-control-handler-prop \
 --add global-aci:'(target="ldap:///cn=config")(targetattr="*")(version 3.0; acl "Allow access to the config tree by cn=admin,c=us"; allow(all) groupdn="ldap:///cn=directory administrators,ou=groups,c=us";)' \
 --add global-aci:'(target="ldap:///cn=tasks")(targetattr="*")(version 3.0; acl "Allow access to the tasks tree by cn=admin,c=us"; allow(all) groupdn="ldap:///cn=directory administrators,ou=groups,c=us";)' \
 --add global-aci:'(target="ldap:///cn=monitor")(targetattr="*")(version 3.0; acl "Allow access to the monitor tree by cn=admin,c=us"; allow(all) groupdn="ldap:///cn=directory administrators,ou=groups,c=us";)' \
 --add global-aci:'(target="ldap:///cn=schema")(targetattr="*||+")(version 3.0; acl "Allow access to the schema tree by cn=admin,c=us"; allow(all) groupdn="ldap:///cn=directory administrators,ou=groups,c=us";)' \
 --add global-aci:'(target="ldap:///cn=alerts")(targetattr="*")(version 3.0; acl "Allow access to the alerts tree by cn=admin,c=us"; allow(all) groupdn="ldap:///cn=directory administrators,ou=groups,c=us";)'