IIS Informant

I installed Windows 2000 Service Pack 2 (SP2) 128-bit encryption on a new server, and I'm trying to set the option to change passwords through Microsoft Internet Information Services (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 Internet Information Server (IIS) 4.0. I used Robocopy to copy the content to the new server, and I used 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 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, let me say 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 infamous .htr files that let users change passwords for their user accounts over the Internet. (I say infamous 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.

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, which you seem to have encountered, exists with IIS 5.0. 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, a hotfix is available for this bug. Contact Microsoft Product Support Services (PSS) at http://support.microsoft.com/directory/overview.asp for the hotfix.

How can I determine the password for the IUSR_computername and IWAM_computername accounts that Microsoft IIS installation creates?

These accounts' passwords reside in the user account database (i.e., the SAM) on Windows 2000 (without Active Directory—AD) and Windows NT 4.0 or in AD on Win2K domain controllers (DCs). As a result, obtaining passwords from those data stores is a severe breach of security. Although you can obtain those passwords by using a few tools, you don't have to work that hard because the passwords also reside in the metabase. Enter the script that Listing 1 shows in a text editor such as Notepad, then save the script as getpass.vbs (any name will do as long as it ends in .vbs). When you execute the script, you'll see the username and password of the default IUSR_computername and IWAM_computername accounts.

   Previous  [1]  2  Next