Using separate administrator accounts

Each administrator should have their own account with their own credentials tailored to the level of access needed.

The setup utility only creates a single root user. Some directory servers from other vendors only support a single root account so all administrators are required to share that account. However, this is a bad practice for several reasons, including:

It’s difficult to audit the actions of individual administrators. With separate accounts for each administrator, it’s easy to see who did what.
Credentials have to be shared across multiple administrators. Shared credentials are at a greater risk of being leaked or compromised. With separate accounts for each administrator, each has its own credentials that are not shared with anyone else.
If the credentials for that single root account are leaked or compromised (or if someone with legitimate access to those credentials leaves their position and no longer needs that access), then those credentials need to be changed. The new credentials need to be communicated to all of the administrators sharing that account, which can be difficult to do securely. If the new credentials are not communicated in advance of the change, then administrators who have not received them won’t be able to manage the server. If the new credentials are communicated in advance of the change, then the old, potentially compromised credentials remain in effect for longer than necessary.
Using a single root account makes it more difficult to use strong authentication, such as a certificate or two-factor authentication, in a secure manner. With separate accounts for each administrator, it’s easier to use strong authentication in a secure manner.
If there is only a single root account, then that account must have a level of access that permits everything that any administrator might need to do, even if all administrators don’t need the same level of access. With separate accounts for each administrator, each can be given precisely the level of access that they need.

It might also be beneficial to remove or disable the account for the initial root user created by setup once all of the administrators have their own accounts.

Using separate accounts is mentioned in the following config/sample-dsconfig-batch-files/create-topology-admin-user.dsconfig batch file, which provides an example for creating a topology admin user with various restrictions.

# Although setup automatically creates an initial root user account that can
# be used to manage the server, we strongly recommend creating a separate
# account for each administrator rather than using a single shared account.
# This offers several benefits, including:
#
# * It is easier to determine which administrator performed a given action.
# * There is no need to share credentials or coordinate password changes.
# * It is easier to use strong authentication options like certificates or
#   two-factor mechanisms.
# * You can customize the level of access that each administrator has.
#
# We also recommend creating topology admin user accounts rather than root
# user accounts.  If you create a root user account, then it is only created
# in that one instance.  If you create a topology admin user, then that
# account will be available in all instances in the topology.
#
# Because administrative accounts are very powerful, they are high-priority
# targets for attackers to try to compromise.  They should be required to have
# strong credentials, and you may wish to require that they use strong
# authentication mechanisms (see other dsconfig batch files for configuring
# password validators and other password policy features).  You may also want
# to give them usernames that are not likely to be guessed by an attacker,
# even if they know information about the individuals administering the
# service.  For example, you may not want to use their name in the DN or
# username, choosing instead something that is less predictable or even
# completely random like a UUID.
#
# Once each administrator has their own account, we recommend that you disable
# or remove the initial root user created during setup.  See the
# disable-or-remove-the-initial-root-user.dsconfig batch file for more
# information about that.

#
# NOTE:  Do not edit this file directly.  Changing this file could prevent it
# from being updated during a server upgrade.  If you want to alter the
# dsconfig commands below before applying the configuration changes, copy this
# file to another directory and edit that copy.
#

# Create a new topology administrator account.  In this example, the user will
# be able to read the configuration but will not be allowed to update it, and
# will be given the bypass-read-acl privilege rather than bypass-acl, which
# only ensures they will be able to read entries but they will not be
# permitted to update them unless permitted by the server's access control
# configuration.  They will also only be permitted to communicate with the
# server over a secure connection, and they will only be permitted to
# authenticate with the EXTERNAL or UNBOUNDID-TOTP mechanisms.
dsconfig create-topology-admin-user \
     --user-name "[USER_NAME]" \
     --set "password:[PASSWORD]" \
     --set "first-name:[FIRST_NAME]" \
     --set "last-name:[LAST_NAME]" \
     --set "user-id:[USER_NAME]" \
     --set inherit-default-root-privileges:true \
     --set privilege:bypass-read-acl \
     --set privilege:-bypass-acl \
     --set privilege:-config-write \
     --set search-result-entry-limit:0 \
     --set time-limit-seconds:0 \
     --set look-through-entry-limit:0 \
     --set idle-time-limit-seconds:0 \
     --set require-secure-authentication:true \
     --set require-secure-connections:true \
     --set "allowed-authentication-type:SASL EXTERNAL" \
     --set "allowed-authentication-type:SASL UNBOUNDID-TOTP"

PingDirectory

Using separate administrator accounts