1 Die ExecutionPolicy

       Beispiel 1: Auflisten aller möglichen Werte der executionpolicy
       Beispiel 2: Prüfen des Status der ExecutionPolicy
       Beispiel 1: Setzen der Policy direkt in der Registry (nicht empfohlen) 
       Beispiel 2: Setzen der Policy am Client über set-executionpolicy
       Beispiel 3: Setzen der Policy per GPO
 

1. Die ExecutionPolicy

Zum Einstieg in das Thema Signierung ist dieser Technet Artikel lesenswert:
TechNet Magazine: Windows PowerShell - Hier signieren, bitte

Leider ist es nicht allzu schwierig, die Executionpolicy zu umgehen. Seht euch bitte dazu das Kapitel Sicherheitsthemen -> 3. Was bringen die Executionpolicies "allsigned, remotesigned" der Security?

Eine genaue Beschreibung der Werte der Execution Policy findet man hier: Codeplex: Execution Policy

Ohne vorherige Konfiguration erlaubt Windows die Ausführung von PSSkripten erstmal nicht. Die sogenannte ExecutionPolicy besitzt den Wert "restricted", der die Ausführung von PSskripten ausnahmslos verhindert. Mit den cmdlets get-executionpolicy bzw. set-executionpolicy lässt sich die Security von einem Administrator so abändern, dass beispielsweise PSSkripte ohne Einschränkungen oder nur signiert ausgeführt werden dürfen.    

ExecutionPolicy

Wirkung

Restricted

Keine PS-Skripte können ausgeführt werden

Unrestricted

Alle PS-Skripte können ausgeführt werden

AllSigned

Nur signierte Skripte werden ausgeführt

RemoteSigned

Aus dem Internet oder nicht vertrauten Netzwerken heruntergeladene Skripte müssen signiert sein

 

Beispiel 1: Auflisten aller möglichen Werte der executionpolicy

[System.Enum]::GetNames([microsoft.powershell.executionpolicy])
#Ausgabe

Unrestricted
RemoteSigned
AllSigned
Restricted
Default
Bypass
Undefined

 

Beispiel 2: Prüfen des Status der ExecutionPolicy

Get-ExecutionPolicy -list | Format-List
#Ausgabe

Scope           : MachinePolicy
ExecutionPolicy : Undefined

Scope           : UserPolicy
ExecutionPolicy : Undefined

Scope           : Process
ExecutionPolicy : Undefined

Scope           : CurrentUser
ExecutionPolicy : Undefined

Scope           : LocalMachine
ExecutionPolicy : Undefined

 

1.1 Verändern der ExecutionPolicy

Beispiel 1: Setzen der Policy direkt in der Registry (nicht empfohlen)

[HKEY_Local_Machine\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.Powershell\ExecutionPolicy]
[HKEY_CURRENT_USER\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\executionPolicy]

Typ: SZ Name: ExecutionPolicy Wert:Unrestricted


Beispiel 2: Setzen der Policy am Client über set-executionpolicy

Set-ExecutionPolicy unrestricted
Set-ExecutionPolicy Undefined -scope LocalMachine


Beispiel 3: Setzen der Policy per GPO

Die ExecutionPolicy kann per GPO gesetzt werden. Für Windows2003-Domänen ist vorher der Import einer *.adm - Vorlage notwendig.

MicrosoftDownloadcenter: admFiles_PowerShell.msi

Erklärung aus der PowershellHilfe

Get-help about_Execution_Policies
#gekürzte Ausgabe
……….
The PowerShellExecutionPolicy.adm file adds the
"Turn on Script Execution" policy to the Computer Configuration
and User Configuration nodes in Group Policy Management Console in the following
paths.

     For Windows XP and Windows Server 2003:
     Administrative Templates\Windows Components\Windows PowerShell

     For Windows Vista and later versions of Windows:
     Administrative Templates\Classic Administrative Templates\
     Windows Components\Windows PowerShell

Policies set in the Computer Configuration node take precedence
over policies set in the User Configuration node.

The PowerShellExecutionPolicy.adm file is available on the
Microsoft Download Center. For more information, see "Administrative
Templates for Windows PowerShell" at 
go.microsoft.com/fwlink/.

 

Nach dem Importieren des ADM-Files PowerShellExecutionPolicy.adm kann man unter
"Benutzer-/Computerkonfiguration -> Richtlinien -> Administrative Vorlagen: vom lokalen Computer abgerufene Richtliniendefinitionen -> Klassische administrative Vorlage (ADM) -> Windows Powershell"
diese Policy öffen:


2 Das CodeSigning-Zertifikat erstellen

Anhand einer einfachen PKI, bestehend aus lediglich einer RootCA auf einem W2k8R2-Enterprise Server wird kurz das Erstellen eines Zertifikates zum Zwecke der Skriptsignatur gezeigt. Um eigene Zertifikatstemplates erstellen zu können, ist ein EnterpriseServer notwendig.
 

2.2 Das Rootzertifkat verteilen

Das Rootzertifikat muss auf jeder Maschine vorhanden sein, auf der die Gültigkeit eines anderen Zertifikats derselben CA überprüft werden muss.
Bei einer Unternehmens-PKI wird das Stamm- oder Rootzertifkat ohne administrativen Eingriff über die Mechanismen des Autoenrollments auf alle Domänenrechner automatisch verteilt.

Zur Kontrolle kann man im Snap-In "Zertifkate" unter "Vertrauenswürdige Stammzertifizierungsstellen" nachsehen. Dort sollte das selbst erstellte RootZertifkat auftauchen.

Certificate Autoenrollment in Windows Server 2003

Root and Cross-Certificate Download from Active Directory

Autoenrollment automatically downloads root certificates and cross-certificates from Active Directory whenever a change is detected in the directory or when a different domain controller is contacted. If a third-party root certificate or cross-certificate is deleted from the local machine store, autoenrollment will not download the certificates again until a change occurs in Active Directory or a new domain controller is contacted.

To manually force a new download, delete the following registry key and all subordinate keys on all affected machines. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache


In der Praxis würde ich wegen der besseren Kontrolle alle vertrauenswürdigen Stammzertifikate über Policies verteilen, egal ob die Zertifikate aus der eigenen UnternehmensCA oder einer eigenständigen CA stammen.  Dass die Stammzertifikate der UnternehmenCA dadurch doppelt im Zertifikatsspeicher der Domänenrechner erscheinen, nehme ich in Kauf, da das überhaupt nicht stört.
Andererseits wird ein versehentliches manuelles Löschen des RootZertifikats beim nächsten PolicyUpdate wieder rückgängig gemacht.

Im Folgenden habe ich die notwendigen Schritte beschrieben, das Zertifikat per Policy zu verteilen.
Natürlich kann man das Stammzertifikat auch auf jedem Rechner einzeln importieren
Snapin Zertifikate (lokaler Computer) -> vertrauenswürdige Stammzertifizierungsstellen -> Zertifikate  --> rechte Maustaste -> Alle Aufgaben -> Importieren ...
 

2.3 Zertifikatstemplate erstellen

Damit die CA ein Signaturzertifkat ausstellen kann, mit dem dann wiederum Skripte signiert werden können, muss in der CA ein eintsprechendes Zertifikatstemplate vorliegen. In diesem Template sind Zertifikatsparameter festgelegt, wie  KryptografieDienstanbieter, Einsatzmöglichkeiten des Zertifikats und weitere.

Im Regelfall erstellt man sich eine Kopie einer bereits bestehenden Vorlage, modifiziert dieses gegebenenfalls, sofern man die CA auf einem EnterpriseServer läuft, und benennt das Template nach einem Namenskonzept.

Im Folgenden zeige ich die Screenshots dieser Schritte auf einem win2008R2-EnterpriseServer. Da ich das Template modifiziere, muss es wiegesagt ein EnterpriseServer sein!
Auf die Zertifikatsvorlagen gelangt man über das Snap-In „Zertifizierungsstelle“ (MMC oder Start -> Verwaltung -> Zertifizierungsstelle)

 

2.4 Rechte setzen auf das erstellte Template

User können das Template nur verwenden, wenn sie auf dem Template die Rechte „Lesen“ und „Registrieren“ besitzen

 

2.6 Skripte signieren und ausführen

Für den Test wird die ExececutionPolicy auf dem Windows7-Client auf Allsigned gesetzt, so dass nur noch signierte PowershellSkripte möglich sind 

Set-ExecutionPolicy allsigned

#Ausgabe
 
 Ausführungsrichtlinie ändern
 Die Ausführungsrichtlinie trägt zum Schutz vor nicht vertrauenswürdigen Skripts
 bei. Wenn Sie die Ausführungsrichtlinie ändern, sind Sie möglicherweise den im Hilfethema "about_Execution_Policies" beschriebenen Sicherheitsrisiken
 ausgesetzt. Möchten Sie die Ausführungsrichtlinie ändern?
 [J] Ja  [N] Nein  [H] Anhalten  [?] Hilfe (Standard ist "J"): j

 

Skript erstellen z.B. unter C:\Powershell\Signaturtest.ps1:

#Inhalt von Signaturtest.ps1

"Dieses Skript soll signiert werden"

 

Zertifikatsobjekt erstellen und Signierung durchführen

$Zertifikat = dir cert:\ -recurse –codesign
#dir cert:\currentuser\my -Recurse -codesign
Set-AuthenticodeSignature C:\powershell\Signaturtest.ps1 $Zertifikat

 
Das Signaturtest.ps1-Skript hat nun einen Signaturblock dazubekommen, dessen Länge und Sicherheit von der ausgewählten Schlüssellänge im verwendeten Zertifikatstemplate abhängt.

#neuer Inhalt von Signaturtest.ps1

"Dieses Skript soll signiert werden"

# SIG # Begin signature block
# MIIIGQYJKoZIhvcNAQcCoIIICjCCCAYCAQExCzAJBgUrDgMCGgUAMGkGCisGAQQB
# gjcCAQSgWzBZMDQGCisGAQQBgjcCAR4wJgIDAQAABBAfzDtgWUsITrck0sYpfvNR
# AgEAAgEAAgEAAgEAAgEAMCEwCQYFKw4DAhoFAAQUgoDdTdcdXJK1KxrE7Khiohuw
# qY6gggWSMIIFjjCCBHagAwIBAgIKKtnOYgAAAAAAAzANBgkqhkiG9w0BAQUFADBC

verändert man nur ein einziges Leerzeichen im Code, so passt die Signatur nicht mehr zum Skript und das Skript kann auf dem Client nicht ausgeführt werden.