Symptoms

You can load the page just fine, but after going through the pages quickly or by opening several tabs at once, you see a 403 error:

403 - Forbidden: Access is denied.

You do not have permission to view this directory or page using the credentials that you supplied.

This is a bit misleading since you might right away think that the you do not have permission to access the web page or the folder. But you know you’re authenticated because you could see the page a few seconds ago and the problem is intermittent. So why do you get 403 Forbidden: Access is denied?

What to Check

The first thing you want to check is the IIS log and look for the specific error code (403) with the timestamp when you see the 403 error. You might see something similar to the following:

2022-02-02 22:33:58 10.20.128.70 POST /ResultPage.asp - 80 - 192.168.1.25 Mozilla/4.0... https://www.itnota.com/CheckPage.asp 403 501 0 0

Open up the IIS log in a text editor and search for ” 403″ (without quotes). A leading whitespace is added to narrow down the search. You can also use regular expression to be precise but for this exercise, I think it’s an overkill.

One key thing we need to pay attention to is to check the whole error code by looking the one next to the 403 → 501. So to be exact, the error code is actually 403.501.

If you check the definition of this error here, you’ll soon find out this error has nothing to do with permission in the traditional sense of how we understand it:

403.501 - Forbidden: Too many requests from the same client IP; Dynamic IP Restriction Concurrent request rate limit reached.

This is the real issue and it’s easier to fix once we’ve figured out that we need to look at the Dynamic IP Restriction.

So now we have three options:

1. Disable Dynamic IP Restriction.
2. Increase the Maximum number of concurrent requests.
3. If your connection comes from the same IP address (i.e. F5), then you can create a whitelist based on its IP address.
4. Maybe four, as you can combine option 2 and 3 if needed.

Whether you choose option 1, 2, or 3, all the settings are in the same location in IIS.

Steps

1. Launch IIS Manager and on the left pane window, select the site that you want to modify.

2. In the middle window, double-click on the IP Address and Domain Restrictions.

   

3. If you want to do either option 1 or 2, click on Edit Dynamic Restriction Settings… on the right window pane.

   

4. Option 1: To disable the Dynamic IP Restrction, uncheck all the checkboxes and click OK.

5. Option 2: Modify the number in the Maximum number of concurrent requests: and still leave the Deny IP Address based on the number of concurrent requests checked. Then click OK.

6. Option 3: You can either leave the Dynamic Restriction Settings alone, or you may combine that setting with the whitelist as well.

7. In IP Address and Domain Restrictions window, click on Add Allow Entry… on the right window pane.

   

   Note: All your modification is saved in applicationHost.config file in the server as indicated on the bottom of the IP Address and Domain Restrictions window.

8. Add the IP Address you want to allow entry that’s not limited by the Dynamic Restriction Settings in the Specific IP address: textbox. Or you can enter a range of IP addresses under the IP address range: textbox. Then click OK.

   

Additional Note

As mentioned earlier, all the settings we did above is saved applicationHost.config file. The file can be found in the following directory:

%windir%\system32\inetsrv\config

And all the steps above can be skipped if you edit the file using a text editor. I personally like to use GUI to prevent typos so just be aware of the risk of editing this file by hand.

  <location path="##Your-website-name-in-IIS##">
    <system.webServer>
      <asp appAllowClientDebug="true" appAllowDebugging="true" />
      <security>
        <ipSecurity>
          <add ipAddress="192.168.1.25" allowed="true" />
        </ipSecurity>
        <dynamicIpSecurity>
          <denyByConcurrentRequests maxConcurrentRequests="1" />
          <denyByRequestRate maxRequests="20" />
        </dynamicIpSecurity>
      </security>
    </system.webServer>
  </location>

That’s it.

Once you saved all the settings, the new change should take effect immediately.

Further Reading

The HTTP status code in IIS 7.0 and later versions
IIS 8.0 Dynamic IP Address Restrictions
Using Dynamic IP Restrictions
IIS Dynamic IP Restrictions whitelist

Typically, web application is run using ApplicationPoolIdentity on IIS. However, for various reasons, it’s very common to find large corporations use service accounts to run the application pools.

Sometimes the challenge comes when you need to move the website to a different server and you’re not given the proper credential to set it up on the new environment. What’s worse, it’s also not uncommon to hear that sometimes not one soul in the company knows the password.

At that point, your options are usually to either have the password reset (a big No-No for a production application), or have a new service account created (also another headache if the service account is tied to other applications or batch jobs for logical grouping).

But there’s a simple trick that’s quite handy to get password from iis application pool by using AppCmd that is commonly used to migrate IIS websites.

Steps

1. We know that the AppCmd can be used to export the Application Pool information to an XML file. And we can also export only a single AppPool. So in this case, just as an example, we want to export AppPool ITNOTA by typing the following in Command Prompt:

   C:\> %windir%\System32\inetsrv\appcmd list apppool "ITNOTA" /config /xml > C:\Temp\ItnotaAppPool.xml
   

   

2. Once that was done, let’s open up ItnotaAppPool.xml file from C:\Temp folder. You would see something similar to the following:

   <?xml version="1.0" encoding="UTF-8"?>
   <appcmd>
     <APPPOOL APPPOOL.NAME="ITNOTA" PipelineMode="Integrated" RuntimeVersion="4.0" state="Started">
       <add name="ITNOTA" autoStart="true" managedRuntimeVersion="v4.0">
         <processModel identityType="SpecificUser"
                       userName="ITNOTA\Admin_Service_Account"
                       password="###MyAccountPassword###"
                       idleTimeoutAction="Suspend" />
         <recycling>
           <periodicRestart>
             <schedule>
             </schedule>
           </periodicRestart>
         </recycling>
         <failure />
         <cpu />
         <environmentVariables>
         </environmentVariables>
       </add>
     </APPPOOL>
   </appcmd>
   

   

If you look at line 7 (highlighted), the password is there in clear text.

Note: This XML is modified and compacted just to demonstrate where you can find the password ONLY if you use custom identity. If you use ApplicationPoolIdentity, there’s no password associated with it in the XML file.

In theory, you don’t need to look at the password to make the website run. Because importing the XML will transfer all the information exactly the same way as the current setting. So other than updating the IP address, the identity most of the time doesn’t need any modifications. But this trick is always useful, when you also need to retrieve a “lost” password for a service account that’s been there for years.

Further Reading

How to Migrate IIS Websites to a Different Server
Getting Started with AppCmd.exe
Exporting & Importing App Pools and Websites configuration between multiple IIS instances