FIM Self-Service Password Reset (SSPR) and Active Directory password policy

Forefront Identity Manager (FIM) 2010 Update 1, when coupled with a Windows Server 2008 R2 Service Pack 1 (or Windows Server 2008 Service pack 2 or Windows Server 2008 R2 RTM plus hotfix) Primary Domain Controller Emulator (PDCe) Operations Master (OM) role holder enables the Self-service Password Reset (SSPR) feature of FIM to fully honour all Active Directory Domain Services (AD DS) password policy settings.

Prior to the AD DS DCR described in KB2386717: ‘The “Enforce password history” and “Minimum password age” Group Policy settings do not work when you reset the password for a Windows Server 2008 R2-based or a Windows Server 2008-based computer‘ password reset operations bypassed the underlying logic that maintains the minimum password age and password history. A password reset has traditionally been thought of as an administrative action therefore an administrative reset should not need worry about history or, more importantly, age. I say traditionally, of course such an operation is still, rightly, considered an administrative operation. However with the advent of end-user focussed self-service password reset applications something has had to change so that a reset operation can optionally reset the password (in a secure manner) with a new password submitted by the end user (a user-defined password).

The AD DS product group (PG) has implemented this change. And the FIM PG has consumed the change.

KB2443871: “FIM 2010 Self Service Password Reset now supports Enforcement of all domain password policies” fully describes how to configure the FIM Synchronization Service to utilise the new AD DS behaviour. In summary, you make the following configuration:

  1. Implement the hotfix for Windows Server 2008 or Windows Server 2008 R2 RTM (it’s included in Windows Server 2008 R2 Service Pack 1) on the PDCe.
  2. Configure the FIM Synchronization Service registry value ADMAEnforcePasswordPolicy (located under the key “HKLM\ SYSTEM\ CurrentControlSet\ Services\ FIMSynchronizationService\ Parameters\ PerMAInstance\<ma name>”)

The reason I’m writing this blog post is to hopefully succinctly describe why the documentation explicitly refers to the PDCe. There have been a number of questions around how to implement this feature on the public FIM forum as well as internally on the FIM discussion alias. The crux of the matter is this: the password reset activity (Password Reset Action Workflow Activity) that runs in the context of an action workflow (Password Reset Action Workflow, 79315438-c20b-465e-bcd6-677685f2783a) submits the password reset operation to the FIM Synchronization Service via the MIIS_CSObject::SetPassword method. This method has been extended. The original definition was:

String SetPassword(String newPassword, Boolean forceChangeAtLogon, Boolean unlockAccount) 

The new definition, or more likely override, is as follows:

String SetPassword(String newPassword, Boolean forceChangeAtLogon, Boolean unlockAccount, Boolean validatePasswordPolicy) 

The last Boolean parameter (validatePasswordPolicy) makes use of the new LDAP extended control: LDAP_SERVER_POLICY_HINTS (1.2.840.113556.1.4.2066). The way the underlying code has been implemented is to always target the PDCe (DsGetDCName() Flag DS_PDC_REQUIRED). This is the reason why the documentation specifically mentions the PDCe. The LDAP extended control can be implemented on any DC (indeed it should be implemented on all DCs if you’re using it outside of FIM SSPR as the mixture of supported LDAP controls should be minimised to that defined by the OS level of the DCs really). However for the purpose of FIM SSPR only the PDCe is targeted. This is slightly confusing but ultimately conveniently flexible. As this means it is potentially considerably easier to implement SSPR with the fully honoured password policy in environments that don’t yet implement Windows Server 2008 or Windows Server 2008 R2 domain controllers. Don’t get me wrong –it’s still not a simplistic change (within the confines of a given organisations politics and processes). It does require the AD DS schema extension and domain preparation required as part of any DC upgrade programme. The difference is that many organisations are currently planning on, or in the process of, moving to a Windows Server 2008 or Windows Server 2008 R2 domain and the introduction of one is often allowed and can sometimes expedite the project itself.

The other thing of note around the current implementation of the set password operation with the LDAP_SERVER_POLICY_HINTS control is that the only connection that the AD MA will work over is LDAPS (LDAP over TLS/SSL). Now, again, this is an implementation choice (by the FIM PG). Yes, it is possible (and in some cases more trivial) to utilise what’s commonly referred to as LDAP bind channel encryption (basically Kerberos signing and sealing of the LDAP connection). However, presently, the FIM PG hasn’t implemented this code. This adds a small complexity to the deployment for environments that have not yet deployed LDAPS. Now you need to configure LDAPS on the PDCe. When I say configure I mean enrol the necessary certificate. There’s no real DC-side configuration. There are three choices, of which only two are really valid in production:

  1. Purchase a certificate from a trusted root authority, e.g. Verisign or Thwarte;
  2. Implement a Public Key Infrastructure (PKI), e.g. Active Directory Certificate Services (AD CS);
  3. Implement a self-signed certificate. Realistically this option is only prudent for testing and sandpit environments.

Interestingly though the AD MA code doesn’t perform certificate revocation list (CRL) checking. Is this a good thing? Bad thing? Or doesn’t it matter? J


When MIIS_CSObject::SetPassword is called with the Boolean validatePasswordPolicy parameter the LDAP_SERVER_POLICY_HINTS control is utilised. The AD MA explicitly requests an LDAPS connection to the DC hosting the PDCe OM role and does not perform CRL checking. When MIIS_CSObject::SetPassword is called without the Boolean validatePasswordPolicy parameter, or the value is false, a “normal” password reset is performed, i.e. password history and minimum age are ignored. Reiterated another way, password resets initiated by the Password Reset Action Workflow always target the PDCe.

  • If the registry value ADMAEnforcePasswordPolicy is enabled on the FIM Synchronization Service computer then an LDAPS connection is established (without CRL checking).
  • If the value is disabled, or not present, a “normal” (dependent upon MA configuration, i.e. either Kerberos signing and sealing or LDAPS) LDAP connection is established to the PDCe.


The latest (at time of writing, use the support website for the most up-to-date information) build of FIM is hotfix rollup package kb2502631 (build 4.0.3573.2). The hotfix rollups are cumulative.

The support article that defines the configuration of the ADMAEnforcePasswordPolicy option is kb2443871.

The AD DS hotfix for the LDAP_SERVER_POLICY_HINTS control is kb2386717.


About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in FIM, Self Service Password Reset and tagged , , , , , , , , , . Bookmark the permalink.

2 Responses to FIM Self-Service Password Reset (SSPR) and Active Directory password policy

  1. Pingback: Resetting an AD DS password and honouring password history and age using the LDAP_SERVER_POLICY_HINTS control | Yet another identity management blog

  2. Pingback: FIM 2010: SSPR with one-way trust | Wim Beck

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s