AUTHENTICATION AND SECURITY
FOR INTERNET DEVELOPERS
INTERNET DEVELOPER SUPPORT
If you are a Web developer working with Microsoft’s Internet Information Server (IIS), it is very important to
understand how IIS uses authentication and impersonation to control security on your Web server. While working
in the Internet Developer Support team at Microsoft, I found that about 1 in 4 of the issues we dealt with were
caused by the umbrella topic we call permissions. Further, most of those issues could have been avoided if the
developer simply had a better conceptual understanding of what was happening under the hood. Authentication is
simply the process of determining the identity of a user. Once a user has been positively identified, Windows NT
can then control what resources that user can access. While not extremely technical, authentication and security
can be confusing. Having a solid understanding of how IIS controls security will allow you to be much more
successful creating solid sites, and to avoid common time consuming problems.
This article explains Windows NT security as it relates to IIS so that you can effectively troubleshoot nasty
security-related problems. We will cover the three forms of authentication, how they differ, several ways of
controlling access to key areas on your Web server, and the important but almost universally misunderstood
concept of "delegation." Understanding delegation is mandatory for anyone building a data driven Web site using
IIS. Understanding how Windows NT handles different "users" will potentially save you days or weeks of
ACLs, NTLM, and other definitions
To start with, let's define some common terms that relate to Windows NT's security.
ACLs Access Control Lists. Each ACL is a list of Access Control Entries (ACEs) that specify
access and auditing information used by Windows NT on an NTFS-formatted hard
drive. Windows NT uses the lists to determine which users have been granted access to
specific resources (files and folders), and which rights a user may exercise such as read,
write, and execute. The ACLs for a file or folder can be viewed by right-clicking the
resource, clicking properties, and clicking the Permissions button on the Securities tab.
Challenge/Response A Windows NT authentication process. Challenge/response can occur when a user or
service (such as IIS) tries to access any resource stored on an NT machine across a
network (such as viewing a shared resource on a server). Can be used by IIS to
authenticate a user browsing a Web site.
NTLM Windows NT's implementation of the challenge/response authentication scheme.
NTLM stands for NT LAN Manager because it was developed and originally used in
Microsoft LAN Manager, one of Microsoft's earliest networking products.
SAM The SAM (Security Account Manager) is a database of user and group account
information. The SAM does not contain passwords, but instead stores password hashes
(described later). The SAM is stored in the HKEY_LOCAL_MACHINE\SAM and
HKEY_LOCAL_MACHINE\Security\SAM registry subtrees. Not surprisingly, the
SAM is often the prime target of hackers.
Under different situations IIS pretends to be different users. Remember that all processes operating on a
Windows NT machine run under a valid NT account. When a program or process (like IIS) runs on behalf of a
user, it is said to be running under the security context of that user. The purpose is to give that process no more
access to files and resources than the user would have. When IIS does this, it is said to be impersonating that
IIS, obviously, is designed to handle Web requests as an automated service. To do this, IIS still needs to run
under some valid user’s security context. There are two kinds of requests that IIS may be required to respond to.
First are anonymous requests where we know almost nothing about the user, and second are authenticated
requests where we know exactly who is requesting the resource. It's not always obvious which method is being
used since both anonymous and authenticated requests can happen with no dialog boxes or other indications to the
user. It is, however, mandatory that we as developers always know which method is being used. What account
IIS impersonates, and by extension, what IIS can and can not do depends completely on knowing.
Anonymous Requests — No information is required from the user. By default, when a browser requests a Web
page, IIS will first try to fill the request without authenticating the user. To do this, IIS impersonates a special
Windows NT account, IUSR_machinename (where machinename is the name of the IIS host computer). This
account is created during the install process for IIS. If IIS, impersonating the IUSR_machinename account, can
access the requested resource, then the page is served to the anonymous user.
A common problem with anonymous access occurs when the password for the IUSR_machinename account and
the password entered in the Internet Service Manager get out of sync. When IIS tries to impersonate the
IUSR_machinename account, it submits the password that was entered in the anonymous logon field to Windows
NT . If that password is incorrect, IIS is totally prevented from using the account. Since anonymous access
failed, IIS attempts to authenticate everyone. The scary part of this is that the authentication can happen silently,
so the site begins to fail but the reason isn’t apparent at all. I’ve talked to many Web site administrators who were
experiencing bizarre security related problems because their site authenticating all users, and they didn’t even
know it. This makes a huge difference if your pages are accessing other resources like databases or server side
Authenticated Requests — Positive identification of the user is required. When IIS cannot fill the request using
the IUSR_machinename account, IIS attempts to authenticate and then impersonate the user so that it can
determine if that user should have access to the requested resource. There are two methods that IIS can use to
authenticate users; Windows NT challenge/response and Basic. These are discussed later in this article.
Authenticated Web access usually works best within a company’s Intranet or some well-defined, contained group.
Even so, there are some limitations to consider.
Controlling the Authentication Method, and Why We Care
The IIS Service Manager tool is the primary place where we can configure IIS for WWW, FTP, and Gopher
services. Without going into great detail about the options in the WWW properties dialog box, we do need to be
aware of several key items. By default, the Password Authentication group will have Allow Anonymous and
Windows NT Challenge/Response selected. The third access method is Basic, which we will cover later. So lets
look at several ways of controlling access to your Web server.
Allow Anonymous Check Box
If Allow Anonymous is selected, IIS will always attempt to access the resource being requested by impersonating
the Anonymous Logon account (by default, IUSR_machinename). When the IUSR_machinename account was
automatically created, it was assigned a random password and given guest privileges by being added to the guests
group. Adding or removing the Allow Anonymous check is the best way to globally turn on or off anonymous
access for the entire Web server. With Allow Anonymous de-selected, only users with valid Windows NT
accounts that can be verified using either of the two authentication methods will be serviced. Setting up IIS this
way is usually only appropriate for a corporate or members-only setting where it is important to validate all users
accessing your site.
Change Permissions on Files and Folders
The NTFS level permissions are respected by IIS, so manipulating individual permissions on files and folders
allows better granularity as you control what pages can be accessed by whom. A common scenario would be to
have customer pages on a retail site set with the default "Everyone Full Control" permissions, while other pages
that allow the prices to be changed could be restricted to administrators. The IUSR_machinename account is of
course part of the Everyone group, so you could restrict access several ways. Either remove the Everyone group
and possibly add a "Web authors" group for those that need editing rights, or if you have a diverse number of Web
authors and you aren’t interested in setting up and maintaining a "Web Authors" group, you could simply exclude
the IUSR_machinename account. This method is obviously best for a site that needs some anonymous while still
securing other pages.
ASP Code-Based Security
Code-based security is the most fun. Using Active Server Pages (ASP) code, we can implement unique and
varied security. For example, say an annoying person is harassing your site. Since the IP address can be pulled
from the logs, we could use the following code to deny access:
<%If request.servervariables(“REMOTE_ADDR”) = “220.127.116.11” then
Response.Buffer = TRUE
Response.Status = ("401 Unauthorized")
There are many server variables that can be used under ASP, including the LOGON_USER that will return the
domain\username of authenticated users, and a blank for anonymous users. In this case it would be possible to
use server side code to check for key individuals and possibly redirect them to different pages depending on their
job requirements. I’ve even seen companies used this technique to lock competitors out of their Web sites.
Windows NT Challenge/Response
Windows NT Challenge/Response is simply NT’s very secure way of determining who is making a request (that
is, authenticating them). The flow of how Windows NT Challenge / Response works is mandatory knowledge for
anyone working on IIS. What we are really getting around to is an understanding of the Windows NT limitation
called delegation, but this can only be explained when challenge/response is clear.
And Now for Something Completely Different: The "Hash"
Windows NT challenge/response does not send a password across the network because it could be intercepted and
deciphered. NT uses a non-reversible algorithm that is like a meat grinder. You put something in, and out comes
the hash. Windows NT uses the Internet standard MD4 hashing algorithm to produce a 16-byte (128-bit) hash. It
is impossible (theoretically) to take both the hash and the algorithm and mathematically reverse the process to
determine the password. In other words, the password serves as a "private key". Only someone who has the key
can generate a particular hash. An NT domain controller has a database of user hashes generated from user
passwords, but doesn’t store the passwords themselves. (Note that this separation of hash and passwords does
NOT make the domain controller less of a target for hackers, because sometimes a hash can be used as a
password-equivalent; more about this later.)
IIS and the Challenge/Response Authentication Process
IIS will try to use Windows NT challenge/response authentication if the following are true:
If the “Allow Anonymous” box in the WWW properties of the Internet Service Manager is cleared or the
IUSR account doesn’t have sufficient permissions to access the requested resource or code is used to deny
Windows NT Challenge/Response is selected in the Internet Service Manager under WWW properties
The browser making the request understands challenge/response. Currently Internet Explorer is the only
browser that supports NT challenge/response.
When we say that IIS tries to authenticate the user, what it actually does is rather simple. It sends an HTTP 401
Access Denied message back to the browser, with the list of authentication methods it accepts. Another way of
looking at this is IIS saying, “You can’t get what you want without identifying yourself. By the way, I accept the
following methods of identification.” The two methods of identification are NT Challenge/Response and Basic.
Which method is acceptable depends on which WWW properties are checked in the IIS Internet Service Manager
dialog box. If both authentication methods are turned on, Internet Explorer will always attempt to use
challenge/response, while other browsers will use Basic.
The following table presents a packet’s-eye view of how NT challenge/response authenticates a user without ever
seeing their password.
1. Client makes an anonymous HTTP GET
request to the Web server.
2. Server replies with an HTTP 401 Access Denied
and includes NTLM and/or BASIC as acceptable
methods of authentication.
3. Client requests the page again.
4. Server again replies with an HTTP 401 Access
Denied, and includes a random value for the client.
This is the CHALLENGE.
5. Client encrypts the challenge using their
password hash as the private key, generating a
new unique hash for this transaction. The
network connection between client and server is
marked as "Keep Alive". The new hash is sent
to the server over the same connection. Only
someone that has the user’s password hash and
the random value could generate this new hash.
The hash and the user’s name and domain are
then base64 encoded and resent.
Page appears in browser 6. The server sends the hash, user name, and the
challenge value to the appropriate domain
controller based on the domain name sent from the
client. The Domain controller encrypts the
challenge value by using the user's password hash
kept in the SAM. The resulting hash is compared
against what the server sent. If they match, the
domain controller authenticates the user, and the
server then returns an HTTP 200 OK to the client
with the requested resource
Why a Random "Challenge"?
The extra step of encrypting a challenge using a password hash, instead of just passing the simple hash up to the
domain, makes it harder for the hash to be intercepted and used as a password. Since the challenge requires the
user’s password hash to generate the new hash, it proves the person has at least the user’s hash, but probably the
user’s password as well. All this without having the password sent over the wire. In essence, the password
becomes a private key and the random value a constantly changing public key.
Delegation is where most people lose the picture on both NT security and IIS authentication, even though
delegation is a huge issue for anyone considering a secure Web server environment, or, for that matter, just
wanting things to work! When the IIS Web server impersonates a user authenticated using NT
challenge/response, IIS does NOT have the user’s password or password hash. IIS only sees the encrypted
challenge, which it passes to the domain controller. You are most likely to see this when you have an ASP page
that accesses resources on another Windows NT box (such as a database). The second Windows NT box will
challenge IIS forcing it to prove that it is truly the impersonated user and IIS will not be able to since it can not
encrypt any challenges sent to it with the user’s hash. The second machine will deny access, and your database
enabled Web pages fail. This is a limitation in the Windows NT 4.0 (and prior) security model, and not IIS.
Using Windows NT challenge/response, there is no way a process impersonating you can access so much as a text
file on another Windows NT box.
If you ever want to determine when delegation is an issue, ask yourself if the Web server
has the user's password or hash. In politics you "follow the money". In delegation you
"follow the password"!
An analogy for this could be an executive that delegates responsibility to a secretary to sign checks and otherwise
act on their behalf. When using NT challenge/response, the user cannot delegate IIS to act fully on their behalf.
This particular limitation may well go away with the release of Windows NT 5.0 when NT incorporates the
Kerberos authentication system (developed for MIT's Project Athena).
Most people are afraid to use the Basic authentication option because of the screen they are confronted with when
The authentication option you have selected results in passwords being transmitted over the
network without data encryption. Someone attempting to compromise your system security
could use a protocol analyzer to examine user passwords during the authentication process.
For more detail on user authentication, consult the online help.
Are you sure you want to continue?
The message is as bad as it sounds. The user name and password are Base64 encoded. Base 64 is easily de-coded
by even novice hackers, though they would still have to access your network and use a TCP/IP packet sniffer to
intercept network packets, so this is not a likely event unless you are an overly attractive target such as a bank.
Most Web administrators I’ve talked to know that there are differences between NT challenge/response and Basic,
but still treat them as interchangeable. Basic authentication always prompts the user with a dialog box and asks
them to type in a user name and password. This information is then sent to IIS, which uses the name and
password to execute a log on locally command to the IIS box. Since IIS now has the password of that user, it can
answer challenges from remote machines, eliminating the delegation problem. Think of a user authenticated
using Basic as actually sitting at the Web server working, where a user authenticated using NT challenge/response
as accessing the Web server from a network. In fact, the user rights “access this computer from the network” and
“log on locally” are specific user rights that need to be set for users depending on which authentication method is
used. To set these rights, use the "User Manager for Domains" tool and select the "user rights" item from the
Even with its flaws, there are two circumstances where Basic authentication should be used.
You need to authenticate users using a browser other than Microsoft Internet Explorer. For example,
Netscape Navigator only understands Basic authentication. If you have NT challenge/response and Basic
authentication selected, Internet Explorer will always use NT challenge/response, and Navigator will choose
Basic. If your data is sensitive, this is a serious security concern.
Your site authenticates users and your ASP pages access resources on other Windows NT machines. The
classic situation is an ASP page that uses ADO (ActiveX Data Objects) to access a database on a remote
Windows NT machine. To avoid delegation issues, either ensure that all requested resources are located on
the IIS machine, or, if that isn’t practical, use Basic authentication.
Common Authentication Scenarios
Whenever an Internet user is authenticated using NT challenge/response, delegation will be an issue when IIS
accesses Windows NT resources across a network or local resources using UNC paths. Of course, all local
resources can be accessed as long as the user has the correct NTFS level permissions.
A common delegation-related error occurs when an ASP page is coded to access a database using a file-based data
source (such as an Access .mdb file) and the location is specified using a UNC path (for example,
\\Server\Share\resource.ext). Even though the resource is local, specifying a location using UNC makes it look to
Windows NT as if it is elsewhere on the network. The Windows NT networking subsystem handles UNC paths.
Windows NT is abstracted within its various components enough that if you step into the networking subsystem,
as far as the other Windows components are concerned, you are out on the network. This leads to the confusing,
but rather amusing scenario where an IIS machine that has authenticated a user using challenge response, and is
trying to access a local resource using UNC, will demand authentication from itself, and is unable to fulfill the
request. To resolve this problem, use absolute paths on the IIS machine (for example, “C:\folder\resource.ext”).
There is a subtle security-related failure that mimics delegation failure, but is not related to delegation at all. In
both these cases, you will see a three machine hop that fails (browser to NT/IIS to NT/remote resource). To
troubleshoot this, check if this is an authenticated or non-authenticated transaction. If authenticated, the problem
is almost certainly delegation failure. However, if the page is accessed anonymously, the problem is likely caused
by the anonymous logon account being local to the IIS machine. This can easily happen because the
IUSR_machinename account is of course created locally. IIS impersonates IUSR_machinename, and attempts to
access a resource on the remote machine. The challenge is passed, and IIS correctly encrypts the challenge using
the IUSR_machinename’s password hash. However, the remote Windows NT machine takes the password hash
and tries to validate it using its local SAM database and the local domain controller. Neither the remote Windows
NT machine nor the domain controller have ever heard of this account and, therefore, can’t validate the
a) Duplicate the IUSR_machinename account as a local account on the remote machine making sure the
user passwords are the same. If an identical local account exists on the machine with the desired
resources, that machine can validate the submitted hash without the aid of a domain controller. Even
though the two accounts are physically separate accounts, if their information matches, validation can
occur. One of the technical reasons you can get away with this technique is because Windows NT’s
hashing algorithm is such that two identical passwords from different users will generate the same
password hash. Under UNIX, this isn’t the case. UNIX introduces a value referred to as "salt" such that
two users with the same password will generate different hash values. Setting up a duplicate local
account is best when you want the IUSR_machinename account to only have access to specific remote
resources on your net. If someone is able to compromise the password for the anonymous account, they
will only have access to those computers on the network where the local account exists. The drawback is
of course that if the anonymous account needs access to multiple remote resources, now you have an
administration nightmare as all the accounts and their passwords must be kept in sync.
b) Make the anonymous logon account a domain account. To do this, remove the IUSR_machinename
account from the local IIS machine, and create a new account on the domain controller. From the WWW
properties dialog box of the Internet Service Manager, enter the Username field information in the format
Domain\Username (for example, BigDomain\JoeUser). This method is the easiest to administer, but in
the event that the account information is compromised, an intruder would have greater access to the
network. For some reason, I’ve talked with a lot of network administrators who are concerned about the
IUSR_machinename account being a target of hackers. It is actually no easier to steal the anonymous
logon account name and password then the CEO’s, so my preference for ease of administration is the
c) SQL Server has the unique ability to allow an unauthenticated connection from another machine,
effectively bypassing Windows NT’s security. If security isn’t a big concern (local company intranets are
usually pretty safe environments), you may want to make the process of connecting to SQL server much
easier by using TCP/IP sockets. SQL server will monitor the network traffic and respond directly to
TCP/IP requests, taking Windows NT out of the loop. SQL has it’s own security layer, so it is very
possible to use this option and still implement a decent security configuration. To enable this option,
select TCP/IP sockets in the Security dialog box when running SQL setup.
To “Security Dialog” or Not to “Security Dialog”? That is the Question!
Some Web developers do not want their users to have to type in a name and password each time they view the
site. So when will users be prompted with a dialog box to enter their name and password?
When using NT challenge/response, Internet Explorer automatically and invisibly sends the logon name, domain
name and hash of the currently logged on user to the Web server. Internet Explorer does this without asking
because sending the encrypted challenge doesn’t present any real security risk. From there, two things can
If the IIS machine sends information that can be appropriately validated by the domain controller, the user
will be authenticated without a visible prompt.
If the domain name sent by the browser isn't recognized by IIS, then IIS will have no idea where to send the
information for validation. This is more common for Internet users than intranet users, since a person sitting
at home is rarely on a domain. Even if they are, their domain controller probably isn’t accessible by the IIS
machine. Internet Explorer prompts the user to enter a new name and password, in effect saying, “Give me
some information that I can use.” If an employee working at home were trying to access a secured site, they
would need to enter their name in the form “bigdomain\JoeUser” and their password in the password field so
that IIS will get the correct domain information. Explicitly stating the domain name in this manner is almost
always mandatory authenticating users across the Internet.
Under Basic authentication, the user will always be prompted with a logon dialog box. You can probably guess
why. We are about to do something that could compromise your Windows NT account name and password. All
browsers figure that if you are willing to fill in the information and click OK, then you must know what you are
doing. I personally don’t have a problem using Basic authentication on a secure corporate network, but I will not
use it over the Internet without an additional layer of security such as Secure Sockets Layer (SSL is invoked on a
specially configured Web server that uses HTTPS:// instead of HTTP://). Once again, the user will need to
explicitly state the domain. IIS still needs to verify the submitted information with some domain controller.
Hackers and Your Site
Before I get into this, it seems I always need to offer a disclaimer. Yes, an aspiring young hacker could read this
and get ideas, but believe me, there are much better sources for hackers than this article. The best way to really
secure your site is to know where the weak points are, and no one knows where the weak points are better than
hackers. There are several key areas that a hacker may try and attack or exploit on a Web site. Obviously getting
their hands on a username and password with administrative privileges is the biggest coup. Getting a user’s
password hash is almost as good because a password hash can be used in some cases as a "password equivalent."
The password hash could be used to answer challenges by encrypting the challenge. Doing this can grant an
intruder "access this computer from the network" rights. To be granted a "log on locally" right, though, they still
need the actual password.
Several programs have been written specifically to extract password hashes from a Windows NT domain
controller’s SAM database, and crack the passwords. PWDump.exe and NTCrack.exe are both free on the
Internet, and are used by both system administrators and hackers. System administrators will use PWDump to
synchronize the password lists between network servers in a mixed environment such as UNIX and Windows NT
so users don’t need different passwords for the different Network operating systems. Hackers will use PWDump
and NTCrack to execute a brute-force attack against a network. Here is how it works. PWDump.exe is a program
written to dump the SAM database of user hashes and account information to a text file. An administrator must
run PWDump, so hackers usually wouldn’t run the program themselves. If they already had an administrator’s
password, they would have enough. A hacker without administrative access to a network could construct a Trojan
horse program that could be sent in e-mail to an unsuspecting user. If the user, while logged on with
administrative rights, ran the attachment in e-mail, the program could silently dump the SAM database and e-mail
the text file to the hacker. (I received mail recently with an attachment that said "click here." I’ll give you one
guess what the chances are of my clicking on an unknown e-mail attachment; exactly zero). Once a hacker has
the output of PWDump, they still don’t have any passwords. Remember that the MD4 hashing algorithm
theoretically cannot be reversed. NTCrack is the program of choice for brute force attacks against a list of
password hashes. NTCrack can take all the words in the English language, as well as play sophisticated games
for variations with numbers and case sensitivity, and in several hours on an average Pentium machine, generate all
the possible hashes for about a million words and phrases. It then just matches the hashes on file with the hashes
retrieved from PWDump, and looks to see which password generated that hash. NTCrack is only useful because
users tend to choose passwords that are easy to remember. If NTCrack had to brute force attack all the possible
password hashes for Windows NT’s maximum password length of 14 characters (including numbers, symbols,
and case sensitivity), the search it would take several thousand million years using a Pentium 120. (I don’t know
if anyone has calculated how long it would take on a Pentium Pro, but I think we’re safe for a little while.) If you
would like more information on security issues, search the Internet for NTCrack or PWDump. I personally enjoy
using NTCrack on my own system to ensure that the password list is secure and that my users are choosing good
I hope you now have a better idea of Windows NT security issues that affect Web site development. This subject
comes up the most frequently on sites that use authentication and deliver dynamic database driven content. In this
article I've tried to look at just the underlying foundations of security and delegation. Future articles will begin to
build on this understanding, and discuss more specific configuration issues and problems. If you have a good
understanding of what IIS is doing to get its job done, you’ll be much more able to get your job done.
ASP / Visual InterDev Training Lead
Microsoft Internet Developer Support