Users fill in the information, in the case Group Name and the UserPrincipalName of the person to add, and push the Execute button. They do not know, nor have to care, that once they push the button, the following script will be executed:

Security Features

PowerScripts offers a number of security features. Users can be logged out automatically after a period of inactivity, prohibited from having more than a single authenticated session at a time (this prevents a user from logging in from two computers, for example), and can display a custom Terms of Use document on login.

Users can be limited as to which scripts they are authorized to run, and on which types of objects they are allowed to run them against. For instance, North American users can be limited to making changes only to North American end-user accounts while Japanese users can be likewise limited to servicing only Japanese end-user accounts. Specific staff members, such as the executive team, can be excluded from PowerScripts altogether. This feature was added at the request of a client whose CEO shared a common name with many employees and they wanted to be certain that the Service Desk didn’t select the CEO’s account by mistake.

As an example, Titleist uses PowerScripts to onboard new employees. Any member of the Service Desk can run a query to search for an existing employee to whom the new hire will report. The user selects the manager from the search results and then selects the “New Hire” script. The script prompts the user for some information, such as whether the employee will be a contractor, employee, or “shared”, and which email domain to assign the user to. For some parameters the user can only select from the choices presented. When the form is complete the user presses the Execute button and the script runs in the background and onboards the new hire.

For obvious reasons, Titleist does not want everyone on the Service Desk to have the power to run a PowerShell script of their own authoring against their Active Directory server. Yet onboarding new hires is a high-volume task that needs to get done. PowerScripts by VitalSigns makes it safe to delegate this task to even the most junior Service Desk personnel.

Every time a script is executed, an audit record of the transaction is recorded. This audit entry contains a pointer to the exact script which was run, the parameters which were given to the script by the user, the date and time the script was run, and the name of the service desk user who ran the script. This alone encourages good behavior.

Finally, when users execute a PowerShell command the underlying script will run using as set elevated run-time credentials which remain unknown to them. In this way, the elevated credentials which would otherwise be required when running native PowerShell cannot be misused by mistake or malice.

If a malicious script administrator changed a script, executed it, then changed the script back to its original form in an attempt to hide their tracks, the audit log within PowerScripts would have a clear record of this. Every execution of a script is matched with the exact script which was in place at the time. It should be noted that the Service Desk staff will not have the script administrator role; this role should be limited to the most trusted and experienced IT staff.

Data Storage

PowerScripts uses an encrypted Mongo database to store all its data. This database is stored on-premise, and it is protected by a password which only the client knows. Any passwords stored inside Mongo (the various credentials which VitalSigns uses to execute PowerScripts) are further encrypted within our software, and only the encrypted value is stored in Mongo. So even someone with the password to the Mongo database would not have access to the passwords stored therein.

What Data Does PowerScripts Store?

PowerScripts has read-only “Graph API” access to your Microsoft365 account. Depending on the level you give it, this means that it can access the list of all your users, all their mail files, all share mailboxes, all Teams, all groups, etc. VitalSigns does not store any personally identifiable information such as home address, SSN, or home phone number. VitalSigns does store a copy of a subset of information which your organization assigned to the employee on hiring, such as their company email address, user principal name, groups they belong to, and Teams they belong to. VitalSigns does not store, nor have access to, user passwords.

This information is collected and updated a few times a day, depending on how large your environment is.

The information gathered is stored in the Mongo database so that fast queries can be performed against it and, subsequently, so that the relevant information therein can be used to submit a transaction to Microsoft (or to your on-Premise system, as the case may be).

This database also contains all the PowerShell scripts (known within the product as “PowerScripts”) which can be executed by the end users, and an audit trail of who ran what, when, and where. When a script is modified, the prior version of the script is kept in a version history.

Third-Party Authentication

In addition to offering its own authentication directory, PowerScripts can optionally authenticate users via your on-premise Active Directory server or using Azure AD. With either directory option, PowerScripts does not have access to the user’s password. Instead, VitalSigns asks the directory server to authenticate the user and gets back a token indicating that the user is legit. An employee who is terminated from the company directory becomes ineligible to log into PowerScripts immediately.

PowerShell Runtime Credentials

When an authorized user of PowerScripts executes a PowerShell command they can run that script using a set of credentials which has the necessary authorization to run such a script. These credentials are not exposed to the user. These credentials are stored in the credentials table in the Mongo database and are decrypted in memory just long enough to execute the script. They cannot be retrieved once saved; they can only be overwritten by a script administrator—a role inside PowerScripts only granted to those who need it.