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 Azure AD 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.

Kennwortrichtlinien

Wen Sie von Entra ID aus das lokale Kennwort aktualisieren, dann gelten hier auch die lokalen Kennwortrichtlinien was Länge, Komplexität aber auch Mindestalter betreffen. Gerade bei Aufbau möchten Sie vielleicht zum Test häufiger das Kennwort ändern. Wenn dann z.B. das Mindestalter noch nicht abgelaufen ist, bekommen Sie einen wenig aussagekräftigen Fehler.

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 Azure AD 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. Die Rechte müssen für jeden Account gelten, für den das Kennwort über die Cloud gesetzt werden soll. Sie können die Rechte aber auch problemlos auf einer OOU anwenden, was Dienstkonten dann aus der Schusslinie nimmt. Wobei Sie Dienstkonten und Administratoren sowieso nicht mit ADSync replizieren sollten.

Reset password
Change 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. Mittlerweile hat Microsoft aber auch ein PowerShell-Skript bereitgestellt, mit dem Sie das Recht dem EntraID Connect Dienstkonto und sogar auf OU-Level delegieren können.

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

Set-ADSyncPasswordWritebackPermissions `
  -ADConnectorAccountDN "CN=MSOL_<id des Konto>,CN=Users,DC=msxfaq,DC=de" `
   -ADObjectDN "OU=Firma,DC=msxfaq,DC=de"

Sie können ja mal gerne in die PSM1-Dateien mit einem Editor nach "Set-ADSyncPasswordWritebackPermissions" suchen.

Interessanterweise setzt das Skript (Stand Juli 2025) nur die Rechte für "Reset password", "lockoutTime" und "pwdLastSet" aber nicht für "Change password" und auch nicht das Recht "Unexpure Password" auf der Domain.

Früher habe ich noch folgendes Skript auf Basis von DACLS genutzt.

# 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.

Entra ID 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.

Lokales Eventlog

Auf der On-Premises-Seite findet sich nichts im ADSync Log aber im Application Eventlog findet sich der Eintrag. Zuerst sollten Sie mal nach der "Gesundheitsmeldungen" schauen:

Log Name:      Application
Source:        PasswordResetService
Event ID:      31042
Task Category: None
Level:         Information
Keywords:      Classic
User:          N/A
Description:
TrackingId: <guid>, Password writeback service is in a healthy state. 
  All serviceHosts for service bus endpoints are in running state, 
  Details: Version: 5.0.922.0

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>

Hier ein paar Fehler

Log Name:      Application
Source:        PasswordResetService
Event ID:      33007
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
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(....)
Log Name:      Application
Source:        PasswordResetService
Event ID:      33008
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Description:
TrackingId: <guid>, Reason: Synchronization Engine returned an error hr=80230619, 
   message=A restriction prevents the password from being changed to the current one specified.,
   Context: cloudAnchor: User_xxxx, SourceAnchorValue: xxxxxxx==, 
      AdminUpn: user@msxfaq.de, UserPrincipalName: user@msxfaq.de, ForcePasswordChange: False, 
   Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException:
     Synchronization Engine returned an error hr=80230619, message=A restriction prevents the 
     password from being changed to the current one specified.
   bei AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   bei AADPasswordReset.SynchronizationEngineManagedHandle.ResetPassword(String cloudAnchor, String sourceAnchor, 
   String password, Boolean fForcePasswordChangeAtLogon, Boolean fUnlockAccount, Boolean isSelfServiceOperation)
   bei Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.
     ResetUserPasswordByAdmin(String resetUserPasswordByAdminXmlRequestString)
Log Name:      Application
Source:        ADSync
Event ID:      6329
Task Category: Server
Level:         Error
Keywords:      Classic
User:          N/A
Description:
An unexpected error has occurred during a password set operation. 
ERR_: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting registry value 'ADMADoNormalization', 0x2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (Das System kann die angegebene Datei nicht finden.): Win32 API failure: 2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002 (Das System kann die angegebene Datei nicht finden.)
ERR_: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting registry value 'ADMARecursiveUserDelete', 0x2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (Das System kann die angegebene Datei nicht finden.): Win32 API failure: 2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002 (Das System kann die angegebene Datei nicht finden.)
ERR_: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting registry value 'ADMARecursiveComputerDelete', 0x2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (Das System kann die angegebene Datei nicht finden.): Win32 API failure: 2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002 (Das System kann die angegebene Datei nicht finden.)
ERR_: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting registry value 'SkipAdminCountCheck', 0x2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (Das System kann die angegebene Datei nicht finden.): Win32 API failure: 2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002 (Das System kann die angegebene Datei nicht finden.)
ERR_: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(58): Failed getting registry value 'CheckPasswordChangeFlags', 0x2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(59): 0x80070002 (Das System kann die angegebene Datei nicht finden.): Win32 API failure: 2
BAIL: MMS(10484): C:\__w\1\s\src\dev\sync\ma\shared\inc\MAUtils.h(114): 0x80070002 (Das System kann die angegebene Datei nicht finden.)
BAIL: MMS(10484): ..\session.cpp(934): 0x80230619 (A restriction prevents the password from being changed to the current one specified.): Password violation: Server Error 0x52d
 Ldap Error 0x35
BAIL: MMS(10484): ..\session.cpp(750): 0x80230619 (A restriction prevents the password from being changed to the current one specified.)
BAIL: MMS(10484): admaexport.cpp(2864): 0x80230619 (A restriction prevents the password from being changed to the current one specified.)
ERR_: MMS(10484): admaexport.cpp(2871): Failed to set the password using LDAP password policy control.
BAIL: MMS(10484): admaexport.cpp(3524): 0x80230619 (A restriction prevents the password from being changed to the current one specified.)
ERR_: MMS(10484): ..\ma.cpp(8135): ExportPasswordSet failed with 0x80230619
BAIL: MMS(10484): ..\ma.cpp(8137): 0x80230619 (A restriction prevents the password from being changed to the current one specified.)
Azure AD Sync 2.5.3.0"

Der letzte Fehler war übrigens darauf zurückzuführen, dass das Mindestalter eines Kennworts nicht auf "0 Tage" gesetzt war.


Quelle: Enable Microsoft Entra password writeback - Microsoft Entra ID | Microsoft Learn
https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-enable-sspr-writeback

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.

Eventlog auf DC

Die erfolgreichen als auch erfolglosen Versuche ein Kennwort zu ändern, werden natürlich auch im Eventlog des Domain Controllers protokolliert, wenn Sie eine entsprechende Überwachung aktiviert haben. Hier eine fehlgeschlagene Änderung.

Protokollname: Security
Quelle:        Microsoft-Windows-Security-Auditing
Ereignis-ID:   4724
Aufgabenkategorie:User Account Management
Ebene:         Informationen
Schlüsselwörter:Überwachung gescheitert
Benutzer:      Nicht zutreffend
Computer:      DC.msxfaq.de
Beschreibung:
Es wurde versucht, das Kennwort eines Kontos zurückzusetzen.

Antragsteller:
	Sicherheits-ID:		MSXFAQ\MSOL_xxxxx
	Kontoname:		MSOL_xxxxx
	Kontodomäne:		MSXFAQ
	Anmelde-ID:		0x3528E33F

Zielkonto:
	Sicherheits-ID:		MSXFAQ\User1
	Kontoname:		User1
	Kontodomäne:		MSXFAQ 

Leider protokolliert das Eventlog hier keine Details, warum das so war.

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