One of our administration applications uses Windows authentication so we can manage some Windows services. In the past we’ve simply changed the authentication method in IIS Manager and moved on but when as we upgraded our development workstations to Windows 7 and IIS 7.5 we started seeing the error:
HTTP Error 500.19 – Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.
The Detailed Error Information section gave a bit more information:
This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault=”Deny”), or set explicitly by a location tag with overrideMode=”Deny” or the legacy allowOverride=”false”.
The Config Source section was kind enough to narrow down the problem to the <authentication> element. Since we need Windows authentication for service administration simply switching back to anonymous authentication wasn’t an option. We really needed to unlock that section.
The page linked from the Links and More Information section has a ton of information about each of the status codes along with links to other knowledge base articles for more details about error conditions. According to the knowledge base HTTP Error 500.19 has nine possible causes. This particular issue is listed as issue 9 and is described in detail on IIS.net.
In short, IIS 7.x locking is controlled primarily by the configuration found in the applicationHost.config file located in the %windir%\system32\inetsrv\config\ folder. Unlocking the section is a matter of moving the security/authentication section to a new location element and setting the overrideMode attribute to “Allow” so it is unlocked for all applications. Alternatively, the security/authentication information can be duplicated into a new location element with a path attribute identifying a specific application to unlock it for just that application, leaving it locked for all others.
I opted for the later option and simply added a new location element. Since I was not only enabling Windows authentication but also disabling anonymous authentication I actually had to unlock both. When I was done my new location element looked like this:
<configuration> <!-- Existing Configuration Excluded --> <location path="Default Web Site\MyApplication" overrideMode="Allow"> <system.webServer> <security> <authentication> <anonymousAuthentication enabled="false" /> <windowsAuthentication enabled="true" /> </authentication> </security> </system.webServer> </location> </configuration>
With that in place the error disappeared and I was able to use the application as expected. Unfortunately I did have some trouble actually editing applicationHost.config since I’m running Windows 7 on a 64-bit system and I needed to edit the file with notepad rather than my trusty Notepad++.
A colleague pointed me to the “Feature Delegation” icon at the root (computer) level of IIS Manager (Thanks, Ryan). Clicking into the Feature Delegation page shows a listing of features and their current override setting. With few exceptions each of the features can be changed to Read/Write, Read Only, or Not Delegated. There’s also Reset to Inherited option to remove any customization.
Note: Each feature’s context menu includes a “Custom Site Delegation” option that allows the settings to be changed per site (i.e.: Default Web Site) but doesn’t go as far as individual applications.
Unlocking the sections via the Feature Delegation page would certainly have been easier than editing applicationHost.config directly and should be suitable for most development environments. I think I’d probably stick to editing the configuration file for a production server though just for that added layer of protection.
Thanks for the summary. It was just what I needed. And, it works well explaining how to edit it first with the text editor, and then with the IIS Manager. I get to see a little more clearly what is happening under the covers.
Glad to be of service. Thanks for stopping by.
You could also do this by selecting your website under default website, right click, you select “Authentication” and can disable/enable Anonymous and Windows Authentication here.
Would it help to be able to do this on the page level: select your website under default website, right click,
switch to content view, select the file, right click, switch to features view. Now the file should be displayed in left nav anad still be selected. From here, you select “Authentication” and can disable/enable Anonymous and Windows Authentication here.
Thanks for the input. If I remember correctly though the problem wasn’t enabling or disabling the authentication but that the authentication section was locked by lower level configuration. I’d already toggled the appropriate authentication types but IIS complained that the sections were locked and therefore the configuration with the appropriate authentications couldn’t be used.
“Feature Delegation” screen was the ticket! Thanks! Someone had installed SharePoint on my box, wonder if it changed those machine settings. . . . .
I’m glad you found what you needed. For better for worse I’ve never had to deal with a fresh SharePoint install but I’ve heard plenty of horror stories about changed settings. I can’t say I’d be completely surprised if that was the culprit.
You can also execute the following command from the %windir%\system32\inetsrv directory
appcmd unlock config /section:anonymousAuthentication
appcmd unlock config /section:windowsAuthentication
Thanks for the note. That will make a nice script for anyone that needs to do this frequently.
Comments are closed.