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:

Zitat

Confirm-MsolDomain : Unable to verify this domain because it is used elsewhere in Office 365. Remove the verified domain 
from the other service before adding it here.

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

vor einer Stunde schrieb testperson:

Dem könnte man ja dann theoretisch mit dem DSInternals PowerShell Modul wiederum nachgehen. ;)

und praktisch: 

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

vor 9 Stunden schrieb magheinz:

Löst euch von dem "ob" und baut Prozesse für das "wann". Ihr werdet die Ransomware nicht verhindern. 

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

vor 4 Stunden schrieb casi4712:

@ sandyB, danke das war mir bekannt, dass man PS Befehle innerhalb der cmd ausführen kann, was ich auch nutze. Aber kann ich diesen Wert dann auch jeweils zur Laufzeit abspeichern,um Ihn als Verzeichnisnamen zu nutzen? Das geht doch dann wohl wieder nicht?

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.

Zitat

Ich möchte auf einem Remoterechner den Namen auslesen und diesen zur weiteren Verwendung in eine Variable abspeichern.

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. 

vor 11 Stunden schrieb daabm:

Man möge mich als pedantisch bezeichnen, aber wo ist bei Kerberos der Zuammenhang zwischen Computer und User?

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.