I have this section in my web.config:

    <modules runAllManagedModulesForAllRequests="true" />
            <anonymousAuthentication enabled="true" />
            <windowsAuthentication enabled="true" />

IIS7 crashes and complains about the autientication section:

Module AnonymousAuthenticationModule
Notification AuthenticateRequest
Handler StaticFile
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" />

(alternatively, 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" />

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.

  • From memory, there's normally a section in the 500.19 that tells you which file at which location is at issue, at the bottom (I think)
    – TristanK
    Commented Feb 15, 2012 at 21:12
  • 1
    This has been answered very well over on SO
    – crthompson
    Commented Sep 10, 2015 at 16:07

6 Answers 6


Worked out these steps which fix the issue for me:

  1. Open IIS Manager
  2. Click the server name in the tree on the left
  3. Right hand pane, Management section, double click Configuration Editor
  4. At the top, choose the section system.webServer/security/authentication/anonymousAuthentication
  5. Right hand pane, click Unlock Section
  6. At the top, choose the section system.webServer/security/authentication/windowsAuthentication
  7. Right hand pane, click Unlock Section
  • 1
    Does this have a PowerShell equivalent? I would like to be able to script this. Commented Jan 4, 2018 at 10:52
  • If you find one, feel free to post it :)
    – tomfanning
    Commented Jan 4, 2018 at 11:15
  • I will, I was hoping someone else already knew how. Commented Jan 4, 2018 at 11:26
  • 6
    @PeteStensønes It has! >%windir%\system32\inetsrv\appcmd.exe unlock config -section:system.webServer/security/authentication/windowsAuthentication
    – joacar
    Commented May 7, 2019 at 8:59

This solved my error on Windows Server 2012, IIS 8.5. Should work for other versions too.

  1. Go to Server Manager, click add Roles and Features
  2. In the roles section choose: Web Server
  3. Under Security sub-section choose everything (I excluded digest, IP restrictions and URL authorization as we don't use them)
  4. Under Application Development choose .NET Extensibility 4.5 and ASP>NET 4.5, both ISAPI entries
  5. In the Features section choose: NET 3.5, .NET 4.5, ASP.NET 4.5
  6. In the Web server section choose: Web Server (all), Management Tools (IIS Management Console and Management Service), Windows

Configuration locking can happen at:

  1. Applicationhost.config (config string: MACHINE/WEBROOT/APPHOST)

  2. a Site Web.config file (MACHINE/WEBROOT/APPHOST/Web Site Name)

  3. 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.

Adding -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).

Just change 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" />
  • Solved my problem
    – zish
    Commented Feb 2, 2022 at 14:30

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:

  • Click "Start button"
  • in the search box, enter "Turn windows features on or off"
  • in the features window, Click: "Internet Information Services"
  • Click: "World Wide Web Services"
  • Click: "Application Development Features"
  • Check(enable) the features. I checked all but CGI.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .