• Glen (Xapity)

Password Reset via Self Service Portal


Password resets are one of the most common requests for a Service Desk. This post outlines how the Service Manager Portal (SCSM SSP) can allow users to reset a password on behalf of another user.


Password Reset Requirements

The requirements for this solution are:

  • End User initiated (no Help Desk involvement)

  • Requestor will have to acknowledge that they are not maliciously resetting a user's password and\or accept legal requirements

  • Audited rather than Approved - no approval speeds the process up, uses Service Manager auditing (History tab)

  • Random password generated (otherwise a simple password is used or the same password is used each time)

  • Password must be changed at next logon by the user

  • Unlock user account if it is locked

  • Email to Requestor with the new password

  • Email to User getting password reset informing them that there password was rest

Optional: More checking and Security

The requirements highlight the problem with any Password Reset process - a person could use it to maliciously reset a password to log on as that user and do nasty stuff. How to manage this risk will depend on your organisation and the security vs convenience trade off.

An optional enhancement is to use two groups to control the process:

  • User Group - list of users that opt in to allow their password to be reset

  • Requestor Group - list of users who can reset a password of any member of the User Group

The example script that can be downloaded has an example of this logic that has been commented out.

Some other options that would increase security and would probably require more checks in the PowerShell script:

  • Only allow the Help Desk to use the tool

  • Email the User's manager the password

  • Only allow the Requestor to reset employees that direct report to them

  • Require an approval step

  • Provide a second Password Reset Request Offering for VIP's - use different groups or use approval process

Prerequisites

The prerequisites for this solution are:

  • Extend Service Request - add Boolean (True/False) Property Only required if Legal Acknowledgement is needed

  • Xapity PowerShell Activity Or use Orchestrator Runbook

  • Xapity Notification Activity Or use email subscription

Steps To Create a Password Reset Solution

  1. Create a PowerShell Script in the Central Script Library - Password Reset. Download script.

  2. Create two email templates based on the Service Request work item. See the examples below. The exact content will depend on your requirements.

  3. One template for the Requestor that will contain the new password

  4. The other for the User notifying them that their password was reset

  5. Create a new Service Request Template. The SR will contain the following:

  6. Xapity PowerShell Activity that does the password Reset. Use the script created above.

  7. Xapity Notification Activity - email to the Requestor with the new password. Use the email template from above.

  8. Xapity Notification Activity - email to User that their password was reset. Use the email template from above.

  9. Create a Request Offering

  10. Use the SR template from above

  11. Add a True/False prompt to acknowledge the legal requirements of resetting a password. In the Prompt section put the legal txt as required.

  12. Add a Query prompt. This is where the user to reset is chosen

  13. Configure the Query to use AD User and display the fields of your choice

  14. Configure the Query to store the relationship with the SR

  15. Publish the Request Offering

  16. Configure a Password Reset Service Offering (or use an existing offering)

  17. A new Service Offering will allow a custom description and title

  18. Publish the Service Offering

The solution uses the Xapity PowerShell and Xapity Notification Activities, but could be configured to use Orchestrator (with slight modification to the script) and email subscriptions.

User and Requestor

The User in this example is the person that requires their password reset.

The Requestor is the person who is submitting the Password Request.


Requestor Email Notification

Both the Requestor and the User will recieve email notifications about the password reset. Optionally you could include the Help Desk or Security Team as well.

The Requestor will get an email with the randomly generated password. This is a one time password that needs to be changed by the user when they first log on. The length of time it takes for the email to appear will depend on your environment - how long will depend on how fast activities run on the service request.

The email has been sent using a Xapity Notification Activity, with a standard Email Notification Template. A subscription could have been used instead of the Notification Activity, but the Notification Activity works in the context of the Service Request and does not need a trigger point.

The PowerShell code for the random password and phonetic characters comes from Simon Wahlin and can be found at these locations:

The function to convert the password into Phonetic letters I thought was pretty cool, so I incorporated it into the requester email below (it is stored on the description field of the SR).


User Email Notification

The User will also get an email informing them that their password has been reset.


Request Offering SR Template

The Service Request template used by the request offering has the Title, Urgency, Priority and Source set. The description field will be used to store the Password details and this makes it easier for the Requestor email notification.


The real work is being done in the activities workflow. Because we have the Xapity PowerShell Activity there is no need to go out to Orchestrator (although that would also work as well).

We then have two Xapity Notification Activities to send out the Requestor and User emails.


PowerShell Activity

The PowerShell Activity calls the PowerShell script that is outlined below. It is the first activity in the workflow and it does all the work.

The PowerSjhell Script will:

  • Changes the Affected user

  • Generates and resets the Password

  • Updates the SR Title and Description


Notification Activities

There are two Xapity Notification Activities that are based on the Service Request and send out the email notifications to the Requestor and to the User.

When the User Notification activity runs the Affected User will be the User (rather than the Requestor), as the PowerShell script changed this.The recipient is the Affected User.

On the Requestor Notification Activity we can use the Created By user as the recipient as this does not change.


The actual templates can have whatever information that you think is appropriate. The PowerShell code places the password in the description field of the SR and this is used in the Requestor email. The User email does not have much detail - the ID, Title and Created By user to tell them who submitted the Password Reset request.

PowerShell Script Details

Download the PowerShell script.

The paragraphs below explain the main points of the script.

Portal - Log on Behalf of

The out of the box Portal does not have log on behalf of option, so the affected user will be the Requestor. This is not how we want it, so we will change the affected user to be the selected User and add the Requestor in as a related CI. See the previous post PowerShell for SCSM: Portal Requests on Behalf of Another User for more detail.

The first step will be to take the User selected on the request and make them the Affected User. We will also take the Requestor and add them as a related Configuration Item. We will also update the Action Log on the SR with each action taken. See the previous post PowerShell for SCSM: Updating the Action Log for more detail.

#Remove the existing Related Config Item User relationship

Get-SCRelationshipInstance -Source $ParentObject | ?{$_.RelationshipId -eq $ConfigItemUserRelClass.Id} | Remove-SCRelationshipInstance

Add-ActionComment -Id "$ParentID" -ActionType "TaskExecuted" -Title "Removed Related Config Item" -Comment "Removed related Config Item $($UserObject.DisplayName)" -EnteredBy "PowerShell Task"

#Set new Affected User of the SR

New-SCSMRelationshipObject -RelationShip $AffectedUserRelClass -Source $ParentObject -Target $UserObject -Bulk

Add-ActionComment -Id "$ParentID" -ActionType "TaskExecuted" -Title "Changed Affected User" -Comment "Changed Affected User to $($UserObject.DisplayName)" -EnteredBy "PowerShell Task"

#Add new Related Config Item User to the SR

New-SCSMRelationshipObject -RelationShip $ConfigItemUserRelClass -Source $ParentObject -Target $RequestorObject -Bulk

Add-ActionComment -Id "$ParentID" -ActionType "TaskExecuted" -Title "Added Requestor to Related Config Item" -Comment "Added related Config Item $($RequestorObject.DisplayName)" -EnteredBy "PowerShell Task"

Functions New-RandomPassword and Get-Phonetic

The PowerShell code for the random password and phonetic characters comes from Simon Wahlin and can be found at these locations:

The random password function allows you to control the complexity of the password and the characters that can be used to generate the password. I have simplified it slightly to make it easier for the users to read and type. I would suggest removing characters that are confusing or hard to type or pronounce.

Reset the password, Unlock Account

The next section resets the password using the random password created by the function. It then sets the account to require a new password and unlocks the account if required.

Set-ADAccountPassword -Reset -NewPassword $SecurePassword -Identity $($ADUserObject.SamAccountName) -PassThru -Confirm:$false

Write-Host 'Password reset successfully'

Set-ADUser -ChangePasswordAtLogon $true -Identity $($ADUserObject.SamAccountName) -Confirm:$false

Write-Host 'Change password at logon set to True'

Add-ActionComment -Id "$ParentID" -ActionType "TaskExecuted" -Title "Reset Temporary Password" -Comment "Reset password for $($ConfigItemUser.DisplayName) and set must change at next logon" -EnteredBy "PowerShell Task"

# Unlock Account if required

If ($ADUserObject.LockedOut -eq $True)

{

Unlock-ADAccount -Identity $ADUser -Confirm:$false

Write-Verbose -Message 'Useraccount unlocked' -EnteredBy "PowerShell Task"

}

Else

{

Write-Host 'UserAccount is already Unlocked'

}

Optional: Enable checking Groups

This section is commented out, but has been included as example of how to check group membership of the Requestor (in this example a member of "Domain Admins"). The same logic can be used to check the User groups as well. By checking both you could add better checks on resetting a password.

$PasswordResetAllowedGroup = "Domain Admins"

$PasswordResetAllowedMembers = Get-ADGroupMember -Identity $PasswordResetAllowedGroup -Recursive

If ($PasswordResetAllowedMembers.SamAccountName -contains $ADUserObject.SamAccountName) {

Write-Host "$($ADUserObject.SamAccountName) exists in the group"

} Else {

Write-Host "$($ADUserObject.SamAccountName) does not exist in the group"

}

Conclusion

This is an example of the how powerful PowerShell can be when used with Portal requests. It gives a basic Password Reset solution that can be expanded on to fit the needs of your organisation and the goals of the Security Team.


#PowerShell #Portal #NotificationActivity #PowerShellActivity #SCSM #HTML5Portal

555 views

© 2018 Xapity PTY LTD ABN: 81 611 883 482

  • White RSS Icon
  • White YouTube Icon
  • White Vimeo Icon
  • Facebook Clean
  • Twitter Clean