Header Insertion for restrict-msa (KB kA14u000000g1E2CAI) not blocking personal accounts

Have you managed to resolve this issue yet,DAVAADEMBEREL PU ? Please don't hesitate to leave a message or ask any questions! I will always do my best to support you.

Hi DAVAADEMBEREL PU,

To permanently resolve the issue you are experiencing in your lab, here are the core details and the optimal solution:

You must turn on SSL Decryption (SSL Forward Proxy). This is the primary reason your configuration isn't working yet. The Palo Alto firewall cannot inspect or inject HTTP Headers (sec-Restrict-Tenant-Access-Policy) into an encrypted HTTPS session. You must enable SSL Forward Proxy for traffic destined for login.live.com.

About Domain coverage: For the method you are currently testing (using the restrict-msa value, which is part of Tenant Restrictions v1), you only need to apply the policy to the login.live.com domain to block personal Microsoft accounts.

While your current setup will work once SSL decryption is enabled, the best practice and Microsoft-recommended approach for "Modern Authentication" flows is Tenant Restrictions v2.

• TRv2 offers more flexible policy management through Microsoft Entra cross-tenant access policies in the cloud, rather than relying solely on the proxy.
• To use TRv2, you will inject the header using a new format (<DirectoryID>:<policyGUID>) and it must be applied across all four domains: login.live.com, login.microsoftonline.com, login.microsoft.com, and login.windows.net.

Go into your Palo Alto NGFW configuration and enable SSL Decryption for the login.live.com destination. Once applied, try logging in with an @outlook.com account again—the system should successfully block it.

I hope this information is helpful. If this answer clarifies your issue, please click "Accept answer" so that other community members facing similar issues can find the solution.

Best regards,

Tracy Le.

Domain coverage:

• For the legacy MSA-blocking method (tenant restrictions v1), only login.live.com is used for consumer Microsoft accounts. The restrict-msa value on the sec-Restrict-Tenant-Access-Policy header is specifically documented as being injected only for traffic to login.live.com.
• The other sign-in domains (login.microsoftonline.com, login.microsoft.com, login.windows.net) are used for Microsoft Entra ID (work/school) authentication and for tenant restrictions (v1 and v2) on organizational tenants, not for the MSA-only restrict-msa signal.
• In tenant restrictions v2, the same header name (sec-Restrict-Tenant-Access-Policy) is reused with a different value format (<TenantId>:<policyGuid>) and must be sent to all four sign-in domains (including login.live.com). When moving to v2, the restrict-msa value must be removed to avoid conflicts.

SSL decryption requirement:

• The proxy/firewall must be able to perform TLS interception and HTTP header insertion to enforce tenant restrictions. This is explicitly listed as a prerequisite for tenant restrictions on a corporate proxy.
• Practically, this means SSL Forward Proxy (or equivalent TLS break-and-inspect) is required on the Palo Alto NGFW for HTTPS traffic to login.live.com (and the other sign-in endpoints when using v2). Without decryption, the firewall cannot see or modify HTTP headers inside the TLS session, so the sec-Restrict-Tenant-Access-Policy header will not be inserted and MSA blocking will not work.

Modern auth and tenant restrictions v2:

• The original restrict-msa header is part of tenant restrictions v1 and still blocks consumer applications when correctly injected to login.live.com. It is described as a deny signal to the Microsoft account platform for consumer apps.
• Tenant restrictions v2 moves configuration from the proxy into Microsoft Entra cross-tenant access policies and uses the same header name with a new value format (<DirectoryID>:<policyGUID>). The proxy simply tags traffic; the actual allow/deny logic is enforced in the cloud policy.
• When migrating from v1 to v2:
  • Remove the v1 headers from the proxy, including sec-Restrict-Tenant-Access-Policy: restrict-msa.
  • Configure partner tenant policies (including for the Microsoft account tenant) in Entra.
  • Re-enable header insertion with the v2 value (<DirectoryID>:<policyGUID>) and send it to login.live.com, login.microsoft.com, login.microsoftonline.com, and login.windows.net.
• Tenant restrictions v2 is the current model and is designed to work with modern authentication flows, including both authentication-plane protection via the proxy and optional data-plane protection via client-side signaling on Windows-managed devices.

Why personal accounts may still be working in the lab:

• SSL Forward Proxy/TLS interception is not enabled or not applied to login.live.com, so the header is never actually inserted.
• The header name or value is misconfigured (must be exactly sec-Restrict-Tenant-Access-Policy: restrict-msa for v1 MSA blocking).
• There is a coexistence/migration scenario where tenant restrictions v2 has been enabled and the proxy is still sending restrict-msa, which is explicitly called out as a conflict that must be removed.

For a forward-looking design and modern auth support, tenant restrictions v2 with proxy header tagging (sec-Restrict-Tenant-Access-Policy: <TenantId>:<policyGuid>) and Entra cross-tenant access policies should be preferred over the legacy restrict-msa approach.

References:

• Restrict access to a tenant
• Set up tenant restrictions v2