Introduction
The Self-Service Password Reset has got to be one of the most used features of RES ONE Identity Director (previously RES ONE Service Store/RES IT Store). It allows a user to reset his/her Active Directory user account password without assistance from the IT organization. This is possible on a 24/7 basis, so even in the evening or the weekends the user can use this service.
While this is very useful service, you should think about the security implications. Since the user apparently cannot login the RES ONE Identity Director site he/she should be to open the site from an untrusted network like the internet. But this would imply that everyone with internet-access can change the password of a user account as long as the username is known. So how to verify that the user requesting the service is actually the user in question?
2. Explaining password resets in RES ONE Identity Director
Now I’m not going to specify how you should secure the website itself (Tip: Use a NetScaler and maybe use some SmartAccess functionality to check the endpoint if it is compliant) but rather on how to verify the user.
RES supplies a working ‘password reset’ building block for RES ONE Identity Director in the RES Success Center as well as a blog on how to implement it (Link). Their solutions relies on the use of the user’s private e-mail address. The user should have provided this earlier when they were still able to login. In earlier methods a new password would be generated and sent to the private e-mail address. The user can use this password to login and afterwards change it to something else. The current method allows the user to specify a new password directly and the private e-mail address will just be used to provide a confirmation link to the user.
Now this is a fine solution, but in both described methods you are relying on the private e-mail address being secure enough for your company’s security standards. Since the user can supply the address themselves it could even be an e-mail address on a lab environment. Of course you could create a compare workflow action of some sort to only accept certain e-mail providers, but this won’t be very user friendly in my humble opinion. Also, the user will need to login to RES ONE Identity Director to register their private e-mail address before they can use the ‘reset password’-service.
Back to the user verification, what other ways are there? Maybe security questions? This method would also require the user to supply the correct answers beforehand.
For a customer I have been looking into user verification with SMS. Since the mobile number of the users are usually registered at some place, why not use these? The customer in question has the mobile number registered in the appropriate attribute in Active Directory. So it was an easy configuration change to the Data Source and Data Connection in RES ONE Identity Director to add a People Attribute or People Identifier for the mobile number and fill it with the information from Active Directory.
3. Description of the Services
On to the SMS verification. First of all: I have created building blocks of the two services we use for this solution (download link below).
We are using two services, one for the SMS verification and the other for the actual password reset. Each service has an accompanying RES ONE Automation Run Book. I will describe the attributes of these services and the Run Books. Afterwards how you can import the building blocks to your own environment (at your own risk of course ;-)). Now I have tried to keep all the Variables/Parameters/Attributes in RES ONE Identity Director or in the RES ONE Automation Global Variables. This way the Run Books and Modules themselves are virtually ‘configuration-free’.
For the SMS service we are using the excellent Nexmo SMS Messaging service (https://www.nexmo.com/products/sms). You can create an account for free with €2 credit to send SMS (in the Netherlands, each SMS is about 8 cents, so that should give you some room for testing). If you want to use this for production you would need to add funds to your account. This will also remove the demo notification in the SMS. If you have another way to send an SMS through a script of some sort than that is also fine of course. You could even use an Android phone that is connected to a PC/server with an RES ONE Automation agent and send the SMS with an ADB (Android Debug Bridge) script.
4. Description of the Service attributes and Run Book parameters
SMS verification
Identity Director Service:
Self-Service Password Reset – SMS verification attributes:
– Sender
Supply the name/text/number that should be shown as ‘Sender’
– Mobile Number
Link this attribute to the created People Attribute/Identifier.
(I’m describing this with the assumption that you have this attribute/identifier setup already so that it exists and has a value!)
– Target Automation Agent
On which machine/agent should the Run Book be executed? No exotic requirements here.
It just needs PowerShell and an internet connection.
– Text
Should there be an accompanying text along the SMS?
– Verification code
The verification code that will be sent. I’ve used the native RANDOM function here.
It will choose a random number between 10000 and 99999. Just change this to something
more to your liking.
Automation Run Book:
Send verification SMS parameters:
Sender, Mobile Number, Text, Verification code, RunBookWho
All these parameters are provided by RES ONE Identity Director.
Global Variables:
Nexmo SMS APIKey
API Key that belongs to your Nexmo account.
(This key is provided on the site and can be changed.)
Nexmo SMS APISecret
API Secret
(This ‘password’ is provided on the site and can be changed.)
Reset password
Identity Director Service:
Self-Service Password Reset – Reset password attributes:
– @NoReply
Source e-mail address for the mail to inform the user of the password change
– ActiveDirectoryUsername
Linked to the ‘Windows user account’ People Identifier
– NewPassword
Password attribute which is provided by the user in the delivery workflow.
– Target Automation Agent
On which machine/agent should the Run Book be executed? No exotic requirements here.
It just needs PowerShell. It will install the Active Directory PowerShell tools if needed.
Automation Run Book:
Self-Service Password Reset parameters:
Username, NewPassword, RunBookWho
All these parameters are provided by RES ONE Identity Director.
Global Variables:
Active Directory Management Account
Active Directory account with enough rights to change passwords for user accounts.
5. Importing the building blocks – RES ONE Automation
Now what to do after the import of the building blocks?
We will begin with RES ONE Automation:
Node Library -> Variables:
– Supply the values for the Active Directory Management Account and Nexmo SMS variables.
6. Importing the building blocks – RES ONE Identity Director
And on to RES ONE Identity Director:
I would advise to use the option ‘Evaluate step-by-step with the option to map to existing objects’ to use the People Identifiers and Attributes you already have in your environment if they exist. If you don’t the import process will create duplicate objects of them.
7. Configuring the services
After the import you would need to do the following:
Service Self-Service Password Reset – SMS verification:
Tab Attributes:
– Supply the values for Sender, Target Automation Agent and Text.
Tab Properties:
– Enable the option ‘Enable transactions’ (if not done during import).
If you chose the option ‘New GUIDs’ during the RES ONE Automation import you would also need to reconfigure the Invoke Run Book action to point to the correct Run Book and set the correct parameters. So that would mean the following:
Tab Workflow:
Delivery action Invoke Run Book:
– Choose Send verification SMS Run Book
– Set Run Book parameters to:
Sender -> #Service[Sender.Value]
Mobile Number -> #Service[Mobile Number.Value]
Text -> #Service[Text.Value]
Verification code -> #Service[Verification code.Value]
RunBookWho -> #Service[Target Automation Agent.Value]
Service Self-Service Password Reset – Reset password:
Tab Attributes:
– Supply the values for @NoReply and Target Automation Agent.
Tab Properties:
– Enable the option ‘Enable transactions’ (if not done during import).
When using the ‘New GUIDs’ option during RES ONE Automation import:
Tab Workflow:
Delivery action Invoke Run Book:
– Choose Self service password change Run Book
– Set Run Book parameters to:
RunBookWho -> #Service[Target Automation Agent.Value]
Username -> #Service[ActiveDirectoryUsername.Value]
NewPassword -> #Service[NewPassword.Encrypted]
8. Choose the imported services as password reset method
The last thing to do is specify the imported services in the Password reset configuration of your RES ONE Identity Director environment:
Setup -> Password reset
Tab General
– Enable the option Web Portal logon screen.
– Set the correct People identifier.
– Specify the Self-Service Password Reset – Reset Password service.
– Set the Password attribute to NewPassword.
– Set the Password complexity hints if you like (See the Admin Guide for examples).
– Change the messages if you like.
Tab Verification code
– Enable the Verification code validation.
– Specify the Self-Service Password Reset – SMS verification service.
– Change the messages if you like.
And of course, don’t forget to save the changes. After that you should be good to go.
Be sure to test the process and I would also advise to inform your users about the new method and supply some sort of password reset guide for it.
So that’s it for this blogpost. Feel free to alter it to your own wishes or use parts of it for other services. If you have any suggestions, improvements or complaints, feel free to contact me about it. Also credits to Jacob Ludriks (blogsite) for his ‘Send-NexmoSMS‘ PowerShell script.
Building blocks:
