daabm

"Entpacken" wäre ne Idee... Mit ZIP kann Powershell nicht viel anfangen.

Also auf jeden Fall Gemauschel mit Servernamen...

Nein. Wenn die Vererbung deaktiviert ist, kommst Du "von oben" nicht mehr durch, Du mußt die "leafs" anfassen.

Zum Glück ist die Frühschicht wieder fleißig - gestern war hier Feiertag, daher "tote Hose". Jetzt Bergfest 🍺 Pils und Weizen steht schon lange kalt, bedient Euch.

Ich werf mal den AdminSDHolder in den Raum, hast Du das mal kontrolliert? Oder ist bei Deinen User-Objekte die Vererbung evtl. aus "anderen Gründen" deaktiviert?

Man "könnte" jetzt auf die Idee kommen, etc\hosts zu modifizieren Aber was spricht dagegen, daß die Kiste einfach weiter DC1 heißt? Alternativen stehen oben schon - CName, SPN, StrictNameChecking deaktivieren. Es spicht nichts dagegen, daß ein Filer unter mehreren Namen erreichbar ist. Unsere haben bis zu ca. 50 SPNs (aus "Gründen" ).

Also meine Version in Settings - Apps ist 2341. Vielleicht solltest Du Deine Informationen mal aktualisieren

Rückblickend sieht man meistens "die gute alte Zeit, in der alles einfacher war"

Ich hab auch keinen Account, aber in dem Fall würde ich auch sagen "erst mal nen Kaffee holen und dann noch mal nachschauen und -denken".

Nabend an Bord. So, auf geht's - TGIF-Bier steht bereit, Tisch ist gedeckt. Gläser muss sich jeder selber besorgen oder halt (ich bin ein Flaschenkind...) ohne auskommen Fürs Essen gibt es Spiegel oder Rühr, jeweils mit Ei. Heute 19-22°C, viel - sehr viel - zu warm für Ende Oktober. Die Frühschicht möchte ich nicht übernehmen, da bin ich noch zu dappig und nicht sozialtauglich 😂

Wäre mir neu, daß Trusts Schwierigkeiten mit unterschliedlichen DFL/FFL hätten Statt der Conditional Forwarder könntest Du auch Secondar DNS verwenden - aber das hängt vom Gesamtdesign ab (DHCP/DNS). Und wenn da "nur auf bestimmte Ressourcen" zugegriffen werden soll, dann sollte selektive Authentifizierung auf dem Trust aktiviert werden. Sonst sind alle überall "Authentifizierter Benutzer".

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