Clever IDM Enterprise Product Guide

Clever IDM Enterprise Technical Guide

Active Directory Password Filter DLL Functional Details

Microsoft provides a Password Filter API that is described here: https://docs.microsoft.com/en-us/windows/win32/secmgmt/password-filters?redirectedfrom=MSDN. When a password change is made on a Windows machine, whether local or through Active Directory (AD), the password is handed off to the Local Security Authority (LSA) service, which then makes two sets of calls to all of the registered password filters. The first round of calls asks the filter to validate whether or not the password is acceptable. This allows for the implementation of custom password policies. If all the registered password filters accept the password, then the password is passed on to the Security Accounts Manager (SAM) for updating the account (local or AD), and is also sent again to each of the registered password filters as a notification that the changes have occurred.

To our knowledge, every 3rd party application that synchronizes passwords from Active Directory to some other set of foreign accounts uses the Password Filter API to capture the password changes. This includes Identity and Access Management (IAM) products from Oracle, Google, Novell/NetIQ/MicroFocus, Okta, ForgeRock, SAP, CA, RSA, and Microsoft. The only other method that Clever IDM Enterprise is aware of for capturing passwords from AD is the Store password using reversible encryption feature of AD, which some Microsoft services require to perform certain kinds of authentication that cannot be performed using only a hash of the password. Microsoft does not expose reversibly encrypted passwords to third-party applications.

A password filter is implemented as a DLL that has three entry points named InitializeChangeNotify, PasswordFilter, and PasswordChangeNotify. A password filter is installed and registered by placing it in the Windows or Windows\System32 directories, and is registered by adding the name of the .dll (without the path or .dll extension) in the Notification Packages subkey of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa in the Windows registry. Registration/unregistration of a filter requires a restart of the LSA, which is most safely accomplished via a system reboot. In order for password changes to be reliably captured, the filter must be installed on all writeable domain controllers.

The installation process for the RapidIdentity Password Filter is as follows:

  1. idautopwfilter.dll and idautopwconduit.exe are installed to the Windows directory using an MSI installer.

  2. idautopwconfig.exe and pwfilterhost.exe are installed to %%ProgramFiles%%\Clever IDM Enterprise\RapidIdentity Password Filter for Active Directory.

  3. idautopwconfig.exe is run to allow the user to:

    1. Extend the AD Schema.

      1. class: idauto-pwFilterConfig

        1. attribute: idauto-publicKey

      2. class: idauto-pwSyncUserAux

        1. attribute: idauto-pwdPrivate

    2. Register the idautopwfilter.dll

    3. Allow the user to import the RSA public key from Clever IDM Enterprise, which is then stored in AD in the idauto=publicKey attribute of idauto-pwdFilterConfig object created at cn=pwfilter,cn=idauto,cn=services in the domain configuration partition.

  4. Reboot to allow LSA to start using the password filter.

When idautopwfilter.dll:InitializeChangeNotify is called by the LSA:

  1. Registers event source idautopwfilter for logging system events

  2. When idautopwfilter.dll:PasswordFilter is called by the LSA:

    1. Returns without doing anything

  3. When idautopwdfilter.dll:PasswordChangeNotify is called by the LSA:

    1. If not already done in a previous call, initializes an AES session key used to encrypt communication with idautopwdconduit.exe.

    2. Spawns (if not already running) an instance of idautopwconduit.exe that it connects to a private pipe.

    3. Encrypts the password using the session key.

    4. Sends the username and encrypted password and sends them to idautopwconduit.exe through the pipe.

  4. The only clear-text copy of the password used by the DLL was the one passed in by LSA and is to be treated as read-only since LSA passes the same copy to each filter and clearing it makes it unavailable to other registered filters.

When idautopwconduit.exe receives a message from the pipe:

  1. The message is placed in a queue for asynchronous processing.

  2. A separate thread polls the queue and with each message:

    1. Retrieves the session key and uses it to decrypt the password

    2. Re-encrypts the password using the configured RSA public key

    3. Looks up the User object in AD and stores the RSA-encrypted password in its idauto-pwdPrivate attribute

  3. The only clear-text copy of the password occurs in the byte array that receives the results of decryption using the session key. As soon as the re-encryption with the RSA public key has finished, the byte array is zeroed out.

In this section: