Security Managers and security configurations

Enabling the External Security Feature (ESF) for an Enterprise Server component, such as the Micro Focus Directory Server (MFDS), the Enterprise Server Common Web Administration (ESCWA) server, or an enterprise server instance (or "region"), involves specifying a security configuration. These various contexts in which a security configuration can be specified — enterprise server instance, MFDS, and ESCWA — are sometimes referred to as security domains.

In ESCWA, the security configuration for an enterprise server instance is specified on the Region Security Facility Configuration page or on the Default ES Configuration page, depending on whether it uses the default configuration. For configuring MFDS security in ESCWA there is a Directory Server Configuration page under the Security menu for the MFDS instance. ESCWA security itself is configured using the Security Settings page available via the spanner icon () on the menu bar.

Each security configuration includes a list of Security Managers. A Security Manager defines an External Security Manager (ESM) to ESF. It includes the name of an ESM Module which provides the interface to the ESM, and typically connection information and processing options. In ESCWA, Security Managers are specified on the Security Managers page for an MFDS instance. Any number of Security Managers can be specified. When a security configuration lists multiple Security Managers, they are usually invoked in the order listed to process each security query (though some options affect which managers are used).

64/32-bit Security Managers

It is necessary to have the correct bitism for the security domain that is going to use the Security Manager. If the enterprise server region is a 64-bit region, it will require a 64-bit security manager. Similarly, the security manager used for MFDS must have the same bitism as MFDS.

If MFDS and the enterprise server region have different bitisms, they might not be able to use the same Security Manager. They can use the same external security manager (for example, LDAP repository) but two separate Security Manager definitions might be required. These would use essentially the same configuration details but any bitness-specific configuration items would differ.

For example, the MLDAP ESM Module has an optional provider configuration setting to specify an LDAP client library; this would need to name a library of the correct bitness. The details will depend on the platform and installation decisions made by the system administrator, but it might look like the following.

In the Security Manager, for 32-bit enterprise server regions and for MFDS (which is normally 32-bit, except on 64-bit-only platforms):

[LDAP]
provider=/usr/lib/libldap_r-2.4.so.2.7.1

In the Security Manager for 64-bit regions:

[LDAP]
provider=/usr/lib64/libldap_r-2.4.so.2.7.1

The difference in this case is in the location of the shared object, /usr/lib versus /usr/lib64.

Note: In recent Enterprise Server releases, the MLDAP ESM Module often does not need the provider setting, as it has improved logic for finding the commonly-used LDAP libraries in their normal installation locations.

The ESM Module must be the correct bitness for the Security Manager. If one of the standard ESM Modules provided with Enterprise Server is used, and it is specified in the Security Manager definition using just its base name (for example, mldap_esm) with no path or extension, then ESF will automatically select the module of the correct bitness. If the Security Manager specifies a path or extension for the module, only that specific file will be used, and you will need separate 32- and 64-bit Security Manager definitions.

Security Manager configuration

Hardening recommendations for Security Managers depend on the ESM Module used. See the following subtopics listed below for each standard ESM Module.

Security Configuration options

Each of the Security Configuration pages — Default ES Security, Security for a specific region, Directory Server Configuration, and the ESCWA Security Settings — provide options to configure ESF. The MFDS Directory Server Configuration and ESCWA Security Settings pages also have some options specific to those components.

ESF options relevant to hardening include:

Allow unknown users

This option should typically only be enabled for certain test situations. It allows anyone to sign on to the system using an unrecognized user ID and any password.

Allow unknown resources

Avoid this option where security is a concern; it permits the use of any unrecognized resource, which might, for example, let an attacker access system files through Enterprise Server applications. It is useful primarily for developers using their own test installations and while phasing in the initial set of security rules.

Verify against all Security Managers

Typically, user authentication (the Verify operation) is decided by the first Security Manager which returns a definite result — either allow or deny sign-on. When this option is enabled, all Security Managers are consulted until either one returns a deny result, or they have all returned allow or unknown (and at least one returned allow, unless "Allow unknown users" is also enabled). In effect, this option lets each Security Manager veto user authentication. It may be appropriate in some security configurations, particularly if a Security Manager has been configured specifically to reject certain users under certain circumstances, such as time of day.

Create audit events

Auditing can improve security by providing an audit trail for forensic analysis if a breach is discovered or suspected. Audit information can also be processed in real time or periodically to check for suspicious activity, or to monitor particularly sensitive resources. Note that enabling this option requires configuring the Micro Focus Audit API, and using a Security Information Event Manager (SIEM) such as syslogd or the Micro Focus Sentinel or ArcSight product to receive and process audit data.

Use all groups

While neither setting of this option is necessarily more secure, some organizations choose to disable it so they can give users particular roles based on their choice of sign-on group. For example, a user might have both an "application" role and an "administration" role, with different resource permissions in each, selected by which group is specified when signing on. Other organizations prefer to enable this option so the system behaves more like Windows or UNIX.

Cache TTL and limit

These options disable ESF caching (if either is set to zero) or enable it (if they are both non-zero). Depending on the organization's threat model and security posture, there may be a security benefit to disabling caching, to prevent ESF from using stale results when changes are made to the security information held by ESMs. For most organizations, some caching is desirable for improved performance. The organization should determine its tolerance for stale security results and set the Cache TTL appropriately. A setting of 60, for example, means no result more than a minute old will be returned by the cache. Also, the ESF Update mechanism can be used to flush the cache.

Configuration text: Group federation

The group federation mechanism can be enabled in the configuration text field using the following setting:

[Operation]
Federate=yes

Note: Section names and keywords are case-insensitive.

Group federation only applies if there are multiple Security Managers being used.

When group federation is enabled, all security managers for the security domain (enterprise server region, MFDS, or ESCWA) share a single list of user groups. Each security manager may add groups to the list, access control rules in one security manager may refer to groups defined in other security managers, and so on. When federation is explicitly disabled with Federate=no, each security manager has its own group list and understanding of which users belong to which groups. If no federation setting is specified, the security managers operate in backward-compatibility mode, which has semantics that are complicated and probably undesirable.

Micro Focus recommends enabling group federation unless the organization has a specific reason for requiring each Security Manager to keep separate group information.

Configuration text: Redundant mode

Redundant mode is an option for customers who are concerned about availability and can put all of their security information in a single security manager. In redundant mode, the security managers are not treated as separate sources for making security decisions. Instead, only the first security manager is used, unless it fails; then the second is used, and so on. So for redundant mode, all security managers must be equivalent in how they make security decisions, for consistency. Redundant mode also requires group federation.

Settings that apply to redundant mode are as follows:

[Operation]
redundant=yes
failover retry interval=time

The failover retry interval setting determines whether failed ESMs will be retried, and if so, how often. An appropriate value for this setting depends on the customer's requirements. See your product Help for more information.

Configuration text: Verify throttling

Verify throttling helps prevent brute-forcing user credentials by slowing down processing when too many Verify (authentication) requests are received by a process in a certain time interval. By default, this is triggered if more than 100 Verify requests are received in a second. The threshold can be changed, or throttling disabled entirely, using the [Operation] verify throttle threshhold setting. Micro Focus recommends leaving throttling enabled, although you might need to adjust the threshold if your workload triggers it.

Configuration text: ESF cache options

In addition to the cache size and TTL parameters discussed above, some additional cache options can be set in the configuration text:

[Cache]
requests=types of requests to cache
flush on change=yes|no
report interval=time in seconds
ignore=request fields to ignore in comparison

These are discussed in more detail in your product Help, but briefly:

requests sets which types of ESF requests can be cached. By default, authorization requests are cached, but authentication requests are not, so that each user authentication is processed by the ESMs.
If flush on change is enabled, then when the result of a request changes, any existing cached information for that request is removed. This is useful if authentication (Verify) caching is enabled and an ESM implements account lockout. See your product Help for more information.
The list of request fields in the ignore setting are ignored when comparing an incoming request with entries in the cache. This can improve cache performance if the fields in question are not considered security-sensitive by the customer. By default, the subsystem and facility fields are ignored.

Micro Focus recommends using the defaults caching options for maximum security, and changing them for performance if necessary. If Verify caching is enabled, Micro Focus recommends enabling flush-on-change.

Configuration text: Audit options

Options for auditing only apply if auditing is enabled. The audit options are:

password change success: This controls whether an audit event is generated for a successful password change.
category 3 events: This controls whether audit events are generated for calls to ESF, as well as the results of those calls. The category-3 events are largely redundant, so some customers prefer to suppress them.
selective: This enables selective auditing. In selective mode, audit events are controlled by additional LDAP attributes of users, groups, and resource access rules. Only the MLDAP ESM Module provides selective-audit capabilities. Selective auditing is useful if you only want audit events generated for ESF requests that apply to certain sensitive security objects. Using this requires additional administrative effort, to set the attributes appropriately for objects of interest.

Micro Focus has no specific recommendations regarding these options. Whether they are appropriate will depend on your requirements.

Configuration text: miscellaneous options

Other configuration text settings affect:

The ESF user exit (user exit)
The ESF Administration feature (allow-list)
Username mapping (map short names)
Update processing (update interval)
Trimming whitespace from character fields in requests (trim whitespace)
Passtokens (allow)

See your product Help for more information.