Password Reset Application

Jim Coyne · ‎08-13-2014

Anyone try using the new Password Reset application in Dublin / Eureka? I was wondering how easy it is to integrate with AD. How long did it take to get up and running? Pros? Cons? Any hidden issues?

I'm also wondering if the "Password Reset - Orchestration Add-on" requires the Orchestration plugin as well. I would assume so, the wiki does not explicitly say so, but I don't like to assume anything with SN licensing anymore.

Thanks

Jim

TrevorK · ‎08-19-2014

One of the challenges we found with the AD Password Reset is that, using the built-in ServiceNow workflow items, the account needed to be a Domain Administrator (which our AD Team would not allow). We ended up having to develop our own powershell command to do the password reset on the MID Server, rather than using the SN way of calling out to the DC. Not hard, but frustrating. It appears that those who do Discovery had the same sort of issues when I did a search at the time.

You can do the AD Password Reset without Orchestration as far as I recall when you write your own commands to work with the Powershell probe on the MID Server. We had to do this and I seem to recall thinking that it is a loophole or something, because you can write everything through the MID Server without much trouble.

One other thing we also found is that the ServiceNow SMS feature did not text to phone number, it texted to 11122233333@att.com, and thus required the carrier information to be present. We ended up just coding a call to Twilio, which was easy enough, and it handles the text to phone number (as our phone numbers sync from an external system).

We really found it was shoe-horning ServiceNow into a world where we could perform the tasks we need much better without ServiceNow (we need to share data with ERPs), and just use a web service to feed the data into ServiceNow about what is being done (failed attempts, successful attempts, etc). I also seem to recall that SN had a Password Reset app (above and beyond Orchestration) but you paid a monthly fee for each user in your system, and with 180,000+ users, that was not going to work too well for us.

I am using words like "I recall" and a lot of past tense because we are going a different route for password reset. But I have it all developed (without the use of Orchestration workflow items even though we have Orchestration) and such in our instance to demo the functionality of it.

Oh - I should also state I have only used this in Dublin/Calgary, not Eureka. We do not have that loaded yet.

Hopefully that helps. As you can tell, sometimes I ramble on too much.

View solution in original post

TrevorK · ‎12-10-2014

Sorry Shyama, I have not had time to compile something that encompasses everything. I will keep working on it and let you know when I can get to it.

azenith_moreno · ‎03-03-2015

Hi Trevor,

I know this thread is a bit old but i was hoping you can help me because we are planning to do the password reset thru servicenow as well that might be of the same approach as what you have mentioned on this thread.

You mentioned that you went on a route of developing a custom web app to accomplish this... would you mind providing some more details on this one? Is the custom web app developed outside SN?

We have an orchestration activated on our instance and we are planning to develop a custom web app as well which holds the information needed for the password reset such as the usernames, etc and after that SN will then get the information from the custom web app and process the reset via Orchestration within SN......

Sorry as i'm not yet an expert when it comes to linking outside websites to SN ,

Hoping you can give some advice on how to go with this.

Thank you.

TrevorK · ‎03-03-2015

We explored three different paths: Password Reset using Orchestration, Password Reset without using Orchestration and an external application that does the password reset and just feeds the data into SN (to create tickets).

Password Reset using Orchestration was a no-go for us. One of the requirements was that the Active Directory account needed to do this had to be a Domain Administrator (our AD people could not figure out a way to parse out the permissions any other way). Orchestration required the use of the domain controller and we were denied an account with Domain Admin permissions that was needed.

Password Reset without using Orchestration worked fine, but the people who saw the demo decided that the 15 -30 second wait for a password reset was too long (that was the main reason I was given). I am also unsure if they wanted our group (SN group) to take on the responsibility of securing an application with such a large potential risk. We just used the MID Server for this and executed the powershell commands on the MID Server itself (so we did not need an account with Domain Admin permissions).

External applications that does the password reset and just feeds the data (when, who, failed/success, date/time, etc) into SN is the route we went. We explored buying the functionality from SN (their actual app, not just orchestration), but with the text messaging integration (which was another add-on) it was very cost prohibitive (we are a post-secondary institution and have hundreds of thousands of accounts). One of our .NET gurus developed a simple web application that asks for the personal information, verifies it against the PeopleSoft database (our source of personal information), then sends a text message/voice call/email with a PIN. The user then enters the PIN and reset the password. It functions just like most other big player's password reset applications. Again, the only use SN serves in this instance is to host the data captured during the password reset for the pure purpose of security reasons. It plays no role in the verification of user data and is merely a storage centre where we can run logic against it to detect potential security risks or areas of improvement (for example, I think we identified that people were using the wrong "ID" in the field based on the failures).

One piece of advice I can give is to look for the best solution, not just the best solution using ServiceNow. I was a little dejected when my password reset app in SN was deemed too slow/not good enough, but when I sit back and see the application that was developed through .NET I can definitely see it was the right way to go. Seeing pieces of the code during our development meetings showed it was relatively easy to develop and leveraged a lot of libraries and such. A password reset application is an enterprise wide application with large potential for security concerns (especially with social engineering attacks and such) so it should receive a lot of scrutiny when coming up with a solution, as opposed to someone just making a meeting room booking application or service catalog items.

If you have any further questions or just want to talk about it further, feel free to message me. I can also chat over email and such too.

james_owen · ‎03-10-2015

Thanks Trevor. The reset taking too long is great feedback - We've added a story to our backlog and are planning to speed it up in a future release.

Regards,

James

moses5 · ‎03-13-2017

Hello Trevor,

We just implemented SN password reset without a Domain admin account. We used a service account that was only given enough rights to reset user password.

Regards

Moses