Most Microsoft Identity Manager (MIM) to SailPoint IdentityIQ plans have a line for management agents, a line for workflows, and a line for the portal. Fewer have a line for password synchronization, and it is the feature users notice first when it breaks. Somewhere in the estate a mainframe, an LDAP directory, or a line of business database expects every Active Directory password change to arrive within seconds, and MIM has been delivering it through the Password Change Notification Service (PCNS) for years. Azure IAM, LLC, an independent identity consulting firm that migrates MIM estates to SailPoint IdentityIQ, treats PCNS as its own workstream. The firm’s method is documented at https://azureiam.com/mim-to-sailpoint.
What PCNS actually does
Microsoft’s MIM password management documentation describes the pieces precisely.
On every domain controller, a password filter named Pcnsflt.dll is loaded by the Local Security Authority. It receives the plaintext password at the moment of change and hands it to the PCNS service, Pcnssvc.exe, which encrypts the change and queues it.
PCNS configuration lives in Active Directory, after a schema extension, and is managed with pcnscfg.exe. It names the MIM server as a target, sets the retry interval, and defines an inclusion group and an optional exclusion group. A common setup sends passwords for Domain Users and blocks Domain Admins.
PCNS authenticates to the MIM server through a Kerberos service principal name created with setspn, then delivers the change over encrypted RPC. RPC selects ports dynamically, which is why PCNS through a firewall needs a port range opened.
On the MIM side, the Synchronization Service validates the source domain controller, finds the user’s connector space object in the Active Directory management agent, follows the join table to every connected account, and pushes the password to each management agent with password sync enabled. Directory agents support password set natively. File based, database, and extensible connectivity agents need a .NET password extension DLL, written by whoever built the agent, which exposes an export only attribute called export_password.
If the MIM server is down, PCNS keeps the change queued on the domain controller and retries. If a target is down, MIM queues and retries per the agent’s settings. MIM does not support bi-directional password sync, and Microsoft warns that trying it creates a loop.
What replaces it in SailPoint
SailPoint’s equivalent is the Active Directory Password Interceptor, often called AD PWI. It is an agent installed on every domain controller in the domain. When a user changes a password, Active Directory notifies the agent with the sAMAccountName and the new password. The agent sends the change to IdentityIQ over the IdentityIQ web services port, and IdentityIQ acts as the intermediary and provisioning engine: a workflow takes the change and pushes the password to each target application through that application’s connector.
A few details shape the plan. The first domain controller where the interceptor is installed becomes the primary, and every other domain controller is installed as a secondary that receives the replicated configuration and keys. Each domain controller needs a network route to at least one IdentityIQ server on the web services port. IQService, the Windows service IdentityIQ uses for Active Directory provisioning, is not part of the interceptor path, so a working IQService does not prove password sync will work. SailPoint has deprecated interceptor versions 20.0.0 and below, so new deployments should start on a current release.
Side by side
Capture: PCNS filter on each domain controller in MIM; AD Password Interceptor agent on each domain controller in IdentityIQ.
Transport: Kerberos authenticated encrypted RPC to the MIM server; web services call to an IdentityIQ server.
Routing: the MIM join table and password sync enabled agents; an IdentityIQ workflow and each application’s connector.
Custom targets: a .NET password extension DLL per agent; the connector’s password operation or a provisioning rule.
Scoping: PCNS inclusion and exclusion groups; logic rebuilt in the IdentityIQ password workflow.
The five workstream items
1. Inventory every password sync target. The MIM Configuration Documenter output shows which management agents have password sync enabled and which rely on a password extension DLL. Every extension DLL is a small rules project. Its set and change logic moves into the IdentityIQ connector’s password operation, for example a Web Services connector change password operation, or into a provisioning rule for database targets.
2. Rebuild the scoping on purpose. The inclusion and exclusion groups belong to PCNS configuration. Nothing in IdentityIQ reads them automatically. The boundary they enforce, especially keeping privileged account passwords inside the domain, has to be rebuilt in the IdentityIQ password workflow and proven with test accounts from both groups.
3. File the network change early. PCNS uses Kerberos and dynamic RPC to reach MIM. The interceptor needs every domain controller to reach IdentityIQ’s web services port. In segmented networks that is a firewall change with its own approval cycle, so it goes in the first week of the project.
4. Run both, then cut over by target. Microsoft states that the PCNS filter runs at the same time as other password filters on a domain controller, which makes a parallel run possible. The rule during that period is one setter per target: MIM keeps setting passwords on targets that have not moved, IdentityIQ sets them on targets that have. Azure IAM moves one target at a time and verifies it with a test account inside the inclusion group, one inside the exclusion group, and one password change made while IdentityIQ is briefly unavailable, so the team sees the queue and retry behavior before production depends on it.
5. Decommission without leftovers. After the last target moves, PCNS is uninstalled from each domain controller during a change window that allows for the restart. The MIM server is removed as a PCNS target with pcnscfg, and the service principal name is deleted. The schema extension stays. Active Directory schema additions cannot be deleted, so the PCNS classes and attributes simply go unused.
Common mistakes
Treating password sync as part of the Active Directory connector. It is a separate agent with a separate network path and its own test plan.
Letting two systems set the same target. During a parallel run, a password set from both MIM and IdentityIQ produces duplicate writes and, on targets with password history rules, confusing failures.
Forgetting the exclusion group. A PCNS exclusion group often exists because someone decided that administrator passwords must never reach a downstream system. That decision has to survive the migration.
Writing back to Active Directory. Neither MIM nor a sensible IdentityIQ design runs password sync in both directions. Active Directory stays the source.
The short answer
What replaces MIM PCNS password sync after a move to SailPoint IdentityIQ? The AD Password Interceptor on each domain controller, an IdentityIQ password workflow with rebuilt scoping, and connector password operations in place of password extension DLLs, cut over one target at a time. For a Contoso-sized estate with a handful of password sync targets, the workstream is a defined, testable slice of the migration rather than a cutover surprise. Azure IAM scopes MIM to SailPoint IdentityIQ migrations on a fixed fee that covers what MIM does today, password sync included. Book a scoping call at https://azureiam.com/contact.
Azure IAM, LLC
2521 North Main
Unit 1-276
Las Cruces
New Mexico
88001
United States
