Nutzer, die ihr Passwort vergessen haben, stehen normalerweise ganz oben auf der Liste der Sorgen und Nöte von IT‑Administratoren. Wer einen Beweis möchte, kann hier Umfrageergebnisse lesen, die diese Feststellung belegen. Gleich an zweiter Stelle stehen Kontensperrungen. Diese sind eng mit dem ersten Punkt verbunden und beinahe ebenso häufig wie lästig. Diese Probleme ließen sich früher leichter lösen, weil es nicht derart viele verschiedene Geräte gab.
Wenn ein Mitarbeiter sich an den technischen Support gewandt hat, entsperrte dieser das Konto über die Active-Directory-Konsole und setzte das Passwort zurück. Doch dann kamen Laptops, Smartphones, Tablet-PCs und Telearbeit, sprich: das moderne Arbeitsleben, wie wir es heute kennen. Und die ehemals einfache Lösung für ein häufiges Problem wurde plötzlich sehr viel komplizierter.
Von der Vergesslichkeit der Nutzer ein Mal abgesehen, liegt die Ursache für die meisten Kontosperrungen in Anwendungen oder Services, die im Hintergrund auf einem dieser Geräte ausgeführt werden und die sich mit ungültigen Anmeldeinformationen beziehungsweise einem veralteten Passwort authentifizieren.
Wie ich Dich authentifiziere? Da gibt es die verschiedensten Art und Weisen.
Wie viele verschiedene Arten von Authentifizierung gibt es? Microsoft hat diesem Problem bei einer Kontosperrung einen ganzen TechNet-Artikel gewidmet und listet zunächst einmal die folgenden Varianten auf:
Durch die Vielzahl der real existierenden Geräte gibt es wesentlich mehr Orte, an denen Administratoren nach dem jeweils störenden Prozess suchen müssen. Rein praktisch bedeutet das: die IT‑Abteilung muss die Audit-Protokolle sorgfältig prüfen, um die Ursache zu finden, und zwar häufig über mehrere Domänen hinweg.
Richtlinien zur Kontosperrung könnten eine Lösung sein, allerdings….
Ich kann mir gut vorstellen, wie das Gros der IT‑Administratoren für eine intelligente Sperrrichtlinie als einzig wahrer Lösung votiert. Ein Ansatz sieht vor, dass der Administrator über das Standard-Richtlinienobjekt einer Gruppe der Domäne angemessene Sperrparameter festlegt.
Für die Einstellung „Schwellenwerte bei Kontosperrung“ sollte ein wesentlich höherer Wert als drei festgelegt werden (evtl. 20 oder 30), sodass Sie oder, genauer gesagt, potenzielle Hacker das Konto wirklich in Gefahr bringen müssen, um eine Sperrung auszulösen. Für „Kontosperrdauer“, also der Zeit bis zur automatischen Entsperrung des Kontos, sollte ein sinnvoller Wert von beispielsweise zehn Minuten (anstelle von, sagen wir, zwölf Stunden) festgelegt werden, der nicht dem Standardwert null, also einer dauerhaften Sperrung, entspricht. Und schließlich sollte die heikle Einstellung „anschließendes Zurücksetzen der Kontosperr-Policy“ auf einen Wert von einer Minute festgelegt werden. Hier können Sie mehr zu diesem Ansatz lesen.
Im Gespräch mit einigen leitenden Angestellten von Varonis habe ich herausgefunden, dass es hilfreich sein kann, die Active-Directory-Standardsperrparameter zu ändern. Hier ist allerdings Vorsicht geboten: Einige Annahmen in Bezug auf die Sicherheit der Mitarbeiterpasswörter müssen erst noch belegt werden. Laut Aussage meiner Kollegen könnte es sinnvoll sein, den Wert für die Einstellung „Schwellenwerte bei Kontosperrung“ zu senken, wenn Sie über eine wirkungsvolle Passwortrichtlinie verfügen. Andernfalls funktioniert dieser Ansatz möglicherweise nicht. Man kann ebenso argumentieren, dass dieser Schwellenwert stets null sein sollte, sodass die Nutzer gezwungen sind, sich zum Entsperren ihrer Konten an den Support zu wenden.
Anwendungen mit abgelaufenen Anmeldeinformationen finden
Um die tatsächliche Ursache der Sperrung infolge gespeicherter Anmeldeinformationen herauszufinden, müssen Administratoren und technische Mitarbeiter zunächst ermitteln, welche Anwendung oder welcher Dienst die Sperrung verursacht hat. Das bedeutet, dass sie die Event Logs der betroffenen Domänen durchsuchen müssen, und zwar entweder manuell (nicht empfehlenswert), mit Anwendungen von Drittanbietern oder LockoutStatus.exe – einem Tool von Microsoft.
Das Ereignis, nach dem sie suchen, hat unter Server 2008 die Ereignis-ID 4771 und unter Server 2003 die Ereignis-ID 529. Wenn das Event Kontosperrung angezeigt wird, ist normalerweise auch der Name des Clientcomputers oder die IP‑Adresse des Geräts zu sehen (siehe Screenshot oben).
Bei Windows-Betriebssystemen meldet sich der Administrator zumindest ab Windows 7 per Fernzugriff auf dem Clientcomputer an und entfernt die veralteten Anmeldeinformationen mithilfe des Credential Managers. Sehr wahrscheinlich handelt es sich um den Zweitcomputer des Nutzers. Nachdem auf dem häufig verwendeten Computer ein Passwort geändert worden ist, sind auf dem anderen Rechner weiterhin bestimmte Dienste ausgeführt worden und damit der Wert für die Einstellung „Schwellenwert zur Kontosperrung“ auf diese Art und Weise überschritten worden.
Und wenn das Event auf eine IP-Adresse hinweist?
In diesem Fall muss der Administrator die MAC-Adresse mithilfe eines anderen Geräts im entsprechenden lokalen Netzwerksegment herausfinden und anschließend den Anbieter der MAC-Adresse suchen (z. B. über http://www.macvendorlookup.com) um herauszufinden um welchen Gerätetyp es sich handelt. In 99 Prozent der Fälle ist die Anwendung auf dem iOS‑ oder Android-Gerät, die mit veralteten Anmeldeinformationen ausgeführt wird, ein Exchange-E‑Mail-Client wie z. B. ActiveSync. Der betroffene Nutzer muss anschließend das Passwort erneuern, um die Anmeldeinformationen zu aktualisieren und alles wieder zu synchronisieren.
Teilen Sie Ihr Wissen und Ihre Ideen zu Active-Directory-Sperrungen (und was sonst noch IT‑Mitarbeitern Kopfschmerzen bereitet) auf Twitter und verwenden Sie dabei den Hashtag #varonisRX.
The post Active-Directory-Sperrung: Wie Sie Anwendungen mit abgelaufenen Anmeldeinformationen finden appeared first on Varonis Deutsch.