EmmKay

Das leuchtet ein. Daran hatte ich nicht gedacht.

Da war ich schreibfaul. Das Netzwerk: 10.50.215.0/24 Kannst Du mir es erläutert, warum es falsche Sicherheit vorgaukelt? Vorerst habe ich es so gelöst, dass ich die IP-Adressbereiche angegeben habe, für die diese Regel gelten soll. Das Schlüsselwort Internet scheint nicht zu funktionieren. Vielleicht funktioniert es nur mit klassischen privaten Netzen.

@All Für einige Systeme möchte ich den ausgehenden Verkehr ins Internet per Gruppenrichtlinie blockieren. Für diese Zwecke habe ich in einer Gruppenrichtlinie eine ausgehende Regel definiert, die alle Protokolle und Ports für den Bereich Internet blockiert. Sobald die Regel aktiv ist, hat das System keine Verbindung mehr zu Domäne. Der Domänencontroller befindet sich im selben Netz wie die betreffende Systeme. Lt. FW_ADDRESS_KEYWORD stellt das Schlüsselwort FW_ADDRESS_KEYWORD_INTERNET eine Sammlung von Adressen dar, die sich derzeit nicht im lokalen Intranet oder Remote-Intranet des Computers befinden. Wie sollte die Regel formuliert werden, dass die Kommunikation im lokalen Netzwerk funktioniert, aber der Verkehr für bestimmte Computer ins Internet blockiert wird? Das Netzwerk: 10.xxx.xxx.0/24

Vielen Dank für die schnelle Lösung. Auf das Naheliegendste bin ich nicht gekommen.

Leider habe ich bisher keine Cmdlets bzw. Möglichkeit gefunden, wie ich die Gruppenmitgliedschaften von gruppenverwaltetene Dienstkonten (gMSA) ermitteln kann. Ist die einzige Lösung in allen Gruppen nach dem gMSA zu suchen?

Unter Typsisien verstehe ich, dass ich der Variable bzw. dem Paramteter den korrekten Datentypen zuweise. In der Regel mache ich mir die Mühe, den "richtigen" Datentypen zu ermitteln. Hierfür verwende ich die Eigenschaft <Object>.GetType().Fullname oder schaue in die Online-.NET Dokumentation nach. Mir ist es schon wichtig den "richtigen" Datentypen zu verwenden. GPO-Objekt an eine Funktion übergebe, die einen [String] erwartet, und das übergebene GPO-Objekt fehlerfrei in eine Zeichenkette konvertiert werden konnte, dann fehlen mir alle Eigenschaften und Methoden des GPO-Klasse und ich habe "nur" noch eine Zeichenkette.

Ich dachte immer, dass es ein Muss ist, die Input-Parameter zu typisieren. Ich glaube, dass ich noch nie ein Beispiel ohne Parametertypisierung gesehen habe. Vielen Dank. Die using-Anweisung kannte ich nur im Zusammenhang, um eine lokale Variable in einem Remotebefehl zu verwenden.

@cj_berlin Vielen Dank für Deine ausführliche Erklärung. Man merkt sehr gut, dass bei der Entwicklung von PowerShell darauf geachtet wurde, Administratoren und Entwickler gleicher Maßen anzusprechen. Also muss ich als Entwickler der Funktion sicherstellen, dass der/die richtige(n) Rückgabetype(n) bei OutputType angegeben wird/werden. Eine Überprüfung findet (leider) durch den PowerShell-Interpreter nicht statt. Da ich in unserem Team der Einzige bin, der PowerShell nutzt, möchte ich möglichst viele Best Practice umsetzen und den Code möglichst sicher machen. Zum Beispiel typisiere ich bereits alle Variablen. Was leider etwas zur Lasten der Lesbarkeit geht, wenn die Typennamen besonders lang sind. Da muss ich noch einen vernünftigen Mittelweg finden.

Zur Zeit lese ich das Buch Building Better PowerShell Code. Im Kapitel 9 schreibt der Autor, dass man immer den Ausgabetypen einer Funktion definieren soll. Der tatsächliche Ausgabetyp kann sich doch von meiner Definition unterscheiden. Deshalb verstehe ich absolut nicht, warum diese Vorgehensweise empfohlen wird. Mich verwirrt es eher anstatt das es hilft, weil der Rückgabewert ein anderer sein kann als den ich erwarte. Vielleicht kann mir jemand erklären, warum die Definition eines Outputtyps zu den Best Practice gehört. Siehe auch Function Structure Beispiel aus dem Buch function Get-File { [OutputType([System.String])] param( [Parameter()] [string]$FilePath ) Get-Item -Path $FilePath } (Get-File -FilePath C:\foo.txt).GetType().FullName # Output: System.IO.FileInfo (Get-Command Get-File).OutputType.Name # Output: System.String (Get-File -FilePath C:\foo.txt).<tab> # Tabvervollständig listet die Eigenschaften und Methoden der Stringklasse auf

Danke für den Hinweis: Das hatte ich auch schon in Betracht gezogen.

Peinlicherweise habe ich den Fehler gefunden; Internet Explorer Enhanced Security Configuration war aktiviert. Zum Deaktivieren von Internet Explorer ESC habe ich bisher keine Einstellung in den Gruppenrichtlinien gefunden. Es doch richtig, dass ich die entsprechende Registierungseinträge per GPP setzen muss? Danke nochmal für Eure Hilfe.

Und wirkt sie auch? Dazu Internet Explorer starten, eine beliebige Datei auf dem Share öffnen (txt oder Dummy-html) und in den Eigenschaften nachschauen, in welche Zone die einsortiert wurde. Ist der einfachste mir bekannte Weg... Die Werte unterhalb von HLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings werden entsprechend gesetzt. Zusätzlich habe ich in der Gruppenrichtlinie den Einstellung Sicherheitszonen: Nur Computereinstellungen verwenden aktiviert. (Der Wert Security_HKLM_only i.d. o.g Schlüssel wurde auf 1 gesetzt.) Leider alles ohne Erfolg. Die geöffnete Dummyhtmlseite von NETLOGON wurde der Zone Internet zugeordnet. Nachdem ich die Gruppenrichtlinie wieder deaktiviere habe, um die Domäne manuell zur Zone Lokales Intranet hinzufügen, wird das Skript anstandslos ausgeführt und die Dummyhtmlseite auch der Zone Lokales Intranet zugeordnet. Der Dienst Application Identity läuft nicht. Ja. Das war ein Tippfehler im Forum. Vielen Dank.

Lt. Hilfetext zum GPO-Einstellung Liste der Site zu Zonenzuweisungen ist Intranet die Zone 1. Aber auch damit funktioniert es nicht bei mir.

Bei funktioniert es leider nicht. FQDN der Domäne (meine_domäne.de) mit dem Wert 2 in die Gruppenrichtlinie eingetragen. Die Zonenzuweisung wurde erfolgreich auf dem Testsystem aktualisiert. Evtl. hilft dieser Eintrag aus dem Anwendungs- und Dienstprotokoll Microsoft/Windows/PowerShell weiter: Wo wurde festgelegt, dass das Skript nicht ausgeführt werden kann. Ist damit die Ausführungsrichtlinie gemeint? Vielen Dank.

Ja. Das verwirrt mich immer wieder. Ich dachte immer, dass Get-ExecutionPolicy ohne Parameter die effektive Ausführungsrichtlinie anzeigt. Leider funktioniert es nicht. Die Domäne hatte ich bereits in der Zonenzuweisung eingetragen. Es ist doch richtig unter Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Internet-Explorer\Internetsystemsteuerung\Sicherheitsseite\Liste der Site zu Zonenzuweisungen Vielleicht sind die Einträge verkehrt? Dort steht: \\meine_domäne.de -> 1 file://meine_domäne.de -> 1 \\server -> 1 file://server -> 1 Danke schon mal.