A password change is attempted when a normal ESF Verify request includes a new password. A "normal" request is one for a normal sign-on operation which includes the existing password (not a no-password Verify).
If the user is successfully authenticated, the MLDAP ESM Module can proceed with attempting the password change. If there are multiple security managers in the security configuration, a password change will only be attempted if no security manager has already successfully changed the user's password for this request.
Additional configuration of the MLDAP ESM Module, security manager, or LDAP server might be required to permit password changes. Changing passwords is not a primary LDAP function so it is not always possible to do it using LDAP. When a password change fails, only limited diagnostic information is available, and an LDAP or system administrator might have to consult other sources to diagnose the information.
Password changes in the MLDAP ESM Module all involve the LDAP "modify" operation, but the specific attributes being modified and their content depends on the password type. See Understanding passwords with LDAP-based security for more information.
The password types which use "internal verifiers", such as MF-A2, are changed by modifying the value of the attribute microfocus-MFDS-User-Pwd (or a different attribute specified in the security manager configuration) in the LDAP object that represents the target user.
The new value of the attribute will be a cryptographic hash which can be used to verify the new password in future sign-on attempts.
The MLDAP ESM Module will only attempt to change the value of this attribute after successfully authenticating the user's credentials, including applying all sign-on constraints (such as account lockout), and checking the new password against whatever password constraints might be configured.
The following is a special case: When a new password is specified, the sign-on constraints "password expired" (controlled by the microfocus-MFDS-User-Pwd-ExpirationDate attribute) and "password must be changed" (the microfocus-MFDS-User-Pwd-MustChange attribute) are ignored. The presence of a new password indicates the user is addressing these restrictions.
In order for the LDAP modify to succeed, the account configured for the LDAP connection in the security manager definition (specified in the "Authorized User" field) must have write access to the attribute.
The other password types, such as AD and SSHA512, refer to password verifiers which are managed by the LDAP server, or some other authentication system that the LDAP server is associated with. Changing these passwords involves making an LDAP modify request, but in many cases that request is intercepted by the LDAP server for special processing.
For the AD (Microsoft Active Directory and AD LDS) password type, the MLDAP ESM Module uses a special LDAP request documented by Microsoft for this purpose. It involves a combined "delete value" request with the old (existing) password, and an "add value" request with the new password, against the write-only attribute unicodePwd. This tells AD to perform a Windows password change for the user. With AD LDS, the target user does not need to be a Windows user account, just an object of the user class. The operation only succeeds if the old password is correct and the new password meets the requirements set on the local computer and/or domain.
For the other external password types, the MLDAP ESM Module uses the mechanism described by RFC 2307, updating the attribute userPassword (unless set otherwise in the configuration) with a new value formed from the password using the hash specified by the password type. Some servers simply set the value of the attribute; others will transform it or perform some other operation, possibly against an external authentication service.
As an example of the server transforming the value being set for userPassword, the OpenLDAP server's olcPasswordHash configuration option can be set to instruct the server to hash the value of userPassword when an application attempts to modify it. In this type of environment, an Enterprise Server administrator could configure the MLDAP ESM Module to use the literal password type so that the new password is sent to the server verbatim. In this configuration, Micro Focus strongly recommends using TLS with LDAP, so passwords are not exposed on the network.
Typically, external password changes are performed after authenticating the user. Because external password types are used with bind-mode verification, when the password change is attempted, the MLDAP ESM Module has an LDAP session bound to the identity of the target user. It will use that session to attempt the password change, so with external verifiers users in effect change their own passwords with the LDAP server, as opposed to having the password change be attempted using the account configured for the security manager. This is more likely to succeed, because LDAP servers are typically configured so users have permission to modify their own passwords, but the account used by the security manager generally does not have permission to modify the passwords of arbitrary users.
Attempting the password change only after verifying the user presents a problem for bind-mode authentication. If, for example, the user account requires a password change because the password is expired then the bind operation will typically be rejected. This leaves users with no way to change expired (or must-change) passwords when bind-mode authentication is configured.
Unfortunately, there is no straightforward solution to this issue when RFC 2307 password types are used.
There is a potential solution to this for Active Directory and AD LDS. As noted above, the mechanism for the AD password type involves a request which includes both the old and new passwords. In effect, the user is authenticated as part of the password-change operation. That means the password change can be attempted before trying to bind as the user without compromising security.
In order for this to work, a second security mechanism needs to be relaxed. An AD-type password change also requires that the LDAP session being used for the request be bound to an account that has the "Change Password" special permission for the user object being updated. Typically, this permission is granted only to NT_AUTHORITY\SELF, to let users change their own passwords.
It is possible to grant Change Permission to the account configured for the security manager, for user objects in AD or AD LDS. This lets that account change the passwords of those users. As noted above, the change will only succeed if the correct existing password is supplied, so this is safe.
Granting the permission involves updating the Access Control List (ACL) for a user object, or for a container of user objects (in which case it must be made inheritable). For example, using Microsoft's dsacls command with a local AD LDS installation and the sample LDAP configuration supplied with Enterprise Server might look like:
dsacls "\\localhost\CN=SYSAD,CN=Enterprise Server Users,CN=Micro Focus,CN=Program Data,DC=local" /G "CN=MFReader,CN=ADAM Users,CN=Micro Focus,CN=Program Data,DC=local:CA;Change Password"
Usually it is more efficient to set inherited ACLs on containers than on individual user objects. ACL changes can also be scripted using PowerShell.
Once this has been implemented, you can use the attempt password change configuration setting with the before or both value to try the password change before attempting to bind as the user. See MLDAP ESM Module Custom Configuration Information for more information.
An alternative to setting this ACL is to configure the security manager to use an account that has administrative privilege. Some installations historically have used this approach, particularly with AD LDS, to enable AD password changes. AD LDS comes with the predefined roles Reader, which does not have any update rights, and Administrator, which can update any attribute of any object in the AD LDS instance; for convenience, AD LDS administrators might configure an AD LDS account in the Administrator role for use by Enterprise Server. However, Micro Focus recommends against using the Administrator role for the account used by Enterprise Server security managers, as a security vulnerability or credential breach could give an attacker high-value access to the AD LDS repository.
It is unsafe to configure before-binding password-change attempts with other external password types.
To avoid exposing passwords or password verifiers on the network, it is safer to configure the security manager to connect to the LDAP server using SSL/TLS. This is also known as LDAP-over-SSL or LDAPS. There is less risk with using MF-mode authentication because the existing password is not sent to the server and when using a hashed password type such as MF-A2 or SSHA512 because only a hash of the new password is sent.
Some servers might require SSL/TLS connections to perform password changes. That is the default for Active Directory and AD LDS.
To use SSL/TLS, both the server and the provider (client library) must be configured to support it. See your LDAP software documentation for more information. Then the connection string in the security manager definition should be changed to begin with ldaps://.