\[Editor's Note: Email your IIS-related solutions (400 words or less) to R2R at [email protected]. We'll edit submissions for style, grammar, and length. If we print your contribution, you'll get $100.\]
By default, the IIS installation creates the iisadmpwd directory in \%systemroot%\system32\inetsrv. This directory contains nine .htr (really just Active Server Pages—ASP) files that let users change their Windows NT passwords. Users must access these files as a secure resource (using HTTP over Secure Sockets Layer—HTTPS) for them to work properly. (In July 1999, Microsoft released a security bulletin about malicious users possibly using .htr files to execute arbitrary code on a server. You can find information about this risk and a patch at http://www.microsoft.com/technet/security/ bulletin/ms99-019.asp.)
Here's a list of each of the nine files and their respective functions:
- Aexp.htr —Password has expired. This file forces users to change their passwords and then allows a redirect to the resource the users are attempting to access. The file first checks to see whether the users' browsers are HTTPS capable; if they aren't, it displays a password expired message and then errors out.
- Aexp2.htr—User-initiated password change. When users complete the password change, this file redirects them to the resource they're attempting to access. The file uses HTTPS to post the form.
- Aexp2b.htr—This file is the same as aexp2.htr, except that it also has a Domain dialog box.
- Aexp3.htr—Password has expired. The file forces users to change their passwords before continuing. This file is the same as aexp.htr, except that it doesn't check whether the browsers support HTTPS.
- Aexp4.htr—This file is the same as aexp2.htr, except that it doesn't use HTTPS to post the form.
- Aexp4b.htr—This file is the same as aexp2b.htr, except that it doesn't use HTTPS to post the form.
- Anot.htr—This file alerts users that they have xx days until password expiration, then prompts users to change passwords (if they do, the file sends the users to aexp2.htr).
- Anot3.htr—This file is the same as anot.htr, except that it sends users to aexp4.htr.
- Achg.htr—This file displays a message if an error occurs while the users are changing their passwords (e.g., the new password and confirmation password don't match; the new password doesn't meet the required password restrictions for your domain).
All these files are plaintext, and you can edit them to make them look cleaner or fit the feel of your intranet, extranet, or whatever they're running on. (Note: Be sure to back up the ASP files before you edit them.) Keep in mind that IIS requires the virtual directory iisadmpwd for this functionality to work. This functionality works well with both NT Challenge/Response authentication and Basic authentication, but if you use Basic authentication on an Internet-accessible server, you really should use Secure Sockets Layer (SSL).
For more information about the iisadmpwd directory and changing passwords, see the following Microsoft articles:
- "How to Change Windows NT Account Passwords Using Internet Information Server (IIS) 4.0" (http://support.microsoft.com/support/kb/articles/q184/6/19.asp)
- "How to Configure the IISADMPWD Pages for Different Ports" (http://support.microsoft.com/support/kb/articles/q240/6/54.asp)
—Chris Lehr
[email protected]
Toggling Kerberos in IIS 5.0
In IIS 5.0, Microsoft changed the authentication methods available for your intranet or extranet. One change is that Windows NT Challenge/Response authentication now has a new name—Integrated Windows authentication. Instead of transmitting usernames or passwords, Integrated Windows authentication can use either Kerberos 5.0 authentication's Negotiate headers or its own challenge/response protocol.
You can configure a site's settings to communicate that it supports Kerberos as an alternative to traditional NTLM authentication. This setting is part of the NT Authentication Providers property, which exists in the IIS metabase. By default, when you upgrade a site from IIS 4.0 to IIS 5.0, that site won't support Kerberos. If you attempt to set Kerberos operation on a site residing on a server you've upgraded to IIS 5.0, the NT Authentication Providers property will prevent Kerberos from functioning.
Alternatively, if you perform a clean installation of a Windows 2000 (Win2K) server with IIS 5.0 and create a site on that server, that site automatically notifies you that Kerberos is an option. However, if your environment doesn't support Kerberos authentication, you can (for performance reasons) turn off the Kerberos negotiation for your server.
The metabase entry \w3svc\NTAuthenticationProviders controls what your site sends to clients for supported authentication methods under Integrated Windows authentication. When you set this key to Negotiate.NTLM, a Microsoft Internet Explorer (IE) 5.0 or later client assumes that your server supports Kerberos authentication. If the client's environment also supports Kerberos, the browser will attempt to use it to for authentication. If you enter NTLM, this informs clients that the server supports only NTLM for Integrated Windows authentication.
You can toggle the Negotiate value by using a command prompt window to edit the IIS metabase. In the command prompt window, change to the C:\inetpub\adminscripts directory. To check the value of the Authentication Provider key, enter
cscript adsutil.vbs get w3svc/NTAuthenticationProviders
To change the value of the key, enter
cscript adsutil.vbs set w3svc/NTAuthenticationProviders _ "key value"
In the preceding command, replace the string key value with either NTLM or Negotiate.NTLM. Include the quotation marks, but delete any embedded spaces in the value. The Microsoft article "Kerberos Authentication Fails After Upgrading from IIS 4.0 to IIS 5.0" (http://support.microsoft.com/support/kb/articles/q248/3/50.asp) explains changing this value in more detail.
—William Sheldon
[email protected]
