We have an app that allows customers to use their own custom domain to access their accounts on our app.
Currently, we are using the Azure App Services Custom Domain option & when a user shares their custom domain with us, we manually add it to the Azure Custom Domains list pointing it to their unique account URL. i.e. projects.customerdomain.com (custom domain) to customer1.anywhereapp.io (their account in our product 'Anywhere').
This approach has been working well.
We are now exploring if we can use Azure Front Door to make our app more responsive worldwide & one of the problems we are stuck at is how do we configure the custom domains of our customers to their specific Anywhere accounts?
I've gone through the official Azure FD Custom Domain documentation & I understand it allows us to add the custom domain pointing to one backend, in our case each custom domain also needs to point to a specific subdomain URL. i.e. customer1.anywhereapp.io
How do we achieve this?
Any guidance in the right direction is really appreciated.
Thanks
ST
Azure Front Door can forward the request Host header to the backend. So you can configure the custom domain both on Front Door and the App Service using DNS verification.
To do this, following the following steps:
Go to your App Service
Go to Custom Domains
Copy the Custom Domain Verification ID
Add a new DNS TXT record with the copied value: TXT asuid.projects.customerdomain.com. <verification id>
Go to your Front Door profile
Setup the Custom Domain as per the instructions on MSDN
Configure the origin as follows:
Name: <any appropriate name>
Origin Type: App services
Host name: <yourappservice.azurewebsites.net>
Origin host header: <blank> <-- leaving this empty will forward the request host header to the backend
Certificate subject name validation: Enabled
Now when a request is made to Front Door this same request is passed onto your backend including the custom domain (projects.customerdomain.com).
From the perspective of your app service, there's then no difference whether you use Front Door or not.
We've been struggling with this same issue. While Jeremy's solution sounds perfect, we are struggling with figuring out how to make it work when we have multiple app services running an app on the same domain.
For example, we have an app running in 2 separate app services/app service plans. It is the same application code. Let's say the domain is my.website.com
AppServiceEast (say its Azure non-custom domain is appserviceeast.azurewebsites.net)
AppServiceWest (say its Azure non-custom domain is appservicewest.azurewebsites.net)
They both run the app.
We've setup the front door pools/rules/etc without problem. However, we are stuck with 1 of 2 problems:
If we keep the origin host headers in place, anytime someone goes to my.website.com, their browser shows them ending up at appserviceeast.azurewebsites.net or appservicewest.azurewebsites.net
If we take those out, it should just keep passing along my.website.com - but the problem with that is that I can only make ONE of those app services have its custom domain be my.website.com. If I try to make them both work on that domain, I get stuck at the point where I'm trying to create 2 TXT records with different values for the same domain.
It feels like this has to be a common thing to want to do - setup a web app in multiple regions on ONE domain, and have Front Door split traffic between them as we see fit. However, we run into roadblocks at every turn.
Related
This is more of a general question about. I have a website running as an Azure App Service. I configured a custom domain so that you are able to call it by my-site-name.com.
As the request of customers kept growing and each customer has specific demands, I was wondering if it is possible to have a subdomain for each customer. For example, client1.my-site-name.com and client2.my-site-name.com.
Is it possible to do all of this within a single App Service or do I need to set up an Azure App Service for each subdomain?
The reason behind my question is, that it would be quite expensive to have an App Service for each individual customer.
You should also consider just adding a wildcard custom domain entry. This is an older blog post, but it outlines Azure WebApp support for Wildcards:
https://azure.microsoft.com/en-us/blog/azure-websites-and-wildcard-domains/
This would mean that *.my-site-name.com traffic goes to your single Web App. Then it is up to the logic of your webapp to determine which client it is by inspecting the hostname of the request (client1.my-site.name.com) and taking the appropriate action to customize the response to that client.
Using a wildcard eliminates the need to add a specific custom subdomain mapping for each client.
It should be possible. Within your app service, if you go to the settings for that service, there is a Custom domains option, select it.
Within there you can then map your subdomains to this service, and it allows you to do it multiple times. You just need to validate and set it up with the A record or CNAME and own the domain. Additionally, you should be able to add SSL Bindings for each.
Here are some documentation on it, I don't believe this documentation handles your exact use case but it does touch on the custom domain portion and should provide additional support.
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain
https://blogs.msdn.microsoft.com/waws/2014/10/01/mapping-a-custom-subdomain-to-an-azure-website/
Let me know if you need more
This seems more like a domain management issue than an azure specific issue. You have already decided to have different sub domains to each customer. That, by definition, means each sub domain needs individual server space. That in turn would mean, an app service for each customer.
So, the answer is what you already have. Have an app service (essentially web server) for each customer via sub domain.
In your position, I would consider some alternatives.
Rebuild your app to work with some form of login system, so clients login and get themselves a separate view.
Alternatively, go with sub folders instead of custom domains. something like, domain.com/client1, domain.com/client2 and so on.
I'm migrating a complete infrastructure over to Azure; it's been slow going as there's so much to learn and for every two steps forward, there seems to be one step back.
After what seems like an eternity, I think I've got it all sorted with one exception.
The architecture is as follows:
Azure Traffic Manager ==> 2 Azure Application Gateways (geo separated) ==> Azure App Service
A custom domain is used for the traffic manager and the gateways are listening for the same domain and, when the route matches, passing on the requests down to the app service.
The actual app itself is a ASP.NET MVC application and it uses forms authentication; and this is where the challenge happens.
When navigating to the public address: client.domain.com and hitting the website, it determines that the user is not authenticated and sends the browser to the login page... so far so good but, rather than using client.domain.com/login it uses the web-server dns name, so client.azurewebsites.com/login
How do I go about changing the behaviour so that it uses the external DNS name rather than the website name?
I can't setup custom domains on the app service as the only route into the site is via the gateway as this is also the firewall.
Is there some Web Config setting I can make? I'm looking at the outbound rewrite rules but these seem to only work on tags rather than 302 redirects.
Any thoughts would be most welcome.
You need to setup custom dns names on your webapp (you can use TXT record to verify dns name, so i dont see a reason why you can add it to the webapp). or you can alter the code.
In order to solve this problem, I had to make a code change to the web app itself. Not ideal but it worked.
What I had to do was to extend the code that redirects an unauthenticated request to the login page by sniffing for the X-Original-Host HTTP Header that the App Gateway forwards on. This contains the public facing DNS name. If the header is present and it is on a pre-approved white-list (so as to prevent any hijacking), then redirect the user to the login page for this domain, rather than the one the server is listening on directly (so use client.domain.com rather than client.azurewebsites.com)
when adding a custom domain to Azure app service, the system always trying to validate your custom domain, but this is very annoying for my case.
i have a CDN service which i have put my www. sub domain on it, and the now i am going to move my website to azure app service
actually i have the website up running already on app service, and the only thing i need to do is point the origin server address to app service in CDN setting
but, i need to set up a custom domain on app service for www. otherwise it won't load.
so the worst thing is, when i try to add the www record as custom domain, it validates if the record is really pointed to app service, which is definitely not possible because if i switch the domain really to app service,
first, i can not guarantee all user will get the dns change in same
time
second, then i need to switch www back to CDN after the
validation, then during this period, my app will work without cdn,
which will be a problem also
so is there anyway to add a custom domain without validation.
this is really stupid, i have to say
maybe i am stupid
found the way in office MS documents
here is the link
https://learn.microsoft.com/en-us/azure/app-service-web/app-service-custom-domain-name-migrate
you can set up a txt verification recond to pass the verification
I have a custom domain www.abc.com configured for web app webapp-a, and I'd like to transfer it to webapp-b without downtime.
If I try to add the domain to webapp-b, I am getting
The host name www.abc.com is already assigned to another Azure website: webapp-a
It there a way to let webapp-a continues to serve the requests, until the DNS cache expires?
Edit: The domain has IP based SSL binding, and the DNS is caching the virtual IP.
I faced the same issue, and was able to solve it in a tricky way.
I created new App Service Plan (previously known as Web Hosting Plan), and assigned "new" Web App to it (you can do it via new portal, or you can create Service Plan during Web App creation).
Then, I was able to assign the same host name to Web Apps in different hosting plans.
Thinking about this, I feel it logical: most probably Service Plan is mapped to physical IIS machine, and you cannot have two sites with the same host name in the same IIS for the obvious reason.
After migration from one DNS to another is done, you can remove unused Service Plan (as you basically pay for each separately).
According to a blog post by the Azure App Service Team in June 2017, it would appear that Azure now supports adding the same custom domain to multiple web apps:
There are scenarios where a customer would like to add the same hostname to multiple web apps in the same subscription, having a geo distributed website is one example. Our custom hostname feature allows you to bypass validation for hostnames that have already been validated. You only need to verify domain ownership when you add a hostname for the first time. For all other apps in the same subscription, you can add the same hostname without creating any DNS records.
You can read the entire blog post at https://blogs.msdn.microsoft.com/appserviceteam/2017/06/21/custom-hostnames-with-app-service/. The quote above was taken from the Adding the same custom hostname to multiple web apps section.
This should help in scenarios such as this where you want to transfer a custom domain name from one web app to another. You can simply add the same custom domain name to both web apps, add any required SSL bindings, and then change the DNS to point to the new web app. As the DNS change propagates, traffic should gradually move over to the new web app without any downtime.
I've tested this myself in the North Europe region and had no problems. Both web apps were in different App Service Plans. I have not tested this scenario with both web apps in the same App Service Plan. Bear in mind that if you're using IP addresses/A records in your DNS, you'd need both web apps to have different IP addresses for the DNS to be able to differentiate between your web apps.
Try assigning the domain to Azure Traffic Manager and have the traffic manager forward the request to the second site. Azure Traffic Manager and Web Apps are two different systems so you might be able to assign the same domain name to a web app and a traffic manager.
Once the DNS cache has expired remove the domain from the old Azure web app and add it to the new one, then finally delete the Traffic Manager account.
Option 2
Set the TTL to something very small, say 5 seconds (I believe your hostname provider should let you set that up), wait for the new TTL to propagate through all the caches. Then switch the custom domain from one app to another, and set the TTL back to it's original value.
This will result in just a few seconds of downtime for any customers, but if you do it at a low-traffic time the effect shouldn't be too bad.
I have a app which is a website builder. Lets say the app is on a azure webrole and its domain is called www.myapp.com.
I want to offer a service where users can use their custom domain with my app. So User 1 has a domain called ww.user1.com, user2 has www.user2.com etc. Whenever someone types www.user1.com, I want them to be able to see come to my my app ie www.myapp.com, with the browser still showing www.user1.com. You can assume I have complete access to the DNS and nameservers of these custom domains. I just need to understand how to configure this in azure.
Not really, as it was on SSL binding of multiple custom domains on a single cloud. I was trying to figure out how to have one app on a cloud service where content changes as per custom domain end user has used to navigate to the website. Turns out its easy, all that is required is cname config and listening to host_header on server side aspx page_init –