A challenge when provisioning accounts to Active Directory using FIM / MIM is how to securely set the initial password and communicate that password to the new user so that they can logon to their computer.
In this blog posting I describe a solution that leverages activities available in the MIMWAL to do the following:
- Configure a Random and Complex Password
- Sets the Password on the Active Directory User Account that was Provisioned by FIM
- Emails the Password to the User’s Manager
A Wiki article exists on TechNet describes some steps that can be taken to achieve these same results. However, the issue with that solution is that it is dependent on a classic synchronization rule based on an Outbound Synchronization Policy (MPR, sets, and workflow) for account provisioning. Many of us have moved to the more desirable method for account provisioning using an Outbound Scoping Filter. My solution supports the latter scenario as there is no dependency on the FIM Synchronization service. Instead it uses MIMWAL workflow activities to achieve the same end state.
So, what’s required?
Requirements
- You must have the MIMWAL installed. The MIMWAL is a Workflow Activity Library (WAL) for building complex workflows in the Microsoft Identity Manager (MIM) 2016 and Forefront Identity Manager (FIM) 2010 R2 solution which was made publically available in January of 2016. For more information about the MIMWAL to include project source code, releases and documentation, and discussion forums visit http://microsoft.github.io/MIMWAL/. Installing the MIMWAL can be tricky. Fortunately I have a blog post that can help you through the process here.
- You should already be provisioning users to Active Directory as that is out of scope for this blog posting.
- You must be synchronizing the ObjectSID from Active Directory back to the FIM Service.
High Level Steps
So, with that, we’ll look at what needs to be configured. The high level configuration steps are as follows:
- Configure Email Template
- Configure Workflow
- Configure Management Policy Rule (MPR)
- Make the Manager attribute required on User Create
- Initialize
Now we’ll look at each of these steps in detail
Step 1. Configure Email Template
Create a new Email template with settings in screenshot below. The body html can be downloaded from here and of course, you may adjust as desired.
The configuration in this activity will result in an email being sent to the user’s manager that looks like this (screenshot below):
Step 2. Configure WF
You will need to create an Action Workflow as depicted in the screenshots below.
The workflow has three MIMWAL activities (screenshot below) that will generate the password, send an email to the user’s manager, and then set the password on the account in AD and flag the account so that the user will have to change the password at first logon.
A screenshot of the MIMWAL Update Resource Activity is below. We use the RandomNum function in this activity to ensure that the password will be random, add some text to ensure that we meet password complexity and save the password in the WorkflowData as “WorkflowData/Password” where it can be used later. We use this [//WorkflowData/Password] in the HMTL of the email template so that the new password would be listed in the email and use it in the PowerShell script that sets the password of the user account in AD.
A screenshot of the MIMWAL Email Notification Activity is below. In this activity we send the email containing the new password to the user’s manager. We specify the template we created earlier by using an XPATH filter that specifies the ObjectID for the template.
A screenshot of the MIMWAL PowerShell Script Activity is below. The powershell script utilized the ADSI provider to connect to AD, sets the password on the account, and sets the account so that the user is required to change their password at first logon. You may download the PS script here. Two parameters (AN and AP) are set in the activity to allow the user’s Account Name (AN) and new password (AP) to be passed along to the script.
Step 3. Configure MPR
We need the _AD Password workflow that we created above to kickoff after a user has been provisioned to AD. The reason is rather obvious; you can’t set the password or require password change at next logon flag until the account has been provisioned. So, the process will require two sync cycles to complete; (1) Provision Account to AD, (2) Set Password and Password Change at Next Logon Flag, Email Password to Manager.
What attribute on a user object in FIM / MIM can we use that tells us that user has been provisioned to AD? It’s the Resource SID which is the objectSID of the user account in AD. So, you must make sure that you are synchronizing this attribute into FIM. This attribute is required for the user to authenticate against the FIM / MIM Portal or FIM / MIM SSPR so in most cases your environment would be configured this way.
So, to kick off the _AD Password workflow, we create a Request MPR that looks for writes to the Resource SID in FIM as depicted in the screenshots below.
Step 4. Make the Manager Attribute Required on User Create
We need the manager to receive the password for the new user. One way to ensure that is to require that when a user is created in the FIM Portal that the Manager attribute is specified. To achieve this, replace this line in the “Manager” control of the User Create RCDC
my:Property my:Name="Required" my:Value="{Binding Source=schema, Path=Manager.Required}"/>
with
<my:Property my:Name="Required" my:Value="True"/>
The RCDC should look like the screenshot below when edited:
If someone tries to create a user and hasn’t specified manager, they will receive the following message when submitting the request (screenshot below).
Step 5. Initialize
To initialize the configuration you will need to:
- Complete a Delta Import on the FIM Service MA followed by a Full Sync on the FIM Service MA.
- Create your user account in FIM
- Complete a Sync cycle so that the new user is provisioned to AD
- Complete a second Sync cycle so that the password is configured and set on the user account in AD, the user account in AD is set for change at next logon, and the manager is emailed with the user’s Account Name and Password.
I hope you found this posting helpful. As always, post your questions/comments. Thanks!
Matt
Hello, Matthew!
I’m trying to implement your solution with MIMWAL and have a problem.
Users are created in AD, but manager don’t receive a email.
I think that a problem somewhere in Outbound sync rule, you don’t write anything about flows needed in it.
As I understand, in Sync rule we also need two flows:
Some strong (temporary) password to create a user account, ie.
P@ssw0rd -> unicodePwd
And “checkbox” to recreate password at first user login:
0 -> pwdLastSet
With this two options (without MIMWAL) users are created in AD.
After I add MIMWAL users get a new password (which is unknown to me and manager).
Service account can get access to mailbox and send/receive emails.
Can you, please, help with troubleshooting?
Thanks!
Hi Oleksandr,
That’s good that you are getting the account created in AD. The email is generated after the account has been provisioned to AD when the new account is synced back into MIM. The workflow that sends the email kicks off because there is an MPR that applies when the objectSID attribute from AD gets assigned to the ResourceSID attribute in MIM.
Its not required to sync “unicodePwd” when provisioning a new user to AD. If you choose not to, AD will assign a random password to the user and the account will be in a disabled state. If you go this route, then you will need to update the PS script on the “Set Password on AD Account” activity of the “_AD Password” workflow so that the account is enabled when the activity sets the new password. Just add the “$accountToSetPW.put(“userAccountControl”, 512)” to the script:
#Param($AN,$AP)
$root = [ADSI]”
$searcher = New-Object System.DirectoryServices.DirectorySearcher($root)
$searcher.Filter = “(&(objectClass=user)(sAMAccountName=$AN))”
$user = $searcher.FindOne()
$userPath = $user.Path
$accountToSetPW = [ADSI]$userPath
$accountToSetPW.SetPassword($AP)
$accountToSetPW.put(“pwdLastSet”, 0)
$accountToSetPW.put(“userAccountControl”, 512)
$accountToSetPW.SetInfo()
We do not need to sync the “pwdLastSet” in the Portal Sync rule as we are handling that in the PS script in the “$accountToSetPW.put(“pwdLastSet”, 0)” line.
It sounds to me like the workflow that generates the email and sets the random password is not firing. Again, this happens later after you have already provisioned to AD when the objectSID from AD is set on the ResourceID in the FIM Portal. This happens on the MIM MA export. So, check your requests log to verify that the MPR is getting applied and the workflow is firing.
I hope you can get it working!
Matt
So, after last iteration I have:
1. Deleted Initial flows from “User’s outbound sync rule”
– pwdlastSet ->0 when it was deleted nothing changes, so when it is setted in PowerShell code it’s OK.
– P@ssw0rd -> unicodePwd – when my users firstly exported to AD they get this password and enabled account. At second stage they get random password and email to manager.
2. Accounts are created in AD in disabled state and manager don’t get email.
How I can understand what my MPR is not applyed?
Thanks for help!
Hello!
After some testing I disabled and enabled my MRP to see if there are any requests in log.
So, what I foud:
1. If I use your guide and create “request” type MPR it is not applied (disable and enable, no requests).
2. If I use a “Transition In” type MPR and disable and enable policy – it works.
So, maybe it would be better to use “Transition In” MPR? What do you think?
I’m using a “static” list of test users with direct choose with employeeID. In prod I will use dynamic list.
That’s strange that the Request MPR is not working. Did you validate that the Resource SID attribute is getting populated on the account in FIM? It’s at that time when the MPR would apply. The resourceSID for an account is synced in from AD. By configuring in this manner, you can be assured that the account has been provisioned in AD and then the Workflow can run that will set the initial password. I suppose you could do a set transition MPR by adding people to the set when Resource SID attribute is getting populated in FIM.