IIS 10 Entra Header Authentication
Budget: $30 – $250 USD
I need clear, working guidance to configure Microsoft Entra header-based authentication on an IIS 10 web server that is hosting a simple HTML/JavaScript front-end. IIS is already setup on a Windows datacenter 2025 running in Azure.
Scope
My goal is for IIS to trust the claims it receives from Microsoft Entra, inject the expected headers, and pass them straight through to the static site. The result should be that any request reaching the content root already carries the user identity information so the JavaScript code can simply read the header or cookie without running its own sign-in flow.
Key points you should cover
• Correct installation/activation of the URL Rewrite or ARR modules if they are part of the recommended pattern.
• Exact web.config entries (handlers, modules, customHeaders, outbound rules, etc.) required for header-based auth with Entra.
• 4 claims / headers are already configures in entra. See attached image
• Ways to test the configuration end-to-end, ideally a lightweight HTML page that echoes the incoming headers.
• Guidance on any required TLS settings or additional hardening so the headers cannot be spoofed.
Deliverables
1. A concise setup guide in Word containing every step from a clean Windows Server to a working solution.
3. Confirmation of success through a short screen-share or recorded demo showing a signed-in user and the expected headers visible in the browser’s network trace.
Acceptance criteria
• Request to /index.html must only succeed when Entra authentication has completed and the chosen claim (e.g. upn) is present in the forwarded header.
• Refresh attempts or direct deep links should stay seamless without additional sign-in prompts once the session exists.
• No changes allowed to the client codebase beyond reading the header.
If you’ve implemented this exact pattern before on IIS 10, let me know – especially any quirks you encountered and solved.
Scope
My goal is for IIS to trust the claims it receives from Microsoft Entra, inject the expected headers, and pass them straight through to the static site. The result should be that any request reaching the content root already carries the user identity information so the JavaScript code can simply read the header or cookie without running its own sign-in flow.
Key points you should cover
• Correct installation/activation of the URL Rewrite or ARR modules if they are part of the recommended pattern.
• Exact web.config entries (handlers, modules, customHeaders, outbound rules, etc.) required for header-based auth with Entra.
• 4 claims / headers are already configures in entra. See attached image
• Ways to test the configuration end-to-end, ideally a lightweight HTML page that echoes the incoming headers.
• Guidance on any required TLS settings or additional hardening so the headers cannot be spoofed.
Deliverables
1. A concise setup guide in Word containing every step from a clean Windows Server to a working solution.
3. Confirmation of success through a short screen-share or recorded demo showing a signed-in user and the expected headers visible in the browser’s network trace.
Acceptance criteria
• Request to /index.html must only succeed when Entra authentication has completed and the chosen claim (e.g. upn) is present in the forwarded header.
• Refresh attempts or direct deep links should stay seamless without additional sign-in prompts once the session exists.
• No changes allowed to the client codebase beyond reading the header.
If you’ve implemented this exact pattern before on IIS 10, let me know – especially any quirks you encountered and solved.