Introduction
In my previous article on Azure Application Gateway Path-Based URL Routing, I walked through setting up path-based routing for Azure App Services behind an Application Gateway. In this article, I will discuss a critical configuration aspect: the “Override with New Hostname” setting and its implications when set to “No” in a custom domain scenario.
Understanding “Override with New Hostname” Setting
When configuring an Application Gateway to route requests to backend App Services, there is an option to override the hostname in the request headers. The “Override with New Hostname” setting determines how the hostname is passed to the backend:
- Yes: The hostname in the request is replaced with the App Service’s default hostname (e.g., xyz.azurewebsites.net).
- No: The original hostname specified by the client is preserved in the request headers.
This setting is crucial when working with custom domains.
Override with new Hostname should be set to No, always for the production setup
Override with new Hostname can be used for basic testing or development, but when you push to staging or production environments it plays a crucial role.
Scenario: Custom Domain for App Services
When configuring Azure Application Gateway with App Services using a custom domain, the “Override with New Hostname” setting plays a crucial role in ensuring seamless authentication and application functionality.
Why is this setting important?
- Authentication Issues with Microsoft Entra ID (MSAL Library)
- If an App Service is integrated with Microsoft Entra ID (formerly Azure AD) using the MSAL (Microsoft Authentication Library), the authentication flow depends on the exact hostname configured in the app registration and reply URLs.When “Override with New Hostname” is set to “Yes”, Application Gateway modifies the Host header to match the backend App Service’s default domain (*.azurewebsites.net).
- This causes authentication failures because the request received by the backend App Service does not match the custom domain expected by the MSAL authentication flow.
- ARR Affinity Cookie Handling
- Azure App Services use the ARRAffinity cookies to maintain session stickiness for user requests. If the hostname is overridden, requests may fail to route correctly to the intended instance, leading to session inconsistencies and authentication errors.
- To ensure session persistence and proper authentication, it is necessary to configure a custom domain for the App Service and ensure that Application Gateway does not modify the hostname.
How to Overcome This Issue?
- Configure a custom domain for the App Service and ensure the custom domain is set in the app registration’s redirect URI in Microsoft Entra ID.
- In the Azure Application Gateway HTTP settings, set “Override with New Hostname” to “No” to preserve the original request hostname.
- This ensures that authentication flows and session handling remain intact, preventing disruptions in applications that rely on Entra ID authentication.
Why Set “Override with New Hostname” to “No”?
- Preserving the Custom Domain:
- If overridden, App Services expect requests with myapp.azurewebsites.net, leading to hostname mismatch issues.
- Keeping “No” ensures the request retains app.mydomain.com, matching the TLS certificate.
- SSL Certificate Validation:
- App Services validate requests based on the configured hostname.
- Using “Yes” without proper hostname configuration may cause SSL/TLS handshake failures.
- Seamless Authentication and Redirection:
- Many authentication flows rely on the original hostname.
- Changing the hostname may disrupt OAuth or OpenID Connect-based logins.
Configuring Azure Application Gateway for Custom Domains
Here’s how I configured my Application Gateway:
- Listener:
- Below is my listener configuration
Make sure you configure the Host name to resolve the Application gateway IP address.
- Backend Pool:
- I added my App Service (xyz.azurewebsites.com).
- Ensured it was accessible via a private link or service endpoint (if needed).
- HTTP Settings:
- Configured the HTTP settings with:
- Override with New Hostname: No
- Custom probe: Enabled to check the connectivity(In my case I used entra.ootysip.com as my hostname)
- Cookie-based Affinity: Disabled (unless required)
- Configured the HTTP settings with:
- Routing Rules:
- Created a path-based rule (/portal* -> App Service backend).
- Associated it with the configured HTTP settings.
- Custom Domain & SSL:
- Backend App Service – Uploaded the SSL certificate for entra.ootysip.com to the Application Gateway.
- Ensured the App Service had a matching TLS binding.
Path mapping /portal in Azure app service is our backend target for the Azure application gateway.
Browser the application and complete the Microsoft Entra ID authentication, after the application login you can find the session cookie, ARRAffinity,and ARRAffinitySameSite cookies.
Azure App Service uses ARRAffinity and ARRAffinitySameSite cookies to enable session persistence, ensuring that subsequent requests from a client are routed to the same instance of an application. This is particularly useful in scenarios where maintaining session state is crucial.
ARRAffinity – Ensures that all user requests are consistently routed to the same App Service instance in a multi-instance deployment.
ARRAffinitySameSite – Similar to ARRAffinity but includes SameSite=None and Secure attributes, making it compatible with modern browser security policies.
Summary
Setting “Override with New Hostname” to “No” is essential when using a custom domain with Azure Application Gateway. It ensures correct hostname preservation, avoids SSL/TLS errors, and maintains authentication flows. By following the above configuration steps, I successfully integrated my App Service with a custom domain while leveraging Azure Application Gateway for traffic management.
If you have any questions or run into challenges, feel free to reach out or comment below!
Useful Link – Host name preservation – Azure Architecture Center | Microsoft Learn
