daabm

Dein Skript enthält wirklich diesen Code? trap { write-output $_; exit1 } echo "Test" Dann hätte ich 2 Anmerkungen: 1. "exit1" ist keine gültige Powershell-Anweisung 2. Was genau ist "echo" bei Dir? ( get-command echo | select * )

Soll ich mal ganz vorsichtig fragen, ob Eventlogs schon analysiert wurden? System, Application, GroupPolicy. User Profile Service (ja, den gibt's tatsächlich).

Ahem - nein. Wir wollen keine Child Domains mehr, wir wollen Single Domain/Single Forest. Den Rest regeln Trusts. Ansonsten steht oben schon alles. Wir hatten die Diskussion in der Firma auch mal - ging um einen Forest mit 2 Domains, 20.000 Servern, 70.000 Clients (restliche Clients stehen woanders) und 200.000 Usern. Ergebnis nach wenigen Minuten: Nicht nur wirtschaftlich sinnlos, sondern auch technisch nicht umsetzbar.

...und ein paar andere Sachen unter HKLM auch noch, sonst gehen Apps nicht mehr und das Startmenü ist kaputt. Die Methode von @testperson ist besser.

Die VPN-Verbindung ist eine eigene NW-Karte - die muß ins Domain Profile. Die "reale" NW-Karte bleibt im Public Profile.

Wie lange dauert es, das kurz selbst auszuprobieren?

Bei uns hat jemand ein Goodie programmiert, nennt sich "Hotelfunktion". Per Default ist 80/443 zu, und wenn Du mal wo bist, wo der Internetzugang hinter nem Captive-Portal hängt, kannst Du damit für 5 Minuten 80/443 aufmachen. "Früher" hatten wir das trivialer gelöst - unser Proxy kommt per PAC, und per GPO wurde zusätzlich ein Dummy-Proxy verteilt. Der wird nur angezogen, wenn das PAC nicht heruntergeladen werden kann - also wenn keine Verbindung per VPN vorhanden ist. Hilft natürlich nix gegen Agenten, denen der Proxy egal ist. Und an AD mußt Du natürlich denken, die Domänenerkennung muß im Public Profile funktionieren. Aber mir fällt spontan keine Malware ein, die auf Port 135 oder 389 nach Hause telefoniert. Und für die Domänenerkennung braucht's auch keine Portausnahmen, sondern Dienstausnahmen. AFAIK - müsste nachschauen, wie genau wir das gemacht haben

Firewall outbound auch weitestgehend zu im Public Profile? Dann kann zumindest keiner "einfach so" nach Hause telefonieren... Ansonsten klingt das nicht schlecht.

Eigenschaften der Netzwerkkarte, Bindungen passend deaktivieren, erste 2 Haken rausnehmen für MGMT:

gpedit.msc zeigt Dir die Einstellungen der "lokalen Policy" an. Die wird dann ggf. von domain based Policies überschrieben. Und rsop.msc ist deprecated, das kann zu viel nicht anzeigen. So gesehen: MS macht da, was es will, ja- ist ja auch "ihr" Betriebssystem. Aber das Ergebnis entspricht exakt dem erwarteten

Du kannst "Freigaben" nicht an eine NIC binden. Den Serverdienst bzw. den Hostnamen dagegen problemlos. Im Managementnetz macht man kein DHCP und hat keine Hostnamen - wir zumindest nicht.

Meine letzte OSI-Schulung ist glaub 28 Jahre her - bitte um Nachsicht mit einem alten Mann, hilf mir lieber über die Straße 😂

@cj_berlin Disjoint Namespaces innerhalb eines Forest sind kein Problem. Interessant wird's mit ganz vielen Forests und "welche SPNs sind jetzt eigentlich wo registriert. wie findet der Client den richtigen KDC und was ist per DNS auflösbar und was nicht". Aber jetzt wird's zu OT

Guck - hätte ich mal die Klappe gehalten oder besser noch mal nachgedacht. Klar, muss ja "da unten" sein 😘 Ok, aber technisch wäre es egal, Hauptsache ein Gerät im Subnetz hat nen Helper. Da simmer uns glaub einig.

Wenn Ihr in flachem Gelände (oder "im Tal") wohnt - freundet Euch schon mal damit an, das wird das neue "Normal"... SCNR

Normalerweise laufen Helper auf dem Router. Aber in Zeiten von Layer-x-Switches weiß man das nicht so genau

Über Multi-Domain Umgebungen kannst mit mir prima diskutieren - wir haben etwa 1.500 Stück von diesen komischen Domänen. Nur 3 davon haben in ihrem Forest noch eine Child-Domain, und das sind genau die 3, die uns den meisten Ärger bereiten... Inkl. der besch***** universellen Gruppen, die auch kein Mensch braucht. Alle anderen sind Single-Domain/Single-Forest, und mit den richtigen Trusts klappt das ganz hervorragend. Sogar mit Kerberos und Disjoint Namespaces. Ja, weiß ich, disjoint sollte man nicht machen, aber wir machen ungefähr alles, was "irgendwie machbar ist"

Nein. "Kann es nur einmal geben" stimmt, DDP ist falsch. Richtig wäre "kann in einer beliebigen Policy auf Domainebene gesetzt werden und landet dann auch in der DDP"

Ja dann fehlt wohl im Stripeset eine HDD...

Beides falsch... Und die Default Domain Policy fasst man am besten gar nicht an, die hat eine unheilige Beziehung zum Domain Head. gpedit.msc zeigt Dir die "lokale Policy" an. Was da drinsteht (oder auch nicht), wird von Domain Policies überschrieben. Und das Gesamtergebnis findest Du dann in auditpol. Oder auch nicht https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/getting-the-effective-audit-policy-in-windows-7-and-2008-r2/ba-p/399010

BTW: Storage Pools werden in keinster Weise über die Datenträgerverwaltung verwaltet - das passiert nur über den Servermanager bzw. Powershell.

Last 24 h...

Warnwetter heute: "Warnung vor HITZE"... Aktuell 33°

Hab mir das mal angeschaut... (Erzeugt mit https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 ) Die bieten eine extrem eingeschränkte Auswahl von Cipher Suites an - https://www.ssllabs.com/ssltest/analyze.html?d=nvd.nist.gov Möglicherweise hat Powershell/Invoke-WebRequest damit ein Problem. Für nähere Diagnose fehlt mir grad die Konzentration.

Da wären wir dann wieder bei dem Zertifikatsproblem mit dem Truststore. Der Angreifer muß ein Zertifikat präsentieren, das den "eigentlichen" Namen enthält.