Introduction
As a web administrator; I used to deploy the web applications changes on the production server, two days ago I have stayed about 6 more hours than my normal working day, me and our developers trying to solve a problem that appears when we tried to deploy a new feature in our application that allow the online users to write articles and upload photos on a specific folder on the server.
The problem starts with this error when we tried to test the application to upload an image file.
Access to the path "d:\visitorsUpload\Vu01.jpg" is denied Exception Details: System.UnauthorizedAccessException: Access to the path "d:\visitorsUpload\Vu01.jpg " is denied.
I have made sure that all the permissions on this folder are on the right place, ASPNET Account will have read-write permissions and the iuser_machinename will have Read, the virtual directory of that folder will have read.
(The error is still showing up).
We have searched the internet as much as we can to find any solution, but we didn't find any acceptable one!
In that case there must be an account that is responsible for access local and network resources in ASP.NET. What is that account? How it works? How can we know more about it and its useful uses to Access Resources in ASP.NET?
Let's have a tour together to learn the restrictions imposed by using this account to access resources.
Use this account to access the following resource types:
About Network Service Account
The Network Service account is a local account used by the service control manager (SCM), this account is not recognized by the security subsystem, so you cannot specify its name in a call to the Lookup Account Name function. It has minimum privileges on the local computer and acts as the computer on the network. The name of the account in all locales is NT AUTHORITY\NETWORK SERVICE. This account does not have a password. If you specify the NetworkService account in a call to the Create Service function, any password information you supply is ignored.
A service that runs in the context of the NetworkService account presents the computer's credentials to remote servers. By default, the remote token contains SIDs for the Everyone and Authenticated Users groups.
By default, Microsoft Internet Information Services (IIS) 6.0 on Windows Server 2003 runs ASP.NET applications in application pools that use the NT AUTHORITY\Network Service account identity. This account is a least privileged machine account with limited permissions. An application that runs using this account has restricted access to the event log, registry, and file system. The account does have network credentials, which means you can use it to access network resources and remote databases by using Windows authentication. The network resources must be in the same domain as your Web server or in a trusted domain.
In some scenarios, using a custom domain service account is a better approach than using the Network Service account. You should use a custom domain service account if:
- You want to isolate multiple applications on a single server from one another.
- You need different access controls for each application on local and remote resources. For example, other applications cannot access your application's databases if access is restricted to your application's account.
- You want to use Windows auditing to track the activity of each application separately.
- You want to prevent any accidental or deliberate changes to the access controls or permissions associated with the general purpose Network Service account from affecting your application.
This is how to show you how you can use the Network Service account to access a variety of resources types including the event log, registry, file system, and databases.
File Access
The Network Service account has Read and Execute permissions on the IIS server root folder by default. The IIS server root folder is named Wwwroot. This means that an ASP.NET application deployed inside the root folder already has Read and Execute permissions to its application folders. However, if your ASP.NET application needs to use files or folders in other locations, you must specifically enable access.
Granting File Access to Network Service
To provide access to an ASP.NET application running as Network Service, you must grant access to the Network Service account.
To grant read, write, and modify permissions to a specific File or Folder
1. In Windows Explorer, locate and select the required file.
2. Right click the file, and then click Properties.
3. In the Properties dialog box, click the Security tab.
4. On the Security tab, examine the list of users. If the Network Service account is not listed, add it.
5. In the Properties dialog box, click the Network Service user name, and in the Permissions for NETWORK SERVICE section, select the Read, Write, and Modify permissions.
6. Click Apply, and then click OK.
Your ASP.NET application can now write to the specified file.
Note: If you need to allow the same level of access to a file resource for all accounts that run ASP.NET applications (Network Service or a custom service account), you can grant access to the IIS_WPG group instead of specifically to the Network Service account. Any account used to run ASP.NET is required to be a member of the IIS_WPG group.
Security Tip: you can restrict access to this account by using NTFS Special permission:
1. In Windows Explorer, locate and select the required folder.
2. Right click the folder, and then click Properties.
3. In the Properties dialog box, click the Security tab.
4. Click advanced button.
5. Chose the Network service account from the permission entries and click Edit button, this will open the special permission entry for your folder.
6. Deny (Delete Subfolders and Files, Delete), Uncheck (Full Control, Traverse Folder/Execute File, Read Permissions, Change Permissions, Take Ownership)
7. Click Apply, and then click OK.
Your ASP.NET application can now write to the specified Folder but with the most restrictive permission.
Event Log Access
Applications that run using the Network Service identity can write to the event log by using existing event sources, but they cannot create new event sources because of insufficient registry permissions. When you use the EventLog.Write method, if the specified event source does not exist, this method attempts to create the event source and a security exception is generated.
Note It is useful to use application specific event sources so that your applications' events can easily be differentiated from other applications' events.
To enable your ASP.NET application to write to the event log using an event source that does not already exist, you have two options:
� Create new event sources at application install time.
� Manually create new event source entry in the registry.
Create a New Event Source at Install Time
With this option, you create a specialized installer class that you run by using the install utility to create a new event source at install time when administrator privileges are available. You run the install utility using an administrator account so it has permission to create the new event source.
To create an installer class to create event sources
1. Use Visual Studio .NET 2005 to create a class library project named InstallerClass.dll. Add a reference of System.Configuration.Install to the InstallerClass project.
2. Name the class CustomEventLogInstaller, and derive it from System.Configuration.Install.Installer.
3. Set the RunInstaller attribute for the class to true.
4. Create a System.Diagnostics.EventLogInstaller instance for each new event log your application needs, and call Installers.Add to add the instance to your project installer class. The following sample class adds one new event source named customLog to the Application Event Log.
using System;
using System.Configuration.Install;
using System.Diagnostics;
using System.ComponentModel;
[RunInstaller(true)]
public class CustomEventLogInstaller: Installer
{
private EventLogInstaller customEventLogInstaller;
public CustomEventLogInstaller()
{
// Create an instance of 'EventLogInstaller'.
customEventLogInstaller = new EventLogInstaller();
// Set the 'Source' of the event log, to be created.
customEventLogInstaller.Source = "customLog";
// Set the 'Event Log' that the source is created in.
customEventLogInstaller.Log = "Application";
// Add myEventLogInstaller to 'InstallerCollection'.
Installers.Add(customEventLogInstaller);
}
public static void Main()
{
}
}
5. Compile the code for the InstallerClass.dll library.
6. Use an account with administrative privileges to run the InstallUtil.exe utility, supplying the name of the DLL on the command line. For example, open the Visual Studio command prompt and enter the following command.
InstallUtil.exe <dll path>\InstallerClass.dll
When the install utility is called with the installer class, it examines the RunInstallerAttribute. If this is true, the utility installs all the items in the Installers collection. This creates the specified event sources for your ASP.NET application.
Manually Create New Event Source Entry in the Registry
If you are unable to create an event source at installation time, and you are in deployment, the administrator should manually create a new event source entry beneath the following registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<LogName>
To manually create a new event source entry beneath this registry key
1. Start the Registry Editor tool Regedit.exe.
2. Using the Application Event log, expand the outline list in the left panel to locate the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application
3. Right-click the Application subkey, point to New, and then click Key.
4. Type a new event source name for the key name and press Enter.
The Network Service account can use the new event source for writing events.
Note You should not grant write permission to the ASP.NET process account (or any impersonated account if your application uses impersonation) on the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\ registry key. If you allow write access to this key and the account is compromised, the attacker can modify any log-related setting, including access control to the log, for any log on the system.
Health Monitoring
ASP.NET version 2.0 health monitoring writes to the Windows application event log to report significant lifetime and security events, if configured to do so. You can raise custom events in your code to write to the event log by using ASP.NET health monitoring. This approach does not use EventLog.WriteEntry, but you are restricted to use a predefined event source.
Registry Access
The Network Service account does not have Write access to the registry. If your application needs to write to the registry, you must configure the necessary access control lists (ACLs) on the required registry keys.
Granting Registry Access to Network Service
In the following example, an application needs to change and display the name of the Internet time server that Windows is automatically synchronized with. An operator can change this setting by using the Internet Time tab from the Date and Time item in the Control Panel.
Your application needs to modify the following registry key:
HKLM\SOFTWARE\ Microsoft\Windows\CurrentVersion\DateTime\Servers
To allow the Network Service Account Write Access to the preceding registry key
You need to use an administrator account with permission to alter the registry security to perform the following steps:
1. On the taskbar, click Start, and then click Run. Type regedit in the Open box, and then click OK.
2. Expand the outline list in the left panel to locate the DateTime folder icon at the preceding registry path.
3. Right-click the DateTime folder, and then click Permissions.
4. In the Permission for Servers dialog box, click the Add button.
5. In the Select Users, Computers, or Groups dialog box, type NETWORK SERVICE in the text box, and then click Check Names. The Network Service name will be underlined; this indicates that it is a valid security principal. Click OK.
6. In the Permissions for Servers dialog box, click the Network Service user name from the list, and in the Permissions for NETWORK SERVICE section, click Advanced.
7. In the Advanced Security Settings for Servers dialog box, click Network Service, and then click Edit.
8. In the Permission Entry for Servers dialog box, select the Set Value and Create Subkey check boxes in the Allow column to permit write access. Click OK several times until the Permissions dialog box closes.
Note You should be careful while editing the registry because any mistake can lead to system instability.
Your ASP.NET application could now use code similar to the following sample to change and display the name of the Internet time server.
using Microsoft.Win32;
...
protected void Button1_Click(object sender, EventArgs e)
{
//change the time server
RegistryKey rk = Registry.LocalMachine.OpenSubKey(
@"SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers",
true); //writable - this will fail without proper access
string sDefault = (String)rk.GetValue("");
int iDefault = Convert.ToInt32(sDefault);
//this an array of all the server names
string[] sServers = rk.GetValueNames(); //requires enumerate sub keys
iDefault++;
if (iDefault >= sServers.Length)
iDefault=1;
rk.SetValue("", iDefault.ToString());
// update display
Response.write(rk.GetValue(sServers[iDefault]).ToString());
}
SQL Server
ASP.NET applications should use Windows authentication while connecting to a database. By using Windows authentication, you avoid storing database credentials in connection strings and you avoid passing passwords over the network to the database server.
With Windows authentication, your application's process account is used by default for authentication. To be able to access a database, your account requires:
� A SQL Server login on the database server.
� Permissions to the required objects (for example, stored procedures, views, or tables) in the required database.
Granting Access to a Local SQL Server
When the SQL Server is on the Web server, you must create a database login for the NT AUTHORITY\Network Service account.
To access a local SQL Server database using Network Service
1. Start SQL Server Enterprise Manager.
2. Expand the folders in the left panel and locate the Security folder for your local SQL Server.
3. Right-click Logins in the Security folder, and then click New Login.
4. In the SQL Server Login Properties - New Login dialog box, in the Name box, enter NT AUTHORITY\NETWORK SERVICE. Accept the defaults for the other settings, and then click OK.
5. Expand the Databases folders, and then expand the Pubs (or equivalent) database.
6. Right-click Users, and then click New Database User.
7. In the Database User Properties - New User dialog box, select the NT AUTHORITY\NETWORK SERVICE account.
8. In the Permit in Database Role list, select the db_datareader check box.
9. Click OK, and then close the SQL Server Enterprise Manager.
The Network Service account now has permission to read the data in the tables of the designated database.
In practice, your application's requirements may be more complex. For example, you might want to allow read access to certain tables and allow update access to others. The recommended approach to help mitigate the risk posed by SQL injection is to grant execute permissions to the Network Service account on a selected set of stored procedures and provide no direct table access.
Granting Access to a Remote SQL Server
If you are accessing a database on another server in the same domain (or in a trusted domain), the Network Service account's network credentials are used to authenticate to the database. The Network Service account's credentials are of the form DomainName\AspNetServer$, where DomainName is the domain of the ASP.NET server and AspNetServer is your Web server name.
For example, if your ASP.NET application runs on a server named SVR1 in the domain CONTOSO, the SQL Server sees a database access request from CONTOSO\SVR1$.
To access a remote SQL Server using Network Service
To grant access to a remote database server in the same domain or a trusted domain, follow the steps described earlier for a local database, except in step 4, use the DomainName\AspNetServer$ account to create the database login.
Note In production environments, you should place the network service account into a Windows group and create a SQL Server login for the Windows group.
Reference:
http://msdn2.microsoft.com/en-us/library/ms998320.aspx
http://dotnetqpearl.net/blogs/default.aspx
A.Kader
