behandelte Themen unter "PSSkripte signieren"

Die ExecutionPolicy
Beispiel 1: Auflisten aller möglichen Werte der ExecutionPolicy
Beispiel 2: Prüfen des Status der ExecutionPolicy
1.1 Verändern 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
Das CodeSigning-Zertifikat erstellen
2.1 eine einfache CA installieren
2.2 Das Rootzertifikat verteilen
2.2.1 Export des Rootzertifkats
2.2.2 Import des Rootzertifkats in eine GPO
2.3 Zertifikatstemplate erstellen
2.4 Rechte setzen auf das erstellte Template
2.5 CodesigningZertifikat am Client beantragen
2.6 Skripte mit Zertifikat signieren und ausführen

******************************************************************************Ü

1. Die ExecutionPolicy

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

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.1 eine einfache Microsoft-CA (AD-integriert) installieren

Ich beschränke mich auf ein paar Screenshots von einem Windows2008R2 EE – Server (Domaincontroller). Produktiv sollte eine CA nach Microsoftempfehlung nicht auf einem DC laufen.

Der Aufbau einer etwas komplexeren Struktur mit OCSP wird in diesem Whitepaper StepByStep beschrieben:
Microsoft Downloads: Windows Server 2008 Active Directory Certificate Services Step-By-Step Guide

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 UnternehmensPKI wird das Stamm- oder Rootzertifkat sich 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.2.1 Export des Stammzertifizierungsstellenzertifkats

2.2.2 Import des Rootzertifkats in eine GPO

Öffnen der GPO "Vertrauenswürdige Stammzertifizierungsstellen" mittels GPMC

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.5 CodesigningZertifikat am Client beantragen

Auf einem Windows7-Client zeige ich im folgenden wieder anhand von Screenshots, wie ein Codesignaturzertifkat auf Basis der oben erstellten Vorlage beantragt und erstellt wird.

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
"Dieses Skript soll signiert und ausgeführt werden"

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

"Dieses Skript soll signiert werden"

Zertifikatsobjekt erstellen und Signierung durchführen

$zertifikate=dir cert:\ -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.

"Dieses Skript soll signiert werden"

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

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