Any ideas on how to accomplish this or it is not possible.
1.) Own a domain, mycompany.com
2.) mycompany.com is registered at GoDaddy
3.) mycompany.com nameservers are pointed to "My Company's" on-premise infrastructure. The nameservers must remain this way. The on-premise solution uses Bind for DNS services.
4.) mycompany.com has a CNAME, hosting.mycompany.com
5.) the zone record at the on-premise DNS points hosting.mycompany.com to an IIS7 VPS at GoDaddy. Let's call this box VPS7.
6.) VPS7 has a dummy IIS ASP.NET site with basically just a web.config with code in it (destination redacted):
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpRedirect enabled="true" destination="**redacted**" exactDestination="true" httpResponseStatus="Permanent" />
</system.webServer>
</configuration>
The above configuration allows a user to surf to hosting.mycompany.com and gets redirected to a GoDaddy reseller site. BUT (obviously) the user's browser's address bar then shows the GoDaddy (secureserver.net) domain instead of hosting.mycompany.com.
Is there a way to retain the hosting.mycompany.com in the address bar instead of secureserver.net without too much trouble?
What I've tried / thought about already:
a.) can we simply use the GoDaddy nameservers (instead of the on-premise mycompany nameserver), and then use GoDaddy's "Forward w/ Masking" feature? ...no, the nameservers have to remain as they are.
b.) could I just remove the web.config redirect, create a single page, and then just iframe the entire reseller site? ...haven't tried this, but it seems like just a horrible solution.
Thoughts/Ideas?
TIA!
~Ted
Related
I have deployed a node js web app on azure and I want to restrict access to it by ip address. I have done a similar thing easily before in AWS with security groups. However, I am at present on the free dev platform and when I got to the ip restrictions setting tab in the Azure portal gui it says I need to upscale the app because ip restriction is not available on the current platform. What I'm build needs very minimal resources. It is a one page internal static newsletter. What is the minimal resource on azure I need to use to get the ip restriction or is there another route I can use?
The minimal resource you need to configure IP restrictions within the Portal is B1:
Read here how to configure it:
Azure App Service Static IP Restrictions
Note: You can also enable IP Restrictions on the free tier by adding a web.config using the IP Security setting. Working sample:
<configuration>
<system.webServer>
<security>
<ipSecurity allowUnlisted="false">
<clear/>
<add ipAddress="83.116.19.53" allowed="true"/>
</ipSecurity>
</security>
</system.webServer>
</configuration>
Now all you have to do is to put the web.config to your wwwroot directory. You can either include the web.config in your deployment or you manually add it using the Kudu engine.
Just replace <YOURSITE> with your actual site and follow the link:
https://<YOURSITE>.scm.azurewebsites.net/DebugConsole/?shell=powershell
If you now browse the app using an unlisted IP you will get the following error:
You do not have permission to view this directory or page.
I wanted to restrict access from internet to my app service environment, such that only my front end app service can only access it. Is there a possible way to do it?.
As shown in the above picture I wanted to associate an NSG to tier 2 such that only tier 1 can access tier 2. Nobody else can access it. Is there a solution to this problem?
Developers can use IP and Domain Restrictions to control the set of IP addresses, and address ranges, that are either allowed or denied access to their websites. With Windows Azure Web Sites developers can enable/disable the feature, as well as customize its behavior, using web.config files located in their website
<system.webServer>
<security>
<ipSecurity>
<add ipAddress="x.x.x.x" allowed="false" />
</ipSecurity>
</security>
</system.webServer>
https://azure.microsoft.com/en-us/blog/confirming-dynamic-ip-address-restrictions-in-windows-azure-web-sites/
If a request is made to a website from an address outside of the allowed IP address range, then an HTTP 404 not found error is returned as defined in the denyAction attribute.
https://learn.microsoft.com/en-us/azure/app-service/environment/network-info
https://learn.microsoft.com/en-us/azure/app-service/environment/forced-tunnel-support
When i host an application on IIS and set the windows authentication, after doing all configuration it will still prompt for credentials.
I followed the below steps to allow automatic login with Internet explorer :
Open Internet explorer go to Settings > Select the "Security" tab
Select "Local Intranet" and select the "Custom Level" button
Scroll down to "User Authentication" > "Logon"
Check the box next to "Enable logon in intranet zone only"
Restart IE.
When I open my application it will still prompt for login.
I have added web config settings to allow Windows authentication as below :
<system.web>
<authentication mode="Windows"/>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
</system.web>
I m hosted my website on http://192.192.8.52:8089/ Check if required.
Please let me know where I am going wrong.
Thanks.
Think about how you are navigating to your intranet site. You're navigating by IP address. If you do a tracert 192.192.8.52 in command prompt, you'll see that you are ignoring your DNS and navigating directly to the computer. You need to create a Forward Lookup Zone in your DNS Manager so the user is passed through the DNS.
In your DNS Manager, under Forward Lookup Zones -> YourDomain, create a New Host (A)... which points to 192.192.8.52. Then use that HostName you just created to navigate to your server http://HostNameYouMade. You can't be automatically authenticated through DNS unless you touch the DNS to get to the page. If you're going by IP, then you bypass the DNS and go straight to the computer (server).
After you're done, you can see with tracert HostNameYouMade that it will touch the DNS and resolve its IP. Your site should now know that a DNS user is connecting to a DNS host and is authenticated or not.
A client of ours has the domain client.com
Our application is at superapp.mycompany.com
We want the client to be able to access our application via their own subdomain, like: superapp.client.com.
Normally we'd just tell the client to add a cname for superapp and point it to superapp.mycompany.com. Then on our server (IIS) we'd bind their domain to our app and everything would work as intended.
However, we can't replicate this functionality when our mycompany.com domain is managed via cloudflare.
When we navigate to superapp.client.com we get the following error page:
Error 1001
What happened?
You've requested a page on a website (superapp.client.com) that is on the Cloudflare network. Cloudflare is currently unable to resolve your requested domain (superapp.client.com).
Is there any way that Cloudflare can be used in this fashion?, this seems like a pretty standard set up for a multi tenant application that supports custom domains.
We don't need all the protection that Cloudfront offers for these client domains, but we want to use the Cloudfront nameservers for out application (mainly for fast switching of DNS records in the event we migrate servers, etc).
Any help is appreciated.
I hope it's not too late. But just found a way to do so.
You just need to add your client's domain (Add site in Cloudflare) to your account.
You don't need to change client domain's NS. So in your Cloudflare panel this domain will showing as "Pending Nameserver Update".
Next step is add the CName record to this domain.
Although the NS of client domain is not changed to CF, but CF has a lookup record as CName for it.
Hope it helps.
Just in case someone arrived here with same issue as me. Here is the answer. For short, no that won't work.
Since Cloudflare is a reverse proxy for the domain that is on Cloudflare, the CNAME redirect for the domain (not on Cloudflare) wouldn't know where to send the traffic to.
Ref: https://support.cloudflare.com/hc/en-us/articles/360017421192-Cloudflare-DNS-FAQ#CloudflareDNSFAQ-CanICNAMEadomainnotonCloudflaretoadomainthatisonCloudflare
If you don't need the CDN benefits, you can still use Cloudflare nameservers to manage your DNS zone and keep your current configuration. Just make sure the CDN is deactivated for the target subdomain in your zone (superapp.mycompany.com in your case).
You can tell if the CDN is activated or deactivated for a subdomain by looking at the cloud icon on the right of each DNS entry: if the cloud is orange the CDN is active, if it is gray, it isn't.
Cloudflare also supports external CNAME resolution in their CDN infrastructure, but it's only available for its Enterprise customers:
https://support.cloudflare.com/hc/en-us/articles/217371987-Managed-CNAME
Lest say I have a web application called example.com
everything is ok with it and both www.example.com and example.com redirect to the correct A record "#" defined on the GoDaddy Zone file.
The thing is, that my back office web application is on a different Azure server than the main site (site is on example.com and the back office needs to be on office.example.com).
for that i have created another server on Azure.
example.com is on example.azurewebsites.net
office.example.com is on example-office.azurewebsites.net
(azure management site shows that both server have the same ip)
(Btw, is that what I should have done?)
What I tried was:
1. add "office" A Record on Goddady that redirects the same ip (in addition to #) - didnt work.
2. add "office" CNAME that redirects to example-office.azurewebsites.net - didnt work
In both cases i added the awverify and the awverify.www as followed:
awverify.office is awverify.example-office.azurewebsites.com
awverify.www.office is awverify.www.example-office.azurewebsites.com
Azure Manage Domains doesnt recognize office.example.com
What should I do at GoDaddy's to make it work?
Thanks
you can find solution (godaddy screenshots included) here
https://azure.microsoft.com/en-us/documentation/articles/web-sites-godaddy-custom-domain-name/
CNAME or A records pointing to IP or domain is right solution
adding awverify is needed only if using A record
better solution is to use CNAME - after stopping web service and starting again, you will receive probably different IP addres in azure (or you can use traffic manager)