I recently received a support case where the customer was concerned that a bad actor “email@example.com” was performing SSPR \ Password Reset operations on their Azure AD user’s without authorization.
When checking the Azure AD Audit Logs, they found entries similar to the below screenshot:
This is concerning as the customer has no account in their AAD tenant with the UPN firstname.lastname@example.org.
We performed a reproduction of a standard SSPR operation performed by a known user, and confirmed that these logs appeared and are to be expected.
A successful SSPR operation will first show the user who performed SSPR performing verification steps, submitting a new password, and then the email@example.com service account resetting the user’s password as seen in the below example:
If you expand your audit log search for all operations with the target account specified, you will see that the user who actually initiated the SSPR action is also audited.
We found it odd that this service account was performing the actual password reset so there was an escalation opened with our engineering team to review. They confirmed the same, that this is to be expected.
” firstname.lastname@example.org is an internal account used to indicate password reset is done in App context versus App + User context. “
This means that as the user doesnt know their password, the reset operation can’t be completed in the context of the SSPR app + User, so in certain scenarios such as SSPR, AAD operations are performed in the App context only and thus are audited as the actor being the internal account email@example.com. There are also other various AAD scenarios that may be audited like this as well such as certain MFA registration operations.
The engineering team acknowledged that this can be confusing to customers and they are working on publicly documenting this account to prevent future support cases in the future. I’ll be sure to update with a link when that occurs.
Hope this answers someone’s questions in the meantime!