Entra Documentation for External ID is WILDLY Wrong

Question

Entra Documentation for External ID is WILDLY Wrong

Arlo Gilbert 5

https://github.com/MicrosoftDocs/entra-docs/blob/main/docs/external-id/customers/concept-custom-url-domain.md indicates that the x-forwarded-for header provided by Azure Front Door to CIAM Login when using custom domains WILL use the actual user IP address for security decisions.

https://learn.microsoft.com/en-us/entra/external-id/customers/concept-custom-url-domain#considerations-and-limitations is the published version.

Sadly this is 100% untrue. In fact, if you are dumb enough to pay for P1 or P2 in order to use important signals like the risk scores and security scores AND you also care about your brand enough to use a custom domain, EVERYTHING in Entra will action and decide and risk rate based upon the Azure Front Door IP address, NOT the client_ip that AFD receives.

Why would anybody WANT conditional access policies and risk ratings and other important security decisions made based upon one of a few dozen IPs that are owned by Microsoft.

Up there with one of the single dumbest and worst decisions I've ever seen in the IDP space. If you can't support custom domains with all capabilities then DONT ENABLE CUSTOM DOMAINS AS AN OPTION MICROSOFT!

We've spoken with Microsoft Support who supposedly escalated to the engineering team and told us:

What we confirmed internally

Our internal specialists have validated that when using custom domains routed through Azure Front Door, Entra External ID currently logs the IP address that reaches the Microsoft identity edge—which is the AFD IP—rather than the end‑user’s original IP. This happens because:

Conditional Access “Network/Location” signals are based on the public IP that reaches Entra, not on forwarded headers such as X-Forwarded-For. This is by design to prevent spoofing.
Azure Front Door does forward the real client IP, but only as HTTP headers such as X-Azure-ClientIP and X-Forwarded-For, which are available to your backend applications, not to Entra’s Conditional Access or sign‑in log engine.

Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-02-26T00:25:34.7433333+00:00

Hi @ Arlo Gilbert,

Welcome to Microsoft Q&A Platform.

We understand how important accurate IP-based security signals are when using Conditional Access and Identity Protection.

IP Address Logging : When using Azure Front Door (AFD) with custom domains for Microsoft Entra External ID, the IP address recorded by Microsoft Entra is the public IP address that reaches the Microsoft identity edge. In this architecture, that IP address is the Azure Front Door ingress IP rather than the original end-user IP. This behavior is by design.

Conditional Access Evaluation : Conditional Access location-based policies evaluate the IP address of the client connection that reaches Microsoft Entra. Forwarded headers such as X-Forwarded-For are not used for Conditional Access evaluation. As documented by Microsoft, this design prevents spoofing risks, since HTTP headers cannot be cryptographically validated as originating from a trusted source.

Forwarded Client IP Headers : Azure Front Door does forward the original client IP in headers such as X-Azure-ClientIP and X-Forwarded-For. However, these headers are available to backend applications and are not consumed by the Conditional Access engine or Identity Protection risk evaluation logic.

As a result, when using custom domains through Azure Front Door, Conditional Access policies and risk signals based on IP address will reflect the Azure Front Door IP rather than the true client IP.

Ref: What if I use a cloud proxy or VPN

Can you please share the requested details in private message further troubleshoot.
Arlo Gilbert 5 Reputation points

2026-02-26T00:28:38.9666667+00:00

What details are you asking for?

Azure Front Door -> Entra External ID with custom domain enabled = all sign-in logs and all conditional access and all customAuthExtensions receive Azure Front Door IPV6 IPs instead of the client_ip

Support is aware, engineering is aware, they just don't care that a) the docs are wrong and b) the product does not work.

An IDP that doesn't log the IPs of the end users and can't consume the IPs of the end users for conditional access is pretty useless. I mean, why even pay for P1 or P2 if you can't use any of the capabilities of those licenses due to this.

This is definitely a bug/failure by EEID but they apparently view it as a feature, what admin doesn't want to look at 1,000,000 logins, all of which have one of a dozen Microsoft IPs?

What admin doesn't wish they could setup conditional access geo restrictions and have the geo restriction utilize Microsoft infrastructure as the origin?
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-02-26T01:21:17.2366667+00:00

Hi @ Arlo Gilbert,

We understand your concerns regarding IP visibility and Conditional Access behavior when using Azure Front Door with custom domains in Microsoft Entra External ID.

When traffic is routed through Azure Front Door, the TLS session that reaches the Microsoft identity platform originates from Azure Front Door infrastructure. As a result, Microsoft Entra evaluates the IP address of the connection that terminates at its identity edge. This is consistent with documented Conditional Access behavior:

When using a cloud-hosted proxy, the IP address Microsoft Entra ID uses while evaluating a policy is the IP address of the proxy. The X-Forwarded-For header isn’t used because it cannot be validated as coming from a trusted source.

This design prevents spoofing risks, since HTTP headers such as X-Forwarded-For can be manipulated and are not cryptographically verifiable.

Azure Front Door does forward the original client IP in headers such as X-Azure-ClientIP and X-Forwarded-For. However, those headers are available to backend applications and are not consumed by Conditional Access, Identity Protection risk evaluation, or sign-in log IP determination.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Arlo Gilbert 5 Reputation points

2026-02-26T02:37:45.04+00:00
I hear you saying the words, but the documentation literally says the opposite. The reason i am upset is because I would not have selected Entra if this issue was known. This is very poor security and very poor governance.

There is NO LOG of client ip address anywhere in the entire IDP. This means that although companies using entra external ID can understand who is accessing the app using the tokens, but they can not tell whether the IPs match, removing a common condition of token evaluations. Sign-In logs reflect the internal Azure infrastructure instead of the correct X-Forwarded-For (or use the doggone internal chain dude, you are microsoft right? Azure client ID + Azure FDID + Lookup to validate it's not forged, i mean, sheesh, ya'll could easily do this).

Custom authentication extensions have no ability to receive a correct IP address, meaning that many popular commercial providers who utilize custom auth (and many many devs) whose ability to assess the authentication request, rely upon geo lookups against the IP address, now entirely useless.

So few of your customers could use this capability if they realized that they could not get PCI or SOC compliance with this kind of silliness.

Again, you don't even LOG the real ip anywhere, this is not just in conditional-access, it is a defect present throughout the entire request in all systems that are party of the Entra request. The customer is entirely in the dark across the entire platform about the ip address of the end user.

We will figure out away around this and eventually just swap to a different provider. But for posterity and so that future customers of Entra External ID are clear:

P1 and P2 licenses are not functional in an Entra External ID Tenant.

Sign-In logs reflect the IP addresses of the Azure Front Door rather than the IP addresses provided in numerous ways by headers such as X-Forwarded-For and X-Azure-Client-IP for example.

Agents must warn users about the significant security risks presented by Microsoft Entra External ID.
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-02-26T18:24:19.4266667+00:00

Hi @ Arlo Gilbert,

We understand your concerns.

When Azure Front Door is used with a custom domain for Microsoft Entra External ID, the IP address evaluated and logged by Entra is the public IP that reaches the identity edge, which is the Azure Front Door IP.

Conditional Access and Identity Protection evaluate the source IP of the transport connection, not forwarded headers such as X-Forwarded-For. This is consistent with Microsoft’s documented behavior for proxy scenarios:

When you use a cloud-hosted proxy, the IP address Microsoft Entra ID uses while evaluating a policy is the IP address of the proxy. The X-Forwarded-For header isn't used because it can't be validated as trusted.

https://learn.microsoft.com/en-us/entra/identity/conditional-access/location-condition

Azure Front Door forwards the client IP in headers, but those headers are not consumed by Conditional Access, risk evaluation, or sign-in logging.

This is current product behavior rather than a service malfunction.

If you would like to request feature enablement, you can submit your idea through the feedback forum The team will review it and take the necessary action

Please "upvote" if the information helped you. This will help us and others in the community as well.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-03-03T03:30:57.43+00:00

Hello Arlo Gilbert

I see Vallepu Venkateswarlu has addressed your queries.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-03-04T10:19:42.88+00:00

Hello Arlo Gilbert

I see Vallepu Venkateswarlu has addressed your queries.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.
Arlo Gilbert 5 Reputation points

2026-03-09T18:14:30.82+00:00

No. Nothing that Microsoft has done here is useful. You've taken my time and seem to be focused on JUSTIFYING poor documentation rather than fixing it. That's your problem, not mine. I already stopped using Entra.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-03-09T18:26:06.8833333+00:00

Hello Arlo Gilbert

Thanks for the reply!

This is current product behavior rather than a service malfunction.

If you wish you may upvote the feedback in the below forum requesting this feature. All the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.

Feedback link: https://feedback.azure.com/d365community

Please "upvote" if the information helped you. This will help us and others in the community as well.
Marcin van de Ven 130 Reputation points

2026-09-10T13:04:42.4433333+00:00

We are facing the same issues with using Front Door to use a custom domain for authentication for our web services through EntraID. Even worse, enabling geoblocking using WAF-policies caused Microsoft Defender to go completely nuts when using Front Door.

In our setup we use an extra tenant within our 'main' tenant to keep accounts from our customers separate from the accounts of the companies employees. To make use of the more professional looking 'custom domain', Front Door is required for having authentication work via our own domain names.

For security reasons, the accounts of employees managing the systems, are external B2B-accounts. This not only gives our company control over which employees get access to the EntraID for the products, it also makes sure the stricter security policies are enforced for the product administrators.

After a suspicious login we decided to enable WAF policies on Front Door to prevent access to our products/authentication from outside our target countries. Instead of increasing security and reducing the amount of logins coming from other countries, Front Door decided to randomly route the administrative B2B-logins via the other side of the world. All those 'malicious' IP-addresses were owned by Microsoft and according to Entra, located in places where, coincidentally, Azure data centers are.
These login source IP-addressed caused Microsoft Defender in our companies' own tenant to sent alert emails about hijacked sessions, coming from our own applications, to our IT Department. This was only happening "some times"; not all administrative users and not on all login attempts caused those alerts.

I've turned of the WAF-policies again, now Defender stopped notifying us about those malicious sessions coming from different parts of the world. I completely miss the logic here: Microsoft wants you to use Front Door to serve your own applications, especially when using EntraID for authentication. But doing so, one is basically barred from using any reasonable security metric to trace where those login attempts come from (as the answer is 'Azure'). Basically we need to implement our own tracing logic when a user is logging in. It seems that Microsoft is not seeing the security issues caused by this: to them it is more important to 'replace' the not verified original IP, than to provide any meaningful logging to increase security.

1 answer

Your answer

Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-02-26T00:25:34.7433333+00:00

Hi @ Arlo Gilbert,

Welcome to Microsoft Q&A Platform.

We understand how important accurate IP-based security signals are when using Conditional Access and Identity Protection.

IP Address Logging : When using Azure Front Door (AFD) with custom domains for Microsoft Entra External ID, the IP address recorded by Microsoft Entra is the public IP address that reaches the Microsoft identity edge. In this architecture, that IP address is the Azure Front Door ingress IP rather than the original end-user IP. This behavior is by design.

Conditional Access Evaluation : Conditional Access location-based policies evaluate the IP address of the client connection that reaches Microsoft Entra. Forwarded headers such as X-Forwarded-For are not used for Conditional Access evaluation. As documented by Microsoft, this design prevents spoofing risks, since HTTP headers cannot be cryptographically validated as originating from a trusted source.

Forwarded Client IP Headers : Azure Front Door does forward the original client IP in headers such as X-Azure-ClientIP and X-Forwarded-For. However, these headers are available to backend applications and are not consumed by the Conditional Access engine or Identity Protection risk evaluation logic.

As a result, when using custom domains through Azure Front Door, Conditional Access policies and risk signals based on IP address will reflect the Azure Front Door IP rather than the true client IP.

Ref: What if I use a cloud proxy or VPN

Can you please share the requested details in private message further troubleshoot.
Arlo Gilbert 5 Reputation points

2026-02-26T00:28:38.9666667+00:00

What details are you asking for?

Azure Front Door -> Entra External ID with custom domain enabled = all sign-in logs and all conditional access and all customAuthExtensions receive Azure Front Door IPV6 IPs instead of the client_ip

Support is aware, engineering is aware, they just don't care that a) the docs are wrong and b) the product does not work.

An IDP that doesn't log the IPs of the end users and can't consume the IPs of the end users for conditional access is pretty useless. I mean, why even pay for P1 or P2 if you can't use any of the capabilities of those licenses due to this.

This is definitely a bug/failure by EEID but they apparently view it as a feature, what admin doesn't want to look at 1,000,000 logins, all of which have one of a dozen Microsoft IPs?

What admin doesn't wish they could setup conditional access geo restrictions and have the geo restriction utilize Microsoft infrastructure as the origin?
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-02-26T01:21:17.2366667+00:00

Hi @ Arlo Gilbert,

We understand your concerns regarding IP visibility and Conditional Access behavior when using Azure Front Door with custom domains in Microsoft Entra External ID.

When traffic is routed through Azure Front Door, the TLS session that reaches the Microsoft identity platform originates from Azure Front Door infrastructure. As a result, Microsoft Entra evaluates the IP address of the connection that terminates at its identity edge. This is consistent with documented Conditional Access behavior:

When using a cloud-hosted proxy, the IP address Microsoft Entra ID uses while evaluating a policy is the IP address of the proxy. The X-Forwarded-For header isn’t used because it cannot be validated as coming from a trusted source.

This design prevents spoofing risks, since HTTP headers such as X-Forwarded-For can be manipulated and are not cryptographically verifiable.

Azure Front Door does forward the original client IP in headers such as X-Azure-ClientIP and X-Forwarded-For. However, those headers are available to backend applications and are not consumed by Conditional Access, Identity Protection risk evaluation, or sign-in log IP determination.

Please "upvote" if the information helped you. This will help us and others in the community as well.
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-02-26T18:24:19.4266667+00:00

Hi @ Arlo Gilbert,

We understand your concerns.

When Azure Front Door is used with a custom domain for Microsoft Entra External ID, the IP address evaluated and logged by Entra is the public IP that reaches the identity edge, which is the Azure Front Door IP.

Conditional Access and Identity Protection evaluate the source IP of the transport connection, not forwarded headers such as X-Forwarded-For. This is consistent with Microsoft’s documented behavior for proxy scenarios:

When you use a cloud-hosted proxy, the IP address Microsoft Entra ID uses while evaluating a policy is the IP address of the proxy. The X-Forwarded-For header isn't used because it can't be validated as trusted.

https://learn.microsoft.com/en-us/entra/identity/conditional-access/location-condition

Azure Front Door forwards the client IP in headers, but those headers are not consumed by Conditional Access, risk evaluation, or sign-in logging.

This is current product behavior rather than a service malfunction.

If you would like to request feature enablement, you can submit your idea through the feedback forum The team will review it and take the necessary action

Please "upvote" if the information helped you. This will help us and others in the community as well.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-03-03T03:30:57.43+00:00

Hello Arlo Gilbert

I see Vallepu Venkateswarlu has addressed your queries.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-03-04T10:19:42.88+00:00

Hello Arlo Gilbert

I see Vallepu Venkateswarlu has addressed your queries.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.
Arlo Gilbert 5 Reputation points

2026-03-09T18:14:30.82+00:00

No. Nothing that Microsoft has done here is useful. You've taken my time and seem to be focused on JUSTIFYING poor documentation rather than fixing it. That's your problem, not mine. I already stopped using Entra.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-03-09T18:26:06.8833333+00:00

Hello Arlo Gilbert

Thanks for the reply!

This is current product behavior rather than a service malfunction.

If you wish you may upvote the feedback in the below forum requesting this feature. All the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.

Feedback link: https://feedback.azure.com/d365community

Please "upvote" if the information helped you. This will help us and others in the community as well.

Answer 1

Arlo Gilbert 5

Congrats, you've successfully read my message.

What you have not done is reviewed the documentation. The documentation says THE OPPOSITE OF WHAT YOU ARE SAYING.

Meaning, other suckers are going to trust the documentation. They should not because the documentation is WRONG.

0 comments