Applies to: Exchange Server 2007 SP3, Exchange Server
2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2007-02-12
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
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:
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
registry key to the desired script execution mode.
|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.|
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 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
.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
Get-Help About_Signing. This
command returns help information that includes detailed
instructions for digitally signing scripts.