With regard to your second question about how to ensure that configuration changes are persisted to a site's web.config
rather than applicationHost.config
, this can be controlled via Feature Delegation.
If you navigate to the machine node of IIS Manager you will see an icon named "Feature Delegation":
Launch this IIS "applet" and you will be presented with a list of features that can have their configuration delegated to web.config
.
Settings that are marked Read/Write will usually have their settings written to the web.config
file. Settings that are marked Read Only will usually have their settings written to applicationHost.config
and cannot be overridden in the web.config
file.
As it so happens the <windowsAuthentication>
configuration can be delegated to the web.config
file.
Minor Gotcha:
Not all of the applets surface the full range of settings you can configure. A good example of this as it so happens is the <windowsAuthentication>
useAppPoolCredentials
attribute. It's no-where to be seen in the Authentication applet, not even under Advanced Settings.
However you can get at this value (and pretty much everything else) via the Configuration Editor. If you navigate to your web site's node in the left hand pane in IIS manager you will see this icon under Management:
If you launch the Configuration Editor you'll be presented with a dropdown list containing a tree of various settings:
If we select the /system.webServer/security/authentication/windowsAuthentication
node we are presented with the full spectrum of settings that can be changed. Here we can see the setting we're interested in (useAppPoolCredentials
):
You can choose whether to configure the values for the website in web.config
or in applicationHost.config
from the From: drop down list next to the config section tree drop down:
If a section has not been delegated as Read/Write in the web.config
then you'll see the following:
We get an alert saying that this particular feature is locked, all of the settings are greyed out and disabled and there's a padlock indicating that child settings of this feature are also locked out.
Finally, not all settings can be delegated, for example site bindings, application pool, virtual directories.
So it looks like posting to html files is impossible in IIS without installing a backend language to interpret the html files rather than the IIS static file handler. If anyone knows differently, please let me know! (Just to make it clear, Apache does not have this problem.)
The post linked to by @JudasIscariot1651 works, however, it requires installing ASP and will break your site if you're using a backend language that isn't ASP (presumably only if posting to html pages - I wasn't able to test). You need to configure whatever language you're using to handle the html files instead of the static file handler.
If you're not using a backend language, or are using ASP, here's a copy of the ASP version (access permissions modified to example in post) - install ASP and ISAPI first:
<add name="html" path="*.html" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="None" />
If you're using PHP, you need to use the following (adjust for PHP settings) - presumably you already have PHP and CGI installed:
<add name="html" path="*.html" verb="*" modules="FastCgiModule" scriptProcessor="C:\Program Files (x86)\PHP\php-cgi.exe" resourceType="Unspecified" requireAccess="None" />
Best Answer
You can not disable individual handler mappings in the UI. The 'Edit Feature Permissions' mentioned by Mark Henderson applies to the whole feature 'Handler Mappings', so it applies to all mappings, not a single one.
There are really three groups of handlers, one that requires Execute permission such as, 'ISAPI-dll' or 'CGI-exe', the second group that requires 'Script' permissions, all the asp.net handlers are in that group. The third group of handlers only requires 'Read' permission, 'StaticFile' is an example of this. Because it does not execute a process nor does it run a script, it just reads a file from the file system.
You can check this by open 'Edit Feature Permissions' and uncheck 'Script', most of the mappings are now disabled. Uncheck 'Read' and the last few enabled ones are disabled as well.
To remove a handler from a site, open the web.config and add something like this:
This will remove the integrate ASP.NET 4 page handler, which means web forms (aspx) will no longer work.
If you look at the 'Handler Mappings' for the same site in IIS Manager, that mapping still shows up in the enabled section, even though it does no longer work for the site.