daabm

Ja, hätte er :-)) Und er kann noch ergänzen, daß das auch in einem Enterprise-Umfeld prima funktioniert. Bissele nachdenken, passende Variablen deployen (bzw. durch Startskripts erzeugen lassen) und die ganzen lokalen Admin- und Rechtegruppen füllen sich magisch wie von selbst.

Nachträglich deaktivieren entfernt nicht zuverlässig alles, was vorher mal kam. Und "erzwungen" kommt eh immer noch.

Jaja, und tailspin noch. Wer kennt den Rest? https://social.technet.microsoft.com/wiki/contents/articles/1117.list-of-fictional-companies-used-in-microsoft-material.aspx

Ja, Titel "my long way from contoso.local to northwindtraders.com and beyond"

Nein. Gibt Third Party für sowas, einfach mal ne Suchmaschine bemühen.

Sei net so pingelig - LDAP bezeichnet das auch als Kette... 1.2.840.113556.1.4.1941

Genau das will er ja nicht erreichen Er will nen Client, wo er die Zeit ändern kann - das ist ein Benutzerrecht, kann man prima per GPO steuern. Frage wäre nur "was ist auf dem Client da aktuell gesetzt?" Sysinternals "accesschk -a *" verrät, wer welche User Rights (bzw. Privileges) tatsächlich hat. "gpresult / report.html" erstellt Dir nen grafischen Bericht, in dem steht, wo es herkommen dürfte.

...und seit Windows 8 mit Store und Apps kommt noch ein wenig mehr in HKLM dazu. Besser supportete Varianten verwenden - per GUI oder über Win32_UserProfile.

Dem kann ich nur zustimmen... Wir haben das Problem grad, daß alle "Alt-Domains" (DNS und AD) alle alten Firmennamen enthalten - au weia... Der neue interne Namensraum ist generisch und firmenunabhängig.

Doch - so ein Mid-Size Familienunternehmen mit 10 bis 20 k Accounts, das wäre meine Wunschumgebung. Am besten international, damit noch ein wenig Herausforderung dabei ist. Wir haben zu viele Domains, wir haben zu viele Schrauben zum Drehen, da geht zu oft hinten eine Mutter ab, wenn man vorne wo dreht... Weil man's einfach nicht wissen kann. Aber jetzt wird's glaub o/t, ich bin damit mal aus meinen eigenen Stories raus und warte auf Fragen des TO @mcdaniels Ich find's gut, daß Du reagierst, wie Du reagierst. Wie @MurdocX oben schon schrub: Der Admin ist in SOHO-Umgebungen oft halt "der" Admin - Domäne, Server, Clients, da gibt's keine Delegation und keine Account-Trennung. Schön, daß Du daran arbeitest

AppLocker oder Software Restriction Policies (SRP) sind eine gute Gegenmaßnahme. Erstaunlich günstig (da in Windows enthalten), erstaunlich einfach "grundlegend" zu konfigurieren, erstaunlich wirksam. Dazu noch anständige Makro-Policies für Office und der Fisch ist im wesentlichen geputzt. Bei c't gibt's sogar ein Standalone-Utility für SRP.

Über Tiers müssen wir hier glaub noch nicht reden, ich hab das inzwischen verinnerlicht AD ist kein Konzept, nur ein Produkt. Die Konzepte entwickeln sich, und ESAE sieht aktuell nicht soo schlecht aus. Wenn man die Tier-Trennung durchhält, ist es brauchbar. Und bisher sieht es sehr danach aus. Unser Hauptproblem aktuell: Das IDM, das alle Non-Domain Admins provisioniert, kann pro User nur einen Account - manche bräuchten aber mehrere (Clients, Terminal Server, SQL-Server). "Toxische Rechte-Kombination" nennt man das dann... Dom-Admins werden nur manuell provisioniert, ohne IDM -> ein Einfallstor weniger. Und man sollte natürlich keine Angst haben vor Umfeldern mit Duzenden Domains und Forests

Versuchen wir grad. SCVMM - negativ. Cluster - negativ. SCCM - negativ. (Alles noch 2016 oder älter - ab 2019 soll es angeblich besser werden). "Dieser Weg wird kein leichter sein"... Das NTLM Operational Eventlog ist unser täglicher Begleiter.

Ich werf mal meinen Senf dazu: Deine Ideen sind richtig, der Weg ist auch richtig. Und wie schon gesagt wurde: Einen Domain Admin kannst Du NICHT wirksam einschränken, von dem Gedanken mußt Du Dich verabschieden. Oder allgemeiner: Wer auch immer Admin des aktuellen Scope ist, kann in diesem Scope nicht wirksam eingeschränkt werden. Wir haben das (in einem größeren Umfeld) auch so umgesetzt: Jeder Service hat seine Service-Gruppen, die sind dann User oder Admin für die Server, die dazu gehören. Domain Admins gehören nicht dazu, können sich nicht mal anmelden. Andersrum natürlich auch nicht. Geht mit ein wenig GPO-Voodoo relativ einfach https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html Und lass Dich von den Kommentaren von Nils nicht entmutigen - Du bist jetzt schon weiter als 95% aller Admins.

Das weiß von uns niemand, da wir nicht wissen, wie Deine Domäne aussieht. Hier werden alle (!) lokalen Benutzerrechte (47 Stück, in der Tat) und Gruppenmitgliedschaften per GPO durchgesetzt, lokale Änderungen sind durch lokale Admins zwar möglich (geht auch nicht zu verhindern, Admin ist Admin), aber nicht persistent. Ob das bei Dir auch so ist? Warum sollte ein Domain Admin bei Dir in den lokalen Admins drin sein - oder warum sollte er das nicht? Ich kann es nicht sagen. Ja, Klassiker. Ameisenlöwe - Loch graben, reinlegen, auf Beute warten Sofortige Minimalprävention: Cached Credentials auf 1 runtersetzen. Aber halt nur minimal. Besser siehe oben, Deny logon locally.

Ja, steht ja schon oben: 1. "Deny logon locally" per GPO auf allen Clients für "Domain\Domain Admins" und "Domain\Administrators" 2. Neue AD-Gruppe "Client-Admins" 3. Group Policy Preferences - Local Users and Groups - Administrators: Neue Domänengruppe hinzufügen (mehr dazu: https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html ) 4. Neue AD-Gruppe mit Accounts füllen PS: Punkt 1 als letztes umsetzen, wenn sicher ist, das 2-4 funktioniert

Nö, das verstehen wir schon

Ja, sag ich doch. "whoami" sagt Dir, in welchen Gruppen du EFFEKTIV Mitglied auf dem Client bist. Administratoren fehlt. Und die Domain Admins sind nicht in der "lokalen" Gruppe "Administratoren"; sondern in der "domänenlokalen" Gruppe "Administratoren". Kleiner, aber wesentlicher Unterschied.

Nein, nicht aktiviert. Kein Bedarf aktuell. SafeDLLSearchMode muß reichen

Ja, gerade geprüft. In deinem whomai-Output oben steht aber nichts von "Administratoren"... Und eine Konsole braucht man dafür auch nicht: "net localgroup administratoren" reicht meistens

Naja, da es eh schon wirr ist, hier noch ne ganz wirre Lösung: Scheduled Task, Account "SYSTEM", Trigger "Bei einem Ereignis" Event-ID raussuchen für interaktive Benutzeranmeldung, Delay 15 Sekunden. Action dann ein Skript, das den angemeldeten User findet, dessen Gruppenmitgliedschaften auswertet und ggf. installiert. Besser wird's dadurch aber auch nicht

@SaschaVolk Du bist schon zu sehr auf die von Dir ausgedachte Lösung fixiert. Besser wäre hier im Forum erst mal "klar die Anforderungen definieren" und die Anfrage dann von jeder dafür möglichen Lösung zu befreien. Das führt in der Diskussion erfahrungsgemäß zu den besten Lösungsvorschlägen.

Schlechte leider auch Könnte man jetzt per Reverse NAT lösen, ändert aber nichts daran, daß Du Recht hast und man in produktiven Business-Netzen einen großen Bogen um 192.168/16 machen sollte.

Fehlermeldungen im Wortlaut sind immer hilfreich. Ein "whoami /groups" auf der Commandline sagt Dir schon mal, wer Du eigentlich bist. Und dann sehen wir weiter PS: Warum meldet sich ein Dom-Admin auf einem Client an? Der hat da nichts verloren, dafür erstellt man sinnvollerweise eine AD-Gruppe "Client-Admins".

@tesso hat's schon zweimal erwähnt: Alles, was hinter Invoke-Command steht, findet REMOTE statt. Und dort (auf dem anderen Rechner) existiert diese Variable $UserSID nicht, weil Du sie nicht per -Argumentlist an Invoke-Command übergibts. Da gibt's glaub Millionen von Fragen dazu bei Superuser.com Variante 2 funktioniert, weil Du hier kein Remote-Command ausführst, sondern lokal einfach zu einer Remote Registry verbindest. Die Befehle laufen aber nach wie vor lokal, also da, wo $UserSID existiert. Alles nur eine Frage des Scope