Configuring Windows Authentication

All ASP.NET applications are configured to run as a specific Windows user. This is specified in the .NET Framework machine.config file. By default, the user account is:

<local machine>\ASPNET

This ASPNET user is a local machine account that has limited privileges, allowing web applications to run as a relatively un-trusted user without administrative privileges so they cannot compromise the integrity of the server.

Configurin basic Windows Authentication

Check the user configuration in the machine.config file as follows:

Step 1: Locate your machine.config file, e.g.:

C:\<WINDOWS-DIRECTORY>\Microsoft.NET\Framework\v2.0.50727\CONFIG

Be sure to use the Machine.config file specific to your active .NET Framework installation.

Step 2: Search for the string processModel and look for the “userName” and “password” attributes.

<processModel

enable="true"

timeout="Infinite"

idleTimeout="Infinite"

shutdownTimeout="0:00:05"

requestLimit="Infinite"

requestQueueLimit="5000"

restartQueueLimit="10"

memoryLimit="60"

webGarden="false"

cpuMask="0xffffffff"

userName="machine"

password="AutoGenerate"

logLevel="Errors"

clientConnectedCheck="0:00:05"

userName="[user]" is the Microsoft Windows user name used when running ASP.NET applications. If a domain is not specified, the current machine name is assumed to be the domain name.

There are two special users:

"machine": run the process as a low privilege user account named "ASPNET". (This is the default.)
"SYSTEM": run the process as a local system (high privilege administrator) account.

password="[AutoGenerate | password]" is the password of the designated Microsoft Windows user. Specify "AutoGenerate" for special users (machine and SYSTEM).

When ASP.NET is running under Microsoft IIS 6 in native mode, the Microsoft IIS 6 process model is used and settings in this section are ignored. Use the Microsoft IIS administrative user interface to configure process identity and cycling for the Microsoft IIS worker process for the desired application.

If Microsoft SQL Server is installed on the same machine as your Microsoft IIS web server, you can create a Microsoft SQL Server login account for the configured Windows user, even if that user is the default <local machine>\ASPNET user. This allows your applications to connect to Microsoft SQL Server using "Windows authentication". If, however, Microsoft SQL Server is running on a remote machine, it is not possible to create a Microsoft SQL Server login account for the <local machine>\ASPNET user because the ASPNET user is not recognized as a valid domain user. It is a local machine account only. In this case, you will have to reconfigure ASP.NET to run as a valid domain user instead of the default ASPNET user.

Case 1: Microsoft SQL Server is installed on the local machine

If your Microsoft IIS web server and your Microsoft SQL Server are running on the same machine, do the following to enable your applications to connect to Microsoft SQL Server.

Step 1: Determine the Windows user ID that is used by ASP.NET applications by checking the machine.config file. By default, this user ID is “<local machine>\ASPNET”.

Step 2: Create an account for the user in Microsoft SQL Server

Use Enterprise Manager --> Database server --> Security --> Logins

If you have not changed the default ASP.NET user, add a <local machine>\ASPNET login. If you have changed the default ASP.NET user to a user other than ASPNET, add a login for that user.

Step 3: Grant db_owner rights to this user on any databases you plan to reference. This will allow Iron Speed Designer to create stored procedures in those databases.

You should now be able to connect from Iron Speed Designer to Microsoft SQL Server using Windows Authentication.

Case 2: Microsoft SQL Server is installed on a remote machine

If your Microsoft SQL Server is running on a different machine than your Microsoft IIS web server and you have not changed the default ASP.NET user, you will need to perform additional configuration steps. If you do not, you will get a “user not found” error when you try to add a Microsoft SQL Server login for the “ASPNET” user. In particular, you must change the ASP.NET user to a valid domain user by configuring machine.config as follows.

Step 1: Locate your machine.config file, e.g:

C:\<WINDOWS-DIRECTORY>\Microsoft.NET\Framework\v2.0.50727\CONFIG

Be sure to use the Machine.config file specific to your active .NET Framework installation.

Step 2: Change the userName and password attributes in the processModel element to a valid Windows domain user.

Step 3: Reset Microsoft IIS or stop the aspnet_wp.exe process in order for your changes to take effect.

Step 4: Create an account for the configured user (now a valid domain user) in Microsoft SQL Server

Use Enterprise Manager --> Database server --> Security --> Logins

Step 5: Grant db_owner rights to this user on any databases you plan to reference. This will allow Iron Speed Designer to create stored procedures in those databases.

You should now be able to connect from Iron Speed Designer to Microsoft SQL Server using Windows Authentication.

Implementing Windows Authentication with .NET Impersonation

Implementing Windows Authentication with .NET Impersonation is fairly simple to set up.

Step 1: Add a line to the application’s Web.config file specifying the desired domain user account and password as the anonymous user for the Web application. Within the <system.web> section, add:

Step 2: Configure the anonymous user within Microsoft IIS for the web site (or virtual directory) on the Directory Security tab by clicking the Edit Anonymous access and authentication control button.

Step 3: Manually create a virtual directory in Microsoft IIS for your application. Iron Speed Designer may not be able to create the virtual directory for you automatically.

Step 4: You may need to manually compile your application using the CompileApplication.bat utility.

Step 5: When running the application after changing the application to use a domain account using .NET impersonation, the application can’t access the data, even though the application domain account is a DBO of the application database. This is because Iron Speed Designer creates the stored procedures as owned by the Iron Speed Designer application user account rather than owned by DBO. This prevents the application, which uses a different application account, from accessing the stored procedures.

As a temporary workaround, make the Iron Speed Designer application user account an “sa” (system administrator) rather than a DBO. Iron Speed Designer then properly makes the ownership of the stored procedures DBO, and the application user account is able to access the data.