Establishing the root administrator DN and basic replication replica server DN and passwords

There are several ways that the LDAP root administrator and replica server distinguished names and password values can be configured. One of these ways must be used because an LDAP root administrator DN and password are required for the LDAP server and some other LDAP directory programs to operate:

A root administrator DN must be specified in the global section of the configuration file using the adminDN configuration option (see Configuration file options). The password for this root administrator DN can optionally (this is not suggested) be placed in the configuration file using the adminPW configuration option (see Configuration file options) or can be held in the namespace managed by this instance of the LDAP server.
If a replica is being established for a backend, the masterServerDN or peerServerDN configuration option must be specified in the backend section of the configuration file. The masterServerPW or peerServerPW configuration option can optionally be specified. (This is also not suggested.) All the options described below are applicable for adminDN and the first three options described below are applicable for masterServerDN and peerServerDN.

Note: The LDAP root administrator can delegate server administrator responsibility by defining the administrative group, adding members, and assigning administrative roles. Administrative roles can be defined in LDAP by an LDAP root administrator or in RACF® by a RACF administrator. See Administrative group and roles for more information.

Root administrator DN and password in configuration file
The simplest but least secure method is to select a root administrator DN that is outside of the scope of suffixes managed by this server (see the suffix configuration option, Configuration file options). In other words, choose a root administrator DN such that it does not fall within the portion or portions of the namespace managed by this server. Selection of this type of root administrator DN requires that the password is placed in the configuration file using the adminPW configuration option (see Configuration file options). There is no password policy support for the root administrator DN when the password is defined in the configuration file.

For example, you might choose a simple DN, such as "cn=Admin" for the root administrator DN and a simple password such as secret. The configuration file options might be:
```
adminDN "cn=Admin"
adminPW secret
```
Note: Do not use the example above without changing the password value, and the actual distinguished name.

When a program or user binds using this root administrator DN, the LDAP server verifies that the password supplied on the request matches the value provided in the configuration file for the adminPW option.

Note: When first configuring a TDBM, LDBM, or CDBM backend, it might be necessary to use this approach until the schema supporting the directory entries is loaded. When the schema is loaded and the entry representing the root administrator is added, the adminDN can be changed to the entry DN (see the next list item regarding Root administrator DN and password as a TDBM, LDBM, or CDBM entry). The server must be restarted to pick up the new adminDN.
Root administrator DN and password as a TDBM, LDBM, or CDBM entry
In this method, the root administrator DN is established as an entry managed by a TDBM, LDBM, or CDBM backend. The userPassword attribute is used to hold the password for the root administrator DN in this case. There is LDAP password policy support for the root administrator DN when the entry contains a userPassword attribute value in the LDBM, TDBM, or CDBM backend.

Alternatively, the password or password phrase can be stored in the z/OS® security manager if native authentication is configured. The LDAP password policy support does not apply to the root administrator DN when the password or password phrase exists in the z/OS security manager. The z/OS security manager provides the authentication rules and enforcement of its own password policy. See Native authentication for more information about using native authentication.

For example, if the TDBM or LDBM backend is managing the portion of the namespace "o=Your Company", one root administrator DN that could be selected is "cn=LDAP Admin,o=Your Company".

The configuration file includes the following options:
```
adminDN "cn=LDAP Admin,o=Your Company"
…
database tdbm GLDBTD31/GLDBTD64
…
suffix "o=Your Company"
```
The LDIF-format entry to be added to the database through ldapadd or ldif2ds might be:
```
dn: cn=LDAP Admin,o=Your Company
objectclass: person
cn: LDAP Admin
description: Administrator DN for o=Your Company server
sn: Administrator
uid: admin
userpassword: secret
```
Note: Do not use the example above without changing the password value, and the actual distinguished name.

If this entry is contained in a file system file called admin.ldif, it can be loaded using ldapadd:
```
ldapadd -h ldaphost -p ldapport -D binddn -w passwd -f admin.ldif
```
Note: The ldapadd example above assumes that the LDAP server is running and that the suffix entry (entry with the name "o=Your Company") exists. Furthermore, the binddn is assumed to exist and have sufficient authority to add the entry. When initially setting up the LDAP server, one way to satisfy the assumption is to first configure the LDAP server using the adminDN and adminPW configuration options. Then, start the LDAP server, load the suffix entry and the root administrator DN entry, using the adminDN and adminPW configuration values for binddn and passwd respectively. After the add operations complete, stop the LDAP server, change the adminDN configuration option value to the name of the entry just added and remove the adminPW configuration option. Then restart the LDAP server.

For a TDBM backend, you can use the load utility, ldif2ds, to load the root administrator DN entry.

When a program or user binds using this root administrator DN, the LDAP server verifies that the password supplied on the request matches the value of the userPassword attribute stored in the entry.

CRAM-MD5 and DIGEST-MD5 authentication binds with the adminDN are supported if the entry exists in a TDBM, LDBM, or CDBM backend. The adminDN entry must contain a uid attribute value that is used as the user name by a client application when attempting a CRAM-MD5 or DIGEST-MD5 authentication bind. See CRAM-MD5 and DIGEST-MD5 authentication for more information.
Root administrator DN and password in RACF
This method requires that the LDAP server is configured to use the RACF support provided in the SDBM backend. The root administrator DN can be established as a RACF-style DN based upon a RACF user ID. (See RACF-style distinguished names for more information.) In this case, the password for the root administrator DN is the RACF user IDs password or password phrase, and is stored and verified by RACF. The LDAP password policy support does not apply to the root administrator DN when the password or password phrase is stored in RACF. RACF provides the authentication rules and enforcement of its own password policy.

For example, if you configure the LDAP server with RACF support where the portion of the namespace held by RACF is "sysplex=Sysplex1,o=Your Company", and the RACF user ID that is used for the administrator is g1admin, the configuration file includes these options:
```
adminDN "racfid=g1admin,profiletype=user,sysplex=Sysplex1,o=Your Company"
…
database sdbm GLDBSD31/GLDBSD64
suffix "sysplex=Sysplex1,o=Your Company"
```
When a program or user binds using this root administrator DN, the LDAP server makes a request to RACF to verify that the password supplied on the request matches the RACF password or password phrase for RACF user ID g1admin.

Note the RACF user ID specified must have an OMVS segment defined and an OMVS UID present.
krbLDAPAdmin option in the configuration file
You might want to configure the root administrator to be able to bind to the server through Kerberos. In this case, you must create a Kerberos identity for the user and also add this value to the configuration file. You cannot use the krbLDAPAdmin configuration option to provide a Kerberos identity for the masterServerDN or peerServerDN option. There is no LDAP password policy support for the Kerberos LDAP root administrator because there is not a userPassword attribute value stored in an LDBM, TDBM, or CDBM backend for the Kerberos identity.
For example, if the RACF user ID associated with the LDAP root administrator is LDAPADM and this identity is configured in Kerberos to be ldapadm@realm1.com, then your configuration file contains the following:
```
krbLDAPAdmin ibm-kn=ldapadm@realm1.com
```
This allows the administrator to bind to the server through Kerberos authentication rather than by performing a simple bind.