Guidance Needed on Handling Microsoft Substrate Management-Created Identities in EntraID

Question

Hello everyone,

I'm seeking advice from those who have successfully implemented Microsoft's Zero Trust Conditional Access (CA) policy framework in environments where Exchange Online is also deployed.

Recently, I began classifying our Entra ID identities using Microsoft's recommended personas. So far, it's been effective — approximately 90% of identities have been successfully tagged. However, during this process, I discovered that the Microsoft first-party app "Microsoft Substrate Management" is being used by Exchange Online to perform CRUD operations on user objects when mailboxes are created.

MS defining this 1st party app under Unkwon actors here - https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/governance/unknown-actors-in-audit-reports#unknown-actors & a third party blog - https://www.jasonfritts.me/2020/08/04/what-is-microsoft-substrate-management-and-why-is-it-creating-users-in-my-tenant/ Which suggests this as a nice effective action, but for Entra administrators it is creating an issue if MS zero trust CA policy framework needs to be implemented.

For example, when our helpdesk team requests a new mailbox (e.g., ******@help.com), the Exchange team provisions it, and this triggers a dual-write action. The "Microsoft Substrate Management" app then automatically creates a corresponding user object in Entra ID. I've found a significant number of these identities, but they don't seem to fit into any of the standard persona categories Microsoft defines.

To address this, I created a new persona called "EXO" to group these identities. However, I'm unclear about the best practices for applying Conditional Access policies to them — particularly whether they should be blocked from interactive sign-in, and if there are any potential risks or implications I should be aware of.

I’d really appreciate insights from anyone who has tackled this scenario. How did you classify these identities? What policies did you apply? Any lessons learned or gotchas would be incredibly helpful.

Thanks in advance!

Answer 1

Hello Danish Anwar,

The article you referenced describes how to block sign-ins for shared mailbox accounts. This is a great first step to secure accounts that are not intended for direct user login.

additionally, you can do is apply the least privilege principle by ensuring that these accounts only have the minimum required permissions for the tasks they need to perform. If these accounts do not need any direct interaction with users, ensure they only have access to what’s absolutely necessary for the operation of Exchange and other related services.

You can block the sign-in of shared mailbox using CA policy in Entra ID. You can follow below instructions.

• Login to Entra ID portal https://entra.microsoft.com/
• Use Global admin credentials to login.
• Go to Protection >> Conditional access
• Click on Policies >> New policy
• Name the new policy
• Under user's section select users and groups and select the shared mailbox account.
• Under Target resources select "All cloud apps"
• Now go to Access controls >> Grant
• Under grant you can select Block access.

Create a CA policy to block sign-ins for service accounts or shared mailbox accounts by targeting these objects based on their attributes in Entra ID (e.g., checking if they are part of a particular group).

As for other CA policies:

-Block legacy authentication (e.g., for Exchange or other non-modern protocols) could further secure these identities.

-Enforce compliance policies (e.g., device compliance or security baselines) if these accounts are tied to devices or need to access resources outside of Exchange Online.

blocking sign-ins via CA policies for non-interactive accounts (such as shared mailboxes, service accounts, etc.) should not have any major impact, provided these accounts are truly not used for login purposes. However, it's important to test these policies in a controlled environment (using a small subset of accounts or a test group) to confirm they behave as expected.

Refer this below document which can help you to create a CA policy with more requirements:

how-to-limit-access-to-a-shared-mailbox-by-device
block-legacy-authentication
list-shared-mailboxes-with-signin-enabled-and-then-block-signin-using-powershell

I hope this clarifies things.

Please remember to "Accept Answer", so that others in the community facing similar issues can easily find the answers.

Answer 2

Hello,

Thanks for reaching out Microsoft community

I will definitely try and clarify your query regards Microsoft Substrate Management-Created Identities in EntraID.

These Identities are created in Entra ID when an operations has been performed directly in exchange online and not in AD / Azure AD because in that case Exchange is the one that is syncing back the object to Azure AD. usually you would see in azure that it was created by Microsoft substrated management however if you want to know who created that object, first try and found out its corresponding exchange online object and then run new-unifiedauditlogserach operation on that exchange online object to find who was the actual actor who created that object.

i hope i was able to clarify your doubts. happy to discuss this in detail if required at all.

Regards

Rahul Gupta

Microsoft Customer Support