Hello folks, David Steadman Here!!
Today we’re releasing the Microsoft Identity Manager 2016 SP1 August 2017 Hotfix (4.4.1642.0),
In addition to the other updates, this hotfix includes an enhancement to the self-service password reset scenario.
As you know, in MIM, there are three steps to password reset:
- The administrator selects the users in scope for password reset, and the gates they’ll use to reset their password – Q&A, alternate email, phone/SMS or Azure MFA
- The users in scope are registered. Either the user registers themselves via the self-service password reset registration portal, or the administrator programmatically registers them using the PowerShell SSPR cmdlets.
- When a user forgets their password or their account is unlocked, they are challenged using the registration data in the gates, and if successful, optionally provide a new password which is then sent to AD.
Typically a customer with MIM has MIM installed in one AD domain in a forest with trusts to all other domains and forests. But suppose an organization has multiple disconnected AD forests. For example, Contoso might have MIM SSPR deployed already for Contoso users, who are all registered and reset using MIM. Contoso then merges FabriKam, who have their own AD. However, Contoso for various security or operational reasons do not yet wish to set up a trust relationship with the legacy FabriKam AD – maybe some of the FabriKam employees are going to a spinoff and shouldn’t have access to Contoso apps. Can Contoso extend their MIM SSPR to cover some of former FabriKam users as well, without needing a AD-to-AD trust?
If you had tried this in the past, MIM would have required a trust, since it attempts impersonation on behalf of the user during reset. Without a trust in place, the password reset would have failed with an error message like “The server encountered an error while attempting to perform a set/change password operation.” being reported in MIM sync.
With this hotfix, you can enable password reset to occur even without a trust to the forest where the user’s account resides. (Note that it will require the FabriKam users to be programmatically registered by the Contoso admins, perhaps with Q&A answers supplied from some organizational data source, or the users registered for a MFA call. This is because the MIM password reset registration portal requires the users to authenticate via Integrated Windows Authentication, either from a desktop browser on Windows, or via a proxy such as WAP, as I described earlier at link).
Here’s how to set up SSPR for resets to a directory that’s not a trusted domain. Note this requires all the components of MIM to be on versions 4.4.1629.0 or later.
Solution: Today we have unlocked & finalized the full end to end scenario for registration on behalf to an untrusted domain connected via the synchronization Service. This requires that you be on MIM 4.4.1642.0 or greater.
First we need to create a management agent and account with least privilege approach we will only delegate to the Users OU
Next we will create a Active Directory Management Agent and use the above credentials and select the following attribute : displayName, objectsid, SamAccoutName
On the Password Management section we will select Boolean ‘Enable password management’
the next step as you guessed it is we need to create a sync rule to import the users . In the MIM Portal select Synchronization rule and New. Select your appropriate inbound join rule and name and then select Boolean ‘Create resource in FIM’
Attribute flow looks likes the below:
Once all complete we can run a Full Import and Sync on the FIMMA / FabriKam MA Then Export on the FIM MA to see the User from the untrusted Domain
Finally we need to allow the Admin or service account to register on behalf the user aka ‘Jeff’. To do this we will create a MPR in the MIM Portal.
- Type: Request
- Operation: Create resource, Delete resource
- Permissions: Grants Permission (True/checked)
- Target Resource Definition Before Request: All Gate Registrations
- Target Resource Definition After Request: All Gate Registrations
- Resource Attributes: All Attributes (not Ideal , but you can get more granular)
Logon to one of your servers running the FIM Service and open a PowerShell shell and import the FIMAutomation snap-in:
Here are the steps from getting the questions to answer and then applying to user
(Get-AuthenticationWorkflowRegistrationTemplate –AuthenticationWorkflowName ‘Password Reset AuthN Workflow’).GateRegistrationTemplates.Data.Name
$AuthNWFTemplate = (Get-AuthenticationWorkflowRegistrationTemplate -AuthenticationWorkflowName ‘Password Reset AuthN Workflow’).Clone()
$AuthNWFTemplate.GateRegistrationTemplates.Data.Value = “1234567”
#Badge Serial Number?
$AuthNWFTemplate.GateRegistrationTemplates.Data.Value = “z1z1z1z1”
$AuthNWFTemplate.GateRegistrationTemplates.Data.Value = “Soccer”
Register-AuthenticationWorkflow -UserName fabrikam\jeff -AuthenticationWorkflowRegistrationTemplate $AuthNWFTemplate
Confirm-AuthenticationWorkflowRegistration -UserName fabrikam\jeff –AuthenticationWorkflowName $AuthNWFTemplate.DisplayName
Lastly we need to update the phone number as Contoso has MFA enabled for SSPR , we go to jeff and update the ‘Phone Gate Phone Number’ under advance view
Now for the true test lets have Jeff go to the MIM SSPR Reset Portal (https://passwordreset.contoso.com/default.aspx)
Out of scope Items : MIM SSPR with Client from untrusted domain, Password Registration Portal
Programmatic User Registration: https://technet.microsoft.com/en-us/library/jj134294(v=ws.10).aspx
FIM 2010 Self Service Password Reset now supports Enforcement of all domain password policies:https://support.microsoft.com/en-us/help/2443871/fim-2010-self-service-password-reset-now-supports-enforcement-of-all-d
Introduction to Management Policy Rules: https://technet.microsoft.com/en-us/library/ee534905(v=ws.10).aspx
Password Reset Deployment Guide: https://technet.microsoft.com/en-us/library/ee534892(v=ws.10).aspx