Tutorials » Web-user Authentication for IIS
First, this tutorial explains Web-user authentication: What it is, how you work with it for Microsoft IIS, and what options are currently available to you.Then second, each choice is described in more detail to help you choose the path that is best for your site.
Part 1: What Is Authentication?
Let's assume you want to restrict access to selected portions of your Web site. For example, you might have valuable information, such as real-time stock quotes, or you may desire to charge a monthly fee for accessing your database.
In these cases, you will want to let people in, but only after checking that visitors have used an authorized username and password. Additionally, you might want to provide access to the bulk of your Web site for the simple price of a visitor's email address, creating an effective method for tracking visitors.
Asking a visitor for their username and password (or their credentials) is called authentication. On the world wide web, the oldest and most widely supported authentication method is Basic Authentication.
Definitions
- ASP = Active Server Pages.
- ISAPI = Internet Server Application Programming Interface.
- MMC = Microsoft Management Console.
- NTCR = NT Challenge Response.
- NTLM = NT Lan Manager.
- NTFS = NT File System.
- ODBC = Open Database Connectivity.
- SSL = Secure Socket Layer.
Assuming you have the latest and greatest IIS, you have several choices when working with authentication including:
- IIS NT Challenge Response
- A good choice if you are on a Windows Network. Can require the use of IE. There is no proxy-server between the browser and the server.
- IIS Basic Authentication
- Can expose your NT usernames and passwords unless all connections are over SSL.
- A Basic Authentication filter such as AuthentiX
- Cannot compromise NT accounts. High performance. Large numbers of users. Can validate against ODBC or internal database. Many advanced features.
- Write your own filter
- Flexible, but resource intensive to build.
- Cookie based authentication with ASP pages
- Only protects ASP pages. Can be slow. Requires cookies. Cookie-based systems can be susceptible to spoofing.
- Self-Authenticating ISAPI dlls, CGI-scripts using Basic Authentication.
- Good performance, all content generated though a single URL. Doesn't use conventional directory/file/html format.
- Certificate based
- Secure, but intimidating for webmasters and surfers alike. Requires SSL.
NT challenge response
Using NT Challenge Response is an obvious choice, and is included as one of the options when you set up each IIS directory. Any directory you want to protect must be on an NTFS partition.
How to set up NTCR
In Internet Service Manager (IIS1-3) or the Microsoft Management Console for IIS (IIS4 and up) select the directory you want to protect. Make sure Basic (Clear Text) is off and Windows NT Challenge Response is on. You can leave Allow Anonymous on.
Create an account for each user you want to provide access, remove the permissions for "IUSR_machinename" from the directory, and add permissions for the added users. Alternatively, you could set up a group, permit access to that group, and add permitted users to the group. Remember, the user will need execute rights if the directory has any ASP, ISAPI extensions, counters, and so on.
Note that when the user returns to a non-protected page, they will be prompted for their username and password again, unless you have also granted them read-access to non-protected pages. However cancelling the prompt will let them in, disconcerting though this may be.
If the user has permission to access the directory but is in a different domain than the IIS machine, the user will have to prepend the domain name, so IIS knows where to look for the password.
Because NTCR uses a token mechanism for verifying users, the password of the currently logged in user is not available to IIS. This will have an impact if you are trying to access a resource which is not on the same machine as IIS, since IIS will not be able to login using the current user to a machine elsewhere on the LAN. For example if an NTCR protected ASP page tried to read an Access mdb file on another machine, it would fail and similarly for an SQL server with integrated or mixed security.
NTFS is the way to go if you are on a windows network.
NTCR can be an ideal solution for intranets, where all users are on accessible domains, there aren't too many users, and you can require the use of a compatible browser (Internet Explorer is the only browser which supports NTCR).
You won't want to use NTFS if:
- You want compatibility with browsers other than IE, or older browsers.
- You want to protect directories on FAT partitions.
- You expect (don't we all?) a large number of users. Having a large number of users becomes a problem because this clutters the NT user database and it becomes very difficult to maintain. It can also impair the speed of the operating system itself!
- Using the NT user base can also be a problem because of potential security risks. You are elevating a 'mere' web surfer to the status of a full NT user. You have to be careful not to inadvertently grant too many permissions.
- There's a proxy server involved as documented in the IIS 4 Resource Kit, NTLM will not work through a proxy. The problem is that it requires more than one round trip to complete authentication and so needs a persistent connection end to end, from client to origin server. Proxies don't generally work that way.
IIS Basic Authentication is included as an option when you set up each IIS directory. Any directory you want to protect must be on a NTFS partition.
How to set up IIS Basic Authentication
Setting up IIS Basic Authentication is similar to setting up NTCR.
In Internet Service Manager (IIS1-3) or the Microsoft Management Console for IIS (IIS4 and up) select the directory you want to protect. Turn on Basic (Clear Text) and turn off Windows NT Challenge Response. It is okay to leave Allow Anonymous on.
When you select Basic (Clear Text) you will be warned that your Windows NT usernames and passwords will be transmitted without being encrypted. For your NT accounts this is a pretty serious issue. You should only consider this option in combination with SSL, which is slow and requires you to buy a certificate from Verisign or Thawte (among others).
Create an account for each user to whom you want to give access, remove the permissions for "IUSR_machinename" from the directory, and add permissions for the users you added. Alternatively you could set up a group, permit access to that group, and add permitted users to that group. Remember the user will need execute rights if the directory has any ASP, ISAPI extensions, counters etc.
IIS Basic Authentication is the way to go if:
- You accept the need for SSL and don't mind paying the performance penalty.
- You already have a certificate or you don't mind paying for one and setting it up.
- If you are concerned about the security of your NT accounts.
- IIS calls LogonUser and ImpersonateLoggedOnUser for each and every request, which is expensive in terms of CPU cycles and performance.
There are many third party authentication filters on the commercial market. The Guru uses and recommends AuthentiX. AuthentiX is a fast, filter based third party tool for IIS authentication developed by Flicks Software.
These filters allow you to protect content directories and individual files by asking for usernames and passwords held separately from the Windows NT usernames and passwords, ensuring the the security of your NT accounts.
How to set up a third party Basic Authentication filter
It is recommended that you carefully read the documentation for your authentication software and install it accordingly. In general, this is an easy task.
A third party Basic Authentication filter is the way to go if:
- You want the high performance that a filter offers.
- You want to be able to add and modify users from ASP and don't want the ASP pages to have SysAdmin privileges.
- You want browser independence.
- You don't want any chance of compromising NT username/password security.
- You want to separate your Web users from your NT Accounts.
- You are concerned about performance and the speed associated with filter based solutions.
- You have directories you want to validate against an ODBC database.
- You want to authenticate multiple IIS servers against a single ODBC machine on the LAN.
- You want to use browser based remote administration.
- You need to protect all content in a directory: htm, asp, gif, jpg, zip, and so on.
- You want advanced features like:
- Limiting concurrent logins.
- Bandwith, request and login throttling.
- Protect by IP, Domain Name and by referrer.
- Protecting your premium content directories does not warrant the price of registration.
- Basic Authentication is not secure enough for your purposes.
- You want all accounts of every type in one userbase, specifically the NT user account database, for administrative reasons.
Writing your own Basic Authentication filter is an option if you have the skills, resources and time to do it.
How to write your own Basic Authentication filter
You will need to build a dll that conforms to the ISAPI filter specification and has the following entry points:
- GetFilterVersion.
- HttpFilterProc.
The HttpFilterProc function is called in response to the notifications set in GetFilterVersion and is where the work of the filter is actually done.
There are several excellent references to help develop an ISAPI filter.
Writing your own Basic Authentication filter is the way to go if:
- You have special requirements, and commissioning a custom enhancement to a third party Basic Authentication filter is not an option.
- You have the skills, resources and time.
- You want to validate against a specific or proprietary type of datasource, such as flat-file, or your own database.
- You have a short deadline.
- You do not have the skills or resources required.
- Basic Authentication is not secure enough for your purposes.
- You want all accounts of every type in one userbase, specifically the NT user account database, for administrative reasons.
- A third party tool like AuthentiX meets all your needs.
You can use the cookie based session variables of Active Server Pages to capture a username and password from a form, validate the username and password, then set a session variable to indicate the user has correctly logged in.
How to use cookie based authentication with ASP pages
- Create a login page like the following example:
Login.asp
<form action="loginNow.asp" method="POST">
Username: <input type="text" name="username" size="22">
Password: <input type="password" name="password" size="22">
<input type="submit" value="Login Now">
</form>
- Create an ASP page to receive and process the results like the
following example:
LoginNow.asp
<%
username = Request.Form("username")
password = Request.Form("password")
if ("George" <> username) Then
response.Write("Sorry, incorrect username and password (1)")
response.End
End if
if ("Washington" <> password) Then
response.Write("Sorry, incorrect username and password (2)")
response.End
End if
Session("username")=username
%>
George, you have logged in successfully.
<a href="protected.asp">Please continue to the protected page</a>
- In each ASP page to be protected, check the username and password.
You could use an include file statement if you had several ASP pages
and wanted a single file to do the checking.
Protected.asp
<%
username = Session("username")
if ("" = username) Then
response.Write("Sorry, you are not logged in.")
response.End
End if
%>
You have access to this Active Server Page!
- You are happy coding your own solution in VBScript, and you only have a few ASP pages to protect.
- You don't mind excluding those who cannot or will not accept cookies.
- You don't have gif/jpeg/pdf or other non-ASP content, so you are not concerned about someone else creating web-pages linking directly to your non-ASP protected content.
- You want to protect all content, not just ASP pages.
- You are worried about performance. Any reasonably large amount of Active Server Pages can have a significant detrimental effect on the performance of your server. The popularity of products such as XBuilder, which generates static html pages from ASP pages for performance reasons (among others), illustrates this point.
- Cookie-based systems can be susceptible to spoofing.
Self-authenticating scripts usually provide a single URL entry point, with parameters indicating the current state of the session and the content requested. Self-authenticating scripts can be written as ASP, CGI, Win-CGI, or ISAPI dlls, and other variations.
Definitions
- ASP = Active Server Pages. The script communicates with IIS via server-variables.
- CGI = Common Gateway Interface. The script communicates with IIS via stdin and stdout.
- Win-CGI = Windows Common Gateway Interface. The script communicates with IIS via temporary INI files.
There are too many variations to show how to create a self authenticating script in this tutorial, however they all share a common means of authenticating.
When a request comes in and the content to be displayed is protected by a Basic Authentication username and password, the script sends a 401 Access Denied message, indicating the realm, and some html that is displayed to the user when the login attempt fails.
A regular http reply looks like this:
HTTP/1.0 200 OK
Server: Microsoft-IIS/3.0
Date: Wed, 11 Mar 1999 16:31:52 GMT
Content-Type: text/html
Last-Modified: Wed, 18 Feb 1998 22:45:46 GMT
Content-Length: 1234
Content: Interesting Stuff
A 401 Access denied reply looks like this
HTTP/1.0 401 Access Denied
Content-type: text/html
Server: Microsoft-IIS/3.0
Date: Wed, 11 Mar 1999 16:35:47 GMT
WWW-Authenticate: Basic realm="Message in Popup"
Content: You cannot get in!
Once the script sends a 401 Access Denied message, the browser will pop up a dialog indicating the realm, and invite the user to enter a username and password. The user will not see the access denied content unless the login fails. Some browser keep retrying the pop-up dialog until it succeeds or the user escapes out, others only pop-up three times.
If the user types in a username and password the browser will send them to the server as a part of the http request header that looks like the following:
Authorization: Basic cGvcmU6cGRcmU=
The string "cGvcmU6cGRcmU=" is Base64 encoded.
The script will ask the server for this header by requesting the server variable HTTP_AUTHORIZATION, and decode it. The resulting string will be in the format username:password and the script can match these against acceptable values in order to determine whether to transmit the content or issue another 401 Denied.
In IIS4, the HTTP_AUTHORIZATION value may not be returned correctly by IIS. In MMC, select the directory in which the ASP page calling this function resides. If Basic (Clear Text) is off, and NTCR is on, then HTTP_AUTHORIZATION will not return the correct value. This problem did not occur in IIS3. Microsoft bug Case Number is SR X980 2166010 644. Recommended workaround is to either:
- Turn Basic (Clear Text) off and NTCR off for that directory.
- Or turn Basic (Clear Text) on and NTCR on for that directory.
Self-authenticating scripts is the way to go if:
- You have the skills, resources and time to do it.
- You want to generate your content in a single program.
- You want protected content in normal directory/file/html format.
- You are worried about maintaining the content. Scripts can become fairly complex when the content becomes large, and changes are not easily made. If you have content stored in a database then this can be more flexible, but you have the added complexity and performance hit of interfacing to the database.
How to use certificate based authentication
Since this technology is still maturing, be sure to have the latest version of IIS4 installed on your system.
- Obtain a certificate from a certificate issuing authority such as Verisign or Thawte. Refer to the IIS documentation on Key Manager.
- Select a directory you want to protect in the MMC.
- Click on the Secure Communicatations Edit button on the Directory Security property sheet and use the certificate you obtained. Select both Enable Client Certificates and Require Client Certificate.
- Enable client certificates for this resource.
- Issue client certificates for access to this resource.
- "Internet Information Server 4.0 - Security for the Web-Enabled Enterprise" by Nick Evans in the Premier Edition of Security Advisor by Advisor.com publications.
- "Web Project, Digital IDs" by Jon Udell in the March Edition of Byte magazine.
- "Issuing digital certificates with Microsoft Certificate Server" section of the IIS Security White Paper by Microsoft.
- You want a high degree of certainty of the identity of the users accessing your site.
- You accept the need for SSL and don't mind paying the performance penalty.
- You already have a certificate or you don't mind paying for one and setting it up.
- The process of issuing a client certificate is too complex and intimidating for both you and your users.
- You do not want the performance hit of having all protected information exchanged via SSL.
