Wir setzen auf unserer Webseite Cookies und andere Technologien ein, um Ihnen den vollen Funktionsumfang unseres Angebotes anzubieten. Sie können auch zu Analysezwecken gesetzt werden. Durch die weitere Nutzung unserer Webseite erklären Sie sich mit dem Einsatz von Cookies einverstanden. Weitere Informationen, auch zur Deaktivierung der Cookies, finden Sie in unserer Datenschutzerklärung.
So erzwingen Sie Passwortänderungen bei der nächsten Anmeldung an Azure AD
Azure AD (demnächst Entra ID) ist die zentrale Komponente für das Identitäts- und Zugriffsmanagement in Microsoft Azure und damit auch in Microsoft 365. Die Verwaltung von Benutzern und Passwörtern für Unternehmenskonten erfordert ein Grundverständnis dafür, wie Azure AD mit Passwortänderungen umgeht, insbesondere wenn Konten aus lokalen Active Directory-Umgebungen synchronisiert werden.
Das Erzwingen einer Passwortänderung bei der nächsten Anmeldung ist eine gängige Einstellung, die schon seit Jahren verwendet wird. Doch wie lässt sich dies mit Azure AD und einer Synchronisierung von Konten und Kennwörtern aus dem lokalen Active Directory bewerkstelligen? Wir zeigen Ihnen, wie das geht, und gehen auf die Probleme ein, die dabei zu beachten sind.
Gründe für eine erzwungene Änderung des Passworts bei der nächsten Anmeldung
Das Kennwort eines Benutzers ist die erste Verteidigungslinie gegen unbefugten Zugriff. Mit der Zeit können diese Passwörter jedoch durch Phishing-Angriffe, unbeabsichtigte Datenpannen, Brute-Force– und andere Formen von Cyberangriffen verwundbar werden. Die Anweisung, das Passwort bei der nächsten Anmeldung zu ändern, ist ein proaktiver Schritt, der dazu beiträgt, dass die Anmeldedaten ein gewisses Maß an Sicherheit behalten.
Welche Gründe gibt es, dass eine Organisation diese Funktion anwendet? Wir haben ein paar aufgeführt:
- Post-Breach-Protokolle: Das Ändern von Passwörtern kann als proaktiver Schritt gegen die Kompromittierung von Anmeldeinformationen betrachtet werden. Sie ist auch nach einem Sicherheitsvorfall von entscheidender Bedeutung, wenn durch das Zurücksetzen des Passworts sichergestellt wird, Konten nicht weiter kompromittiert sind.
- Onboarding-Prozesse: Wenn sich neue Benutzer anmelden, erhalten sie möglicherweise temporäre Passwörter. Die Forderung nach einer Änderung stellt sicher, dass sie ein Passwort festlegen, das nur sie kennen.
- Verfall von Passwörtern: Regelmäßige Passwort-Resets verkleinern den Zeitraum, in dem ein unbefugter Zugriff möglich ist.
- Zurücksetzen von Helpdesk-Kennwörtern: Wenn ein Helpdesk-Techniker das Kennwort eines Endbenutzers zurücksetzt, ist es am besten, den Benutzer zu zwingen, sein Kennwort bei der nächsten Anmeldung erneut zu ändern, damit niemand außer dem Endbenutzer das aktuelle Kennwort kennt.
Unten sehen Sie ein Beispiel für die Einstellung Active Directory Domain Services: Benutzer muss Kennwort bei der nächsten Anmeldung ändern.
So sieht die Einstellung in der SaaS-Umgebung von Microsoft 365 aus: Ein Administrator hat “Kennwort zurücksetzen” ausgewählt und die Option aktiviert: Diesen Benutzer verpflichten, sein Kennwort bei der ersten Anmeldung zu ändern.
Wie kann der Prozess zur Synchronisierung von Passwörtern zwischen lokalen Active Directory-Domänendiensten und Azure Active Directory automatisiert werden?
Synchronisierung von Kennwortänderungen mit Azure AD
Im Allgemeinen werden die meisten Unternehmen, die zu einer hybriden Infrastruktur übergehen und Ressourcen in Microsoft 365 nutzen, Azure AD Connect konfigurieren. Azure AD Connect ist ein Tool, mit dem Unternehmen ihre lokalen Active Directory Domain Services-Konten mit Azure AD synchronisieren können.
Um die verschiedenen Optionen für die Synchronisierung von Konten und Passwörtern zwischen der lokalen Active Directory-Umgebung und Azure AD zu konfigurieren, installieren Administratoren den Synchronisierungsassistenten in Azure AD Connect und führen ihn schrittweise aus.
Über Azure AD Connect können Passwortänderungen, die im lokalen AD erzwungen wurden, auf Azure AD übertragen werden. Hier können jedoch Probleme auftreten.
Gewisse Szenarien bei der Verwendung von Azure AD Connect können Administratoren möglicherweise überraschen:
- Writebacks von Passwörtern: Wenn “Self-Service Password Reset” aktiviert ist, werden die in Azure AD vorgenommenen Änderungen möglicherweise nicht im lokalen AD übernommen, es sei denn, “Password Writeback” ist ebenfalls aktiviert.
- Authentifizierungsmethoden: Abhängig von der Passwortrichtlinie in Azure AD und den Einstellungen im lokalen AD kann es sein, dass bestimmte Authentifizierungsmethoden die Passwortänderung nicht sofort durchsetzen.
- Azure AD-Passwortrichtlinien vs. lokale Richtlinie: Es können Diskrepanzen zwischen den beiden bestehen, vor allem wenn benutzerdefinierte Richtlinien auf beide angewendet wurden. Es ist wichtig, diese Unterschiede zu verstehen und abzugleichen.
Unten sehen Sie ein Beispiel für eine Azure AD Connect-Konfiguration, bei der die Kennwort-Hash-Synchronisierung aktiviert, die Rückschreibung des Kennworts jedoch deaktiviert ist. Wenn Sie jedoch Specops Passwortrichtlinien mit Azure AD Connect verwenden, empfehlen wir, Passwort-Writeback hier zu aktivieren.
Der Verlauf einer erzwungenen Passwortänderung
Wenn sich ein Benutzer zum ersten Mal anmeldet oder ein Administrator das Kennwort des Benutzers zurückgesetzt hat, wird in der Regel sichergestellt, dass der Benutzer sein Kennwort ändert. Administratoren konfigurieren die Option “Benutzer muss Passwort bei nächster Anmeldung ändern” für das Benutzerkonto. Dieses System für temporäre Kennwörter ist von entscheidender Bedeutung, da es sicherstellt, dass nur der rechtmäßige Benutzer die Anmeldedaten über die erste Verwendung hinaus kennt, wodurch Sicherheitsprobleme mit dem Kennwort minimiert werden.
Was ist erforderlich, damit Azure AD Connect diese Änderungen korrekt aufnimmt und das Attribut “Erzwungene Änderung” und das temporäre Kennwort synchronisiert?
Synchronisierung erzwungener Passwortänderungen mit Azure
Standardmäßig wird die Einstellung “Benutzer muss Passwort bei nächster Anmeldung ändern” nicht von On-Prem AD zu Azure AD synchronisiert. Um die Synchronisierung dieser Einstellung zu aktivieren, muss die Funktion ForcePasswordChangeOnLogOn gesetzt werden. Sie kann mit Azure AD Connect mit dem Befehl aktiviert werden:
Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true
Im Folgenden haben wir das PowerShell-Cmdlet auf unserem Azure AD Connect-Server ausgeführt, um die Einstellung ForcePasswordChangeOnLogon zu aktivieren.
Es gibt jedoch einige wichtige Punkte, die bei diesem Prozess im Zusammenhang mit der Kontosynchronisierung zu beachten sind:
- Das einfache Aktivieren der Einstellung “Kennwortänderung erzwingen” löst den Prozess nicht von selbst aus. Es werden nur zukünftige Ereignisse synchronisiert, bei denen ” User must change password at next logon” (Benutzer muss Passwort bei nächster Anmeldung ändern) gesetzt ist – es werden keine bestehenden Instanzen synchronisiert, bei denen dieses Flag auf Benutzerkonten gesetzt ist.
- Bei Benutzern mit dem AD-Attribut “Kennwort läuft nie ab” wird das Flag “Kennwortänderung erzwingen” in Azure AD nicht aktiviert. Daher wird bei der nächsten Anmeldung in Azure keine Aufforderung zur Änderung angezeigt.
- Neu angelegte Benutzer im AD mit aktivierter Option “Benutzer muss Passwort bei nächster Anmeldung ändern” werden in Azure AD immer aufgefordert, ihr Passwort bei der nächsten Anmeldung zu ändern. Dieses Verhalten bleibt unverändert, unabhängig von der Einstellung ForcePasswordChangeOnLogOn. Dies geschieht, weil diese neuen Benutzer ohne Kennwort in Azure AD erstellt werden, so dass diese Funktion nur für Szenarien spezifisch ist, bei denen das Kennwort von Administratoren zurückgesetzt wird.
Weitere Details finden Sie in der offiziellen Microsoft-Dokumentation hier: Implementierung der Kennwort-Hash-Synchronisierung mit Azure AD Connect sync.
Eine Hinweis bezüglich Azure AD verbundenen Workstations
Es gibt eine erwähnenswerte Lücke in Microsofts Ökosystem, was das Erzwingen von Kennwortänderungen bei der nächsten Anmeldung betrifft: Ein Benutzer wird nie aufgefordert, sein Kennwort zu ändern, wenn er sich bei einer mit Azure AD verbundenen Workstation anmeldet oder diese entsperrt.
Für On-Prem- oder hybride Azure-verbundene Workstations ist dies kein Problem. Die Benutzerauthentifizierung erfolgt gegenüber der On-Prem-Domäne AD, und der Benutzer wird gezwungen, sein Kennwort zu ändern (solange er sich im Netzwerk befindet und sich nicht mit Cached-Anmeldedaten anmeldet):
Bei diesem Schritt klickt der Benutzer auf OK und erhält den Dialog Passwort ändern:
Bei rein mit Azure AD verbundenen Computern wird der Benutzer bei der Anmeldung gegenüber Azure authentifiziert, und Microsoft erzwingt niemals eine Kennwortänderung vor der Anmeldung an der Workstation. Man könnte vermuten, dass dies ein Nebeneffekt der Entfernung des oben gezeigten Dialogs zum Ändern des Kennworts von Azure AD-verbundenen Computern ist; wenn ein Benutzer Strg+Alt+Entf drückt und Kennwort ändern auswählt, wird er zu seiner Anmeldesitzung zurückgebracht und eine Microsoft-Seite zum Ändern des Kennworts wird in seinem Standardbrowser geöffnet.
Wenn ein Benutzer, der ausschließlich auf einer Azure AD-verbundenen Workstation arbeitet, sein Kennwort nicht proaktiv ändert, wird er möglicherweise nie dazu gezwungen, bis er sich das nächste Mal auf einem neuen Gerät anmeldet.
Weitere zu berücksichtigende Punkte
- Temporäre Passwörter: Während Azure einen Benutzer dazu auffordern kann, sein temporäres Passwort bei der nächsten Anmeldung zu ändern, erkennen bestimmte Dienste oder Anwendungen, die mit Azure AD verbunden sind, das Event der Passwortänderung möglicherweise nicht und erlauben die Anmeldung mit dem temporären Passwort. Dies gilt auch für Azure AD Joined Workstations, wie oben beschrieben.
- Gültigkeitsdauer der Passwörter: Die Standardeinstellungen von Azure können sich von denen unterscheiden, die eine Organisation in ihrem lokalen AD festgelegt hat. Diese unterschiedlichen Einstellungen können zu Verwirrung in Bezug auf Passwortrichtlinien führen.
- Umfassendere Kennwortstrategie: Das Erzwingen von Kennwortänderungen ist für die meisten Unternehmen mit lokalen Active Directory-Domänendienste-Umgebungen seit langem eine Kernkomponente der Kennwortstrategie. Da Unternehmen jedoch von einer lokalen Infrastruktur auf SaaS-Lösungen wie Microsoft 365 migrieren, müssen sie verstehen, wie erzwungene Kennwortrücksetzungen zwischen Konten funktionieren, die von der lokalen Infrastruktur und Azure AD synchronisiert werden.
Möchten Sie gerne mehr darüber erfahren, wie Specops Password Policy und Specops Password Auditor in Ihrer Organisation zu mehr IT-Sicherheit beitragen kann? Dann vereinbaren Sie noch heute einen unverbindlichen Termin mit unseren Experten.
(Zuletzt aktualisiert am 08/11/2023)