Runbook Automation (RBA) and Active Directory (AD) password reset - Thoughts? Experience?

[TrevorK]

We are looking into purchasing Runbook Automation (RBA) and one of our immediate projects will be to develop methods for users to reset their Active Directory (AD) password. We have not purchased it yet so I cannot play with it but I'd like to gather some thoughts on the business processes around it so that we can start working on the logic/process behind it.

What sort process are you using for your password resets? Do you require a personal email address and email them a temporary password? Cell phone number and text them a temporary password? How do you verify the user's identity (we use SSO so it's not like they can log into SN or anything)?

We are going to be starting from nothing so requiring and gathering a personal email address/cell phone number is a daunting task in itself, especially because in our environment many staff do not have a personal email account (or a computer outside of work).

Any thoughts, comments or experience with this?

[hartr]

I'd be interested to know about this too If anyone has any input ..

[randrews]

we have both runbook and AD integration.. we haven't worked on a pw reset yet but have considered it...

first problem is that the pw reset toy would have to be on the splash page, not in the service catalog so you would have to be able to work in an item that calls scripts from there.... this also means you need to be able to send the customer a password without them being logged in, and means a whole new set of issues how do you validate they are the right person without having their pw? In my history security questions rarely work.. as the customers never remember what they put in...

now that i think about it.. i would think in Calgary you could use the app builder to build your own security question tool and allow them to set their security questions from inside of SF... then use that to validate them and trigger the pw reset.. you could even trigger a periodic email to set security questions if they hadn't used it yet.

what we settled on was putting the service desk phone number on the splash page, this seems like the best solution for us since the service desk is a 24/7 shop...

[mike_smith]

There are a few ways to handle this. I've had 2 clients do it 2 different ways.

1. Enrollment of a secondary email address.
2. Security Questions

The secondary enrollment process would send an email after you enrolled with a unique URL/MD5 hash combo and we did a processor to validate when received/clicked. Doesn't sound like this will work for you since you mention that a number of users do not have computers outside of work.

The security questions/answers may work well for you. Define a global set of questions that users can pick from. Ensure they answer say 5 questions to seed the pool of questions upon requesting a password reset. Dynamically pull 2 questions from the 5 so they aren't always getting the same question. After successfully answering the questions you display the temporary password and kick off a backend workflow to actually do the reset. This workflow should set the flag to force users to change password at 1st login.

With both we had a UI Script & Script Include that would check for a certain session variable. If not set, force the users to the enrollment page.

Hope that gives a little bit of insight...

Mike Smith