Custom Domains Deep Dive

Hi Everyone,

Throughout our documentation, we emphasize that we recommend using custom domains - bringing your own domain for the external URL rather than using the msappproxy.net domain we provide. To help make the value and configuration of custom domains clearer, below is a deep dive – starting with some FAQs and then moving into details on custom domains configurations for different scenarios.

FAQs

Why should I use custom domains?
We recommend using this solution so you can ensure your internal and external URLs are the same.

• Your users will have an easier experience. They don’t need to learn different internal and external URLs and track where they are – the same URL will work for them no matter where they are.
• The links contained in applications will work without additional configurations. If you have hard coded internal links within your applications, these may break when clicked if the internal link is not published within the Application Proxy application, and the link is not externally resolvable. When your URLs are the same, you avoid this problem. To learn more about options for this problem if you are not able to use custom domains, see the documentation on translating inline links.
• Some configurations will only work if you have custom domains. For example, you will need custom domains for applications that use SAML, such as when you’re using ADFS but are unable to use WS-Fed. See the documentation on claims-aware applications for more detail.
• Build user confidence. Seeing and using an “msappproxy.net” domain may be less familiar for your users – a custom domain can help build their confidence when accessing these applications.

If you are unable to make the internal and external URLs match, the recommendation is not as strong though there may still be benefits.

If I use custom domains, will my internal users be routed externally?
This is a configuration you can choose. You can use a split-brain DNS to ensure that internal users are never routed externally and stay within the network, while external users are directed through Application Proxy. See the deployment section for more information on configuring a split-brain DNS.

Why do you need a certificate?
We use the certificate to create the secure SSL connection for the domain you provided.

What types of certificates do you accept?
For complete details, please see our custom domains documentation. Please note that we only support PFX certificates to ensure that we also have any required intermediate certificates.

Can I use a wildcard certificate?
Yes, we are able to handle wildcard certificates. Those are explicitly required if you are using wildcard applications.

How do the certificates work with wildcard publishing?
When publishing a wildcard application, you must use a wildcard certificate with a subject name that matches the domain you are publishing externally.
If you'd like to use this application to also access subdomains, you should add these subdomain wildcards as subject alternative names in the same certificate.

Can I use one certificate with multiple applications?
Yes, you will be able to upload a certificate once for use with multiple applications. If an uploaded certificate works with another application, we will automatically apply it. You will not be prompted to upload it again.

Does my certificate also work for subdomains of the listed domain?
You need to make sure that subdomains are listed as subject alternative names in the same certificate. Otherwise a given certificate doesn’t work for subdomains. So, for example, a certificate for *.adventure-works.com will not work for *.apps.adventure-work.com.

Can I use a private root CA?
We strongly discourage you from using this. If you use a private root CA, it then also needs to be pushed to client machines. This can introduce a lot of additional challenges.

Deployment

We have documented the high level flow for using custom domains with Application already, but below is another look at these steps. While this information is current at the time the blog is published, please be sure to reference the documentation for the most up-to-date information.

Part #1: Adding a Verified Domain

First you need to add the desired domain as a verified domain in the Azure Portal. Below is a summary of the steps. For more information, please see the adding custom domains documentation.

1. In the Azure Portal, navigate to Azure Active Directory -> Custom domain names and select the “Add custom domain” button.
2. Enter the domain name and click “Add Domain”
3. You will be prompted to create a new TXT record in your domain registrar with specific information.
4. Once you make this change, you can come back to this page and click “Verify”. That will update the status of the domain to “Verified” and you will now be able to use this domain when applicable in across your Azure AD configurations, including for Application Proxy.

Part #2: Create the Application Proxy application, and add the certificate

Next you need to apply your custom domain when publishing an application. The steps below start at publishing a new application. However, you can also change the domain of an application after publishing. In that case, navigate to the application through the Enterprise Applications menu, select the “Application Proxy” menu, and go to step #2.

1. When you publish an application that uses custom domains, follow the standard add application flow. Navigate to Azure Active Directory -> Enterprise applications, select “New application” and then “On-premises application”.
2. To use a custom domain, ensure that you chose your verified domain while defining the external URL.
3. You will see an information bubble telling you what DNS entry you need to configure on your external DNS to make sure that your external traffic to the custom domain is getting directed to the Application Proxy endpoint. DNS configurations are handled in more depth in part #3.
   
4. Click Add (or save if modifying an existing application).
5. If you have uploaded a certificate to Application Proxy that matches the external URL, you are done with this section. Otherwise, navigate to the "Application Proxy" menu for the application you just created. Click on the certificate upload prompt at the bottom of the screen.
   
6. Upload the certificate, enter the certificate key, and click Upload Certificate.
   
7. Save the application, and your custom domain is now set up. Be sure to assign users to your application before testing or releasing it.

Part #3A: Setting Your DNS entries – Same Internal/External URL, Different Internal and External Behavior

If you would like to make sure your internal users are not directed through the Application Proxy, you will need to set up a split brain DNS.
A Split DNS infrastructure is used to direct internal hosts to an internal domain name server for name resolution and external hosts to an external domain name server for name resolution.

Part #3B: Setting Your DNS Entries – Same Internal/External URL, Same Internal and External Behavior

Both the internal and external DNS CNAME entries point to the msapproxy.net URL.

One common case for this scenario is if you wanted to apply conditional access to the web application/websites irrespective of the location of the devices - for example a trusted device is only allowed access from a Azure AD Registered/Join Device.

Part #3C: Setting Your DNS Entries – Different Internal/External URL

When your internal and external URLs are different, you don’t need to configure the split brain behavior since the user routing is determined by the URL they hit. In this case, you will only be changing the external DNS, routing the external URL to the Application Proxy endpoint.
In part 2, after selecting your custom domain from the external URL, you will see a pop-up that shows the CNAME entry you need to add to the external DNS. You can always see these instructions again by navigating to the application in Enterprise Applications, and clicking on the Application Proxy menu.

Is there anything else you'd like to know about custom domains? Let us know in the comments!

Best,

Harshini Jayaram

Program Manager II