daabm

Wie wär's mit nem gebrauchten Business-Rechner? Gibt's ab ca. 150,- dann noch SSD rein und mit deutlich unter 300,- hast ne Kiste, die mit jeder Windows-Variante kompatibel ist...

Nix gegen Bootcamp, aber alles hat Grenzen

Das mit "Sicherheit herabsetzen" ist eine Folge von NLA - dann klappt die Anmeldung mit abgelaufenem Kennwort per RDP nicht mehr... Das mit der Sinnhaftigkeit der regelmäßigen Kennwortänderung wurde ja schon erwähnt - Microsoft und das BSI sind von dieser Empfehlung abgerückt, könnte diese Cyberversicherung ja mal nachziehen. Besser "lang - sehr lang".

PS: Rein aus Neugier - wie implementiert man eine FGPP für "4 OUs"? Bei mir war das bisher immer für "Gruppen", nicht für OUs

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.

vor 7 Stunden schrieb NorbertFe:

Nee aber ne Schachtelung. ;)

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.

vor 34 Minuten schrieb Cryer:

Nur den Profilordner zu löschen reicht seit Windows 7 (vielleicht auch schon seit Vista) nicht mehr. Du musst dann manuell in der Registry noch den entsprechenden Benutzereintrag entfernen.

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

vor 13 Stunden schrieb testperson:

Dann sollte aber auch hier (https://www.faq-o-matic.net/2007/06/08/welcher-name-ist-der-beste-fuer-eine-ad-domaene/) geschaut werden. Insbesondere

, da oben die "Zukunft" bzw. "vorausschauend" angesprochen wurde.

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.

vor 8 Minuten schrieb MurdocX:

Gibs zu, Du würdest dich doch nie wieder mit kleinere Umgebungen abgeben wollen 

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

vor 13 Minuten schrieb mcdaniels:

Wäre dann wohl zb auch im Falle von div. Cryptolockern der Fall, die ja auch so arbeiten (Passwörter etc. abgreifen ev. auch über den Hash (oder gar keylogger) -> Domänenadmin -> dann gute Nacht).

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

Am 25.9.2020 um 17:01 schrieb MurdocX:

NTLM-frei wäre schon eine schöne Sache für die Zukunft...

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.

vor 49 Minuten schrieb mcdaniels:

Wobei: Ist das Ausgangsproblem mit dem Client mit der aktuellsten Win 10 Version nun ein Sicherheitsfeature, oder ist auf dem Client einfach etwas verbogen?

 

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.

vor 4 Minuten schrieb MurdocX:

Einmalige Anmeldung an einem Client reicht um sich das Bein zu stellen.

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

vor 2 Minuten schrieb mcdaniels:

vor 4 Minuten schrieb MurdocX:

Sind die Domänen-Admins noch Mitglied in den Administratoren?

 

lusrmgr.msc ist die Konsole zum nachsehen.

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.

Am 29.9.2020 um 12:40 schrieb MurdocX:

Deshalb kosten gute IT´ler Geld,

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.