Script Security
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
This topic explains how script security in the Exchange Management Shell helps prevent harmful or otherwise unwanted scripts from running in your organization and what options are available to modify script security to meet the requirements of your organization.
You typically encounter scripts from three different sources: yourself, another person in your organization, and script writers from outside your organization, such as the Internet. If you write a script, you trust the script to do what it is designed to do. If you share the script with other administrators in your organization, they too may trust the script, but only because they trust you.
When scripts come from other sources, such as the Internet, script security is a concern. The only way that you can trust scripts from sources unknown to your organization is to inspect the script code directly and test it in an isolated lab environment. This process can be time-consuming and tedious. But it is a recommended practice to prevent unintentional execution of malicious or destructive code.
The Exchange Management Shell supports the recommended use of digital signatures to make sure a script is not altered after the script is created. For more information about digital signatures, see "Code-Signing Basics" later in this topic.
Script Execution Modes
Four modes of script execution are possible for the Exchange Management Shell to control how scripts are used, depending on how they are signed and if they are from known or unknown sources. The following table describes each script execution mode.
Script execution modes
| Mode | Description |
|---|---|
|
No scripts will run, even if they are signed by a trusted publisher. |
|
All scripts must be digitally signed by a trusted publisher before they will run. |
|
All scripts that are locally created will run. Scripts that are downloaded from remote locations, such as the Internet, that cannot be trusted, will not run. This is the default script execution mode. |
|
All scripts regardless of whether they are digitally signed or trusted will run. We don't recommend the |
To change the script execution mode from the default RemoteSigned script execution mode, use the Set-ExecutionPolicy cmdlet in the Exchange Management Shell. For example, to change the execution policy to AllSigned mode, run the following command:
Set-ExecutionPolicy AllSigned
The Exchange Management Shell recognizes the change to the policy immediately.
Large organizations that want to set a consistent script execution mode for all computers that are running the Exchange Management Shell should apply the script execution mode setting by using an Active Directory group policy. You configure the Active Directory group policy to set the ExecutionPolicy value located under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell registry key to the desired script execution mode.
Warning
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.
Code-Signing Basics
Digital signatures are created by using a public-key signature algorithm that uses two different cryptographic keys called a key pair: the public key and the private key. The private key is known only to its owner, and the public key is available to anyone. In digital signatures, the private key generates the signature, and the corresponding public key validates the signature.
A certificate is a digital document that is generally used for authentication and to help secure information on open networks. A certificate securely binds a public key to the entity that holds the corresponding private key. Certificates are digitally signed by the issuing certification authority (CA). By using a code-signing certificate, the author of the script adds a digital signature to the script file. During this process, a one-way hash of the script is created and encrypted by using the private key. The encrypted hash is a digital signature string that is added to the script file. This digital signature string is commented out so that it does not interfere with script functionality.
When this script is run in an Exchange Management Shell environment where code signing is required, a new one-way hash of the script file is produced. The one-way hash is compared to the encrypted hash that is included with the script file after it is decrypted by using the public key. If the script wasn't altered in any way after it was signed, the hashes will match. The computer then tries to verify that the signature is from a trusted publisher by building a certificate chain to a trusted certification authority. If the trust is verified, the script runs.
Whether a script is from a trusted source depends on the origin of the code-signing certificate that was used to digitally sign the script. There are generally two types of certificates:
Certificates that are issued by a trusted certification authority The certification authority verifies the identity of requestor before it issues a code-signing certificate. The issuing authority can be an external, public third party that sells certificates or an internal certification authority that is hosted by your organization. If you sign a script by using this kind of certificate, you can share the script with users on other computers that recognize and trust the certification authority that issued the certificate.
Self-signed certificates For this kind of certificate, your computer is the authority that creates the certificate. The benefit of a self-signed certificate is you can write, sign, and run scripts on your computer. But you can't share your script to run on other computers because they don't recognize your computer as a trusted certification authority. If they don't trust your computer, they can't validate your self-signed signature and the script won't run.
Cmdlets for Managing Code Signing
The Exchange Management Shell includes two cmdlets for managing code signing. The Set-AuthenticodeSignature cmdlet is used to add digital signatures to script files. The Set-AuthenticodeSignature cmdlet takes the name of the file to be signed as its first positional parameter. If the file is not in the current working directory, you must provide the path of the file. The second input parameter for this cmdlet is the certificate that is used for signing. This certificate is stored in the local certificate store. You must provide this parameter in the form of a string that references the certificate. The certificate can be accessed through the Cert: drive.
The second cmdlet for managing code signing is the Get-AuthenticodeSignature cmdlet. Use the Get-AuthenticodeSignature cmdlet to check and confirm the current code-signing status for the file that is provided as a parameter input. If a problem occurs when you use a code-signed script, the output from the Get-AuthenticodeSignature cmdlet will provide useful troubleshooting information.
If you want to run scripts from outside sources, such as Microsoft, you must adapt the scripts according to the script execution mode of your environment. You can receive scripts as basic .txt files, rename them as .ps1 script files, and then, after you apply any required signing, run these scripts as if you had written the script yourself.
For more information about digital signing and script execution policies, in the Exchange Management Shell, run the following command: Get-Help About_Signing. This command returns help information that includes detailed instructions for digitally signing scripts.