SandyB

Das stimmt so nicht. IAM/PAM Lösungen sind weit verbreitet. https://www.kuppingercole.com/report/lc79014

Das große Problem insbesondere beim Umgang mit Passwörtern ist das nicht Einhalten dieser BSI Vorgabe aus ORP.4.A8 [Benutzer, IT-Betrieb] (B): Passwörter DÜRFEN NICHT mehrfach verwendet werden. Für jedes IT-System bzw. jede Anwendung MUSS ein eigenständiges Passwort verwendet werden. Gerade Administratoren verwenden ein und dasselbe Passwort zum Surfen, Email-Lesen und für den administrativen Zugriff auf 100 Server und Applikationen. Ob dieses PW 12 oder 15 Zeichen, 60 oder 6000 Tage Lebensdauer hat, spielt für die Sicherheit eine untergeordnete Rolle.

Der Support war nicht so wirklich hilfreich. Außer einmal der Dispatcher aus USA hat sich niemand mehr gemeldet. Bin dann selbst draufgekommen: Nachdem ich eine neue Triallizenz für die alte Azure-Umgebung beantragt hatte, hatte ich das Microsoft 365 Admin Center wieder zur Verfügung und konnte die Domäne rauswerfen.

Vielen Dank für den Tipp! Er beschreibt genau mein Problem. Leider funktioniert das Skript auch nicht. Ich bekomme eine ähnliche Meldung wie im Admincenter zurück:

Ich habe vor langer Zeit mit Azure gespielt und mir dabei eine Azure Eval-Testumgebung erstellt. Darin habe ich eine damals nicht benötigte eigene Domäne verifiziert und verbunden. Nun einige Zeit später möchte ich meine Domäne wieder aus der alten Eval-Umgebung entfernen, um diese an anderer Stelle zu verwenden. Diese andere Stelle kann meine Domäne solange nicht verifizieren, solange diese noch in der altenEvalumgebung hängt. Ich kann mich in der alten Azure-Evaldomain anmelden, der Eval-Zeitraum ist längst abgelaufen. In der Microsoft 363 Online Oberfläche gibt es kein Admincenter mehr, in dem ich die Domäne entfernen könnte. (s. Anhang). Erneuern kann ich die Eval-Lizenz wohl auch nicht Ich suche schon seit geraumer Zeit, aber finde keine Lösung meine Domäne zu "befreien" Danke Sandy

und praktisch: https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-password-protection-is-now-generally-available/ba-p/377487

Die "Incident Response Methodologies" der Cert Societe Generale sind eine excellente Prozessgrundlage für weitere individuelle Anpassungen https://github.com/certsocietegenerale/IRM https://github.com/certsocietegenerale/IRM/blob/master/EN/IRM-17-Ransomware.pdf Bei uns ist für den Incident Response u.a. Kansa im Einsatz https://www.powershellmagazine.com/2014/07/18/kansa-a-powershell-based-incident-response-framework/ https://github.com/davehull/Kansa

Danke ecuh! Klist purge wirft die Tickets raus, das funktioniert! Die groupmemberships 'WHOAMI /all' bleiben erhalten. Werden diese mit einem neuen KerberosTicket aktualisiert? Ich habe leider keine moeglichkeit selbst zu testen.

Wenn man unter Windows10 den angemeldeten AD-User in eine neue Gruppe steckt, muss sich der user erst ab- und wieder anmelden, damit die neue Groupmembership wirksam wird. Gibt es einen "renew" Befehll, um diesen Aktualisierungsprozess auch ohne logon/logoff zu starten? Danke Sandy

Du kannst den Filenamen in eine temporäre Datei oder einen temporären Regkey speichern und anschließend wieder auslesen. Der Weg über eine Environmentvariable geht vermutlich auch. Ich bin allerdings kein Freund der PS und erst recht nicht von Batches, Daher kann ich nur eine Idee liefern.

Man kann in einer batch Datei Powershellbefehle ausführen: powershell -Command "& {(Get-WmiObject -ComputerName 192.168.178.55 -Class Win32_Bios).PSComputername}" Vielleicht hilft das weiter.

Meine Meinung bisher war, dass ohne Mitglied in der Domäne zu sein, - bekommt der Client keine Policies (u.a. .\System\Kerberos) - fehlen dem Client die notwendigen SPNs für Kerberos - gibt es keine mutual authentication -> No Kerberos on non-domain clients. Wiegesagt, ich akzeptiere gerne, dass meine Überlegungen falsch waren.

Ich war felsenfest überzeugt, dass für eine Kerberos Authentication sowohl ein Computer- als auch ein Userkonto vorhanden sein müssen. So kann man sich irren. Danke!

Ich bin bis jetzt davon ausgegangen, dass eine Domain Membership Voraussetzung für den Austausch von Kerberostickets ist. Ich werde versuchen, mich besser einzulesen.

Dass eine Domänenaufnahme mit Kerberos und nicht mit NTLM abgesichert wird. Es würde mir eine Reihe von Problemen lösen, wenn dem so ist.

Jetzt bringt ihr mein Windows Bild vollkommen zum Einsturz

Echt nicht? Welches Protokoll dann?

Alles klar! Mittlerweile habe ich auch die Onlinestellen wieder gefunden: https://enterprise.verizon.com/resources/reports/DBIR_2018_Report.pdf https://enterprise.verizon.com/resources/reports/2019-data-breach-investigations-report-emea.pdf Ich finde Statistiken interessant, weil sie manche Meinungen unterstützen, andere widerlegen. (z.B. das BSI) Ich leite für mich aus diesen beiden Verizon-Statistiken her, dass die Bedeutung super-sicherer User-Passwörter überschätzt wird. Klar sollen User-Passwörter vernünftig-sicher sein, aber ob es jetzt 8 oder 16 Zeichen, 6 oder 24 Monate maximales Alter etc. sind, spielt bei den aktuellen Angriffsvektoren unterm Strich kaum eine Rolle für die Gesamtsicherheit. Das ist meine Interpretation

das Gesamtpaper ist leider zu groß zum Hochladen. Aber auch dann wärst du vermutlich nicht zufrieden,

Die relative Anzahl an Attacken auf schwache Passwörter war 2018 lt. verizon sehr gering (<0.4%). Welche Auswirkungen auf diese Häufigkeit eine verändertes Wechselintervall oder unterschiedliche Passwortlängen haben, kann m.E. niemand sagen. Vermutlich liegen wir da im Promille-Bereich. Eine Empfehlung zu entfernen, die fast keinen Effekt hat, ist sinnvoll.

Hi, Kann man in einer AD-Domäne NTLM komplett disablen? "Deny all" in https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain Dann kann doch kein neuer Rechner mehr in die Domain joinen, oder habe ich einen Denkfehler?

Ehrlich gesagt nein. Nicht weil ich nicht wollte, sondern weil ich selbst nur wenige Details mitbekommen habe.

Die Dämme scheinen gehalten zu haben. Dank ziemlich aufwändiger Protectionkonzepte konnte der Angriff rechtzeitig unterbrochen werden und die Kill-Chain lässt sich mit den vorliegenden Monitoring-Daten relativ gut zurückverfolgen. Trotzdem Danke für den seelischen Beistand gestern abend

Gibt es für dieses Scenario kein standardisiertes Vorgehen von Microsoft? @daabm: Plattmachen ist keine Alternative, @v-rtc: Soweit ich bis jetzt weiß, wurden Golden Tickets entdeckt und so flog die Attacke auf. Nein, ich bin weder Dienstleister, noch AD-Experte, eher das "Mädchen für Alles", das sich auf morgen schonmal vorbereiten will.

Hi, Gibt es eine Beschreibung oder einen Prozess wie man verfahren soll, um aus einer kompromittierte Domäne einen erfolgreichen Angreifer rauszuwerfen. Beispielsweise habe ich schon gefunden: - Neue Passwörter für die Adminaccounts - Reset krbtg-Account - Trusts resetten - SID-History löschen - disable "rc4_hmac_md5" and below ciphers for Kerberostickets - Wo im Directory könnte ein Angreifer mit Adminrechten noch Backdoors eingebaut haben, Da gibt es sicher noch viele weitere Möglichkeiten. Die genaue Größe und Struktur der Domäne kenne ich selbst noch nicht. Aber sie ist jedenfalls international verzweigt und läuft auf Windows 2012R2 DCs.