How to validate users with the Microsoft AD spoke so as to not get in trouble with Security audits

[Royal Sirrine]

We are looking for some suggestions on using the AD Integration spoke for resetting passwords. 

Background: I feel it is important to give some context here to avoid extra questions if possible (is it though?)

Our company has several domains.

• Our primary domain which is tied to our email and ServiceNow instance
• We have several other independent domains (owned and managed by us) that are for our clients we provide a service to
• Our primary domain and these client domains do not interact

Challenge: Currently we get aprox 1600 service requests to reset passwords every quarter. These tickets land in our Service Desk queue and they are using a tool to reset and unlock. We are working to use the AD spoke to automate this process in the client domains to reduce this ticket load and only create a ticket if the automation fails. 

Status: We were able to successfully link one domain to the Mid Server. We created a test catalog item in our DEV instance. The catalog is currently asking for the following fields

• Requested For - Tied to the ServiceNow User
• User Account name to be reset
• Domain the account resides
• Special notes

Workflow does the following: Generates a random 12 value secure password. Validates user exists in the domain. Check to see if the account is locked and if yes, unlocks it. Resets the password. Updates the RITM with the actions performed and sends a email with the new password to the value of the Requested For. (This is where red lights go off) If any of the actions fail, it creates a SCTASK for the Help Desk. All these actions have been tested and work.

Problem: As you can already guess, ANY user could request a password to be changed for any user as long as they k the account name (which based on naming conventions isn't hard). Doing so, they would get a new password and gain access to the u account. This is a big security risk! So, how do we put controls around validating that the user requesting the password to be reset is the actual user that exists in a completely different domain t the one used against the u account in ServiceNow? 

Some thought was put around doing a lookup against the email address tied to the users account in the domain and emailing the password to that users email. IE: If the user account is Joe.Smith@hero.com (client domain) and the email on the account is Joe.Smith@masters.com (primary account tied to ServiceNow) then email to that email address. However, adding the alt email address was not always a requirement so not all accounts have that field populated on the 1000's of accounts that may e in each domain. We also discussed possibly sending the email if the email exists and creating a ticket if it doesn't and cleaning up as we get them. (not ideal but possible). 

We would love some feedback on this. There are other tools such as OKTA that have tools that prompt for Security questions, but we only have OKTA tied to one of the many domains and does not solve the big picture issue.

Thx to everyone!

[Royal Sirrine]

Seeing the lack of views or lack or responses, I am trying to understand if this spoke is not well used or those that do, dont have this issue as they only have one domain they support?

[nick135]

We built a similar catalog item for password resets. we addressed this issue by forcing the password reset action to take place on the user opening the request. so we used the opened_by field in lieu of requested_for. that way they even if they do try to reset another users account, they will reset their own by default.