I have this section in my web.config:
<system.webServer> <modules runAllManagedModulesForAllRequests="true" /> <security> <authentication> <anonymousAuthentication enabled="true" /> <windowsAuthentication enabled="true" /> </authentication> </security> </system.webServer>
IIS7 crashes and complains about the autientication section:
Error Code 0x80070021
Config Error 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".
Config Source 69: <authentication> 70: <anonymousAuthentication enabled="true" />
So the usual way to solve this is to go into
%windir%\system32\inetsrv\config\applicationHost.config and unlock the section:
<sectionGroup name="system.webServer"> <sectionGroup name="security"> <section name="access" overrideModeDefault="Deny" /> <section name="applicationDependencies" overrideModeDefault="Deny" /> <sectionGroup name="authentication"> <section name="anonymousAuthentication" overrideModeDefault="Allow" /> <section name="basicAuthentication" overrideModeDefault="Allow" /> <section name="clientCertificateMappingAuthentication" overrideModeDefault="Allow" /> <section name="digestAuthentication" overrideModeDefault="Allow" /> <section name="iisClientCertificateMappingAuthentication" overrideModeDefault="Allow" /> <section name="windowsAuthentication" overrideModeDefault="Allow" /> </sectionGroup>
appcmd unlock config).
The weird thing: I've done that and it still complains.
I looked for Locations (MVC is the name of my website that's the root of all sites I'm using):
<location path="MVC" overrideMode="Allow"> <system.webServer overrideMode="Allow"> <security overrideMode="Allow"> <authentication overrideMode="Allow"> <windowsAuthentication enabled="true" /> <anonymousAuthentication enabled="true" /> </authentication> </security> </system.webServer> </location>
Still it blows up. I'm puzzled as to why this happens. I cannot remove it from the web.config, I want to find the root problem.
Is there a way to get specific information from IIS which rule is eventually denying me?
Edit: I was able to fix this using the IIS7 management console by going to the very root (my machine) and clicking "Edit Configuration" and unlocking the section there. Still I'd like to know if there is a better way since I can't find the file it actually modifies.
Worked out these steps which fix the issue for me:
This solved my error on Windows Server 2012, IIS 8.5. Should work for other versions too.
.NET Extensibility 4.5and
ASP>NET 4.5, both ISAPI entries
Web Server (all),
Management Tools (IIS Management Console and Management Service),
Configuration locking can happen at:
Applicationhost.config (config string: MACHINE/WEBROOT/APPHOST)
a Site Web.config file (MACHINE/WEBROOT/APPHOST/Web Site Name)
Any App web.config file that (MACHINE/WEBROOT/APPHOST/Site Name/App Name)
Locking a section (section: IIS configuration section, eg
<asp>) lets you deny the ability to configure those settings to anyone at a lower level in the hierarchy than you.
Using the GUI's Feature Delegation thingo isn't wrong, and does a very similar thing to what AppCMD does, under the covers - sets OverrideMode for a given section in a
<location> tag at whatever level of config you're focused on.
APPCMD can be used to unlock files, but pay attention to where it says it's doing it - it's not as smart as the GUI about this.
-commit:apphost to the end of your
APPCMD UNLOCK command targets Applicationhost.config, which is the key file for IIS operation (replaces the metabase from earlier versions; stores all centralized settings but allows overrides (if you do) in web.config files).
Without -commit:apphost, APPCMD will target the closest logical spot for a web.config file - whether at the site or app level, and indicate it's changed the setting using a configuration string like the above set. (Aside: you can still target just the settings in sub web sites, but commit to apphost - it uses location tags to accomplish that)
So if it said (memory paraphrase) "Changes committed to MACHINE/WEBROOT/APPHOST" , that'd mean the top level of the IIS hierarchy.
If it says "committed to MACHINE/WEBROOT/APPHOST/Dodgy Web Site", that'd mean it looked up the physical path behind Dodgy Web Site, and wrote a web.config file (or updated it) in that location.
If you are using IISExpress and Visual Studio 2015, the
applicationHost.config is stored in
$(solutionDir).vs\config\applicationhost.config (thanks to Nime Cloud's answer).
overrideModeDefault="Allow" wherever appropriate.
<sectionGroup name="security"> <section name="access" overrideModeDefault="Deny" /> <section name="applicationDependencies" overrideModeDefault="Deny" /> <sectionGroup name="authentication"> <section name="anonymousAuthentication" overrideModeDefault="Allow" /> etc...
Try in your Applicaiton Pool, Disable 32-bit applications support IIS Manager -> Application Pools -> select [Your AppPool] -> Advanced Settings -> Enable 32-Bit Applications - change it to 'False'
Take a look at IIS - this configuration section cannot be used at this path (configuration locking?)
The accepted answer worked perfectly for me on Windows 10, it instructs to do the following:
User contributions licensed under CC BY-SA 3.0