Authentication and Security
For Internet Developers
Scott Stabbert
Internet Developer Support
Microsoft
Introduction
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 troubleshooting.
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.
Impersonation
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 user.
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 components (DLLs).
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”) = “200.200.157.4” then
Response.Buffer = TRUE
Response.Status = ("401 Unauthorized")
Response.End
End If%>
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 access.
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.
Client Server
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!
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).
Basic Authentication
Most people are afraid to use the Basic authentication option because of the screen they are confronted with when activating it:
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 "policies" menu.
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.
UNC Paths
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”).
Delegation, NOT!
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 information.
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.
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 domain route.
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 happen:
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 passwords.
Final Word
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.
Happy programming!
Scott Stabbert
ASP / Visual InterDev Training Lead
Microsoft Internet Developer Support
|
