Is it possible to pre-register a user's One Time Password on the initial account creation process? I have populated the email address to the FIMMA msidmOneTimePasswordEmailAddress attribute. What I need to do now, is register this email address. I know you can pre-register thru the new PowerShell cmdlets but I'd like to do this when an account is provisioned.

What specifically do you mean by "register this email address"? Provided you have exported a value to the one-time email address and configured OTP email in read-only mode within the password reset authn workflow, all that remains is for the user to enroll for security questions.

I want to have the OTP email address I exported to msidmOneTimePasswordEmailAddress to be pre-registered so the user does not have to register to be able to reset their password. I have configured the OTP email as read/write in the OTP gate. Maybe that's my issue, that it needs to be read-only. Don't know why this would make a difference but I'll give it a try. Not using the QA gate.

A powershell workflow or powershell MA should help.http://www.wapshere.com/missmiis

Are you referring to something like http://fim.codeplex.com/releases/view/69375? Is PowerShell the only way to pre-register a user for Password Reset?

Are you referring to something like http://fim.codeplex.com/releases/view/69375? Is PowerShell the only way to pre-register a user for Password Reset?

Well I'm only just starting to go through the docs myself but Register-AuthenticationWorkflow seems to be what you want. So you have to find a way to run it for each user. Tying it to provisioning with a powershell custom activity or powershell extensible MA would be a nice way to do it - but actually it would be probably a lot easier just to periodically run an out-of-band powershell script.There is another cmdlet called Confirm-AuthenticationWorkflowRegistration which you may be able to use to check who needs to be registered.http://www.wapshere.com/missmiis

Well I'm only just starting to go through the docs myself but Register-AuthenticationWorkflow seems to be what you want. So you have to find a way to run it for each user. Tying it to provisioning with a powershell custom activity or powershell extensible MA would be a nice way to do it - but actually it would be probably a lot easier just to periodically run an out-of-band powershell script.There is another cmdlet called Confirm-AuthenticationWorkflowRegistration which you may be able to use to check who needs to be registered.http://www.wapshere.com/missmiis

Bloody hell... I'm going to do the same in a few months I think. I was more or less hoping that just flowing an e-mail adres to that attribute would be enough :) I just browsed a bit in an empty FIM instance. I'm not sure whether this would work, but I would definately try it: create a request MPR which triggers a workflow on the modification of the OTP-email attribute. The workflow I'd use would be the "System Workflow Required for Registration". Don't you think this would give the expected result? I'm all for PowerShell magic, but I like to keep things as simple as possible :) Kind regards, Thomashttp://setspn.blogspot.com

Bloody hell... I'm going to do the same in a few months I think. I was more or less hoping that just flowing an e-mail adres to that attribute would be enough :) I just browsed a bit in an empty FIM instance. I'm not sure whether this would work, but I would definately try it: create a request MPR which triggers a workflow on the modification of the OTP-email attribute. The workflow I'd use would be the "System Workflow Required for Registration". Don't you think this would give the expected result? I'm all for PowerShell magic, but I like to keep things as simple as possible :) Kind regards, Thomashttp://setspn.blogspot.com

There's a Technet article about programmatic user registration, although the details on how to use the FIMAutomation PowerShell snap-in are spotty (i.e., never have I seen any details about how to tell the snap-in how or where to connect to the FIM Service... does that mean it has to run on the same host as the FIM Service?) (Edit: The -Uri argument using value 'http://fimservice:5725' does the trick.) From a security perspective, I can't recommend removing the security questions altogether--they serve as a useful gate to prevent using the FIM Service to spam users with spurious password reset messages, if nothing else.

There's a Technet article about programmatic user registration, although the details on how to use the FIMAutomation PowerShell snap-in are spotty (i.e., never have I seen any details about how to tell the snap-in how or where to connect to the FIM Service... does that mean it has to run on the same host as the FIM Service?) (Edit: The -Uri argument using value 'http://fimservice:5725' does the trick.) From a security perspective, I can't recommend removing the security questions altogether--they serve as a useful gate to prevent using the FIM Service to spam users with spurious password reset messages, if nothing else.

Well, this is very interesting. What I thought would be a fairly straight forward process within FIM doesn't look like it. I have looked at the AuthenticationWorkflow cmdlets and they work as specified. The only issue there is, I don't see how I can extract the required user information (OTP Email Address) from FIM to input into the PowerShell cmdlet. I thought maybe the Get-FIMResource cmdlet might help but that doesn't seem to retrieve all the attributes. I need to retrive the OTP Email address for the specified user so that I can use the Register-AuthenticationWorkflow cmdlet. Carol, the PowerShell workflow looks very interesting. I have set it up in my test environment but I'm not sure how to debug it as I not getting the desired result. Any words of wisdom on how to debug the PowerShell script in the workflow?

Well, this is very interesting. What I thought would be a fairly straight forward process within FIM doesn't look like it. I have looked at the AuthenticationWorkflow cmdlets and they work as specified. The only issue there is, I don't see how I can extract the required user information (OTP Email Address) from FIM to input into the PowerShell cmdlet. I thought maybe the Get-FIMResource cmdlet might help but that doesn't seem to retrieve all the attributes. I need to retrive the OTP Email address for the specified user so that I can use the Register-AuthenticationWorkflow cmdlet. Carol, the PowerShell workflow looks very interesting. I have set it up in my test environment but I'm not sure how to debug it as I not getting the desired result. Any words of wisdom on how to debug the PowerShell script in the workflow?

Hi, I'm just starting to figure this one out too, but if you don't want the user to answer questions and therefore only want to use the email OTP gate, I think you only need to set the 'AuthN workflow registered' on the user, like so: Once you've done that, be sure to verify if the user can reset without registration. If that is the case, you can create a workflow which sets this attribute. I'm going to work on this myself tomorrow, so I maybe able to give you an update on that in time. Best regards, Pieter.Pieter de Loos - Consultant at Traxion (http://www.traxion.com) http://fimfacts.wordpress.com/

Hi Pieter, Just tested this and you are correct. I had populated the OTP email attribute already. I added the 'Password Reset AuthN Workflow' to the 'AuthN Workflow Registered' and I was able to reset the user's password without pre-registering. I just need to create the workflow now to set the attribute. I'll let you know how that goes. Thanks, Bruce

Setting AuthNWFRegistered directly is not supported (though it might work) The only supported way to to register a user for SSPR is to use the powershell cmdlets as part of R2The FIM Password Reset Blog http://blogs.technet.com/aho/

Certainly defeats the whole purpose of FIM, having to use a PowerShell script outside of the FIM process. Anyway, for others that are interested, here is a script that can be used to get all unregistered users in FIM and register them. This script is from http://social.technet.microsoft.com/wiki/contents/articles/3616.how-to-use-powershell-to-export-all-users-who-have-registered-for-self-service-password-reset-sspr-en-us.aspx with the addition of the Register-AuthenticationWorkflow command. If ((Get-Variable URI) -eq $Null) {set-variable -name URI -value "http://localhost:5725/resourcemanagementservice' " -option constant} If ((Get-Variable CSV) -eq $Null) {set-variable -name CSV -value "RegistredResetPassUsers.csv" -option constant} clear If(@(Get-PSSnapin | Where-Object {$_.Name -eq "FIMAutomation"} ).count -eq 0) {Add-PSSnapin FIMAutomation} $WFDFilter = "/WorkflowDefinition[DisplayName='Password Reset AuthN Workflow']" $curObjectWFD = export-fimconfig -uri $URI onlyBaseResources -customconfig ($WFDFilter) -ErrorVariable Err -ErrorAction SilentlyContinue $WFDObjectID = (($curObjectWFD.ResourceManagementObject.ResourceManagementAttributes | Where-Object {$_.AttributeName -eq "ObjectID"}).value).split(":")[2] $Filter = "/Person[not(AuthNWFRegistered = '$WFDObjectID')]" # Add any other filter requirements $curObject = @(export-fimconfig -uri $URI onlyBaseResources -customconfig ($Filter) -ErrorVariable Err -ErrorAction SilentlyContinue) [array]$users = $null If ($curObject.Count -gt 0) { foreach($Object in $curObject) { $ResetPass = New-Object PSObject $UserAccountName = (($Object.ResourceManagementObject.ResourceManagementAttributes | Where-Object {$_.AttributeName -eq "AccountName"}).Value) $UserDomain = (($Object.ResourceManagementObject.ResourceManagementAttributes | Where-Object {$_.AttributeName -eq "Domain"}).Value) $UserOTPEmailAddress = (($Object.ResourceManagementObject.ResourceManagementAttributes | Where-Object {$_.AttributeName -eq "msidmOneTimePasswordEmailAddress"}).Value) $ResetPass | Add-Member NoteProperty "AccountName" $UserAccountName $ResetPass | Add-Member NoteProperty "Domain" $UserDomain $ResetPass | Add-Member NoteProperty "OTPEmailAddress" $UserOTPEmailAddress $Users += $ResetPass $template = Get-AuthenticationWorkflowRegistrationTemplate AuthenticationWorkflowName Password Reset AuthN Workflow $usertemplate = $template.Clone() $userTemplate.GateRegistrationTemplates[0].Data[0].Value = $UserOTPEmailAddress Try { Write-Host "Processing account $($UserAccountName), OTPEmail: $($UserOTPEmailAddress)" Register-AuthenticationWorkflow -UserName "$($UserDomain)\$($UserAccountName)" -AuthenticationWorkflowRegistrationTemplate $userTemplate -ErrorAction SilentlyContinue } Catch { Write-Host "ERROR" "Registering object." } } $users | Export-Csv -path "$($WorkingFolder)\$($CSV)" -NoTypeInformation }

i'm looking into this scenario... how do you map msidmOneTimePasswordEmailAddress? When I check the attribute in FIM MA it's being displayed in data source objects, not in metaverse. i dont get it. its the way its supposed to be, if so how do i flow it into fim?

That's how FIM works eh... You've got to choose for your self to what you want to map that. Take this example: you want to import the Account Name from AD to the FIM Portal. * In the AD MA it will be called: sAMAccountName * in the MV you map it to accountName, however you could also create a new MV attribute called: userID * In the FIM MA you map it to AccountName Each MA has its own set of attributes. And you can reuse, or add new, attributes in the MV as per your requirements... Does that makes things more clear?http://setspn.blogspot.com

thats pretty clear but shouldn't msidmOneTimePasswordEmailAddress be a MV attribute not Data Source? How can I possible flow in INTO FIM if its not displayed in MV attributes? so the scenario looks like this: SQL database - custom attribute named OTP should flow into MV as msidmOneTimePasswordEmailAddress and flow into FIM Portal. right?

The msidmOneTimePasswordEmailAddress attribute is something which the Password Reset solution, which is based upon/talks with the FIM Service, uses. In "normal" scenario's you would populate this value by letting the user register himself. You don't even need this value in the MV. If you want to prepopulate it. I would say that somewhere you have an external source with an attrbute called "email". You could flow this to the MV attribute email. And this email in the MV could be flowed to the msidmOneTimePasswordEmailAddress attribute. If you want to have a distinction in the MV between the user his regular email and the one used for SSPR. Then you could add a custom attribute in the MV called OTPemail (an example).http://setspn.blogspot.com

I still dont get it. I have a FIM MA, I configure it to allow for msidmOneTimePasswordEmailAddress to flow. so for example I map it to OTPemail custom attribute I created on portal and mapped to user (right?) what next? I flow it into FIM? or what? And if msidmOneTimePasswordEmailAddress is NOT stored in MV, where is it stored? where should I sync it to? To portal? what should I map it to in that case? Sorry if I sound really wrong or stupid, I just cant get the idea...

oukey, it appears i'm a tad bit retarded today. i finally managed to get it, sorry. I was thinking completely the opposite of how it is.

no problem :) glad you sorted it out.http://setspn.blogspot.com