How to Record User Information in ISA Server Firewall and Web Proxy Logs and Reports
By Thomas W Shinder, M.D.
One of the most common questions I see on the ISAServer.org Web boards and mailing list is how to get user information in the ISA Server reports. ISA Server create creates reports using ISA Server log summaries. The log summaries are derived from the ISA Server Web Proxy service, Firewall service and packet filter logs. If you want to see user information in the reports, you’ve got to get that information into the logs first.
You need to address the following issues to get the user information into the logs:
Configuring the Logs to Record User Information
The ISA Server Firewall service and Web Proxy service log files record Client user names by default. However, it is possible that someone disabled the logging of user names. You can confirm that that the Client user name (cs-username) field is logged by going into the Properties dialog box for the ISA Server Firewall service and ISA Server Web Proxy Service logs. Click on the Fields tab and you’ll see what appears in the figures below. Confirm that there is a checkmark in the Client user name (cs-username) checkbox.
Configuring the Users as Web Proxy and/or Firewall Clients
User information associated with a connection request is only available with requests sent by Web Proxy and Firewall clients. The SecureNAT client can’t send user information with its connection requests because SecureNAT client connections are not proxied through the ISA Server firewall; there is no "client piece" that sends user information to the firewall and such a "client piece" is required to obtain user information. Web Proxy and Firewall client requests are proxied through the ISA Server firewall with the aid of the Firewall client software and Web browser configuration (Web Proxy client configuration).
Firewall client users must be logged into the same domain as the ISA Server firewall, or logged into a domain the ISA Server firewall trusts. The Firewall client always sends user credentials in the background. The Firewall service never prompts the user for credentials. If you see a log on dialog box, it is not the Firewall service asking you for credentials.
The user does not need to be logged on to the domain when using the Web Proxy client. However, basic authentication must be enabled on the Outgoing Web Requests listener as seen in the figure below.
When a user is logged into the same domain as the ISA Server firewall belongs to, or a domain that the ISA Server firewall trusts, the user credentials are sent to the Web Proxy service automatically in the background if integrated or digest authentication is enabled on the listener. If the user is not logged into the same domain as the ISA Server firewall, or a domain the ISA Server firewall trusts, and if the Outgoing Web Requests listener is configured to allow Basic authentication, then the Web Proxy service will bring up a log on dialog box that allows you to manually enter credentials.
Remove Anonymous Access Site and Content and/or Protocol Rules
One of the most common answers I give on the ISAServer.org Web boards and mailing list contains the phrase "remove all anonymous access rules". What is an anonymous access rule? An anonymous access rule is any rule that does not require user/group or IP address based authentication.
For example, when you install ISA Server 2000 in standalone mode (in contrast to enterprise array mode), a default Site and Content Rule is created. This default Site and Content Rule allows everyone access to everything at all times. This is an anonymous access rule because no user/group or IP address based (client address set) authentication is required to access this rule. This is characterized by the Any request option on the Applies To tab.
There are no default Protocol Rules, but if you create a Protocol Rule that does not require user/group or IP address authentication, then you end up with an anonymous access Protocol Rule.
While you can remove all anonymous access Site and Content Rules and all anonymous access Protocol Rules, there is no reason to do this from the context of getting user information into the log files. All you need to do is configure all Site and Content Rules to require either user/group based authentication or IP address based authentication. You may want to lock down access to Protocol Rules based on user/group or IP address for access control reasons, but from the viewpoint of getting user information into the log files, this is not required.
I recommend that you do the following:
The first requirement can be met by configuring the Site and Content Rules that users need to access the Internet to require user authentication. Then the internal network machines are all configured as Web Proxy and Firewall clients. An example of such an allow rule assigned to a group appears in the figure below.
Servers on the internal network do not typically have logged on users. Because these machines should not have logged on users, you will need to create clients address sets for these servers and create separate Site and Content Rules for these servers. For example, a DNS server on the internal network that performs recursion needs access to all computers on the Internet. An SMTP server on your internal network that send outbound mail to Internet SMTP servers also needs access to all machines on the Internet.
The DNS and SMTP server IP addresses should be placed in a client address set. Then create a Site and Content Rule that allows access to all sites, all content at all times. Allow access to these rule to the machines in the client address set, as seen in the figure below.
An example of such an Allow Rule appears in the figure below.
Configure the HTTP Redirector to Drop HTTP Requests from Firewall and Web Proxy Clients
The HTTP Redirector Filter allows SecureNAT and Firewall clients to access the Internet using the Web Proxy service. This confers the advantages of the Web Proxy service, such as higher performance Web browsing and the Web Proxy cache to SecureNAT and Firewall clients. This is a valuable feature if you are not interested in authenticating outbound requests.
But a funny thing happens when the HTTP Redirector Filter is configured to forward requests directly to the destination Web server. Firewall clients that are not configured as Web Proxy clients are able to completely bypass Site and Content Rule restrictions! Of course, if you configure all clients as Web Proxy and Firewall clients, you will not have this problem. Stefaan Pouseele did an excellent article on this subject and I recommend that you review here.
Because of the issues brought up in Stefaan’s article, I recommend that you disable the HTTP Redirector Filter. Just right click on the filter and click the Disable command, as seen in the figure below. An ISA Server Warning dialog box will appear and ask you if you want to restart the Firewall service. The HTTP Redirector filter will be disabled after the Firewall service restart.
NOTE: The Firewall client can only be installed on Windows operating systems. You can’t install the Firewall client on non-Microsoft operating systems. These clients will only be able to access HTTP, HTTPS and HTTP-tunneled FTP via the Web Proxy service. All Web browsers support the Web Proxy client configuration; there is no reason to not configure the browser as a Web Proxy client, as the Web Proxy client is supported by virtually all browsers and all operating systems.
ISA Server makes it easy to get detailed user information in the Web Proxy and Firewall service log files. You just need to force all clients to use the Firewall and Web Proxy client configuration, configure the logs to record user information, disable the HTTP Redirector filter, and remove all anonymous access rules. I routine create the configuration because a major factor in security is accountability. The only way to get accountability is to require user authentication and identification.I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=2;t=009680 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom