Password WriteBack / SSPR

Immer mehr Anwender nutzen Office 365 bzw. Microsoft 365 und sind durch Covid19 auch immer seltener im Office oder am Firmen-PC. Diese Seite beschreibt, wie die auch unterwegs ihr Kennwort mit Microsoft 365 ändern können. Diese Seite vereint die Funktion, das eigene Kennwort zu ändern als auch ein vergessenes Kennwort selbst zurück zusetzen. Diese Seite hätte auch unter Authentifizierung stehen können aber die primäre Funktion macht ADSync.

Bedarf

Ich bin ja kein Freund davon, dass Anwender alle paar Wochen ihr Kennwort ändern müssen. Dadurch wird das Kennwort nicht sicher. Jedes Kennwort ist sicher, solange es nur der legitime Inhaber kennt. Sobald das Kennwort einer anderen Person bekannt ist, ist es als unsicher anzusehen. Es ist dabei egal, ob das Kennwort nur abgephished, ausgespäht oder per Brute-Force-Angriff geknackt wurde.

In dem Fall ist es aber wichtig, dass nicht nur erkannt wird, dass das Kennwort einer anderen Person bekannt wurde, sondern dass der Anwender das Kennwort auch ganz schnell ändern kann. Zudem sollte der Dienst von vorneherein "unsichere" Kennwort, die womöglich woanders schon benutzt werden, verhindern und natürlich muss die Übermittlung des neuen Kennworts absolut sicher erfolgen. Auch Multi Faktor Authentifizierung ist zu berücksichtigen.

Checkliste

Weiter unten beschreibe ich die einzelnen Schritte. Aber folgende Checkliste können Sie sequentiell abarbeiten, damit sie nichts vergessen. Sie benötigen Natürlich einen Office 365 Tenant, in dem sich der Benutzer auch anmelden kann:

Prüfpunkt Erledigt

Lizenzfragen

Azure AD P1oder P3, auch enthalten in EMS E3, EMS A3, Microsoft 365 E3/E5/F1 oder M365 Business
Früher hat Microsoft wohl auch eine Azure AD P2-Lizenz gefordert, aber das wurde mittlerweile auf P1 reduziert. Die Azure AD P1 ist in Microsoft 365 E3 und EMS E3 enthalten und aus meiner Sicht für jeden Office 365 Kunden sowieso erforderlich, um das System "sicher" mit Conditional Access zu betreiben

Berechtigungen

Für die Einrichtung müssen Sie sowohl im Tenant als auch im lokalen Active Directory Einstellungen vornehmen, zu denen privilegierte Rechte erforderlich sind.

  • Global Admin
    Mit weniger Berechtigungen geht es nicht. Nur ein "Globaler Admin" kann im AzureAD die Änderungen vornehmen
  • Domain Admin
    Wenn Sie mit ADSync auch die geänderten Kennworte in das lokale AD zurück replizieren wollen, dann müssen sie im AD entsprechende Berechtigungen setzen, was sie am besten auch als Domain-Admin der jeweiligen Domäne machen.

Planung und Change Management

Speziell die Aktivierung von "Self Service Password Reset" (SSPR) erzwingt eine Aktion der Anwender, die Sie vorab erklären und beschreiben sollten.

Berechtigungen im Active Directory

Damit ADSync später in der Cloud geänderte oder gesetzte Kennworte auch in das lokale AD schreiben kann, braucht er Rechte

Aktivierung in ADSync

Dann müssen Sie die Konfiguration des lokalen ADSync-Prozesses anpassen, damit er auch Kennworte in das AD schreibt.

Kontrolle im AzureAD

Das Zurückschreiben des Kennworts ist keine Funktion, die ADSync zyklisch wie den Verzeichnisabgleich ausführt, sondern getriggert ausgelöst wird. AzureAD kann erkennen, ob die lokale ADSync-Instanz verbunden ist.

Kennwort ändern

Wenn Sie alle Einstellungen richtig vorgenommen haben, können Sie nun über das Portal ihr Kennwort ändern.

Reporting

Alle Änderungen bleiben natürlich nicht unbemerkt. Im AzureAD AuditLog aber auch im lokalen Eventlog hinterlassen Aktionen der Anwender ihre spuren, die bei Fehlersuchen hilfreich sind.

Bonus: Self Service Password Reset

Wenn AzureAD auch das On-Premises Kennwort setzen kann, dann können Sie die Funktionen von AzureAD auch zum Freischalten von vergessenen Kennworten nutzen.

Hier geht es nun zu den einzelnen Punkten.

Rechte im Active Directory

Konten, die Kennworte in einem AD schreiben können, sind besonders "sensibel" zu behandeln. Sie haben ein nicht zu unterschätzendes Schadpotential. Daher haben eigentlich auch nur "Konten-Operatoren" auf "Nicht-Administratoren" (siehe AdminSDHolder) und ansonsten muss man schon selbst Administrator sein.

Nun muss auch das ADSync Dienstkonto das Recht bekommen, zumindest für die Benutzer das Kennwort zu setzen, die in der Cloud ihr Kennwort aktualisieren dürfen. Sie müssen auf den entsprechenden OUs oder der Domain das entsprechende Recht setzen. Genau genommen sind es vier Rechte, die der Administrator delegieren muss.

Reset password
lockoutTime:Write
pwdLastSet:Write

Extended rights:"Unexpire Password": Auf die Domain Root und alle Unterobjekte

Die Berechtigungen können Sie einfach über die MMC für Benutzer und Computer zuweisen. Das folgende Skript macht dies auf der "Root" der angegeben Domain für alle Objekte. Sie müssen natürlich ihre Domain und das Dienstkonto des ADSync-Service anpassen:

# Root Domain
param (
   $DomainDN = "DC=msxfaq,DC=de",
   $ADSyncAcc = "msxfaq\MSOL_1234567"
) 
# http://technet.microsoft.com/en-us/library/cc771151.aspx 

Invoke-Expression "dsacls '$DomainDN' /I:S /G '`"$ADSyncAcc`":CA;`"Reset Password`";user'"
Invoke-Expression "dsacls '$DomainDN' /I:S /G '`"$ADSyncAcct`":CA;`"Change Password`";user'"
Invoke-Expression "dsacls '$DomainDN' /I:S /G '`"$ADSyncAcc`":WP;pwdLastSet;user'"
Invoke-Expression "dsacls '$DomainDN' /I:S /G '`"$ADSyncAcc`":WP;lockoutTime;user'"

Aktivierung in ADSync

Sie müssen die Checkbox bei "Password writeback" setzen, wenn die Konten in der Cloud durch das lokale AD-Konto verwaltet werden und die Kennwort aus dem lokalen AD per Password Hash Sync (PHS) ins AzureAD übertragen werden oder sich der Anwender direkt gegen das lokale AD mittels Pass-Through Authentifizierung (PTA) oder ADFS authentifiziert.

Nur dann kann ADSync das in der Cloud aktualisierte Kennwort auch in das lokale AD übertragen. Durch die Aktivierung startet ADSync keinen "FullExport", denn bislang hat sich in der Cloud ja nichts geändert. Es gibt daher kein "Backlog". Wenn das Zurückschreiben nicht aktiv ist, dann finden Sie im AzureAD folgende Meldung:

Diese Meldung kann eigentlich nicht missverstanden werden.

Kontrolle im AzureAD

Direkt im Azure Portal können Sie die Integration mit der On-Premises Umgebung überprüfen.

Der Hinweis-Text unter dem Info-Icon schriebt dazu:

If you deployed password writeback when installing Azure AD Sync, you can control whether or not this feature is enabled here. If set to "no", federated or password synchronized users will not be able to reset or change their passwords, even if password writeback has been configured. You can change this setting at any time.

Ein Kennwort, zwei Speicherorte

Wenn ihre Anwender ihr Kennwort nun über die Cloud setzen können, dann gibt der Anwender das neue Kennwort an Microsoft und das Backend muss diese nun sowohl ins AzureAD als auch ins lokale AD schreiben. Das es ein "gleichzeitig" nicht gibt, kann es hier je nach Konfiguration zu temporären Problemen kommen.

Kenwortänderung in Domain Ablauf Probleme

Lokales AD

Egal
  • Benutzer oder Helpdesk ändert Kennwort im AD
  • ADSync gleich einige Zeit später ab

Änderung im AzureAD ist immer etwas verzögert. Ein Benutzer kann sich nicht sofort mit dem neuen Kennwort anmelden. Voraussetzung ist, dass ADSync auch funktioniert

AzureAD

Staged Mode
  • Benutzer ändert Kennwort über https://aka.me/sspr
    oder Helpdesk oder GraphAPI
  • AzureAD Kennwort wird zuerst ins lokale AD geschrieben
  • ADSync repliziert dann Hash ins AzureAD

Durch das "Durchschreiben" ins lokale AD fallen Fehler bei der Verbindung sofort auf und der Benutzer behält sein altes Kennwort und sieht einen Fehler.

Sollte das Kennwort im AD aktualisiert werden, dann kann es wieder etwas dauern, bis es durch ADSync im AzureAD ankommt

AzureAD

Managed Mode
  • Benutzer ändert Kennwort über https://aka.me/sspr
    oder Helpdesk oder GraphAPI
  • Entra ändert parallel das Kennwort im AzureAD und lokalen AD

Der Benutzer kann in der Regel direkt weiter arbeiten.

Kennwort ändern

Wenn ich mich noch korrekt anmelden kann, dann kann ich über mein Profil direkt den Link anklicken:

https://myaccount.microsoft.com/?ref=MeControl

Der Link ist natürlich auch direkt erreichbar:

https://account.activedirectory.windowsazure.com/ChangePassword.aspx

Das Fenster ist natürlich etwas "schmucklos" und oben erscheint nur das im Portal hinterlegte Firmenlogo. Weitere Anpassungen sind hier noch nicht möglich. Aber die Funktion erfüllt es so natürlich.

Reporting

Da alle Aktivitäten im AzureAD protokolliert werden, ist das auch der erste Ansatzpunkt für eine Fehlersuche. Hier sehen zwei Fehlversuche mein Kennwort zu ändern (3:28:50 und 3:38:04). Die erfolgreiche Änderung hat vier Logs generiert. Es ist auch gut zu sehen, dass das STS-TokenTimestamp angepasst wurde.

Ein Blick auf die Details einer fehlerhaften Änderung zeigt den Fehler im Detail, der aber auch schon bei der Übersicht zu finden ist:

Leider gibt es hier keine weiteren Informationen über den Client, die IP-Adresse oder den Netzwerkstandort, was ich etwas schade finde. Auf der On-Premises-Seite findet sich nichts im ADSync Log aber im Application Eventlog findet sich der Eintrag. Bei einer erfolgreichen Änderung findet sich dieser Eintrag:

Log Name:      Application
Source:        Directory Synchronization
Date:          20.07.2020 15:40:56
Event ID:      657
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      adsync.uclabor.de
Description:
Password Change Result - Anchor : xxxxxx==, 
   Dn : CN=Carius\, Frank ,OU=Firma,DC=carius,DC=de, 
   PwdChangeOnLogon=False, 
   Result : Success.

<forest-info>
  <forest-name>uclabor.de</forest-name>
  <connector-id>04dddde8-352d-40f8-b6d4-f63c10ed8d66</connector-id>
</forest-info>

Bei einem Fehler:

Log Name:      Application
Source:        PasswordResetService
Date:          20.07.2020 15:38:03
Event ID:      33007
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      adsync.uclabor.de
Description:
TrackingId: 9445235c-d73b-4253-a063-866c25c4c198, 
  Reason: Synchronization Engine returned an error hr=8023061A, 
  message=The password given does not specify the user's current password., 
  Context: 
      cloudAnchor: User_b39bb717-ea64-46cd-ab57-00186effe82c, 
      SourceAnchorValue: x3br8sCjvE2JVGroFmng0Q==, 
      UserPrincipalName: frank@carius.intern, 
      Details: Microsoft.CredentialManagement.On-PremisesPasswordReset.Shared.PasswordResetException: 
         Synchronization Engine returned an error hr=8023061A, 
         message=The password given does not specify the user's current password.
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword...)
   at Microsoft.CredentialManagement.On-PremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(....)

Auch der PasswordResetService loggt ca. alle 5 Minuten regelmäßig seine Arbeit:

Log Name:      Application
Source:        PasswordResetService
Date:          20.07.2020 15:49:53
Event ID:      31019
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      adsync.uclabor.de
Description:
TrackingId: 6216222d-2296-434f-ae95-ae2f41c02828, 
 HeartBeat for Namespace: ssprdedicatedsbprodscu, 
 Details: Version: 5.0.682.0

Damit könnten sie das Thema schon abschließen.

Password Reset Bestätigung

Password Writeback kann aber nicht nur ein in der Cloud geändertes Kennwort ins lokale Active Directory zurückschreiben, sondern Anwender können auch im Falle eines vergessenen Kennworts diese selbst neu zu setzen. Wenn sie über die Cloud ihr Kennwort zurücksetzen wollen, dann müssen Sie natürlich irgendwie anders nachweisen, dass Sie legitimiert sind.

ACHTUNG:
Diese Änderung kann dazu führen, dass die Anwender bei der nächsten Anmeldung einen Dialog zur Absicherung ihrer Anmeldedaten  durchlaufen müssen. Informieren sie ihre Anwender vorher, damit Sie den Unterschied dieser "guten" Abfrage zu einem Phishing-Versuch wissen.

Binden Sie hier am besten ihre Schulungsabteilung oder Change Management mit ein, damit die Anwender nicht überrascht sind.

Daher ist es unabdingbar, entsprechende Informationen zu hinterlegen. Normalerweise sind "Email" und "Mobile Phone" aktiviert. Weitere Optionen sind eine mobile App, die Büronummer oder Sicherheitsfragen.

Diese Einstellungen werden mit der Aktivierung dem Anwender auch angeboten und muss die Mindestanzahl auch ausführen. Der Anwender sieht dann, z.B.:

Danach muss er sein aktuelles Kennwort bestätigen:

Erst dann kann er die Fragen zum "Rücksetzen" beantworten bzw. die vom Admin hinterlegten Elemente bestätigen:

SSPR aktivieren

Sie müssen die Funktion "SSPR" nicht sofort für alle Benutzer aktivieren. Sie haben die Wahl, ob sie die Funktion "Password Reset" für die Mitglieder einer Gruppe oder alle Konten in Azure bereitstellen. Sie können hier aber nur genau eine Gruppe auswählen. Es kann daher sinnvoll sein, eine eigene Gruppe "Password Reset" o.ä. anzulegen. Wenn Sie diese Gruppe im lokalen AD anlegen, dann muss ADSync die Gruppe natürlich ins AzureAD replizieren. Allerdings können Sie dann keine "Cloud Only"-Benutzer mit aufnehmen. Eine Cloud-Only-Gruppe umgeht das Problem aber zwingt sie dann zu einer Verwaltung der Mitglieder in der Cloud. 

In meinem Beispiel nutze ich ein lokales Active Directory mit ADSync und alle "Menschen" haben auch ein lokales AD-Konto. Die "Cloud Only"-Benutzer sind durchweg nur Administratoren oder Diensten, die kein "Password Reset" nutzen sollen. Da ich die Gruppe "Domain Benutzer" sehr ungerne nutze, pflege ich eine eigene Gruppe "Mitarbeiter" im lokalen Active Directory, die sich hier verwenden kann. Sie können natürlich eine eigene Gruppe verwenden. Mit der nächsten Anmeldung bekommen die Anwender dann den Dialog zur Verifizierung der alternativen Informationen.

Vergessenes Kennwort zurücksetzen

Wenn ein Anwender sein Kennwort vergessen hat, dann kann er sich natürlich nicht an der Cloud anmelden. Aber kann in der Anmeldemaske den Assistenten starten:

Mit der Auswahl "Geschäftskonto" landet der Anwender dann auf dem Dialog zur Eingabe der Adresse und des Captcha.

Diese URL können Sie auch direkt ansurfen:

https://aka.ms/sspr
https://passwordreset.microsoftonline.com/

Weitere Links