Guten Tag zusammen,
ich habe das Problem, dass Powershell Pakete von neo42 nach einer Client-Härtung mittels GPOs nicht mehr installiert werden.
Da wir in den GPOs den Dateizugriff unter C:\ beschränken, denke ich, dass es damit was zutun hat.
Unter „C:\ProgramData“ ist kein neo Ordner vorhanden (neo42, neo42Pkgs und neo42PkgsLogs), deshalb kann ich auch nicht schauen, woran es scheitert.
Gibt es eine Dokumentation, welche Benutzer oder Gruppen auf diese Ordner zugreifen müssen?
Ich will ungern die Pfade für alle wieder öffnen, einschränken wäre eine bessere Option.
Habt ihr Erfahrungswerte bezüglich Powershell Pakete von neo42 und Client Härtung?
Pakete die rein mit der setup.inf gepackt wurden, wurden installiert.
Viele Grüße Patrick H.
Guten Morgen @PatrickHenkel ,
dich glaube erstmal nicht an einen Zusammenhang mit Berechtigungen auf C:, sondern eher, dass PowerShell eingeschränkt wurde. Habt ihr eventuell nur signierte PowerShell Skripte zugelassen (was auch unsere Empfehlung wäre), aber im Application Package Center die Skript Signierung nicht konfiguriert/aktiviert!?
neo42 Empfehlungen zur PowerShell Skriptsignierung
neo42 PowerShell Signierung & AppLocker
Gruß Holger
Hallo Holger,
vielen Dank für die schnelle Rückmeldung. Die Powershell Skripte werden auch durch die GPOs beschränkt. Das Codesiging Zertifikat wurde von unseren internen CA ausgestellt, deshlab habe ich gedacht, dass der schon vertraut wird.
Ich habe das verwendete CodeSigning Zertifikat nun explizit in der GPO ausgerollt, nach eurer Anleitung.
Ich werde nach dem Wochenende berichten, ob die Installation nun funktioniert.
Gibt es im neo42 Management Service eigentlich eine Mail, wenn das CodeSign bald abläuft?
VG Patrick
Hallo @PatrickHenkel
Es gibt keine E-Mail-Benachrichtigung. Seit Version 4.6.3 erscheint jedoch ein deutlich sichtbarer Hinweis, sobald man sich in der Web-Konsole anmeldet.
Gruß
Marco
Alternativ wären die Windows-Event-Logs noch eine Anlaufstelle zur Analyse:
Oder die Logs zu Endpoint-Security-Software.
Oder mal prüfen, ob SRP bzw. AppLocker blockiert.
Im härtesten Fall kann man auch das AdvancedAuditing einschalten und schauen, welche Prozesse zwischendurch so auf die Powershell-Skripte zugreifen.
Die sauberste Lösung sind aber natürlich Zertifikate und Signaturen, daher ist der bereits erwähnte Weg wahrscheinlich bereits die Lösung 
In unserer Härtungsgruppe haben wir aktiviert, dass nur Powershell Pakete installieren, die signiert sind.
Außerdem haben wir in der GPO über die Windows Sicherheitseinstellungen die Benutzer eingegrenzt, die auf die ausführende Powershell.exe Zugriff hat.
Es darf nur Ersteller-Besitzer, NT-Autorität\System, Zertifizierungsstelle für anwendungspakete\alle anwendungspakete und eine AD-Gruppe drauf zugreifen.
Dort habe ich die Gruppe EmpAgents freigegeben, wo auch der Benutzer EmpAgent (neo42 Härtung) drin ist.
Das Powershell Log haben wir über eine GPO auch aktiviert. Leider konnte ich da noch nichts rauslesen. Ich probiere weiter.
Danke schonmal für die Hilfe.
Hallo @PatrickHenkel,
der EmpAgent führt keine Pakete selbst aus. Diese werden stattdessen im Systemkontext und ggf. im Benutzerkontext ausgeführt.
Das bedeutet, dass eure Benutzer die Berechtigung benötigen, PowerShell-Skripte ausführen zu können, damit der benutzerbezogene Teil erfolgreich installiert werden kann.
Zusätzlich muss der öffentliche Schlüssel des Codesigning-Zertifikats auf den jeweiligen Rechnern hinterlegt sein.
Hallo zusammen,
vielen Dank für die Hilfe von allen. Die Benutzer haben nun wieder Zugriff auf Powershell.exe und das Zertifikat wurde veröffentlicht. Pakete lassen sich nun installieren.
VG Patrick