Renaming ACEEs

The External Security Facility (ESF) can be configured to permit changing userids of users who are already signed on to an Enterprise Server component (for example, enterprise server, MFDS, ESCWA, and so forth). When enabled, the userid or "short name" of one or more ACEE objects, which identify signed-on users, can be updated as part of processing an ESF Update request. The effect of the ESF Update is that the Enterprise Server identity of a user might be altered within a running enterprise server region, without having to restart it.

This feature, known as ACEE rename, requires the following ESF features:

Name Mapping: ACEE rename changes the "short name" (ES userid) associated with a "long name" (external username). If name mapping is not being used, this is not meaningful.
LDAP-based security: ACEE rename is implemented as part of the ESF Update processing performed by the MLDAP ESM Module. At least one Security Manager using the MLDAP ESM Module must be configured and enabled for the enterprise server region or other component to process ACEE renames.
Note: The name mapping does not need to be implemented using LDAP - it can be provided by any Security Manager.

ACEE rename is a change in behavior and is potentially expensive, since it must scan and modify the ACEEs in the system, which requires locking and will potentially block other processes. Consequently it is not enabled by default. Enable it using the rename active users setting in the [Update] section of the Configuration Information field for an LDAP-based Security Manager. See The MLDAP ESM Module for more information.

ACEE rename workflow

An enterprise server region with suitable security configuration is running. Various users have signed on to the region, creating ACEEs.
An administrator changes the security data in the External Security Manager (ESM) used for name mapping, so that one or more users now have "short names" that are different from the ones they had when they signed on to the enterprise server region. You want the enterprise server region to recognize these changes.
You must submit an ESF Update request with the appropriate parameters, as specified below.
The enterprise server instance identifies the affected ACEEs and changes the short names in them to reflect their new values.

ESF update and ACEE renaming

There are different types of ESF Update requests. See Implementing Security Manager Changes for more information.

When ACEE renaming is enabled, you can use the following types of ESF Update requests to process ACEE renames:

An Update User request will check for and process an ACEE rename for the specified user. For example, esfupdate ... user USERA will check for an ACEE rename for ACEEs that currently use the short name "USERA".
Note: The old short name should be specified with such a request. See the note regarding user updates, short names, and long names below.
An Update Users or Update All request will check all ACEEs for renames, and process any that it finds.
CAUTION:

As with any Update Users or Update All operation, this is significantly more expensive than a single-user Update request, and might pause processes in the Enterprise Server for a significant span of time, depending on how many ACEEs exist in the system.

Effects of ACEE renaming

Renaming an ACEE changes the ES userid of the ACEE. This is how the user is known to Enterprise Server.

Changing the userid will affect any security or permission settings which depend on the userid. It will not normally affect group-based permissions assigned using the MLDAP ESM Module, as those are based on the user's "long name" (when using Micro Focus user groups) or Windows groups (when using Active Directory groups). Group-based permissions might be altered by other changes to the security data and incorporated by Update processing.

Old short name, new short name, and long name in update requests

Prior to the introduction of this feature, an ESF Update User request needed to be made using the user's short name (ES userid) to be effective.

With this feature, when a user's short name has been changed in the ESM which is performing name mapping, the old userid should be used in an ESF Update User request to process the rename. If an Update Users or Update All request is used instead, no user name is specified, so this issue does not arise.

Remember: That Users and All updates can significantly impact performance.

In addition, with this feature, if the MLDAP ESM Module does not find any ACEEs for the user named in an Update User request, it will search the ACEEs again looking for ones with a long name that matches the supplied name. That means it is now possible to do an Update User request using a user's long name.

Restrictions on ACEE renaming

ACEEs must be unique by primary key, which is formed from the short name and sign-on group. When all-groups mode is enabled, the sign-on group is always "*ALL", so in this case ACEEs must be unique by short name.

That means an ACEE cannot be renamed if the new name would cause it to match an existing ACEE. In this case, an error message is logged to the enterprise server region console and the rename operation fails.

Renaming an ACEE, and ESF Update in general, does not change the ACEE's sign-on group. If all-groups mode is not enabled, removing a user from a group they have used as a sign-on group will not alter any existing ACEEs for that user. That means a user can retain the permissions of that group until the enterprise server region has been restarted.