Creating Non-Admin Users for AM in DS

jelle.verbraak · January 20, 2021, 5:00am

Introduction

In this article, I explain the best practice for creating non-admin users for DS, and why this is so important to do. These users can be used by such software applications as AM and IDM.

Note that I use AM 6.5.2.3 and DS 6.5.3 are used in this approach.

Why using an admin user for your applications is a bad idea

The default admin user cn=Directory Manager is like the Linux root user. You only want to connect with this user if you need to do admin tasks. It is a best practice to use a non-admin user to connect from your application to your DS instance.

A second reason that you don’t want to use the cn=Directory Manager is that out of the box, it uses the PBKDF2 password storage scheme. Bcrypt, Blowfish, or PBKDF2 password encryption use extensive amounts of CPU /memory resources, and will cause a decrease in performance. The password storage scheme a non-admin user will use is generally SHA-512.

Some companies have strict security policies in place, and even require a stronger level of password storage like PBKDF2. It is important to keep in mind that using a stronger password scheme will have a negative impact on performance.

What is the best practice to implement non-admin users?

Well, it depends.

If you start from scratch, implementing non-admin users is easy. DS supports the usage of setup profiles from version 6.5.

If you are planning an upgrade or running an older version of DS, you will need to create the non-admin user manually.

Installing DS from scratch using setup profiles

A setup profile refers to the outline form of a directory server configuration for a specific use case. Profiles greatly simplify the directory server setup process for such use cases, such as preparing a directory server to serve another ForgeRock Identity Platform component product. Every profile has it own parameters, and creates its own non-admin user that can be used by products like AM, IDM,…

Instructions for configuring those profiles are explained here: Directory Services 6.5 > Installation Guide.

Creating non-admin users in DS manually

In this example, we will create a non-admin for the DS configuration store for AM.

Create the new non-admin user (configuration store)

First of all, we need to create a new user in DS. In this example, we use ou=am-config as base DN, and ou=admins to store the non-admins (as this is used by the setup profiles).

To use this user in AM 6.5, we need to set the privileges for the configuration store. Privileges control the administrative tasks that users can perform, such as bypassing the access control mechanism, performing backup and restore operations, making changes to the configuration, and other tasks. By default, privileges restrict administrative access to directory root users, though any user can be assigned a privilege.

The following ds-privileges are needed for the configuration store:

subentry-write: Perform LDAP subentry write operations.
update-schema: Change LDAP schema definitions.

An example of an ldif file can be found below:

dn: ou=admins,ou=am-config
objectclass: top
objectclass: organizationalUnit
ou: adminsdn: uid=config-user,ou=admins,ou=am-config
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: AM Configuration Admin
sn: AM
uid: config-user
userPassword: SomeStrongPassword
ds-privilege-name: subentry-write
ds-privilege-name: update-schema

If you already have the ou=admins, remove the following part out of the ldif file:

dn: ou=admins,ou=am-config
objectclass: top
objectclass: organizationalUnit
ou: admins

Next, import the ldif file into the configuration store:

./ldapmodify --port 1389 --bindDN "cn=Directory Manager" --bindPassword changeit non-admin.ldif

Creating new acis for non-admin users (configuration store)

Access control instructions (acis) apply to directory data, providing fine-grained control over what a user or group member is authorized to do in terms of LDAP operations. Most access acis specify scopes (targets) to which they apply, such that an administrative user who has all access to ou=x,ou=am-config need not have any access to ou=y,ou=am-config.

The following acis are needed for the configuration store:

aci: (targetattr=”*||+”)(version 3.0;acl “Allow CRUDQ operations”;
allow (search, read, write, add, delete)
(userdn = “ldap:///uid=config-user,ou=admins,ou=am-config”);)
aci: (targetcontrol=”2.16.840.1.113730.3.4.3||1.2.840.113556.1.4.473")(version 3.0;
acl “Allow persistent search and server-side sorting controls”; allow (read)
(userdn = “ldap:///uid=config-user,ou=admins,ou=am-config”);)

An example of an ldif file to set the acis can be found below:

dn: ou=am-config
changetype: modify
add: aci
aci: (targetattr="*||+")(version 3.0;acl "Allow CRUDQ operations";
 allow (search, read, write, add, delete)
 (userdn = "ldap:///uid=config-user,ou=admins,ou=am-config");)
aci: (targetcontrol="2.16.840.1.113730.3.4.3||1.2.840.113556.1.4.473")(version 3.0;
 acl "Allow persistent search and server-side sorting controls"; allow (read)
 (userdn = "ldap:///uid=config-user,ou=admins,ou=am-config");)

You can download the full ldif file here: Non-Admin-Templates-DS/non-admin-configstore.ldif at master · jellev/Non-Admin-Templates-DS · GitHub.

Next, import the ldif file into the configuration store:

./ldapmodify --port 1389 --bindDN "cn=Directory Manager" --bindPassword changeit acis.ldif

Creating a global aci to allow schema modifications

When installing or upgrading AM, it is possible that AM requires changes to the schema in DS. For this reason, we will allow the non-admin user to modify the schema in DS:

./dsconfig set-access-control-handler-prop — hostname localhost — port 4444 — bindDN “cn=Directory Manager” — bindPassword changeit — no-prompt — trustAll — add ‘global-aci:(target = “ldap:///cn=schema”)(targetattr = “attributeTypes || objectClasses”)(version 3.0; acl “Modify schema”; allow (write) userdn = “ldap:///uid=config-user,ou=admins,ou=am-config”;)’

Example for creating a non-admin user for the identity store

The identity store needs other privileges and acis as the configuration store. In this example, we use ou=identities as base dn and ou=admins to store the non-admins (as this is used by the setup profiles).

For example, you will get something like this:

dn: ou=identities
changetype: modify
add: aci
aci: (targetattr="* || aci")(version 3.0;acl "Allow identity modification";
 allow (write)(userdn = "ldap:///uid=am-user,ou=admins,ou=identities");)
aci: (targetattr!="userPassword||authPassword")(version 3.0;
 acl "Allow identity search"; allow (search, read)
 (userdn = "ldap:///uid=am-user,ou=admins,ou=identities");)
aci: (targetattr="+")(version 3.0;
 acl "Allow identity search operational attributes"; allow (search, read)
 (userdn = "ldap:///uid=am-user,ou=admins,ou=identities");)
aci: (version 3.0;acl "Add, delete, proxy identities"; allow (add, delete, proxy)
 (userdn = "ldap:///uid=am-user,ou=admins,ou=identities");)
aci: (targetcontrol="2.16.840.1.113730.3.4.3||1.3.6.1.4.1.42.2.27.8.5.1||2.16.840.1.113730.3.4.18")
 (version 3.0;acl "Allow persistent search, password policy and proxied authz controls"; allow (read)
 (userdn = "ldap:///uid=am-user,ou=admins,ou=identities");)dn: ou=admins,ou=identities
objectClass: top
objectClass: organizationalunit
ou: adminsdn: uid=am-user,ou=admins,ou=identities
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: am-user
sn: am-user
uid: am-user
userPassword: SomeStrongPassword
ds-privilege-name: password-reset
ds-privilege-name: proxied-auth
ds-privilege-name: modify-acl

You can download the full ldif file here: Non-Admin-Templates-DS/non-admin-identitystore.ldif at master · jellev/Non-Admin-Templates-DS · GitHub.

Example for creating a non-admin user for the CTS store

The CTS store needs other privileges and acis as the configuration store. In this example, we use ou=tokens as base dn and ou=admins to store the non-admins (as this is used by the setup profiles).