This article describes the Authentication & Security Features of Microsoft Internet Information Server.
Integration with Windows NT
The World Wide Web (WWW), Gopher, and FTP services included with the Microsoft Internet Information Server are fully integrated with Windows NT Server user accounts and file access permissions.
Every access to a resource (for example, a file, an HTML page, an Internet Server API (ISAPI) application, etc.) is done by the services on behalf of a Windows NT user. The service impersonates the user by supplying a username/password pair in the attempt to read/execute the resource for the client. IIS starts the process using the CreateProcessAsUser System API.
The Windows NT File System (NTFS) allows Access Control Lists (ACLs) to be assigned to files and directories. ACLs grant and/or deny access to the associated file or directory by specific Windows NT user accounts, or groups of users. When an Internet service attempts to read or execute a file on behalf of a client request, the user account offered by the service must have permission, as determined by the ACL associated with the file, to read or execute the file, as appropriate. If the user account does not have permission to access the file, the request fails, and a response is returned, informing the client that access has been denied. File and directory ACLs are configured using the Windows NT File Manager.
Anonymous Connections
An anonymous connection is processed when a client request does not contain a username and password. This occurs in the following cases:
- An FTP client logs on with the username Anonymous.
- All Gopher requests.
- A WWW (HTTP) request's headers do not contain a username and password.
Each Internet service maintains a Windows NT username and password to be used for the processing of anonymous requests. When an anonymous request is received, the service impersonates the user configured as the anonymous-logon user. The request will succeed if the anonymous-logon user has permission to access the requested resource, as determined by the resource's ACL. For WWW only, if the user does not have permission to access the resource, the response returned to the client contains a list of supported authentication schemes for gaining access to the resource.
The anonymous-logon user account can be viewed and modified on the Service property page of the Internet Service Manager. Multiple Internet Information Server services running on the same computer can use the same, or different anonymous-logon user accounts. Including the 'anonymous logon' user account in file or directory ACLs allows for precise control of the resources available to 'anonymous' clients.
The anonymous-logon user account specified must be a valid Windows NT user account on the server computer, and the password specified must match the password for this user in the computer's user database. User accounts and passwords are configured using the Windows NT User Manager.
When the Internet Information Server product is installed, Setup creates a user account on the server computer to be used for anonymous connections. The username of this account has the form IUSR_<computer_name>. For example, if the server computer name is MATLUS, the username created will be IUSR_MATLUS. The same anonymous-logon user account is set up for all Internet Information Server services installed on the computer. The account is made a member of the computer's Guest group. This will, in most cases, give anonymous client requests access to public content published on the server. Run the Control Panel/Network applet to see the computer name configured for the Windows NT Server computer.
A randomly generated password is created for the IUSR_ account. For maximum convenience and security, we suggest that you change the password associated with this account to a password that you will remember, but is not easily guessed. To do this, you must specify the new password for the account in User Manager, and on the Service page of the Internet Service Manager for each Internet Information Server service installed.
When the Internet Information Server is installed on a primary or secondary domain controller, the anonymous-logon user account is created in the user account database of the domain. When Internet Information Server is installed on a domain member-server, or a stand-alone server, the account is created on the local machine.
If Internet Information Server is installed on multiple domain controllers of the same domain, a separate user account is created in the domain user database for each Internet server computer. This does not cause any conflicts since each username is unique, containing the name of the associated computer.
However, you may find it more convenient to create a single anonymous-logon user account in the domain to use for all Internet Information Server domain controllers in the domain. This can simplify administration of ACLs.
Client Requests Containing Credentials
A request containing credentials is one of the following:
- An FTP client logs on with a valid Windows NT username and password. This requires that the FTP service checkbox labeled Allow Only Anonymous Connections be unchecked. WARNING: FTP sends passwords across the network in clear text.
- A WWW (HTTP) request's headers contain a username and password. This is HTTP Basic Authentication.WARNING: HTTP Basic Authentication sends passwords across the network in clear text.
- A WWW browser supports NTLM (Windows NT native) authentication, and an anonymous client request is denied access to a resource. In this case, the browser automatically sends the Windows client's username and password to the Internet Information Server Web server using the encrypted NTLM protocol. Currently only IE browser 2.0 and above support NTLM authentication.
When an Internet Information Server service receives a client request that contains credentials (a username and password), the anonymous-logon user account is not used in processing the request. Instead, the username and password received by the client are used by the service. If the service is not granted permission to access the requested resource while impersonating the specified user, the request fails, and an error notification is returned to the client.
For WWW (HTTP) only, when an anonymous request fails because the anonymous-logon user account does not have permission to access the desired resource, the response to the client indicates which authentication schemes the service supports. This is determined by the configuration of the WWW service authentication features. If the response indicates to the client that the service is configured to support HTTP basic authentication, most Web browsers will pop up a username/password dialog box, and reissue the anonymous request as a request with credentials, including the username and password entered by the user.
If a Web browser supports NTLM authentication, and the Web service is configured to support NTLM authentication, an anonymous WWW request failing due to permissions, will result in automatic use of the NTLM protocol to send a username and encrypted password from the client to the service. The client request will then be reprocessed, using the client's user information. The user account obtained from the client is that with which the user is logged into the client computer. As this account, including its Windows NT domain, must be a valid account on the Web server machine, NTLM authentication is most useful in an intranet environment, where the client and server machines are in the same, or trusted domains. Internet Explorer for Windows 95/98 is the only browser that supports NTLM authentication.
Internet Service Manager Authentication Options
In addition to the anonymous-logon username and password fields, the Internet Service Manager Service property page contains the following authentication options:
For WWW:
- Allow Anonymous. When this check box is checked, anonymous connections are processed, and the anonymous-logon username/password are used for these connections. When this checkbox is unchecked, all anonymous connections are rejected. In this case, basic or NTLM authentication can be used to access content.
- Basic Authentication When this check box is checked, the Web service will process requests using basic authentication. WARNING: Basic authentication sends Windows NT usernames and passwords across the network without encryption. This checkbox is unchecked by default for security reasons.
- Windows NT Challenge/Response. When this check box is checked, the service will honor requests by clients to send user account information using the Windows NT Challenge/Response (NTLM) protocol. This protocol uses encryption for secure transmission of passwords. The NTLM authentication process is initiated automatically as a result of an 'access denied' error on an anonymous client request. Currently, NTLM authentication only works with Internet Explorer 2.0 and above.
How NT Challenge/Response works
IIS supports Microsoft Windows NT Challenge/Response authentication, which identifies users without requiring the transmission of actual passwords or account information across a network. Instead, the Web server authenticates users by carrying out a procedure that challenges the user's Web browser to carry out a specific mathematical computation involving the password and to respond by returning the results of the computation to their Web server.
Next, your Web server duplicates this computation using the user's account password information, and compares this result to the user's result. If both results match, your Web server recognizes that the user has the correct password and grants access.
Your server will not switch to another authentication method if the user is initially denied access. Instead, the user's Web browser will prompt the user for a user name and password, which the browser will process and send to your Web server as part of the Windows NT Challenge/Response authentication protocol. If this second authentication attempt fails, the user will be denied access to the Web server.
You will find Windows NT Challenge/Response authentication useful in an Intranet environment only, where both user and Web server computers are in the same, secure domain. Additionally, you can only use Windows NT Challenge/Response to authenticate users that logon with Web browsers capable of supporting this method. Currently, Microsoft Internet Explorer version 2.0 or later is the only Web browser that supports Windows NT Challenge\Response.
For FTP:
Allow Anonymous Connections. When this check box is checked, FTP logons in which the user enters a username of 'anonymous' will be processed. These anonymous connections will be processed on behalf of the Windows NT user account specified on the Service property page. When this check box is unchecked, users will be required to enter valid Windows NT usernames and passwords to log on to the FTP service.
- Allow only anonymous connections. When this checkbox is checked, user logons with a username other than anonymous will be rejected. WARNING: FTP User names and passwords are sent across the network in clear text. When this check box is unchecked, Windows NT passwords will be sent to the server without encryption. This check box is checked by default for security reasons.
Other Authentication Issues
SSL:
SSL is a WWW feature that supports data encryption and server authentication. All data sent to or from the client using SSL is encrypted. If HTTP basic authentication is used in conjunction with SSL, the username and password are transmitted after being encrypted by the client's SSL support
'INTERACTIVE' and 'NETWORK' Users
If you use the predefined Windows NT user accounts 'INTERACTIVE' and 'NETWORK' for access control, your use of these accounts may affect client access to some resources. In order for a file to be accessed by anonymous client requests or client requests using basic authentication, the requested file must be accessible by the INTERACTIVE user. In order for a file to be accessible by a client request using NTLM authentication, the file must be accessible by the NETWORK user.
Log On Locally User Right
In User Manager, when configuring a Windows NT user account to be used either as the Internet Information Server anonymous-logon account, or as a user account specified by client requests using HTTP basic authentication, be sure that the user account is granted the 'Log on locally' user right. This is specified in User Manager's Policies menu.
Customized Authentication
If you need a WWW request authentication scheme not supported by the service directly, you need to build an ISAPI filter to do the job. ISAPI Filter Authentication methods can perform a superior authentication scheme that is customized to suit the specific needs of an Enterprise. This article does not go into the details of developing an ISAPI filter DLL, but will leave this topic for later.
Digest Authentication
Digest Authentication is new to Windows 2000 and Internet Information Services 5.0. This form of authentication encrypts the user's password information, and provides a mechanism for aiding in the prevention of some common server attacks (such as a replay attack).
In order to use Digest Authentication in Windows 2000, the server must have access to an Active Directory Server that is set up for Digest Authentication.
If the server running IIS is not a Active Directory Server, or does not have access to the Active Directory, this authentication will not work. For more information about making the server a Directory Server, see the Windows 2000 documentation.
If the server is already a Directory Server, perform the following steps:
- Open the Active Directory Users and Computers.
- Open the domain that you want to administer.
- Double-click the user name that you want to use with Digest Authentication.
- In Account Options, select Store password using reversible encryption.
- Click OK.
- Reset the user's password now in order for the encryption to take place. To reset the user's password, right-click the user name in the directory and click Reset Password.
- Click OK.
In order for Internet Information Services 5.0 to use Digest Authentication, you must select it in Internet Service Manager. To do this, perform the following steps:
- Open Internet Services Manager.
- Expand the Web server that you want to make the change in, and then open the Web site's properties.
- Click the Directory Security tab.
- Under Anonymous Access and Authentication Control, click Edit.
- Select Digest Authentication from the list, and then click OK,
Basic Authentication Scheme
The "Basic" authentication scheme is based on the model that the user agent must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server. The server will authorize the request only if it can validate the user-ID and password for the protection space of the Request-URI. There are no optional authentication parameters.
Upon receipt of an unauthorized request for a URI within the protection space, the server should respond with a challenge like the following:
WWW-Authenticate: Basic realm="DelphiTutorials"
where "DelphiTutorials" is the string assigned by the server to identify the protection space of the Request-URI.
To receive authorization, the client sends the user-ID and password, separated by a single colon (":") character, within a base64 [5] encoded string in the credentials.
basic-credentials = "Basic" SP basic-cookie
basic-cookie =
userid-password = [ token ] ":" *TEXT
If the user agent wishes to send the user-ID "skumar" and password "Delphi", it would use the following header field: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
The basic authentication scheme is a non-secure method of filtering unauthorized access to resources on an HTTP server. It is based on the assumption that the connection between the client and the server can be regarded as a trusted carrier (such as SSL). As this is not generally true on an open network, the basic authentication scheme should be used accordingly. In spite of this, clients should implement the scheme in order to communicate with servers that use it.
Security Ramifications for IIS Applications
Anonymous Authentication
Setting Anonymous Authentication in IIS Manager means that IIS will not use any HTTP authentication mechanism to control access to resources on the machine. By default, when IIS is installed, it creates a user account called IUSR_<servername>, where <servername> is the name of the server on which IIS is running. This user account is added to the "Guests" group on the machine, which implies that its access to resources is limited. When an HTTP request is received by IIS with Anonymous authentication being used, IIS will impersonate the IUSR_<servername> account in order to execute any code or access any files that are involved in the request. This allows a level of security by limiting the accessibility to such things as system files by an unauthenticated user. IIS is able to impersonate the IUSR_<servername> account because the username and password credentials for this account are known by IIS.
You can change the account that is used for anonymous authentication in Internet Service Manager. You can also change the security privileges for the IUSR_<servername> account in Windows NT User Manager. Be aware that any changes will result in changes to every anonymous HTTP request that is serviced by IIS. Also note that if the anonymous account configured in Internet Manager does not have the "Log On Locally" right (not a right given to "Guest" accounts by default on domain controllers), then IIS will not be able to service any anonymous requests. The IIS installation specifically gives you the "Log On Locally" right to the IUSR_<servername> account.
Most resources, such as the IUSR_<servername> account, that allow Guests to access them, do so by allowing access to the special group "Everyone." You can set permissions on files and other resources specifically to allow or disallow the IUSR_<servername> account to access them, but most people end up managing access by controlling access to the groups "Everyone" or "Guests."
Basic Authentication
Basic authentication is a scheme that causes the client to be prompted for a Username and Password that are then Base64-encoded and passed to IIS. IIS receives the username and password credentials and verifies them against the Windows NT-user database on the machine or the applicable domain controllers in any trusted Windows NT domains. If the credentials are valid, IIS will impersonate the specified user when allowing access to resources by IIS or any applications that the request is launching. Thus, the application that is being executed, whether it is an ISAPI extension a DLL, a CGI application, or a scripting mechanism, will be executed with the permissions of the corresponding user account passed by the Basic authentication.
Because Basic authentication provides the username and password credentials to IIS, access to items that require credential knowledge can successfully be performed when using Basic authentication. For example, if an ISAPI application mapped a drive letter across a network, then it would require knowledge of the current user's credentials. Because IIS is given the username and password credentials as part of Basic authentication, this task will succeed if the account specified has access to the network resource.
Windows NT Challenge/Response Authentication
Windows NT Challenge/Response authentication (often called NTLM authentication) is the most secure form of authenticating a user because the username and password are not sent across the wire. Rather, the Windows Security Provider interface is used to provide an encrypted challenge/response handshake mechanism that is functionally unbreakable. The Windows security provider interface allows IIS to validate and impersonate the user. Unlike Basic authentication, NTLM authentication does not prompt users for their user name and password by default. The current Windows user account on the client machine is used for the NTLM authentication. Then, if this fails, it will prompt the user for the username and password to be used. If NTLM authentication succeeds, the requested application or resource is executed in the context of the specified user.
Because of the one way encryption is used, NTLM authentication validates the user for IIS without providing knowledge of the user's password to IIS. Therefore, a full set of username and password credentials is not available to IIS for doing such tasks as mapping a network drive. If an ISAPI application calls WNetAddConnection2 without specifying a username and password, it will fail under NTLM authentication.
Multiple Authentication Schemes Selected
You can select any combination of Anonymous, Basic, and NTLM authentication in Internet Manager. If Anonymous authentication is checked, the request will try to be handled without any actual authentication and IIS will execute the request in the context of the IUSR_<servername> account. If, for some reason, the IUSR_<servername> account does not have access to the resource, IIS will send back an access-denied error to the client indicating that the client needs to use one of the other authentication schemes. This scenario could occur if you limited access to the actual ISAPI DLL file to a specific user, such as User1. IIS would receive the initial anonymous request and attempt to launch the ISAPI DLL under the IUSR_<servername> user context, only to get an access-denied error from the NTFS file system. IIS would respond to the client with a message saying that access was denied and the client needs to submit the request using either the Basic or NTLM authentication schemes (depending on which one is enabled, possibly even both). The client can then resubmit the request with the Basic authentication credentials or with the initial NTLM challenge/response sequence. If either of these responses provides validation of the User1 account, then IIS will impersonate the User1 account and successfully launch the ISAPI DLL.
It is worth noting that if both NTLM and Basic authentication schemes are checked, IIS responds to requests indicating that both schemes are acceptable. It is up to the client to determine which authentication schemes it supports and to respond appropriately. For browsers, such as Internet Explorer, which support both Basic and NTLM Authentication, they will respond using the first supported authentication scheme indicated by IIS. On IIS 1.0, when both Basic and NTLM authentication schemes were checked, Basic authentication was listed first. On IIS 2.0, NTLM is now listed before Basic. The result is that for a server running IIS 1.0 using both, Internet Explorer will use Basic authentication. For an IIS 2.0 server using both, Internet Explorer will use NTLM authentication. Many IIS applications access resources provided by other software components. For instance, an ISAPI extension DLL may call an OLE automation server from a third-party software company, or a CGI application. These components may have persistent information stored in the registry that they require in order to execute properly. For standard desktop use of these components, the registry information is read from the profile of the user currently logged on the Windows NT machine. These applications often have problems when launched by IIS because the profile made available to an IIS application is that of the "default user." The default-user profile is filled with information generic to all users, but, unfortunately, is specific to no users. Therefore, a component may run as expected when User1 executes it interactively on his or her desktop because it is reading information from User1's profile in the registry. The same application may not run at all from IIS because it will not have access to User1's profile. This is true even if IIS is impersonating User1's account using Basic or NTLM authentication.
Desktop Issues
Windows NT uses the concept of having multiple desktops on the same machine. A desktop can be thought of as the screen that you view when you are logged on an NT machine. Your desktop receives all the mouse and keyboard messages that you create as the user in front of the machine, and it allows for applications to interact with one another to a certain extent. For instance, one application on a desktop can post messages to other applications on the desktop. NT supporting multiple desktops implies that there are other desktops running; you just can't see them and you have no way of sending keyboard or mouse messages to them. This may seem like a futile concept, but, in fact, many applications that run as Windows NT Services require the capabilities that a desktop provides yet don't want to interact with the interactive user's desktop. Therefore, each service gets its own desktop that won't be interfered with by the currently logged-on user.
The implications of this to IIS applications are that the IIS service has its own desktop. If your IIS application interacts with a desktop in any way (for instance, if it displays a message box), then it will display that message box on a desktop that cannot be seen on the computer's monitor. Similarly, an IIS application will not be able to send or post messages to an application on the interactive desktop. If your IIS application needs to interact with the interactive desktop, then you should use another form of inter-process communication such as named pipes.
ISAPI Filter DLLs
ISAPI Filter DLLs, not to be confused with ISAPI Extension DLLs, run in the original context of the IIS service. All services run by default under the Local System account of the machine on which they are installed. The Local System account has access to almost all resources on the local machine not specifically denied to it, and no resources on any other machines on the network.
COM and OLE Permissions
Launching an OLE or COM object on an NT 4.0 machine requires certain permissions. This is normally not an issue for most interactive users because the default permissions for launching and accessing OLE and COM objects on an NT machine allow access to anyone logged on the local machine interactively. An IIS application, whether it is running in the context of the IUSR_<servername> account or an impersonated user account from Basic or NTLM authentication, is *NOT* interactively logged on. Therefore, the default permissions for launching and accessing OLE and COM objects will not allow an ISAPI extension DLL, CGI application, or Internet script to launch these objects successfully by default.
The utility DCOMCNFG on Windows NT 4.0 allows you to set the default permissions for *ALL* COM and OLE objects on your machine. You can use this utility to provide OLE and COM access to the IUSR_<servername> account as well as all user accounts that might be impersonated by your IIS configuration. You can even grant permissions to the "Everyone" group.
However, providing global access to all OLE and COM objects may not be in your best interest, so DCOMCNFG will also allow you to specify permissions for specific applications so you could provide access to only the applications you will need to access from your IIS application. OLE and COM applications also have the ability to determine what permissions are associated with launching and accessing themselves. To do this from inside your OLE or COM server, see the CoInitializeSecurity function new to Windows NT 4.0, as well as CoCreateInstanceEx (in particular, the COSERVERINFO and COAUTHINFO structures) for manipulating OLE access from the client side.
Distributed COM (DCOM), also referred to as Remote Automation, requires all of the OLE/COM permissions discussed above. In addition, it needs to access resources across the network. If a request is received using Anonymous authentication, the IUSR_<servername> account username and password credentials will be used to connect to the remote DCOM server. Unless your IIS server machine is also a domain controller, the remote machine by default will not know who the IUSR_<servername> account is (it only exists on the local IIS server machine). Adding access and launch permissions to the group "Everyone" does not help in this case because DCOM will not map access by an unknown account to the guest account in the same way that the Lanman Server service does for file sharing. The DCOM server machine must explicitly know the account that is being used.
To deal with a scenario where you have IIS applications accessing resources (including DCOM resources) on remote machines, you need to have all the machines involved participate in a domain relationship. Then, in Internet Manager, you can change your anonymous account to an account in the local or trusted domain. Now, all machines in the domain structure will recognize the account and can explicitly add/delete access to their network resources for that account or any group that account is a member of.
Be aware that if Basic authentication is used for an IIS request, access to network resources (including DCOM servers) will be done in the context of the user whose credentials were passed with the request. If the user specified does not have permissions to launch or access the DCOM server, the request will fail.
If the IIS request is validated using NTLM authentication, the impersonation level does not imply knowledge of the username and password credentials. Therefore, access to network resources, regardless of the permissions on the resource, will be denied (with the exception of NULL Session resources).
