Passwortpolicy

[carnivore 10]

Hallo,

 

Ich bin in einer relativ großen  Windows 2008R2 Umgebung unterwegs, in der Sicherheit recht groß geschrieben wird. Momentan kümmere ich mich um unsere priviligierten Accounts, für die z.B. ein Passwortänderungintervall per granularer Policy von 30 Tagen gilt.

von diesen privilgierten Accounts existieren allerdings eine ganze Menge und einige davon werden auch mal 60 oder mehr Tage nicht benutzt, sind aber enabled. Daher altern diese PWs über die 30 Tage hinaus.

Gibt es einen Prozess/ Werkzeug , das z.B. einen zugeordneten Accountowner darüber informiert, dass bei einem seiner ChildAccounts das PW ablaufen wird?

 

Merci

carnivore

[h-d.neuenfeldt 21]

Lesen diese Accounts denn eingehende E-Mails ?

 

oder : Welchen Weg stellst du dir vor diese Accountinhaber zu erreichen ?

guck mal hier, das wäre ein Ansatz für eine Powershell Lösung

http://www.techguy.at/ablaufdatum-des-passwortes-der-ad-user-mit-powershell-auslesen/

[carnivore 10]

Hallo,

 

So ähnlich machen wir das jetzt auch. Ich hole mir alle enabled-Accounts per Powershell raus, vergleiche diese mit den PW-Richtlinien und versuche bei Abweichung irgendwie automatisiert die Account-Verantwortlichen zu erreichen.

Ich bin nicht so tief im Windows2008-ActiveDirectory drinnen und hoffe daher auf ein existierendes Microsofthilfsmittel per Policy etc., das Problem über einen Prozess eleganter ösen zu können.

Es hilft m.E. alleine relativ wenig, wenn nur diejenigen privilleged User aufgefordert werden, ihr PW zu ändern, die sich mindestens alle 30 Tage interaktiv neu anmelden. Inaktive User > 30 Tage hart zu disablen ist nicht praktikabel.

 

Wunschkonzert: Meldet sich ein AccountOwner am AD an, bekommt er per Policy nicht nur für seinen aktuellen Account eine Passwordänderungsaufforderung bei bzw. schon vor dem PW-Ablauf, sondern auch für seine Childaccounts. Idealerweise könnte ich im Account den Accountowner bzw. eine Ownergruppe direkt eintragen.

 

Wenn es andere Ansätze gibt, gerne! Es muss nur irgendwie automatisiert werden können.

 

carnivore 

[Daniel -MSFT- 129]

Von diesen privilgierten Accounts existieren allerdings eine ganze Menge und einige davon werden auch mal 60 oder mehr Tage nicht benutzt, sind aber enabled. Daher altern diese PWs über die 30 Tage hinaus.

 

Was genau ist denn Dein Problem mit den Accounts, wenn sie länger als 30 Tage nicht benutzt werden? Welches genaue technische Problem tritt danach auf, das es zu lösen gilt?

[carnivore 10]

Warum setzt man ein Passwortalter? Damit ein abgegriffener Hash eines Accounts nicht innerhalb der Gültigkeitsdauer des PWs entschlüsselt werden kann, so zumndest mein Verständnis.

Windows ist noch dazu so "liebenswert" jedem einfachen authenticated User forestweit sensible Accountdaten (pwdlast, lastlogontimestamp, groupmembership, admingroup etc.) aller Accounts per einfacher ldap-Query zu präsentieren, so dass ein Angreifer sich ganz bequem die passenden Accounts raussuchen kann.  (oder gibts da einen gangbaren Weg dies zu verhindern?)

 

Daher fände ich es schon sinnvoll, möglichst wenige Accounts mit pwdlastset > minpwdage im AD zu haben.

 

Konkret:ist  es ist unsere Corporate Security Policy für Accounts, die ein maximales PWDAge einfordert. Und die unterscheidet nicht zwischen benutzten und unbenutzten Accounts, was wiegesagt m.E. absolut sinnvoll ist.

bearbeitet 28. Mai 2014 von carnivore

[Stoni 10]

Hi carnivore,

wenn du schon von highquality Usern etc sprichst, und dann noch von sensiblen Daten etc. würde ich nicht mal  30 Tage einstellen. Dann sind das für mich "Highsensitiv" User. Davon mal ab, was sicheres gibbet nicht.

 

Wenn dem so ist, müste sich auf alle Fälle mal die GF Gedanken machen, und denen per BS sagen, so und so.

 

mfg

Stoni

bearbeitet 28. Mai 2014 von Stoni

[Daniel -MSFT- 129]

Hi Carnivore,

 

Warum setzt man ein Passwortalter? Damit ein abgegriffener Hash eines Accounts nicht innerhalb der Gültigkeitsdauer des PWs entschlüsselt werden kann, so zumndest mein Verständnis.

 

Da ist, glaube ich, Dein Verständnis falsch. Ein maximales Passwortalter setzt man, damit sichergestellt ist, dass nicht mehr benutzte Accounts automatisch ablaufen und nicht jemand, der (wie auch immer) Kenntnis über ein Password erlangt, es unlimitiert nutzen kann. Deine Bedenken wegen des Hashes haben damit gar nichts zu tun. Mit dem Hash würde man auch nicht das Passwort entschlüsseln, sondern einen sogenannte "Pass the Hash"-Angriff verfolgen. Deswegen hat das Passwortalter nichts mit dem Problem zu tun - wenn das Passwort abgelaufen ist, ist der Account gesperrt. Selbst wenn man einen Hash hätte, könnte man sich mit dem nicht mehr gegen einen Account mit abgelaufenen Passwort authentifizieren.

 

Wenn Ihr Euch Gedanken über "Pass the Hash" macht, dann müsst ihr da ganz anders rangehen. Ich gehe mal davon aus, dass wir hier nicht ünber LM Hashes reden, sondern über NT Hash aufwärts. Der Hash kann von keinem unprivilegierten Benutzer abgegriffen werden. Generell muss man sich hier Gedanken machen über die genaue Verwendung von privilegierten Konten und die Absicherung der Computer machen, auf denen solche Accounts verwendet werden. Siehe dazu:

• How Password Hashes Work
• Pass-the-Hash Attacks
• Pass-the-Hash Defenses

Du kannst jetzt Scripte nehmen und zum Beispiel sobald ein Domaincontroller gefunden wird (ist ein Netztwerkereignis), einmal am Tag eine Benachrichtigung für den User aufpoppen lassen, welches der ihm zugeordneten Accounts demnächst ablaufen. Du kannst das zentral machen und Benutzer per Mail über Accounts informieren, die in Kürze ablaufen. Dafür brauchst Du eine Datenbank, in der der Besitzer eines Accounts hinterlegt ist. Das geht dann schon in Richtung Identity Management - wir machen das intern mit Forefront Identity Manager.

 

Im Hinblick auf das genannte Szenario ist das aber Security Theater - das geht voll am Problem vorbei. Auch das Informationen über LDAP eingesehen werden können (ich habe jetzt nicht geprüft, welche Berechtigungen dafür tatsächlich notwendig sind) ist nicht das eigentliche Problem. Du musst doch die privilegierten Accounts generell schützen und nicht die Information versuchen zu verstecken, dass diese existieren.

 

Daher meine Frage: Was genau ist das sicherheitstechnische Problem von Accounts, deren Passworte abgelaufen sind? Was macht ihr mit Accounts, bei denen der Besitzer die Warnung ignorieren würde und das Kennwort nicht ändert?

 

Have fun!
Daniel

 

P.S.: Meine Frage auch nicht "Warum setzt man ein Passwortalter?", sondern "Was ist das Problem mit Accounts, deren Kennwort abgelaufen ist?" Ein kleiner, aber feiner Unterschied.

bearbeitet 29. Mai 2014 von Daniel -MSFT-

[NorbertFe 2.035]

Hi Carnivore,

 

 

P.S.: Meine Frage auch nicht "Warum setzt man ein Passwortalter?", sondern "Was ist das Problem mit Accounts, deren Kennwort abgelaufen ist?" Ein kleiner, aber feiner Unterschied.

 

So klein ist der Unterschied nicht, wie ich denke. ;)

[daabm 1.355]

Im Hinblick auf das genannte Szenario ist das aber Security Theater - das geht voll am Problem vorbei. Auch das Informationen über LDAP eingesehen werden können (ich habe jetzt nicht geprüft, welche Berechtigungen dafür tatsächlich notwendig sind) ist nicht das eigentliche Problem. Du musst doch die privilegierten Accounts generell schützen und nicht die Information versuchen zu verstecken, dass diese existieren.

 

Entweder den Security Descriptor aller Objekte ändern und AuthUsers entfernen oder List Object Mode aktivieren (entspricht dem "Traversal Checking" in Verbindung mit ABE in NTFS).

[carnivore 10]

Hallo Daniel,

Danke für deine Erklärungen,

 

das Securty Problem sehe ich darin, dass ein Angreifer sich mit einem Passwort bei einem  Account, dessen PW abgelaufen ist, anmelden und das PW ändern kann. Besser kann ich es leider nicht erklären.

 

Wenn das Problem mit Boardmitteln nicht zu behben ist, dann OK!

 

Danke für deine ausführliche Antwort

carnivore

[NorbertFe 2.035]

Wie meldest du dich denn mit einem abgelaufenen Kennwort an?

[Daniel -MSFT- 129]

Das Securty Problem sehe ich darin, dass ein Angreifer sich mit einem Passwort bei einem  Account, dessen PW abgelaufen ist, anmelden und das PW ändern kann. Besser kann ich es leider nicht erklären.

 

Wenn ein Angreifer das Kennwort eines Accounts hat, dann kann er sich mit dem Kennwort anmelden. Das überrascht mich jetzt nicht. Das ist aber unabhängig davon, ob das Kennwort abgelaufen ist oder nicht. 

 

Wenn Du sowas verhindern willst, dann brauchst Du Two-Factor-Authentifizierung. Adminanmeldung nur mit Smartcard zum Beispiel ist eine Lösung.

 

Wenn das Problem mit Boardmitteln nicht zu behben ist, dann OK!

 

Klar geht da was mit Boardmitteln. Ich verstehe nur das Problem noch nicht. Du kannst auch einen Task täglich laufen lassen, der alle Accounts mit abgelaufenen Kennworten komplett sperrt. Viel Spaß beim Umsetzen - die Anwender und den Helpdesk wird es nicht erfreuen.

 

Ich verstehe aber immer noch nicht das eigentliche Problem. Daher ist eine Lösungsempfehlung schwierig.

bearbeitet 29. Mai 2014 von Daniel -MSFT-

[carnivore 10]

Wie meldest du dich denn mit einem abgelaufenen Kennwort an?

?

einmal das abgelaufene Kennwort eingeben, dann ein Neues + Bestätigung

[Daniel -MSFT- 129]

Und wo hat der Angreifer das Passwort her? Und wie unterscheidet sich das Szenario, ob das Passwort abgelaufen ist oder nicht?

[carnivore 10]

Drehen wirs mal um:

Welchen Wert hat die PwdMaxAge-Policy, wenn nicht alle enabled Accounts berücksichtigt werden?

 

sobald ein Auto auch nur auf der Straße steht, muss es sich an die SecurityPolicies des Straßenverkehrs halten und u.a. versichert sein, alle 2 Jahre eine neue TÜV-Plakette erhalten, etc.

bearbeitet 1. Juni 2014 von carnivore