This section describes issues encountered when logging to any log format: file, MSDE, or SQL database.
Logs Show Requests from Anonymous Users
Problem: Anonymous access is blocked, but the logs show requests from anonymous users.
Cause: When a user is required to authenticate, the communication works as follows:
-
A user sends an anonymous request. ISA Server responds with a 407 error and terminates the connection. An anonymous request is logged.
-
The user sends the same request with Keep-Alive and NTLM authentication information. ISA Server responds again with a 407 error, and with an authentication challenge. The connection is not terminated. Another anonymous request is logged.
-
The user sends the same request with the authentication response. Now the request is authenticated and served.
Solution: Validate that the anonymous requests are followed by a request from an actual, authenticated user.
Otherwise, the firewall policy may have been configured incorrectly.
Client User Name Marked with ?
Problem: In the log file, the Client Username field is set to question mark (?).
Cause: The question mark indicates that the client user name has not been authenticated. This happens when a request arrives from a Firewall client. The Firewall client always sends the user name, and therefore it is always logged. However, if the firewall policy does not require authentication, the name is logged as a question mark.
Solution: If you want the user name to appear rather than a question mark, update the firewall policy to require authentication.
IP Addresses Are Logged, Not User Names
Problem: In the log file, Internet Protocol (IP) addresses are logged, rather than user names.
Cause: When requests are made by SecureNAT clients, rather than by (authenticated) Web Proxy or Firewall clients, only the IP address is logged. The user name cannot be determined.
Solution: If you require logging of user names, consider deploying Firewall Client software.
Cannot Find Authentication Information
Problem: Cannot find client authentication information (user names) in the log file.
Cause: ISA Server does not always require that clients authenticate themselves. If clients are not authenticated, they are granted anonymous access and their authentication information is not logged.
Solution: You can configure ISA Server to always require that Web Proxy clients authenticate themselves by configuring the incoming and outgoing Web request properties.
To configure authentication methods for a Web listener (incoming requests), perform the following steps:
-
In the console tree of ISA Server Management, click Firewall Policy:
-
For ISA Server 2004 Enterprise Edition, for array-level firewall policy, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, and then click Firewall Policy.
-
For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, and then click Firewall Policy.
-
On the Toolbox tab, click Network Objects.
-
Expand Web Listeners, and then click the applicable Web listener.
-
On the toolbar beneath Network Objects, click Edit.
-
On the Preferences tab, click Authentication.
-
Select Require all users to authenticate, to force clients from this network to authenticate using one of the selected authentication methods.
To configure authentication methods for Web Proxy clients, perform the following steps:
-
In the console tree of ISA Server Management, click Networks:
-
For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, expand Configuration, and then click Networks.
-
For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, expand Configuration, and then click Networks.
-
In the details pane, click the Networks tab, and then select the applicable network.
-
On the Tasks tab, click Edit Selected Network.
-
On the Web Proxy tab, click Authentication.
-
Select Require all users to authenticate, to force clients from this network to authenticate using one of the selected authentication methods.
0.0.0.0 IP Addresses Are Logged
Problem: The Web Proxy log includes 0.0.0.0 IP addresses, specified as the destination for specific requests.
Cause: Sometimes only a URL is available for the destination host. In this case, the IP address appears as 0.0.0.0. This happens when a request has been denied and no Domain Name System (DNS) name resolution lookup was performed for it.
Solution: To determine an IP address of a specific URL, type the following at a command prompt:
ping URL_name
Logs Show Empty Rules Deny Requests
Problem: In the Rule field, the log indicates "-" (empty) as the rule denying the request.
Cause: The Rule field is marked empty when ISA Server denies the connection for any reason other than a firewall policy rule. The Result Code field indicates the reason. For example, the rule may have been denied for the following reasons:
-
No network relationship was defined between the source and destination.
-
ISA Server considered the traffic spoofed.
-
The request is from a client with too many open connections.
Logs Show Empty Content Types
Problem: In the MIME type field, the log indicates "-" (empty) as the Multipurpose Internet Mail Extensions (MIME) type.
Cause: The MIME type field is marked empty (with a "-") when the destination server does not respond with the Content-Type header. ISA Server logs the content type information only when the server's response includes a Content-Type header.
False Log Entries
Problem: The logs indicate an All Port Scan alert with source IP addresses from the Internal network. A false alert was generated.
Cause: Some false alerts may be generated when the Microsoft Windows Internet (WinINet) application programming interface (API) and Windows HTTP Services (WinHTTP) reset connections, rather than closing sessions properly, to reduce network packets. In particular, this happens when a response is still on the way from an upstream server. In this case, ISA Server will generate the All Port Scan alert.
Solution: To verify that the alert is a false alert, check the following:
-
ISA Server logs contain traffic to the IP address.
-
Date and time specified in the log entry corresponds to a packet that reverse-matches the last connection (source and destination IP and port are reversed) from ISA Server to the upstream server.
Too Much Information
Problem: Too much information is filling the log.
Cause: When you create a rule, by default, any requests that match the rule are logged. Because the Default rule denies all traffic, any requests that are not specifically allowed by rules that you create will be logged. This could potentially fill your log quickly.
Solution: If you notice a large amount of log data from a specific protocol or source, you can create a new rule, which applies to that type of traffic, for which requests are not logged. For example, suppose your policy does not allow Dynamic Host Configuration Protocol (DHCP) requests, and many DHCP requests are being denied. Instead of relying on the Default rule, create a new access rule that denies DHCP requests, but does not log the requests.
To log requests matching a rule, perform the following steps:
-
In the console tree of ISA Server Management, click Firewall Policy (for Standard Edition and for array-level requests in Enterprise Edition) or Enterprise Policies (for enterprise-level requests in Enterprise Edition):
-
For ISA Server 2004 Enterprise Edition, for a specific enterprise policy, expand Microsoft Internet Security and Acceleration Server 2004, expand Enterprise, expand Enterprise Policies, and then click Enterprise_Policy.
-
For ISA Server 2004 Enterprise Edition, for array-level firewall policy, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, and then click Firewall Policy.
-
For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, and then click Firewall Policy.
-
In the details pane, click the rule for which logging should be enabled.
-
On the Tasks tab, click Edit Selected Rule.
-
On the Action tab, select the Log requests matching this rule check box.
Query Stopped Due to Error
Problem: An error message indicates that "The query stopped because an error occurred while it was running."
Cause: Permissions were not configured appropriately on the SQL Server database table.
Solution: On the computer running SQL Server, verify that SELECT permissions on the relevant tables were given to the user authenticating with the computer running SQL Server.
Log Fields Display Even When Not Selected
Problem: Certain log fields are displayed in the Firewall and Web Proxy logs, even though those fields were not selected to display in the log.
Cause: This is a known issue. Certain fields are displayed even though they are not selected in the logging configuration.
In the Firewall logs, the following fields are logged:
In the Web Proxy logs, the following fields are logged:
-
Server Name
-
Transport
-
Bytes Received
-
Bytes Sent
-
Service
-
Authenticated Client
-
HTTP Status Code
-
Action
Solution: There is currently no workaround.
Log Deletion Failure Event
Problem: The Log Deletion Failure event was generated.
Cause: Log deletion failed, possibly because the database was locked.
Solution: Run the osql utility, which is located on the computer running SQL Server in the \Program Files\Microsoft SQL Server\80\Tools\Binn\ folder. At a command prompt, type the following:
OSQL.EXE" –E –S <server name>\msfw
Then, at the command prompt, type:
sp_who2
Go
A list of sessions to the SQL objects will be displayed.
If after you run that procedure, no SQL objects are listed, check the MSDE error log named ERRORLOG, located in the \Program Files\Microsoft SQL Server\MSSQL$MSFW\LOG folder, and verify that none of the ISA Server databases are listed. Specifically, check for the following:
-
"udopen: Operating system error 32(The process cannot access the file because it is being used by another process.) during the creation/opening of physical device d:\logfiles\ISALOG_20041120_FWS_000.mdf."
-
"FCB::Open failed: Could not open device d:\logfiles\ISALOG_20041120_FWS_000.mdf for virtual device number (VDN) 1."
If the suspected database is no longer needed, launch the osql utility, as described previously. Then type:
drop database <databaseName>
go
This removes the specified database. You can then safely delete that database.
Very Large Log Files Are Generated
Problem: Very large Firewall log files are generated. Some of the log files may be 1 gigabyte (GB) or larger. These log files may fill up the hard disk where they are stored. By default, the Firewall log files are stored in a compressed format in the C:\Program Files\Microsoft ISA Server\ISALogs folder.
Cause: This may occur if the ISA Server-based computer's external adapter is connected to a network that exposes it to much NetBIOS broadcast traffic.
Solution: To avoid this, do one of the following:
-
Reduce the exposure of the external adapter to broadcasts. One method is to use a switch to connect to the network.
-
Reduce the set of fields that are logged.
-
Turn off logging.
To change the log settings, perform the following steps:
-
In the console tree of ISA Server Management, click Monitoring:
-
For ISA Server Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, and then click Monitoring.
-
For ISA Server Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, and then click Monitoring.
-
In the details pane, click the Logging tab.
-
In the task pane, click Configure Firewall Logging. Then, do one of the following:
-
To reduce the set of fields that are logged, click the Fields tab, and then clear the check boxes for the fields that you do not want to log.
-
To turn off logging, on the Log tab, clear the Enable logging for this service check box.
New Logs Are Created
Problem: New Firewall and Web Proxy logs were created.
Cause: When the Microsoft Firewall service restarts, new Firewall and Web Proxy logs are created. This is by design.
Solution: You can safely ignore the creation of these new logs. Because the logs are subject to log maintenance policy, they will eventually be deleted in accordance with maintenance settings.
Lowercase and Uppercase Traffic Displayed
Problem: When monitoring ISA Server traffic, some HTTPS traffic is displayed in lowercase (https), and other traffic is displayed in uppercase (HTTPS). What is the difference?
Cause: In the ISA Server Firewall log, the protocol name displayed is taken from the protocol definition, and is in capitals. In the ISA Server Web Proxy log, the protocol name is usually taken from a set of hard-coded strings, and is in lower case. In some cases the protocol names in the Web proxy log are also taken from the URL, and capitalization is according to that specified in the URL.
Solution: No workaround required.