Standalone LDAP registry wizard settings
Use this security wizard page to provide the basic settings to connect the appserver to an existing LDAP registry.
To view this security wizard page, click...
Security | Global security | Security configuration wizard
We can modify the LDAP registry configuration by completing the following steps:
- Click...
Security | Global security
- Under User account repository, click the Available realm definitions drop-down list, select Standalone LDAP registry, and click Configure.
- Primary administrative user name
Name of a user with admin privileges that is defined in the custom user registry.
The user name is used to log onto the admin console when administrative security is enabled. V6.1 requires an administrative user that is distinct from the server user identity so that administrative actions can be audited.
In WAS, Vs 5.x and 6.0.x, a single user identity is required for both admin access and internal process communication. When migrating to V6.1, this identity is used as the server user identity. specify another user for the administrative user identity.
- Type of LDAP server
Type of LDAP server to which you connect.
IBM SecureWay Directory Server is not supported.
- Host
Specifies the host ID (IP address or DNS name) of the LDAP server.
- Port
Specifies the host port of the LDAP server.
If multiple appservers are installed and configured to run in the same single sign-on domain or if the appserver interoperates with a previous version, it is important that the port number match all configurations. For example, if the LDAP port is explicitly specified as 389 in a V4.0.x configuration, and a WAS at V5 is going to interoperate with the V 4.0.x server, verify that port 389 is specified explicitly for the V5 server.
Default: 389 Type: Integer
- Base distinguished name (DN)
Base distinguished name (DN) of the directory service, which indicates the starting point for LDAP searches of the directory service. In most cases, bind DN and bind password are needed. However, when anonymous bind can satisfy all of the required functions, bind DN and bind password are not needed.
For example, for a user with a DN of...
cn=John Doe,ou=Rochester,o=IBM,c=US
...specify the Base DN as any of the following options:
- ou=Rochester, o=IBM, c=US
- o=IBM, c=US
- c=US
For authorization purposes, this field is case sensitive. This specification implies that if a token is received, for example, from another cell or Lotus Domino, the base DN in the server must match the base DN from the other cell or Lotus Domino server exactly.
to interoperate between the appserver V5 and a V 5.0.1 or later server, enter a normalized base DN. A normalized base DN does not contain spaces before or after commas and equal symbols. An example of a non-normalized base DN is o = ibm, c = us or o=ibm, c=us. An example of a normalized base DN is o=ibm,c=us. In WAS, V5.0.1 or later, the normalization occurs automatically during run time.
- Bind distinguished name (DN)
Specifies the DN for the application server to use when binding to the directory service.
If no name is specified, the appserver binds anonymously. See the Base distinguished name (DN) field description for examples of distinguished names.
- Bind password
for the appserver to use when binding to the directory service.
Related tasks
Use specific directory servers as the LDAP server
Set LDAP user registries
Standalone LDAP registry settings