IIS Insider - December 2005

By Bernard Cheah, IIS-Resources.com

IIS Insider is a monthly column designed to answer your questions on how to troubleshoot and make the most of Microsoft Internet Information Services.

Understanding IIS FTP Log File Entries

Fac1

Q. Can you tell me what each of the following FTP log entries stands for? See my individual questions below.

#Software: Microsoft Internet Information Services 5.0 #Version: 1.0 #Date: 2005-10-10 10:10:13 #Fields: time c-ip cs-username s-port cs-method cs-uri-stem sc-status �� ������. 10:54:13 ip1 anonymous@ftp.msft.com 21 [135]USER anonymous@ftp.msft.com 331 10:54:13 ip1 - 21 [135]PASS - 530 11:48:04 ip2 anonymous 21 [136]USER anonymous 331 11:48:04 ip2 - 21 [136]PASS Cgpuser@you.com 530 13:50:27 ip3 Anonymous 21 [137]USER Anonymous 331 13:50:27 ip3 - 21 [137]PASS guest@me.net 530 17:40:30 ip4 anonymous 21 [138]USER anonymous 331 17:40:30 ip4 - 21 [138]PASS IEUser@ 530 17:40:30 ip4 anonymous 21 [139]USER anonymous 331 17:40:30 ip4 - 21 [139]PASS IEUser@ 530 17:40:41 ip4 Administrator 21 [140]USER Administrator

**a) In the first log entry above, what do [135] and 331 stand for? Where can I find further information about this status code?

b) My machine running Windows 2000 Server doesn't have anonymous@ftp.msft.com, and I didn't allow anonymous access. Is this user trying to log on by guessing the user name?
c) In line two, does PASS - 530 mean that the user didn't log on?
d) In line six, why is there an e-mail address between PASS and 530?
e) At the end of line eight, why is IEUser@ in the PASS field?
f) Are the last two log entries indicating that the user has logged on to FTP?

A. Before we look at each of your questions, it is important to understand which "fields" are being logged in this log file. In your case, the field is:

time c-ip cs-username s-port cs-method cs-uri-stem sc-status

The following table shows what information is captured by each field:

Now, let's move on to your individual questions.

Q (a): In the first log entry above, what do [135] and 331 stand for? Where can I find further information about this status code?
A (a): The [135] in the cs-method field represents the "connection ID" for the IIS FTP. In this case, the first connection from ip1 is the 135th connection since service started. The 331 is the replied status code and stands for "User name okay, need password" as per the RFC959 specification. The next log entry, containing status code 530, shows that the user failed to log on. Authentication may have failed because of an invalid user name/password or the user account does not have required permissions or user right to log on. For the complete status code and its description, refer to the Microsoft Knowledge Base article called IIS Status Codes.

Q (b): My machine running Windows 2000 Server doesn't have anonymous@ftp.msft.com, and I didn't allow anonymous access. Is this user trying to log on by guessing the user name?
A (b): Yes. Since you have disabled anonymous access, the standard e-mail format user name will not work. If you see a logon like "administrator" or some random user name that exists in your user database, then most likely the attacker is trying to log on using a known user name.

Q (c): In line two, does PASS - 530 mean that the user didn't log on?
A (c): Yes. Refer to the answer to your first question above and see also the Microsoft Knowledge Base article called Err Msg: 530 User <Username> Cannot Log In. Login Failed.

Q (d): In line six, why is there an e-mail address between PASS and 530?
A (d): Good question. The log entries on line three and line six both indicate that the user is trying to log in anonymously; you see the cs-username as "anonymous." Even with an anonymous account, a user still needs to provide a password. The password can be anything in any format. However, IIS FTP responds with the following: "331 Anonymous access allowed, send identity (e-mail name) as password." Hence, most users will enter an e-mail address as the password. This anonymous password is captured in the FTP log file.

Q (e): At the end of line eight, why is IEUser@ in the PASS field?
A (e): Well, this clearly tells us that the user is using Internet Explorer (IE). By default, IE will automatically log on as anonymous when browsing an FTP site. Thus, you see the user name "anonymous" and IEUser@ is just the password used by IE.

Q (f): Are the last two log entries indicating that the user has logged on to FTP?
A (f): Yes. This is because the status code for PASS is 230, which indicates a successful logon. However, take note that IIS will not store the logon user password in the log file.

Troubleshooting IIS SMTP

Fac2

Q. I have an ASP application that uses CDOSYS to send mail. However, I noticed that all my mail is stuck in the queue folder. How can I troubleshoot this problem?

A. This is a common question with IIS SMTP. I suggest that you start by following the steps in this article: How to Test Outbound Mail Flow with a File in the Pickup Folder. This simply tests the basic function of SMTP. The article has you create a plain text file with the specified format. If SMTP is working, the mail will be delivered. When mail gets stuck in the server, it is usually due to a DNS issue. For example, the SMTP component might not be able to resolve the recipient's e-mail domain MX record. In IIS 5.1 and earlier versions, IIS SMTP only supports TCP DNS queries. If a query failed, the mail would not be delivered. (Microsoft Windows Server 2003 and IIS 6.0 support both TCP and UDP.) So, to test whether mail getting stuck in the server is a DNS issue, follow the steps in this article: Windows 2000 and Exchange 2000 SMTP Use TCP DNS Queries. In order to avoid the need for such troubleshooting, you can download a diagnostic tool called SMTPDiag. This tool is from the Microsoft Exchange Server team. It helps you troubleshoot SMTP-related issues including DNS MX resolution, testing connection to the remote hosts, and more. And no, it does not require Exchange Server; it only requires the SMTP component. The tool is tiny, too -- only 96KB. Here's the sample output of the diagnostic process:

D:\Tools\SmtpDiag>SmtpDiag.exe "sender@sender.com" "foobar@foobar.com" /v Searching for Exchange external DNS settings. Computer name is XXXXX. Failed to connect to the domain controller. Error: 8007054b �<-- You can ignore this if you are not in Active Directory domain. Checking SOA for foobar.com. Checking external DNS servers. Checking internal DNS servers. Checking TCP/UDP SOA serial number using DNS server [xxx.xxx.xxx.xxx]. TCP test succeeded. UDP test failed. �<-- Windows 2000 Server behavior Serial number: 2004092100 Checking TCP/UDP SOA serial number using DNS server [xxx.xxx.xxx.xxx]. TCP test succeeded. UDP test failed. Serial number: 2004092100 SOA serial number match: Passed. Checking local domain records. Starting TCP and UDP DNS queries for the local domain. This test will try to validate that DNS is set up correctly for inbound mail. This test can fail for 3 reasons. 1) Local domain is not set up in DNS. Inbound mail cannot be routed to local mailboxes. 2) Firewall blocks TCP/UDP DNS queries. This will not affect inbound mail, but will affect outbound mail. 3) Internal DNS is unaware of external DNS settings. This is a valid configuration for certain topologies. Checking MX records using TCP: sender.com. A: sender.com [xxx.xxx.xxx.xxx] Checking MX records using UDP: sender.com. A: sender.com [xxx.xxx.xxx.xxx] Both TCP and UDP queries succeeded. Local DNS test passed. Checking remote domain records. Starting TCP and UDP DNS queries for the remote domain. This test will try to validate that DNS is set up correctly for outbound mail. This test can fail for 3 reasons. 1) Firewall blocks TCP/UDP queries which will block outbound mail. Windows 2000/NT Server requires TCP DNS queries. Windows Server 2003 will use UDP queries first, then fall back to TCP queries. 2) Internal DNS does not know how to query external domains. You must either use an external DNS server or configure DNS server to query external domains. 3) Remote domain does not exist. Failure is expected. Checking MX records using TCP: foobar.com. MX: gsmtp171.foo.com (10) MX: gsmtp57.foo.com (20) A: gsmtp171.foo.com [64.233.171.27] A: gsmtp57.foo.com [216.239.57.27] Checking MX records using UDP: foobar.com. MX: gsmtp171.foo.com (10) MX: gsmtp57.foo.com (20) Both TCP and UDP queries succeeded. Remote DNS test passed. Checking MX servers listed for foobar@foobar.com. Connecting to gsmtp171.foo.com [64.233.171.27] on port 25. Received: 220 mx.foobar.com ESMTP 73si601551rna Sent: ehlo sender.com Received: 250-mx.foobar.com at your service 250-SIZE 20971520 250 8BITMIME Sent: mail from: <sender@sender.com> Received: 250 OK Sent: rcpt to: <foobar@foobar.com> Received: 250 OK Sent: quit Received: 221 mx.foobar.com closing connection Successfully connected to gsmtp171.foo.com. Connecting to gsmtp57.foo.com [216.239.57.27] on port 25. Received: 220 mx.foobar.com ESMTP v71si245850cwb Sent: ehlo sender.com Received: 250-mx.foobar.com at your service 250-SIZE 20971520 250 8BITMIME Sent: mail from: <sender@sender.com> Received: 250 OK Sent: rcpt to: <qbernard@foobar.com> Received: 250 OK Sent: quit Received: 221 mx.foobar.com closing connection Successfully connected to gsmtp57.foo.com.

So, what you need to do is use the output as a base and then focus on each problematic area. For example, if SMTPDiag complains that it is unable to resolve MX records, check to make sure that the SMTP host is able to query MX records via TCP/UDP port 53.

IIS HTTP GET and POST Limits

Fac3

Q. I'm very confused with all the different size limits imposed in IIS, versions 5.0 or 6.0, with HTTP.sys (ASP-specific), URLScan, etc. Can you help me?

A. That's a very good question. I share your pain. I myself get lost from time to time. So, let's see how we should start. First of all, let's look at the browser limit. For the HTTP GET request, Internet Explorer limits it to 2,083 characters, as per the following Microsoft Knowledge Base article: INFO: Maximum URL Length Is 2,083 Characters in Internet Explorer. This does not apply to HTTP POST, as mentioned in the article. To learn more about HTTP GET and POST, refer to RFC 2616 for HTTP/1.1 method definitions. Moving on to server-side limits, we know the following:

*If you have installed URLScan, you can set additional request limit settings in URLScan.ini. For more information on URLScan, refer to Using URLScan on IIS. In addition, IIS 6.0 has HTTP.sys settings. Refer to the following article for more information: INF: HTTP.sys Registry Settings for IIS.

Before we go into defining the relationship between each configuration setting, here's a brief explanation of each setting:

Here are URLScan request limit settings:

In the table above, note that these are the default configuration settings for URLScan 2.5. Changes are made in the URLScan.ini file. You can also impose your own request limit to a specific request header. Refer to Using URLScan on IIS for more information.

Here are HTTP.sys request limit settings:

Note that these settings indirectly translate to part of the feature or configuration offered by URLScan for IIS 6.0. To determine whether to deploy URLScan on IIS 6.0, refer to the section called Determining Whether to Use UrlScan 2.5 with IIS 6.0. Changes can be made in the following registry key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters.

By now you should have a good understanding of all the different request limit settings. Now let's look at the relationships between the settings. For instance, which limit should be imposed first?

In short, the limitation of MaxClientRequestBuffer is equivalent to MaxRequestEntityAllowed. With IIS 6.0, Microsoft provides further granularity to controlling request limits, such as AspMaxRequestEntityAllowed, as well as those in HTTP.sys.

Now, let's look at the order in which restrictions are applied. Figure 3.1 shows the order of request limits applied in IIS. If you are not running IIS 6.0, the HTTP.sys section does not apply.

Figure 3.1 Request Limits in IIS

Ok. I'm done! Hopefully, you have a better understanding of the different request limit settings in IIS. Until next time, Ciao!

For More Information

Submit your questions to IIS Insider. A response is not guaranteed; however, selected questions along with the answers will be posted in a future IIS Insider column.

Visit IIS Insider column archives for a list of previous months' questions and answers.

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.