In the new security architecture, external security can be enabled for ES servers and for the Directory Server (MFDS) through the security configuration panels in the MFDS administration GUI. ESM modules are defined in the ES directory, much like servers, listeners, and other objects. Then one or more modules can be specified in a security configuration. There is a security configuration for MFDS itself, a "default server" configuration that applies to all ES servers that do not have their own security configuration, and an optional configuration for each individual server. This lets you use different security configurations for different servers (eg for test and production systems), and a different configuration for MFDS.
Here we will only configure one ESM module, the MLDAP ESM module which is used with LDAP servers. You may want to configure it only for ES servers, or even for only one server, until you become familiar with how it operates.
When external security is enabled for an ES component, that component will load and initialize the ESF Manager at startup. (MFDS loads ESF Manager shortly after it starts. ES servers load ESF Manager in each SEP as the SEP initializes.) ESF Manager will load and initialize each defined (and enabled) ESM Module. In the case of the MLDAP ESM Module, the module will connect to the LDAP server (here AD or ADAM).
At appropriate points in processing, the ES component will call the ESF Manager to verify a user signon or authorize user access to a resource. ESF Manager will relay these requests to the MLDAP ESM Module, which will perform the appropriate searches of the LDAP repository and process the returned information in order to make its decision.
In the default (and simplest) configuration, the MLDAP ESM Module uses LDAP object types defined by Micro Focus (an LDAP schema), which specify users and resource definitions. So configuring the LDAP repository for ES security requires importing the Micro Focus schema and creating user and resource objects.
LDAP user objects include such information as the user name, a password verifier (which can be a plain-text password or a password hash), and user data such as default group, idle timeout, and expiration date. Resource objects name the resource or resources they apply to and include an access control list (ACL) which details who is allowed what kind of access to the object. Resource objects can use wildcards in their names, as can ACL entries, which makes it possible to easily create generic rules. ACL entries can also apply to individual users or to user groups, for role-based access control.
The rest of this document covers installation and configuration of the LDAP server.