Understanding Windows Authentication in Detail

Digest Authentication, like Basic Authentication requires the user to provide account information using a login dialog box that is displayed by the browser. Unlike Basic Authentication, the user name and password are not transmitted in clear text. Instead, a cryptographically secure hash with this information is sent. We can implement this authentication by simply enabling this option in IIS as in the following;



Figure 1.10 Digest Authentications

Digest Authentication involves hashing the user's password using the MD5 algorithm. Windows is unable to store MD5 hashes of passwords for local accounts (SAM database) thus the limitation of Digest Authentication is that in IIS, it only functions when the virtual directory is being authenticated or controlled by a Windows Active Directory Domain Controller.

Digest Authentication protects users and applications against a variety of malicious attacks by incorporating a piece of information about the request as input to the hashing algorithm.

Enabling and disabling digest authentication can also be performed programmatically. We can enable this authentication using the AppCmd command as in the following;

appcmd.exe set config /section:digestAuthentication /enable:true

Integrated Windows Authentication

Integrated Windows Authentication is the most reasonable mechanism for LAN-WAN-based applications. For this authentication to work properly, both client and server must be on same network. In fact, integrated authentication does not transmit any credential information. Instead, it coordinates with the domain server where it logged in and gets that computer to send the authentication information to the server.

It performs authentication without any client interactions. When IIS asks the client to authenticate itself, the browser sends a token that represents the Windows account of the current user. Technically, this authentication incorporates two authentication mechanisms; NTLM and Kerberos. Enabling integrated authentication via IIS Manager typically enables support for both of these two mechanisms as in the following;



Figure 1.11 Integrated Authentications

UNC Authentication

UNC (Universal Naming Convention) authentication allows you to configure IIS to use a specified user account when accessing resources on a remote share. This authentication can be implemented during creation of a virtual directory for a web application. Use the following procedure to configure UNC authentication:

1. Open IIS Manager using inetmgr from the "Run" window.
2. Locate the website at which you wish to add a new virtual directory. Right-click and choose "Add Virtual Directory".
   
   
   
   Figure 1.12 UNC Authentications
   
3. Enter the alias name that the directory should be accessed under and UNC physical path as in the following:
   
   
   
   Figure 1.13 UNC Authentications
   
4. Now click the "Connect as" button and choose the "Application User" radio button and chose a specific user account. Finally click the "Ok" button.
   
   

Figure 1.14 User Account

Anonymous Authentication

A remote user is not required to supply credentials to access a file when Anonymous Authentication is enabled. By default, the configured anonymous access account is the IUSR account created when IIS is installed. Anonymous Authentication can be configured from the IIS Manager as in the following;



Figure 1.15 Anonymous Authentications

It is important to note that if you enable more than one authentication options, the client will use the strongest authentication method as long as anonymous authentication is not enabled. If anonymous authentication is enabled then the client will access the website anonymously. So it is suggested to disable anonymous authentication during more than one authentication implementation.

Programmatic Authentication

You can access some additional information about the currently authenticated user using the WindowsIdentity class. The following code is required to do that;

When you build this program, the following extra Windows-specific information will be displayed;



Figure 1.16 Information

Impersonation

Impersonation is the process under which an application can take the identity of its user to access all the resources the user is authorized for. Instead of using a fixed account for all users, web pages and applications, you can temporarily change the identity that ASP.NET uses for certain tasks.

You may want to access some resources residing on your local system, that requires you to login with valid credentials. Let's say that you have some files in the location "C:\temp\". The ACL editor for the folder temp removes all the groups and leaves only the Administrator users and Administrator user groups associated to it as shown below;



Figure 1.17 ACL

Now create a simple ASP.NET web application with a Button and a List box control to access all files that reside in the temp folder as in the following;

Now configure the application in IIS to use Windows integrated authentication. Finally build the project. When you click the button to access the files in the temp folder, you might see an error indicating that access to "C:\temp" is denied. This is because your application is running with an ASP.NET account that will not be allowed access to the "C:\temp" folder depending on the ACL.

So we need to make our application run under the Administrator's identity that can be done by impersonation. We would add the following code in the web.config file to impersonate the Administrator identity as in the following:

Now build the project again to test the application and it should work fine when you click the button as in the following;



Figure 1.18 output

Alternately, you can also configure impersonation using the IIS Manager. Let's take the preceding example as a reference, when you are done with all the programmatic and other configurations related to impersonation you will notice that in IIS Manager the ASP.NET impersonation option is enabled and configured with the impersonation "VidyaVrat" account as in the following;



Figure 1.19 Impersonations