I installed Windows 2000 Service Pack 1 (SP1) 128-bit encryption on a new server, and I'm trying to set the option to change passwords through IIS 5.0. The Win2K server is a member of a Windows NT 4.0 domain. The installation also consists of migrated content from another server running IIS 4.0. I used Robocopy to copy the content to the new server and Addusers to replicate the user accounts. I added the virtual directory for Iisadmpwd in the Default Web site. I've enabled Basic and Integrated Windows authentication and required 128-bit Secure Sockets Layer (SSL) connections. When a user accesses the site, the site asks for the user's username and password, accepts them, and seems to work. The account, however, is marked must change password at next login, so the server brings up the page for an expired password and correctly prompts the user to change his or her password. When the user submits the change, the server immediately prompts the user again to change the password. Why doesn't the password change?
Migrating from IIS 4.0 to IIS 5.0 is quite a task, and you've used a methodology that I often recommend. Your migration and 128-bit encryption shouldn't be causing problems. However, before I talk about a solution, I want to repeat that I don't recommend that you let users change passwords to Win2K or NT 4.0 accounts over the Internet unless you're using a VPN. Changing passwords over the Internet isn't a good idea for two reasons. First, having that kind of doorway open to anyone who can find it is a security risk. Second, the only way you can use a browser to effectively authenticate over the Internet is to set Basic authentication, which requires SSL to be secure. Therefore, authentication over the Internet requires constant diligence to maintain security. In addition, when you've authenticated with Basic authentication, you can't turn off SSL because the server sends credentials with each request for a file. As you discovered, when you perform a clean installation of IIS 5.0, the Iisadmpwd virtual directory, which contains the files that let users change passwords, isn't present as it was in IIS 4.0.
Nevertheless, the required files are loaded onto the IIS 5.0 server, and you can manually create the Iisadmpwd virtual directory and map it to \%systemroot%\winnt\system32\iisadmpwd. In that virtual directory, you'll discover the legendary .htr files that let users change passwords for their user accounts over the Internet. (I say legendary because the .htr files have been the subject of more than one Microsoft security bulletin. My bias is that when a particular feature has been nailed a few times as a security problem, that feature is more likely than other parts of the server to turn up further problems.)
If you don't manually create the Iisadmpwd virtual directory, the .htr files are still present on your server and make a potential target to malicious users. I suggest removing the .htr files and the Application Mapping feature in IIS 5.0, which maps the .htr files to C:\winnt\system32\inetsrv\ism.dll. (See "For More Information" for resources about using IIS to change passwords.)
In addition to manually creating the Iisadmpwd virtual directory (or otherwise providing access to it), you must make a change to the metabase. Set the value in the metabase for w3svc/<n>/passwordchangeflags, where <n> is the instance number for the Web site:
- 0—Password changes require an SSL connection.
- 1—Password changes don't require an SSL channel.
- 2—Password change notification is disabled.
- 4—Advanced notification of password change is disabled.
You can use MetaEdit or scripting with Microsoft Active Directory Service Interfaces (ADSI) to set this value.
Aside from security problems with changing passwords over the Internet, at least one operational difficulty with IIS 5.0, which you seem to have encountered, exists. Because IIS 5.0 manages the password-change process differently than IIS 4.0 does, if you don't allow Anonymous access to the Iisadmpwd virtual directory, you wind up in an infinite loop. (Clearly, Anonymous access to the password-change files isn't a great idea.) Fortunately, this bug has a hotfix available. Contact Microsoft Product Support Services (PSS) at http://support.microsoft.com/directory/overview.asp for the hotfix.
|FOR MORE INFORMATION|
Microsoft has some helpful information about using IIS to change user account passwords. Here are a few resources to get you started:|
For details about the Infinite Loop hotfix, see the Microsoft article "IIS May Loop Infinitely When a User Is Forced to Change Their Password" (http://support.microsoft.com/support/kb/articles/q275/4/57.asp).
For information related to difficulties that cached passwords cause, see the Microsoft article "Changing the Default Interval for User Tokens in IIS" (http://support.microsoft.com/support/kb/articles/q152/5/26.asp).
For information about changing the PasswordChangeFlags metabase property for IIS 4.0, see "How to Change the PasswordChangeFlags Metabase Property" (http://support.microsoft.com/support/kb/articles/q209/3/89.asp).
For information about changing the PasswordChangeFlags Metabase property for IIS 5.0, see the IIS 5.0 online documentation.