Active Directory Password Filter Details

Technical Guide

Microsoft provides a Password Filter API. Whenever 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 to allow for the implementation of custom password policies. If all registered password filters accept the password, then the password is sent to the Security Accounts Manager (SAM) for updating the account (again, whether local or through AD), and is sent again to each of the registered password filters as a notification that the change has occurred.
To our knowledge, every third-party application that synchronizes passwords from Active Directory to some other set of foreign accounts uses the Password Filter API to capture 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 Identity Automation is aware of for capturing passwords from AD is the Store password using reversible encryption feature of AD, in which some Microsoft services require certain kinds of authentication that cannot be performed using only a hash of the password. Microsoft does not expose the reversibly encrypted passwords to third-party applications.
A password filter is implemented as a .dll file that has three entry points named InitializeChangeNotify, PasswordFilter, and PasswordChangeNotify. A password filter is installed and registered by adding the name of the .dll (without the path or .dll extension) to 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.

Under the Hood

When you follow the Password Filter Installation process steps, this is what happens on the system throughout that procedure.

1.** idautopwfilter.dll** and idautopwconduit.exe are installed to the Windows directory using an MSI installer, executed with an Administrator account.
2. idautopwconfig.exe and pwfilterhost.exe are installed to %%ProgramFiles&&\Identity Automation\RapidIdentity Password Filter for Active Directory.
3. idautopwconfig.exe is run to allow the user to:
1. Extend the AD schema
1. class: idauto-pwdFilterConfig
1. attribute: idauto-publicKey
2. class: idauto-pwdSyncUserAux
1. attribute: idauto-pwdPrivate
2. Register the idautopwfilter.dll.
3. Allow the user to import the RSA public key from RapidIdentity, 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 portion.
4. Reboot to allow LSA to start using the password filter.

Event Calls Explained

1. When idautopwdfilter.dll:InitializeChangeNotify is called by the LSA, it registers event source idautopwfilter for logging system events.
2. When idautopwfilter.dll:PasswordFilter is called by the LSA, it returns without doing anything.
3. When idautopwfilter.dllPasswordChangeNotify is called by the LSA, it:
   1. Initializes an AES session key (if not already done) used to encrypt communication with idautopwconduit.exe.
   2. Spawns an instance of idautopwconduit.exe (if not already running) that it connects to as a private pipe.
   3. Encrypts the password using the session key.
   4. Sends the username and encrypted password 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, which is treated as read-only since LSA passes the same copy to each filter, and clearing it makes it unavailable to other registered filters.
5. When idauaopwconduit.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 cleartext copy of the password occurs in the byte array that recieves the results of decryption using the sessions key. As soon as the re-encryption with the RSA public key has finished, the byte array is zeroed out.