We've been asked to lock down our Umbraco-based site so that no one can access the Umbraco control panel. I've seen many of the recommendations to use the "IP Address and Domain Restrictions" feature of IIS but doing so results in a 500.22 error. I have the validateIntegratedModeConfiguration="false" and that did not resolve the issue. The error remains even after disabling the restrictions and the only fix was to manually edit the applicationHost.config file.
My question is, how are others locking that subfolder down? Are they making the "IP Address and Domain Restrictions" work or is there another method? I've seen the URL Rewrite but, correct me if I'm wrong, that doesn't seem to fully address the issue since the server is still technically responding to the outside world. Thoughts? Advice? Thanks in advance!
The IP Address Domain Restrictions is definitely the way to go but I was running into errors getting it working (500.22). What I found was that although I had the validateIntegratedModeConfiguration set in the web.config, it was getting overridden somehow and I needed to add it to the location section of the applicationHost.config:
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.
Locking down /umbraco/ by source IP
Greetings!
We've been asked to lock down our Umbraco-based site so that no one can access the Umbraco control panel. I've seen many of the recommendations to use the "IP Address and Domain Restrictions" feature of IIS but doing so results in a 500.22 error. I have the validateIntegratedModeConfiguration="false" and that did not resolve the issue. The error remains even after disabling the restrictions and the only fix was to manually edit the applicationHost.config file.
My question is, how are others locking that subfolder down? Are they making the "IP Address and Domain Restrictions" work or is there another method? I've seen the URL Rewrite but, correct me if I'm wrong, that doesn't seem to fully address the issue since the server is still technically responding to the outside world. Thoughts? Advice? Thanks in advance!
Hi Ryan,
I have never tried it myself, but I have seen many times that is the solution with IP Address and Domain Restrictions has been recommended
As here where Ismail Mayat point that solution with IP Address and Domain Restriction http://our.umbraco.org/forum/getting-started/installing-umbraco/13272-How-to-Lock-Down-Umbraco-Backend
http://technet.microsoft.com/en-us/library/cc731598%28v=ws.10%29.aspx
So I think that the IP Address and Domain Restriction solution would be a good solution.
Hope this is useful.
/Dennis
Thanks Dennis,
The IP Address Domain Restrictions is definitely the way to go but I was running into errors getting it working (500.22). What I found was that although I had the validateIntegratedModeConfiguration set in the web.config, it was getting overridden somehow and I needed to add it to the location section of the applicationHost.config:
<location path="REMOVED/umbraco"> <system.webServer> <security> <ipSecurity allowUnlisted="false"> <add ipAddress="127.0.0.1" allowed="true" /> </ipSecurity> </security> <validation validateIntegratedModeConfiguration="false" /> </system.webServer> </location>Hope that also helps the other users who have posted this issue.
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.Hope this helps someone else.
is working on a reply...