Dec 162019
 

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.

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

Sep 262019
 

The Azure AD support team has received a number of support requests from customers looking for information on a curiously named Enterprise App \ Service Principal found in Azure Active Directory.

The service principal’s name is “P2P Server”. Understandably, customers are worried that this may evidence of some type of malware running in their Azure environment.

P2P Server app as found in Azure AD Enterprise Applications blade

After some digging and investigation, it was determined that this service principal is automatically registered in Azure AD after a Windows device has been successfully joined to Azure AD. This service principal enables a specific type of certificate based RDP authentication to take place called PKU2U authentication for DJ++ and AADJ devices. Using this principal, Windows devices that are Azure AD joined will provision device certificates in their computer store with a name matching “MS-Organization-P2P-Access” that enables RDP using Azure AD credentials. Via PKI, these certificates trust the tenant root certificate that is registered on the “P2P Server” service principal in Azure AD.

Full details on this certificate and how it is used can be referenced in our public doc https://docs.microsoft.com/en-us/azure/active-directory/devices/faq#qwhat-are-the-ms-organization-p2p-access-certificates-present-on-our-windows-10-devices

Snippet from this doc below

Q:What are the MS-Organization-P2P-Access certificates present on our Windows 10 devices?

A: The MS-Organization-P2P-Access certificates are issued by Azure AD to both, Azure AD joined and hybrid Azure AD joined devices. These certificates are used to enable trust between devices in the same tenant for remote desktop scenarios. One certificate is issued to the device and another is issued to the user. The device certificate is present in Local Computer\Personal\Certificates and is valid for one day. This certificate is renewed (by issuing a new certificate) if the device is still active in Azure AD. The user certificate is present in Current User\Personal\Certificates and this certificate is also valid for one day, but it is issued on-demand when a user attempts a remote desktop session to another Azure AD joined device. It is not renewed on expiry. Both these certificates are issued using the MS-Organization-P2P-Access certificate present in the Local Computer\AAD Token Issuer\Certificates. This certificate is issued by Azure AD during the device registration process.

Hopefully this answers someones questions on the source and purpose of the “P2P Server” service principal in Azure AD and the “MS-Organization-P2P-Access” certificate found on Azure AD joined Windows devices.

Thanks for reading!