daabm

Jepp - auch das nicht. Wenn der Rechner in einer Domäne ist und kein DC erreicht werden kann, ist nix mit GPOs jeder Art. Die fängt für Domain Member mit der Ermittlung eines DC an. Klappt das nicht-> Schicht im Schacht. Sonst könnte man ja in der lokalen GPO Werte setzen, die eigentlich von Domain GPOs anders gesetzt werden... Das führt dann die Inheritance ad absurdum.

Nein - oder ich bin blind. Entweder die lange Version von Evgenij, oder die kurze: "nslookup <Domänenname> <IP des DNS der anderen (!) Domäne>"

Die Frage war nicht nach PortQry - wobei es da eh für Domänen was viel besseres gibt https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 Die Frage war, ob Du Namen bei dem anderen DNS auflösen kannst. Und dann wäre noch die Frage, ob der andere DNS den Zonentransfer auch erlaubt. Die Frage würdest Du Dir mit einem conditional forwarder ersparen.

Nicht ganz. Einstellungen aus GPOs werden auf dem jeweiligen Computer/Benutzer gesetzt. Wenn bei der GPO-Verarbeitung kein DC erreicht werden kann, wird nichts verarbeitet (auch nicht die "lokale GPO"). Damit bleibt alles beim letzten Stand.

Ich klingle nach dem Wednesday midweek break mal vorsichtig das Wochenende ein Kaffee koche ich nicht (der Kaffeeautomat heißt so, weil er das automatisch macht), aber der Kühlschrank ist wie immer gut gefüllt, bedient Euch 🍺

Das war's, was ich mit API durcheinander geworfen habe... Treibermodell-Version, und natürlich Anschlußart. Mit WSD hatte ich auch oft "Spaß"

Der Drucker ist "immer" vorhanden oder wird bei der Anmeldung erst irgendwie erstellt? Das hatten wir mal als kurioses Problem, daß nachträglich erzeugte Drucker nicht angesprochen werden konnten von manchen Programmen. Gibt da wohl 2 verschiedene Windows-APIs, aber genau krieg ich das nicht mehr zusammen. War irgendwas mit der Ermittlung der verfügbaren Drucker... Und dann gäbe es von MS auch noch ein FixIt zum Reset des Spoolers. Netzsuche findet das sicher.

Wir wurden nicht informiert. Vermutung: BIOS/Firmware-Updates.

Nop - ich wurde angemessen ignoriert 😂 Diese Woche 2 mal HyperV Cluster-Ausfall, b***d daß darauf 16 Domain Controller laufen. Sieht nicht gut aus für uns Sysadmins.

So ungefähr Es gibt gpedit.msc ("Gruppenrichtlinienobjekt-Editor", lokale Policy), gpmc.msc ("Gruppenrichtlinienverwaltung" - das Schweizer Messer des busy Admin) und gpme.msc ("Gruppenrichtlinenverwaltungs-Editor" - ich kann nix für die Namen) . Letzteres ist die Version von gpedit.msc, die domänenbasierte Gruppenrichtlinien bearbeitet. Das, was die Cmdlets nutzen, ist im "GroupPolicy" Modul. Bei allem außer "x-Gp[Pref]RegistryValue" wird dabei auf das COM-Interface von GPMC zurückgegriffen: IGPMGPO und dessen ganze Klassen und Methoden. COM ist Mist, ist nur bedingt remotingfähig. Edit: Noch ein "k" gefunden...

Hätte in dem Fall nicht geholfen - Strg-Shift-V ist keine Kombination, die gpme.msc versteht. Und ein Line Break fällt da auch nicht darunter, der bleibt dabei erhalten. Resumée für mich: Shit happens, never expected that "attack chain" 😂 Der Pentest-Dienstleister hat deswegen übrigens seine Berichte umgebaut, das steht jetzt in formatierungsfreien Code Blocks. @BroBias Copy/Paste über NPP+ ist mein tägliches Brot - in dem Fall hab ich schlicht überhaupt nicht damit gerechnet... "Betriebsblind", die Brille war zu dunkel 😎

Jupp - oder auch keins, vermutlich gehen auch mehrere. Ironischerweise war es ausgerechnet der Ergebnisreport eines Pentest, der uns diesen Zeilenumbruch eingebrockt hat: Die Textverarbeitung trennt am Leerzeichen wegen Zeilenumbruch -> CR/LF 🤔 Und dann Copy/Copy/Copy/Error...

Sodele - Update: Manchmal glaubt man kaum, was alles passieren kann... Blogpost ist aktualisiert, "Rolle rückwärts" - man muß zu seinen Fehlern stehen 🙈 Die Anforderung, das zu implementieren, kam per Jira-Ticket zu uns. Da war aus unbekannten Gründen ein Zeilenumbruch - vermutlich kopiert aus einem PDF, und Textverarbeitung macht sowas ja gerne wegen Line Wrapping. Den Wert habe ich einfach kopiert. Nach dem Einfügen sah alles in Ordnung aus: Nur beim Durchfahren mit dem Cursor kann man noch feststellen, daß nach dem Leerzeichen erst mal keine Bewegung erfolgt -> unsichtbares Zeichen. Aber warum sollte man das tun? Und im GPResult muß man auch gezielt hinschauen - das sind 2 Leerzeichen: So gesehen: Unsere Schuld, nicht gründlich gearbeitet... Allerdings natürlich trotzdem ein kleines Problem der ganzen Security/Compliance Scanner, die das nicht erkennen.

Qualys hat auch eine falsche Regex (matcht mit und ohne Leerzeichen), und in den Remediation Hinweise steht's falsch drin.

Und ich hab's mal bei Heise als Redaktionstip gemeldet...

Alles lösbar, wenn die Anforderung klar formuliert wird. Wir haben uns erst mal für den Würgaround entschieden, weil zu viel Automation dran hängt...

Dann bin ich mal gespannt, was bei unserem nächsten Scan rauskommt Ich glaube nicht, daß das bei unserer Security auch schon angekommen ist - ich hab mal nix gesagt... Und wir hatten ein Security Audit, wo das definitiv auf der Checkliste stand, aber da wird halt auch nur geschaut ob konfiguriert - ich wüßte auch nicht, wie man das "einfach und schnell" testen kann.

Jepp. Nicht mal die Security Audits der einschlägigen Firmen haben das auf dem Schirm...

"Store network credentials"...

Sers. Mal wieder über einen Quirk gestolpert - schaut besser noch mal genau hin, wenn Ihr denkt, daß UNC-Hardening aktiv wäre. Windows 10 macht's von Haus aus, sofern man es nicht per GPO "kaputtkonfiguriert"... https://evilgpo.blogspot.com/2023/07/unc-hardening-ms15-014-you-think-you.html TL;DR: Das Leerzeichen hier muß raus - "RequireMutualAuthentication=1, RequireIntegrity=1"

Ja und ja 🍺

Wir drucken nicht über Windows-Server - puh, Glück gehabt, endlich auch mal was richtig gemacht

Ist möglicherweise auch kein file:// Protkoll-Link, sondern direkt ein UNC-Pfad. Leider hast Du den Screenshot im ersten Post komplett anonymisiert Und ob die GPO überhaupt ankommt und wirkt, weiß auch noch niemand.

Das sieht komplett wirr aus - entweder ist RPC offen oder zu, daß die Hälfte geht und die andere Hälfte nicht ist ungewöhnlich... Glaskugel hat dafür keine Antwort Die IPs, zu denen das jeweils auflöst, ist der jeweilige PDCe? Nur der kann Trusts erstellen...

Warum Stubzone statt conditional Forwarder? Den Portchecker für genau solche Fälle habe ich vor einiger Zeit schon geschrieben: https://github.com/daabm/PowerShell/blob/master/Scripts/Test-TcpPorts.ps1 Aufruf mit -Computername <Name der Zieldomäne> -IncludeEPM Liefert Dir eine wunderbare Liste aller für Domänen relevanten Ports (die sind als Default im Skript hinterlegt) inkl. der dynamischen RPC-Ports. Vermutlich LSASS Remote Storage nicht erreichbar, weil ne Infrastruktur Firewall dazwischen hängt, aber das wäre jetzt Glaskugel