I know I've seen discussions here, but cannot find them. What is the recommended method to lock down the Umbraco backend so that it is only visible and accessible from our Intranet? We don't even want outside users to get to the login screen if they type website.org/Umbraco/.
I was thinking about writing a blog post to answer this and outline most available solutions and their pros/cons... but just a quick response would be that you can lock down the Umbraco login page in IIS by restricting access to a certain set of IP addresses (what I typically use)...
I've run into problems when I restrict access to the whole /umbraco directory. Things like courier need access to the /umbraco/Plugins directory. There are also some things in /umbraco/webservices that may or may not need to be available to the public. The biggest problem was that access to /umbraco/api was restricted, so none of my WebApiControllers worked.
I wasn't able to resolve the problem with the <location> in the web.config. I kept getting 500 errors. Instead, I created an /umbraco/api directory on the file system. I went into IIS and and used the IP Address and Domain Restrictions feature to do the following:
Remove all the listed IPs from the Api directory
On the right hand sidebar, I clicked "Edit Feature Settings" and set "Access for unspecified clients" to Allow
That should resolve the problem for most people. We found that on IIS 7.5, there is some strange caching going on. IIS 7.5 will not immediately recognize the new Api directory or any of the settings you apply to it. I had to add a web.config to the Api directory. That caused IIS to realize that Api actually existed and that it should pay attention to it. After that, I was able to make sure the IP Address and Domain Restriction settings were correct. I was even able to delete the entire Api folder, and IIS still holds on to the settings for the directory that no longer exists. I don't know if the cache will be purged later, so I left the Api directory, but deleted the web.config from it.
How to Lock Down Umbraco Backend
I know I've seen discussions here, but cannot find them. What is the recommended method to lock down the Umbraco backend so that it is only visible and accessible from our Intranet? We don't even want outside users to get to the login screen if they type website.org/Umbraco/.
Connie,
In IIS you could restrict the umbraco folder to an ip range that corresponds to your organisation.
Regards
Ismail
I was thinking about writing a blog post to answer this and outline most available solutions and their pros/cons... but just a quick response would be that you can lock down the Umbraco login page in IIS by restricting access to a certain set of IP addresses (what I typically use)...
In IIS 6.0... http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/128d26dd-decb-42f9-8efb-30724d1a2f29.mspx?mfr=true
In IIS 7.0 (I haven't tested this tutorial, but I think it's the right one)... http://technet.microsoft.com/en-us/library/cc770819(WS.10).aspx
Hope this helps.
I've run into problems when I restrict access to the whole
/umbracodirectory. Things like courier need access to the/umbraco/Pluginsdirectory. There are also some things in/umbraco/webservicesthat may or may not need to be available to the public. The biggest problem was that access to/umbraco/apiwas restricted, so none of my WebApiControllers worked.I wasn't able to resolve the problem with the
<location>in the web.config. I kept getting 500 errors. Instead, I created an/umbraco/apidirectory on the file system. I went into IIS and and used the IP Address and Domain Restrictions feature to do the following:ApidirectoryThat should resolve the problem for most people. We found that on IIS 7.5, there is some strange caching going on. IIS 7.5 will not immediately recognize the new
Apidirectory or any of the settings you apply to it. I had to add aweb.configto theApidirectory. That caused IIS to realize thatApiactually existed and that it should pay attention to it. After that, I was able to make sure the IP Address and Domain Restriction settings were correct. I was even able to delete the entireApifolder, and IIS still holds on to the settings for the directory that no longer exists. I don't know if the cache will be purged later, so I left theApidirectory, but deleted theweb.configfrom it.is working on a reply...