In PingDirectory server, administrative accounts can be placed in any of three places.
- They can be created as root users. These accounts exist in the
cn=Root DNs,cn=config) and are not synchronized across server instances. If you want to use root accounts across multiple servers, then you must create the account in each server and keep it up to date across all of them. Root user accounts can optionally automatically inherit a default set of privileges, and you can also explicitly grant and revoke privileges as needed.
- They can be created as topology administrators. These accounts also exist
in the configuration (after
cn=Topology Admin Users,cn=topology,cn=config), and these accounts are automatically synchronized between server instances within the same topology. Topology administrators can also automatically inherit a default set of privileges, and you can also explicitly grant or revoke privileges.
- They can be created in the user data. These accounts will be replicated across all directory servers and they can be used to authenticate to PingDirectory and PingDirectoryProxy servers, but they cannot be used to authenticate to PingDataSync or PingDataMetrics servers. They cannot automatically inherit a default set of privileges, but you can explicitly grant privileges to them as needed. Accounts created in the user data can also be unavailable if the backend containing that data is offline, such as when performing an online restore, replica initialization, or LDIF import.
We recommend using topology administrator accounts over root users or accounts created in the user data. Topology administrators have all of the same capabilities as root users, and their accounts are also automatically synchronized across all servers in the topology so there is no need to apply the same change across multiple servers.
# 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"