daabm

Wenn Du vorher eh alles löscht, ist es in der Tat wurscht. Du kannst aber durchaus bei "Aktualisieren" bleiben - der Mehraufwand für Dich wäre nach dem Ändern der serverseitigen Defaults, daß Du das bestehende Item kopieren/einfügen mußt und das alte danach löschen. Vorteil für den Anwender: Seine Drucker werden nur neu erstellt, wenn es erforderlich ist. Du "könntest" auch mal schauen, ob Du mit Zielgruppenadressierung was besseres hinbekommst - so als Idee. Weil das Neuerstellen halt wirklich Zeit frißt.

Edge hat doch nen eingebauten Task Manager, da könnte man mal schauen, ob bestimmte Tabs "herausragen"

Früher ging das - dafür muß aber auf "Gemeinsam" der Haken "Entfernen wenn nicht mehr angewendet" raus. Und dann brauchst Du für das Entfernen tatsächlich ein "gegenläufiges" Item mit umgekehrter Zielgruppenadressierung, das überzählige Drucker dann löscht.

Das erinnert mich jetzt dunkel an ein ähnliches Problem, das Lotus-Anwendungen mal hatten. Aber das ist so lange her, daß ich den Fix dafür nicht mehr weiß 😫

Der direkt sichtbare Vorteil des PAM-Trusts: Die Domain Admins der verwalteten Domänen sind leer. Damit existiert zunächst kein Angriffsziel. Der indirekte Vorteil wäre wohl JIT-Admin mit kurzer Token-Laufzeit. Und da separater Forest, könnte man auch noch auf die Idee kommen, zweimal täglich krbtgt-Kennwörter durchzuwechseln

IMHO: Wenn kein Standarddrucker definiert ist, wird der älteste Drucker zum Standard. Oder war's der neueste? Einer von beiden In Win32_Printer findest "Default", das ist bei einem "True", bei allen anderen natürlich "False".

Gestern das Feierabendbier wieder ohne AI genossen. Die Lippe wird heilen, und der ausgeschlagene Zahn gibt mir einen wilden Touch

Das heißt für mich eigentlich, daß "Domain Admins zum Owner machen" nicht wirklich die Lösung ist, oder? Weil joinen können muß ich ja trotzdem noch, also die alten Bedingungen (Schreibzugriff) sind hoffentlich noch in Kraft?

made my day Wir nutzen GPOAdmin, funktioniert wie die 1. Wird leider nach der Anzahl Accounts in den verwalteten Domains lizenziert (also nicht nach Anzahl der GPOs oder Anzahl der Admins/GPOAdmin-Nutzer, sondern Endbenutzer) und kann damit sehr teuer werden. AGPM tut's "eigentlich" auch. Leider nicht bei unserer Größe, Anzahl Admins und vor allem Anzahl Domains - ohne den GPO-Sync von GPOAdmin müssten wir sehr viel skripten... Und einen Lösungsvorschlag für "arme" hätte ich auch noch: Im SCM Toolkit ist AFAIR ein GPO Diff Tool dabei. Jetzt braucht man nur noch ein Backup von jeder Version. Das läßt sich per Skript recht einfach erzeugen. Und wenn man dieses Skript auf dem PDC mit einem Eventtrigger ausstattet und GPOs mit einer Auditing-ACL versieht, ist man schon fast am Ziel, wenns nur ums Nachvollziehen geht. Oder man läßt stupide das hier alle 10 Minuten laufen - braucht nicht viele Ressourcen... https://evilgpo.blogspot.com/2012/12/backup-nur-fur-feiglinge-oder-auch-fur.html

Wir haben das leider auch nicht mitbekommen, und es hat uns voll erwischt... Derzeit prüfen wir, ob unser Offline Domain Join durch den Fix aus dem Artikel von Günter Born repariert werden kann. Andere Prozesse haben's evtl. schwerer... Hintergründe: Wir joinen Clients über den Offline-Join von netdom. Dafür verwenden wir einen Service-Account, der natürlich kein Dom-Admin ist. Das resultierende File wird zum Client transportiert, so daß der ohne Join-Credentials auskommt. "Früher" haben wir die Clients mit einem dedizierten Join-User gejoint. Wird jetzt ein Client reinstalliert, der mit dem früheren Verfahren "ursprünglich" erstellt wurde, kan das Djoin-File nicht mehr erstellt werden - "Reuse prohibited". Klar - der Account wurde unrsprünglichen dedizierten Join-User erstellt, der jetzt verwendete Account ist ein anderer Für kleinere Umgebungen, in denen sich nicht sooo viel ändert bei den Clients, würde ich einfach die Dom-Admins zum Owner aller Member machen. Sollte per dsacls oder setacl nicht der riesen Aufwand sein, das zu skripten und auf den Domain Controllern per Task auszuführen. Könnte man sogar noch triggern auf "Computer Account created", dann wäre es eine "nachhaltige" Lösung

Ich versuch's noch mal: Was _genau_ versuchen sie zu erreichen? Domain based DFS? Beide DCs als Namespace-Server? Target-Shares in beiden Standorten vorhanden und verfügbar? Fragen über Fragen Du hast Fragen, Du suchst Lösungen. Dann mußt Du auch Input liefern.

Doch, meistens hat er. Schau Dir mal die Traversal/PrivEsc Pfade an, die Bloodhound/Scanhound Dir zeigt... Das hat sogar uns erwischt, und wir wissen eigentlich, was wir tun 🙈 (Also "erwischt" im Sinne von "unerwartete Traversals", nicht im Sinne von "Ransomware")

Was _genau_ versuchen sie zu erreichen? Also welcher Prozess auf dem Client versucht welchen Dienst auf dem DC zu erreichen? Und wIe gesagt, AD ist nicht DNS. AD ist site aware, aber DNS nicht. Zum DC Locator: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/domain-locator-across-a-forest-trust/ba-p/395689 Da steht zwar auch noch "across forest trust", aber die Grundlagen sind auch dabei.

Sch.... AI. Der letzte Step hat echt weh getan, ich mach das lieber wieder selber

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".