daabm

Dann schau ich heute mal der Automatik zu, wie sie nicht nur das Licht steuert, sondern auch mein Feierabendbier aus dem Kühlschrank holt, aufmacht, einschenkt und mir dann das Glas an den Mund führt

Indizieren? Powershell? Dokumentenmanagement? You name it - kommt drauf an, was genau Du erreichen willst und welchen Aufwand Dir das wert ist

Jepp. "Theoretisch" wird es erst im Domänenkonto geändert, und wenn das erfolgreich war, wird die lokale Version aktualisiert.

SRPv2 ist - korrekt - AppLocker. Was steht denn im Applocker Eventlog so drin? Wenn Du die Regeln loswerden willst, reicht es "normalerweise", HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SrpV2 zu löschen. Wenn die Regeln danach wiederkommen, laß ProcMon mitlaufen und schau, wer da reinschreibt und was dieser Prozess vorher so gelesen hat. Und daß AppLocker "blockt", ohne daß AppIdSvc läuft, habe ich noch nie gesehen.

Ich würd ja jetzt anfangen, Eventlogs zu wühlen Ich meine mich zu erinnern, daß SRP ins Application Eventlog protokolliert.

Würde mir umgekehrt genauso gehen - und deshalb "open failure committment" Ich mach bestimmt viel richtig (wie die meisten hier), aber wenn ich mal was falsch mache, dann darf das auch klar und eindeutig ersichtlich sein.

Warum heißt der Thread eigentlich "Letzter macht das Licht aus", wenn die meisten Beiträge von dem kommen, der "Erster macht das Licht an" macht? SCNR...

Asche auf mein Haupt - ich bin Ü50, bitte hilf mir über die Straße Das gilt nur für Domain Controller - der PDC ist der einzige DC, der PW-Policies verarbeitet. Für alle "normalen" Member in der Domäne gilt das ganz normale Vererbungsprinzip bis hoch zur Domäne. Keine Ahnung, welchen mentalen Aussetzer ich da hatte

Die Nachtschicht ist wieder am Start - ich schau mal, daß noch kurz durchgevoitelt wird und mach dann das Feierabendbier startklar

"Insufficcient access rights" - da würde ich mich nicht auf diese DSID versteifen, der Fehler heißt schlicht, der ausführende Account darf nicht. Die DSID Werte sind nicht öffentlich dokumentiert, manche findet man im Web, andere nicht. Und "Objekt finden schwierig"? Ich denke mal Du weißt welcher Account hier gerade agiert. Und Du weißt, welches Zielkonto er versucht zu ändern. Wenn nicht, wird's lustig

Für lokale Konten gilt das gleiche wie für Domänenkonten. Ist die Kennwortrichtlinie in einem GPO, das an der Domäne verlinkt ist, wird es von Membern nicht verarbeitet und gilt nicht für lokale Konten. Ist es "irgendwo" anders verlinkt, gilt es _ausschließlich_ für lokale Konten. Wenn der Computer noch in CN=Computers ist, greifen - korrekt, klar - keine GPOs, und eine Policy als Quelle von PW-Regeln scheidet schlicht aus. Kann dann nur noch eine lokale Einstellung sein -> go to "secpol.msc".

Dann sag das nächstens doch gleich mit dazu. Hier geht's genau um Passwortrichtlinen, also genau um die Ausnahme...

Negativ. Kennwortrichtlinien, die an der Domäne verknüpft sind, verarbeitet ausschließlich der PDC-Emulator. Kein sonstiger DC, kein Member. "net accounts" ist auf nem Member die schnellste Möglichkeit, die aktive PW-Richtlinie zu prüfen.

Wenn ein Account in der Delegierung "Lesen" und "Anwenden" hat, taucht er automatisch im Sicherheitsfilter auf. Der ist nur eine Convenience-Anzeige für die effektiven ACLs, da taucht alles auf, was halt "Read/Apply" hat. Was ist jetzt nochmal das aktuelle genaue Problem?

Microsoft setzt auf AppLocker, vielleicht solltest Du das auch tun SRP hat quasi kein Logging. AppLocker hat immerhin eigene Eventlogs.

Da bin ich leider raus - ich kenne SMB-Relays nur vom Hörensagen Brauchen tun wir sowas gottseidank nicht. Wobei Dir das vermutlich nicht mal hilft, weil ja die Authentifizierung immer noch ein Problem ist - die SMB-Relays, die ich bisher wahrgenommen habe, waren wegen unterschiedlicher Versionen.

Hersteller wechseln. Klingt b***d, ist aber so. Oder ein SMB-Relay davorsetzen (Raspi z.B. ).

Musst Du aktivieren, per default wird da nichts protokolliert: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/enabling-group-policy-preferences-debug-logging-using-the-rsat/ba-p/395555

Nachdem nix ein war, schalte ich auch nix aus, der Kühlschrank läuft eh immer 🍺

Loopback aktiviert...

Punkte wären mir egal, ich will Kröten/Asche/Konto voll

Das muß auch so sein. Wenn beim 1. Change was schiefgeht, hast noch den Fallback auf n-1. Wenn Du das nicht merkst und weitermachst, ist Kerberos kaputt Und grundsätzlich mag ich solche Skripts, die erst mal 250 Zeilen Doku und Hilfe enthalten. Ohne Ironie, ich mag das wirklich! Dazu ist es auch noch technisch sehr gut umgesetzt. Er vermeidet z.B. Test-NetConnection oder Test-Connection, nimmt statt dessen [Net.Sockets.TcpClient]. Und auch da hat er noch das letzte rausgeholt mit BeginConnect() und AsyncWaitHandle.WaitOne() 👍 Schade, daß er die Abhängigkeit zu den Modulen ActiveDirectory und GroupPolicy hat, sonst wär's sogar self contained.

Deny apply reicht. Wie gesagt, mit "deny read" passieren gern mal komische Dinge

Ich weise mal behutsam darauf hin, daß Datatables (falls das als Return-Typ in der SQL-Query verwendet wird) von PS automatisch in Arrays konvertiert werden. Ansonsten sind mir hier zu viele unklare Leerzeichen im Spiel

Um das mal zu präzisieren: "Deny Read" sollte man tunlichst vermeiden. Sonst kommt die GPO Core Engine nämlich so aus dem Tritt, daß gar keine GPOs mehr angewendet werden... Ja, sollte so nicht sein, ist aber so.