PowerScripts gives you complete control over the PowerShell scripts which are run against your Microsoft365 tenant to perform administration actions such as maintaining groups, Teams, users, mailboxes and more. You can control exactly what the script can do (and what it cannot do) and you can control precisely who is authorized to run the scripts, and on which objects (users, teams, etc.) they can run on.

You can explicitly exclude a group of users from even appearing as a option in PowerScripts. This is a feature we added at the request of a large client whose CEO had a name which was shared by several employees and they wanted to be ABSOLUTELY sure that no level-one IT person ever performed any operations against the CEO’s mailbox.  

PowerScripts even allows you to grant regional access, for instance allowing the AMEA service desk to perform actions against users in Africa, the Middle East, and some countries in Asia, but not other countries.   Role-based access control makes it easy to grant and restrict access.

Security: PowerShell scripts can be used to perform a wide range of actions on a system, and some of these actions can be potentially harmful. By limiting the PowerShell scripts that a junior person can execute, an organization can reduce the risk of accidental or malicious damage to systems and data.

Compliance: Some organizations are subject to regulatory requirements that mandate specific controls around the use of PowerShell scripts. Limiting the PowerShell scripts that a junior person can execute can help an organization meet these requirements and avoid potential fines or penalties.

Auditing: Limiting the PowerShell scripts that a junior person can execute can make it easier to track and audit the actions that are performed on a system. This can be useful for troubleshooting, incident response, and forensic investigations.

Efficiency: Junior personnel may not have the experience or knowledge required to safely and effectively execute certain PowerShell scripts. Limiting their access to certain scripts can help them to focus on tasks that they are better equipped to handle, and avoid making mistakes that could require additional time and resources to correct.

Maintaining the Integrity of the system: Junior personnel may not be aware of all the dependencies and the interconnection of the different systems and sub-systems. Running scripts that are not authorized or not tested by the senior staff may cause unexpected results and can break the system or its functionality.

The Service Desk assignee gets a request to reset a user’s password. Here’s how this task would be accomplished using PowerScripts with no possibility of mischief or malfeasance. 

First, the assignee searchs for the name of the user needing a reset, in the case “Todd” 

Once the correct Todd is located, the Service Desk double clicks on the row and is prompted to select a script.

The Service Desk person next selects the Reset User Password script.  If the Service Desk person is not authorized to reset passwords, this script will not appear on the list of available scripts.   You have complete control over which scripts appear to whom.

All that remains to do is press the Execute button.  The script will create a new random password and put it in the result window. Next the Service Desk person communicates the new password to the end user and the ticket can be closed.

 Param([string]$UserPrincipalName)

 $newPass = [System.Web.Security.Membership]::GeneratePassword(8,2)

 Set-MsolUserPassword –UserPrincipalName $UserPrincipalName –NewPassword $newPass -ForceChangePassword $true | Out-Null

 Write-Output “The password for $UserPrincipalName has been reset. The new password is $newPass. Please give $UserPrincipalName this new password and advise them that it must be changed on first use.”

It’s straight-forward PowerShell, but there are a couple of things that are very important about this script which prevent mischief. Remember, the Service Desk person cannot modify the script. If they could modify the script there are two things they could do: 

1) set the password to a known string rather than something random. 

2) Drop the parameter -ForceChangePassword.

If the junior IT person was devious, the two changes above would leave the transaction such that the end user password could be set to a password which the end user would like to keep — “What would you like your new password to be?” AND the end user would not have to change it. The devious Service Desk person would then be able to gain access to the end user’s email at will– even send emails on their behalf and nobody would ever know it. 

PowerScripts prevents this and 1,000 other scenarios from happening. Service Desk personnel can only execute scripts, they cannot use the credentials for any other purpose, and the whole transaction is written into an audit log for extra security.