Who is the actor fim_password_service@support.onmicrosoft.com in my Azure AD logs?

I recently received a support case where the customer was concerned that a bad actor “fim_password_service@support.onmicrosoft.com” was performing SSPR \ Password Reset operations on their Azure AD user’s without authorization.


UPDATE (2022-10-28)
There are other opeations which may be logged as fim_password_service@support.onmicrosoft.com being the actor. This includes

  • SSPR portal updates to a user during SSPR password reset from https://aka.ms/sspr portal
  • MFA and SSPR Security Info registration from https://aka.ms/mysecurityinfo portal such as adding/deleting/updating Microsoft Authenticator registration details (StrongAuthenticationPhoneAppDetail, AuthenticatedTimestamp and OauthTokenDriftTime etc.)

If you have other unknown principals showing up in your AAD logs and you would like to verify they are Microsoft 1st party principals please use the Feedback sections of the below articles

Unknown Actors in AAD Audit Reports
Verify first-party Microsoft applications in sign-in reports

When checking the Azure AD Audit Logs, they found entries similar to the below screenshot:

fim_password_service@support.onmicrosoft.com AAD audit log entries

This is concerning as the customer has no account in their AAD tenant with the UPN fim_password_service@support.onmicrosoft.com.

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 fim_password_service@support.onmirosoft.com service account resetting the user’s password as seen in the below example:

Reproduction of a successful SSPR by user testsspr@jasonfritts.me

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.

fim_password_service@support.onmicrosoft.com 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 fim_password_service@support.onmicrosoft.com.

UPDATE (2022-10-28)
There are other opeations which may be logged as fim_password_service@support.onmicrosoft.com being the actor. This includes

  • SSPR portal updates to a user during SSPR password reset from https://aka.ms/sspr portal
  • MFA and SSPR Security Info registration from https://aka.ms/mysecurityinfo portal such as adding/deleting/updating Microsoft Authenticator registration details (StrongAuthenticationPhoneAppDetail, AuthenticatedTimestamp and OauthTokenDriftTime etc)

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!

Oauth2 and OpenID Protocol Review

The following presentations by John Craddock and Pamela Dingle at Microsoft Ignite are the best explanations I have found for understanding and troubleshooting the Oauth2.0 and OpenID protocols as they related to Azure Active Directory in increasing order of complexity:

Introduction to identity standards – BRK3238 – Pamela Dingle
An IT pros guide to Open ID Connect Oauth 2.0 with the V1 and V2 Azure AD – BRK3234 – John Craddock
Troubleshooting OpenID Connect and Oauth 2.0 protocols – John Craddock

What is Office 365 Shell WCSS-Client?

On a recent support case a customer noted that an application named “Office 365 Shell WCSS-Client” was found in his Office 365 and Azure AD sign in security logs.  This customer was concerned that this may be some type of malware.  After searching public documentation we could not find any information on what this application was, so we asked the product engineering teams to see if they could explain.  Our Office 365 UX team provided this very helpful description of what this application is and that it should not be viewed as malware:

Office 365 Shell WCSS-Client is the browser code that runs whenever a user navigates to (most) Office365 applications in the browser.  The shell, also known as the suite header, is shared code that loads as part of almost all Office365 workloads, including SharePoint, OneDrive, Outlook, Yammer, and many more.


The suite header needs authentication to do the following:


* Get information about the user’s licensing state, so that we know what apps to show in the app launcher


* Connect to services that provide information about most recently used documents, so that we can show those in the app launcher


* Connect to Exchange, so that we can provide mail and calendar notifications


* Authenticate against the Microsoft / O365 graph, so that we can get and set user preferences for things like language, user theme and other O365 settings

There are different providers for those different things, necessitating different auth exchanges.  These exchanges happen without direct user intervention, when a page hosting the shell code is loaded.  The shell code, workload-specific code (e.g. SharePoint) and the browser all cache different parts of this information in different ways, so that pattern might not always line up for each user in each workload, but multiple auth exchanges here are the norm. A typical user navigating through different Office365 workloads can expect to see several different requests such as shown in the logs”

O365 Product Engineer

Hopefully this helps someone understand what this application is in the future when performing a similar audit of their security logs in Office 365 or Azure AD.

Capturing a Fiddler trace

A Fiddler trace can be used to view any Http\Https web requests and responses made from your web browser. Capturing this data can be very useful for analyzing errors encountered. To capture a Fiddler trace, follow the steps below.

How to capture a Fiddler trace

  1. Download Fiddler from here and install it.
  2. Run Fiddler and go to Tools -> Fiddler Options.
  3. On the HTTPS page, verify that Capture HTTPS Connects is enabled.
  4. Verify that Decrypt HTTPS traffic is enabled with the …from all processes option.
  1. NOTE: If you are in a Federated enviornment, please also check Rules -> Automatically Authenticate.
  2. In the very bottom left of the Fiddler application, ensure that you see “Capturing” displayed indicating that Fiddler is capturing traffic.
  1. If Fiddler is not capturing. Choose File -> Capture Traffic (Or press F12)
  1. Minimize Fiddler to tray.
  2. Replicate the reported issue.
  3. Once Complete, you can stop capturing by selecting File -> Capture Traffic again or pressing F12
  4. In Fiddler, go to File -> Save -> All Sessions and save the archive to disk.
  1. Save .SAZ file locally and then provide this .SAZ to engineer troubleshooting your issue
  2. Once complete, Fiddler can be uninstalled from Windows Control Panel \ Programs and Features \ Uninstall “Progress Telerik Fiddler”

Capturing a HTTP Archive (HAR) trace

A HTTP Archive (HAR) trace can be used to view any Http\Https web requests and responses made from your web browser. HAR traces are useful when you do not want to install a full application like Fiddler, as HAR files can be captured naively using most Web Browsers like Edge, Chrome, or Internet Explorer. Capturing this data can be very useful for analyzing errors encountered. To capture a HAR trace, follow the steps below

To generate the HAR file for Internet Explorer
  1. Open Internet Explorer and go to the page where the issue is occurring.
  2. Press F12 on your keyboard(or click the gear icon > F12 Developer Tools)
  3. Click the Network tab.
  4. Reproduce the issue that you were experiencing before, while the network requests are being recorded.
  5. Once done click the Save button to export as HAR (or press Ctrl+S).
  1. Give the trace a filename and click the Save button which will save it as a .har file .
  2. Upload your HAR file to your ticket or attach it to your email so that we may analyze it.
To generate the HAR file for Chrome
  1. Open Google Chrome and go to the page where the issue is occurring.
  2. From the Chrome menu bar select View > Developer > Developer Tools .
  3. From the panel opened at the bottom of your screen, select the Network tab.
  4. Look for a round red Record button ( )) in the upper left corner of the Network tab, and make sure it is red. If it is grey, click it once to start recording.
  5. Check the box next to Preserve log .
  6. Click the Clear button ( )) to clear out any existing logs from the Network tab.
  7. Now try to reproduce the issue that you were experiencing before, while the network requests are being recorded.
  8. Once you have reproduced the issue, right click anywhere on the grid of network requests, select Save as HAR with Content , and save the file to your computer.
  1. Upload your HAR file to your ticket or attach it to your email so that we may analyze it.
To generate the HAR file for Edge
  1. Browse to the URL where you are seeing the issue.
  2. Navigate to Developer tools (use F12 as a shortcut) and select the “Network” tab.
  3. Refresh the page to start capturing the traffic between the browser to the server, or click on a link with which you are seeing the issue. The aim is to reproduce the issue and capture the output.
  4. Click on “Export as HAR” followed by Save As… to save the HAR file.
HAR trace Analysis with Fiddler

A support technician can then analyze this HAR trace using an application like Fiddler.

The steps for that are using the File -> Import Sessions option in Fiddler and then choosing HTTPArchive as shown below.