On-Premises AD & Office365 Self Service Password Reset

Office365 Services sind mittlerweile weit verbreitet. Viele Unternehmen setzen bereits auf eine hybride Infrastruktur, bestehend aus einem On-Premises AD sowie Office365 Diensten. So werden mittlerweile Services wie Exchange Online, Microsoft Teams oder auch SharePoint vollends in die Cloud ausgelagert. Da der Trend auch immer weiter in Richtung mobiles Arbeiten und Home Office geht, muss für den Endnutzer die Möglichkeit geschaffen werden, das eigene Kennwort bei Bedarf selbstständig zurücksetzen zu können. Da der eigene Client nicht immer zwangsläufig Kontakt zum Domain Controller der lokalen Umgebung herstellen kann, kann diese Funktionalität ebenfalls zu Office365 und Azure AD ausgelagert werden. Welche Schritte du zu beachten hast und wie die Konfiguration aussieht, schauen wir uns in diesem Artikel näher an.

Self Service Password Reset

Mithilfe des SSPRs können Nutzer selbstständig ihr Kennwort über das Office365 Portal zurücksetzen und ändern. Grundvoraussetzung bildet dafür die Konfiguration eines zweiten Faktors (Stichwort MFA). Welcher zweite Faktor für das Rücksitzen des Kennworts erlaubt wird, entscheidet dabei der Administrator. Folgende Faktoren stehen zur Verfügung:

• Authenticator (TOTP & Notification)
• Telefon (Anruf & SMS)
• E-Mail
• Sicherheitsfragen

Der Userflow sieht dabei wie folgt aus.

Durch die Anbindung der On-Premises Umgebung wird das Kennwort auch auf den lokalen Domain Controllern übernommen. Außerdem gelten beim Setzen des Kennworts alle lokalen Kennwortrichtlinien. Gibt es in der Domäne bspw. eine GPO welche strikte Richtlinien vorgibt, müssen sich die Nutzer daran halten, auch wenn sie das Kennwort über O365 zurücksetzen.

Übersicht & Theorie

Voraussetzungen

Der Aufbau ist relativ simpel und dürfte genau so in den meisten Umgebungen bereits vorzufinden sein:

• On-Premises AD
• Azure AD
• Azure AD Connect
• Office365 Lizenzen

In den nachfolgenden Kapiteln besprechen wir die einzelnen Komponenten näher.

Das Ziel ist es, einzelne Nutzer für den SSPR freizugeben über Office365 freizugeben. Es ist zwar auch möglich, den Dienst für die gesamte Organisation freizuschalten, meiner Meinung nach ist es aber sinnvoller, nur Nutzer diese Funktionalität bereitzustellen. Somit läuft man nicht in die Gefahr, etwaige Service Accounts dafür freizugeben.

On-Premises AD

Da lokale Active Directory bildet auch bei einer hybriden Umgebung den Master. Alle Änderungen gehen immer vom lokalen AD aus. Daher ist es nach wie vor essentiell, die Organisation sauber und nachhaltig zu administrieren. Um die Administration zu erleichtern, arbeiten wir neben synchronisierten Nutzern auch mit synchronisierten Gruppen. Diese Gruppen übernehmen im Azure AD verschiedene Aufgaben – wie beispielsweise das Aktivieren von MFA oder SSPR.

Wer mit dem Konzept in erster Linie noch nichts anfangen kann, ein kleines Beispiel: Administriert man ein Fileshare, werden NTFS Permissions auch durch AD Sicherheitsgruppen gesetzt. Somit besitzt man ein aufgeräumtes Berechtigungssystem. Ähnlich sieht es mit den Azure AD Funktionen aus. Möchte man für einen Benutzer SSPR (Self Service Password Reset) aktivieren, wird dieser als Mitglied in die lokale Gruppe hinzugefügt. Somit bekommt dieser automatisch die SSPR Funktion freigeschalten. Das gleiche Spiel lässt sich auch mit Office365 Lizenzen spielen. Dazu aber in einem späteren Artikel mehr.

Azure AD

Das Herzstück unserer Cloud-Umgebung. Hierüber werden die Online Services wie Exchange Online, Teams & Co zur Verfügung gestellt (streng genommen über Office365). Auch der SSPR (Self Service Password Reset) wird für den Nutzer hierüber bereitgestellt.

Azure AD Connect

Da wir von einer hybriden Umgebung sprechen, wird das On-Premises Active Directory in den meisten Fällen mit dem Azure AD synchronisiert. Daher bildet der Azure AD Connect eine Grundvoraussetzung für diesen Artikel.

Office365 Lizenzen

Der SSPR Service ist for Cloud-Only Nutzer kostenlos. Für hybride Nutzer benötigt man aufgrund des Password-Writebacks allerdings eine Azure AD Premium P1 Lizenz. Diese Lizenz lässt sich entweder als Add-On dazu kaufen, ist aber auch Bestandteil folgender Subscriptions:

• M365 Business Premium
• M365 E3
• M365 E5

Eine vollständige Liste könnt ihr bei Microsoft selbst einsehen.

Nutzer ohne entsprechender Azure AD Premium P1 Lizenz dürfen das Passwort nicht in das On-Premises AD zurückschreiben. In diesem Fall würde sich also ein hybrides Deployment, wie ich es hier beschreibe, nicht umsetzen lassen.

Konfiguration

Da wir nun die wichtigsten Bestandteile besprochen haben, können wir mit der Konfiguration der Umgebung beginnen.

On-Premises AD & Sync

Wie im Theorie-Kapitel besprochen, möchten wir SSPR über lokale Sicherheitsgruppen steuern. Somit legen wir innerhalb der Domäne eine neue Gruppe an:

Mitglieder dieser Gruppe werden später dazu in der Lage sein, dass Kennwort über Office365 zurückzusetzen.

Außerdem müssen wir sicherstellen, dass wir die Organisationseinheit, in der sich die Gruppe befindet, mit dem Azure AD synchronisiert wird.

Der Azure AD Connect muss außerdem die Funktion „Password Writeback“ aktiviert haben.

Damit haben wir die lokale Konfiguration bereits abgeschlossen.

Azure AD Admin Center

Eigenschaften

Im Azure AD Admin Center wechseln wir zum Reiter „Password reset„. In den „Properties“ hinterlegen wir nun jene Gruppe, die wir im Schritt zuvor angelegt haben. Ihr habt hier natürlich auch die Möglichkeit SSPR für alle Nutzer zu aktivieren – falls das wirklich gewünscht ist.

Falls die Gruppe hier noch nicht aufscheinen sollte, hat entweder noch keinen Azure AD Connect Sync-Cycle abgewartet (läuft alle 30 Minuten automatisch) oder die OU wird nicht korrekt synchronisiert.

Authentifizierungsmethoden

Im Menü „Authentication methods“ haben wir nun die Möglichkeit festzulegen, welcher zweite Faktor für den Password Reset verwendet werden darf. Hier muss man zwischen Nutzererlebnis und Sicherheit abwägen. Wer SSPR sehr sicher betreiben möchte, verwendet ausschließlich den Authenticator. Das eigene Smartphone (Anruf & SMS) wird ebenfalls noch als sicher angesehen. Auf E-Mail & Sicherheitsfragen sollte man aber in der Regel verzichten.

Die hier zu konfigurierenden Authentifizierungsmethoden werden von Microsoft bereits als Legacy angesehen und wird mit Anfang 2024 deaktiviert. Die neue empfohlene Funktion zum steuern eben dieser nennt sich „Combined Security Info Registration„. Mehr dazu erfahrt ihr in kürze auf diesem Blog.

Registrierung

Natürlich müssen die Nutzer den zweiten Faktor erst konfigurieren. Wer in Office365 bereits auf MFA (und womöglich auch schon Combined Registration) setzt, dürfte diesen Schritt bereits erledigt haben. Ansonsten empfiehlt es sich diese Funktion zu aktivieren und die Nutzer regelmäßig auf Aktualität prüfen zu lassen.

Notifizierung

Es empfiehlt sich zumindest den Nutzer per E-Mail über den erfolgreichen Passwordchange informieren zu lassen. Wer als Administrator ebenfalls eine Notifizierung erhalten möchte, kann das hier aktivieren. Bei kleineren Umgebungen durchaus sinnvoll. Ansonsten lassen sich SSPR Aktivitäten natürlich jederzeit über die Azure AD Logs nachvollziehen.

Password Writeback

Im On-Premises Kapitel haben wir die Funktion „Password Writeback“ im Azure AD Connect aktiviert. Hier bekommt man noch einmal die Bestätigung, dass dieser auch aus Sicht des Azure ADs erfolgreich aktiviert wurde.

Benutzerexperience

Sobald der Nutzer für SSPR aktiviert wurde, wird er beim nächsten Logon aufgefordert, die notwendigen Daten zu hinterlegen (falls er es nicht bereits getan hat).

Anschließend bekommt der Nutzer auch noch einmal die Bestätigung, dass der Registrierungsprozess erfolgreich abgeschlossen wurde.

Ab diesen Zeitpunkt kann der Nutzer sowohl sein Kennwort über das Office365 Portal ändern, als auch zurücksetzen lassen.

Fazit

Der Self Service Password Reset (SSPR) ist eine einfache Methode, Nutzern die Möglichkeit zu geben, ihre Kennwort selbstständig und sicher über ein Webinterface zurückzusetzen. Durch den Azure AD Connect wird das Passwort nicht nur in das On-Premises Active Directory zurückgeschrieben, sondern auch noch anhand der dort geltenden Richtlinien evaluiert. Erst dann wird das Kennwort auch tatsächlich übernommen. Gerade für größere Organisationen kann dies etwas Last vom Service Desk nehmen und auf die Nutzer selbst verlagern.