Active Directory Password Change
Last modified 27 Oct 2021 10:53 +02:00
Since 3.9
This functionality is available since version 3.9. (AD connector version 2.0 and later)

Introduction

There are two related, but somehow distinct ways how to change user’s password in Active Directory:

  • Password reset by an administrator. This method does not need old (current) user password. Administrator can change password that violates some parts of password policies (e.g. password history), administrator can force password change and so on. However, this may be somehow rough operation. For example password history is cleared when password is reset by an administrator.

  • Password change by end user. This method requires knowledge of old (current) user password. The change is executed using user’s own identity. The password must comply with all password policies, password history is properly maintained and so on.

MidPoint and the AD connector are using password reset as a default method for all password changes. This is a reasonable default that works with most AD deployments. However, there can be consequences, such as erased password history. Therefore since midPoint 3.9 there is an alternative way how to support nicer self-service password change.

RunAs Capability

For proper password change support the connector must be able to execute operations using end user’s identity. This feature is referred to as runAs capability. Active Directory connector supports this capability since version 2.0 (bundled with midPoint 3.9). However, this capability is not enabled by default. Enabling this capability by default may lead to operational problems and even security risks for some deployments. RunAs capablity can be enabled in connector configuration:

<resource>
    ...
    <connectorConfiguration>
        <icfc:configurationProperties>
            ...
            <icfcldap:runAsStrategy>bind</icfcldap:runAsStrategy>
            ...
        </icfc:configurationProperties>
    </connectorConfiguration>
    ...
</resource>

Please make sure that you refresh cached resource capabilities after this capability is enabled in the connector (e.g. by deleting <capabilities> element in the resource and initiating connection test).

Limitations

Obviously, old (current) password of the user needs to be known in order to use password change method. This is usually the case only during self-service password change in midPoint. In that case user is prompted for old password and new password. Old password value entered by the user is used to authenticate user to Active Directory in order to execute the password change (runAs capability). Old password is also used as a part of the operation itself. Therefore this method of password change is used only if end user is changing his own password using the self-service password change page in midPoint user interface.

If administration part of midPoint user interface is used then password reset method is used instead. In this case the old password value is not available and therefore it is not possible to use user’s own identity to initiate password change.

This mechanism relies on fact, that the password in midPoint and the password in Active Directory are the same. If they are not the same then this approach will not work. That is also the reason why is this capability disabled by default. But even if midPoint password are mapped to AD, the situation that midPoint and AD password is different may still happen under some circumstances. For example if new password is valid as midPoint password but it is not valid as AD password, e.g. due to different password policies, password history and so on. In that case password change in midPoint is executed, but password change in AD is not executed. The result is a situation when midPoint and AD passwords are different for that particular account. Currently, midPoint cannot automatically recover from this situation and the password needs to be reset manually by an administrator. Therefore it is important to make sure that this situation does not happen - and the most efficient approach is to make sure that midPoint password policy is at least as strong as AD password policy.

This situation may be particularly cumbersome for deployments for which AD is the primary authentication mechanism. Such deployments would probably like to use AD authentication even for midPoint. This is currently possible, although it may be slightly difficult to configure and this approach is not supported in standard midPoint subscription. And this will not work for self-service password resets completely as midPoint will still check old password using its own database. The solution would be to use flexible authentication. This is future midPoint feature. For those interested in this approach we recommend to use midPoint subscription to make sure that flexible authentication feature is placed on midPoint roadmap.

See Also

Was this page helpful?
YES NO
Thanks for your feedback