If you are a semi-managed dedicated customer, please review the changes we recommend below. We recommend that all customers implement these changes. Please note these changes may cause disruptions to some of your ASP.NET based domains. After making these changes, we recommend checking your ASP.NET sites to ensure that they are working properly.
Step 1: Application Pool Settings:
The first and most important thing is that all of your application pools in IIS are running under the "Network Service" account. If any application pools are running under the local system account, then it's possible for users to execute .exes they upload under the local system context and gain full access to your server.
The first and most important thing is that all of your application pools in IIS are running under the "Network Service" account. If any application pools are running under the local system account, then it's possible for users to execute .exes they upload under the local system context and gain full access to your server.
To make this change, please follow these steps:
- Login to your server using Terminal Services
- Open up the Internet Services Manager
- Expand the "Application Pools" folder. Right click on each application pool and go to Properties.
- Click on the Identity tab. Change the drop down to "Network Service"
- Login to your server using Terminal Services
- Open up the Internet Services Manager
- Expand the "Application Pools" folder. Right click on each application pool and go to Properties.
- Click on the Identity tab. Change the drop down to "Network Service"
- Click OK
NOTE: Do not make any changes to the MSSharePointAppPool
Step 2: MACHINE.CONFIG Changes :
The second item that's crucial is making some configuration changes to your .NET configuration files that force impersonation - that is, they force ASP.NET pages to be executed under the web sites user account, not the network service account. In a shared hosting environment, this will ensure that users cannot use ASP.NET to access other domain's content in any way. Please follow these steps to make this change:
The second item that's crucial is making some configuration changes to your .NET configuration files that force impersonation - that is, they force ASP.NET pages to be executed under the web sites user account, not the network service account. In a shared hosting environment, this will ensure that users cannot use ASP.NET to access other domain's content in any way. Please follow these steps to make this change:
- Open C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\Machine.Config using Notepad
- Search for "" or ""
- Replace that entire line with:
- Search for "" or ""
- Replace that entire line with:
- Save and close the file.
Step 3: NETWORK SERVICE permissions :
The third change that's necessary is ensuring that 'Network Service' account has the proper permissions on your c:\domains folder. This user account needs to have READ / EXECUTE permissions on the c:\domains folder for ASP.NET to work correctly. The simplest way to effect this change is as follows:
The third change that's necessary is ensuring that 'Network Service' account has the proper permissions on your c:\domains folder. This user account needs to have READ / EXECUTE permissions on the c:\domains folder for ASP.NET to work correctly. The simplest way to effect this change is as follows:
- Create a batch file with the following contents:
cacls c:\domains /E /C /G "Network Service":R FOR /D %%c IN (C:\domains\*) DO cacls %%c /T /E /C /G "Network Service":R
- Now, execute the batch file.
NOTE: If you have a large number of sites/files on your server, running this script may take a long period of time. Ensure that you keep your terminal services session active. If your session times out, you will have to re-run the batch file from the beginning.
Known Issues:
- Any sites running DotNetNuke will require some manual permission changes. You will need to grant the NETWORK SERVICE account Modify permissions on the domain's wwwroot folder.
Support-Agent
Comments