IIS Insider - April 2003

  • Article

By Brett Hill

What Triggers the IUSR Password to Expire?

Q: I ran into a problem on our IIS 5 servers where anonymous access began to fail. The event log showed that that the IUSR password had expired. What triggers the IUSR password to expire? Is it configured to expire by default?

A: The anonymous user account has the properties Password never expires and User cannot change password configured by default. This is true for both stand-alone and domain controllers. Consequently, the password will not expire unless some action is taken on the account that changes those settings. This could happen if a security policy has been applied to the server that enforces password expiration. Most likely an administrator either created a new anonymous user account or set the account to expire not realizing its special purpose. (I have had security administrators tell me that the IWAM account was not required for IIS and could be deleted) Also, a security script enforcing a set of password policies could have been run that reset account policies for all users, including the anonymous user. You may want to enable auditing for Account Management and Policy Change in order to determine what action is changing these settings.

Only One Web Site Returned For Multiple Domains (Using Host Headers)

Q: We are running IIS 5.0, Windows 2000 Advanced Server. In providing web sites for multiple domain names using host headers that all share the same IP address, IIS will return to IE or any web browser only one web site for all domains regardless of the host header being used. DNS is set up properly as we can ping any of the domain names in question and the proper IP address is returned. The web sites properties are set to use all unassigned IP addresses on port 80 with host headers. The home directory path for each site is unique. Why is only one web site returned on all virtual web sites?

A: When I encounter a problem where it seems like everything is correctly configured, but still it doesn't work - I stop for a moment and start with the big picture. There are generally two types of issues: configuration errors or server problems. The task at hand is to try your best to determine which class of problem you are seeing, and to do so expeditiously.

The first thing to consider is the history of this particular application (IIS) with the feature (host headers). Using Host Headers with IIS 5 is proven to be a very solid feature and extremely reliable. The vast majority of problems I've noticed are configuration problems. Consequently, I would focus on eliminating a misconfiguration issue before assessing the possibility of something more problematic, like Metabase corruption.

Of course, the exact symptom you are describing is what would happen if you were using SSL in combination with host headers. You cannot use SSL with host header based web sites when you are using the host header to identify the site.

Assuming SSL is not in use, the next thing I would do is to remove the all unassigned setting from all the web sites and associate them with the correct IP address. This eliminates the possibility that the DNS IP address is pointing to a different address, as no web site will respond if that is the case. As a general rule, I avoid the use of the all unassigned setting for IP addresses, as it can cause web sites to start or stop responding depending on the how other web sites are configured. It's better to be explicit about the addresses you want the sites to use.

When all your web sites are configured to use host headers, no web site will respond when you use the IP address. Instead, you'll get the message No web site configured at this address. Consequently, the next test is to check for this behavior - launch Internet Explorer and access the web server by IP address rather than a FQDN. (Instead of using https://yourservername, use https://<IIS IP ADDRESS>.) If you get a web site response, then examine closely the configuration of that site (as it should not have responded when only an IP address is provided).

The IIS user interface works in such a way that this particular misconfiguration occurs more than it should.

If your browser does not support inline frames, click here to view on a separate page.

When configured as shown above, the web site will respond to the IP address and the host header is effectively not used. This occurs because when you first open the Advanced Multiple Web Site Configuration window (Web Site properties, Web Site, Advanced), the only button enabled is Add. Instead of pressing Add, select the existing entry of (All Unassigned) 80 and then click on Edit. Verify that the Advanced Identity tab of all your web sites is properly configured.

The next test may not be feasible if you have a large number of sites. Presuming you can, stop all the web sites except for one, and try to access that web site by name and IP address. The IP address should fail and the name should succeed. If that works, then stop the one you just tested and start another, and test it. Repeat this process until you have verified that each works correctly. If at any time, one responds to the IP address, that site is either not working correctly or is misconfigured.

In the event that all your sites are configured correctly, but it is still not working properly, then we move to the category of troubleshooting system problems. Unfortunately, these are generally more drastic measures.

You can try one or both of the following:

  • Browse the Metabase with MetaEdit 2.2 and look for obvious Metabase corruption
  • Delete and recreate any site that is not behaving as expected

If both fails, contact Microsoft Product Support Services.

What You Can Do If Your IIS Server Has Been Successfully Attacked

Q: I recently discovered that my IIS was successfully hacked. I set up the System Audit on Sunday afternoon and found that somebody logged onto my computer on Monday morning (1 AM). I found that the Hacker had made several modifications to the users on my system.

I found that Guest logons had been activated. Guest and IUSR accounts had been added to Administrators, as well as several other changes to user rights and enabling the remote registry service. I fixed all of these things and set up auditing on the server and have seen no other suspicious activity. Will the hacker still be able to gain any privilege to access the system?

A: I'm sorry to be the bearer of bad news, but the best advice I can give you and anyone else who has had their system breached to this level is to reformat the drive and start again. The strategy of fixing the things you have identified has two big problems.

First, you are presuming that you've found all the changes the attacker had made to the system (which is almost impossible unless you have a moment by moment log of all file and network activity). It is possible that the attacker installed a Trojan, keyboard logger, or administrative console that you have not identified. Some of the more recent hacks include kernel mode drivers that appear like part of the operating system (it is very difficult to detect by even a trained eye).

Secondly, the attacker may already have accessed privileged information such as user names and passwords, even if you did fix everything. They may have created a location in the file structure that grants them full control buried deep in the file tree and can log on with names they created or passwords cracked.

You should immediately check any other computer that connects to the IIS server. Domain controllers are the first order of business as well as any other servers (i.e. SQL, Exchange, IIS) the IIS server communicates with. If the attackers had privileges on the IIS server, it is likely they began to infiltrate the network.

Obviously, the time and expense for these measures is not trivial. For this reason, I urge companies and administrators to put in place the necessary expertise and technology to ensure that the probabilities for a successful attack are minimized as much as possible. Additionally, monitoring systems should be in place to alert administrators as quickly as possible.

One way to quickly implement a high degree of security is to use Microsoft's Internet Security and Acceleration (ISA) server and publish your web server to the ISA server. When so configured, the ISA server acts as a firewall protecting the IIS server from attacks and at the same time delivers the required content to the client. In this way, an attacker does not have access to the IIS server directly.

Of course, even with an ISA server or other solid firewall server in place, this is no substitute for securing you web server effectively. There's lots of good advice on the topic, which include the following:

Submit your questions to the IIS Insider. Selected questions along with the answers will be posted in a future IIS Insider column.

For a list of previous months questions and answers on IIS Insider columns, click here.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.