THE OFFICIAL BLOG OF THE SBS DIVA

Hello Susan,
Good Topic.
But, the subject title might be a bit more clear that this is only <weblog> data and not other logs.

One of the things I try to do on all systems I support is configure some consistency where authentication takes place, which is one reason why I frown on all Website Server Publishing which includes the recommended procedure to deploy Companyweb to the Internet on port 444. Note that on a default SBS Premium setup, it's the old saying that nothing is missing but you're not looking in the right place... because a default SBS setup plus deploying Companyweb on port 444 is not consistent what methods are used.

Life is so much easier if you can say "ISA will do all my website authentication so everything is in the ISA logs and reports." Or, for those who are running Standard, then everything will be in the IIS logs

Let me take this opportunity to describe for those new to this topic how to determine where you should look for relevant website security log data.

You need to determine <what> is authenticating the remote User. By this, I mean that when a remote User fires up IE and connects to your SBS, what Service determines whether the User should be granted permissions to see the web page?

On SBS Standard, it's clear and uncomplicated. IIS will receive the request, do the necessary evaluation possibly passing its own authentication request to the local or domain Windows Authority, then either returning the requested content or an error.

Also, it does not matter whether you're running 1 NIC or 2 NIC or have the ICF on or off. This is because nothing changes... The Service authenticating the User is IIS.

For those who are running ISA though, this can become complicated because ISA supports so many ways to either pass the request to IIS or do the authentication itself instead of IIS. The bottom line regarding logging is that if the original request is passed to IIS(Packet Filtering or Server Publishing), then IIS will authenticate and you will see relevant entries in the IIS logs.

But if ISA is configured as a Reverse Web Proxy for a website, then ISA will not pass the original request to IIS. Instead, the User will talk only to ISA which will do the User authentication evaluating what the User is permitted to access, and if the User has sufficient permissions, then ISA will create a brand new request on behalf of the User to IIS. The original request from the User is <terminated> at ISA and goes no further.

When this happens, since ISA is talking to IIS on behalf of the User, ceebf7all that will be in the IIS logs are the converstations between ISA and IIS and nothing about the User... and that won't be informative at all. You won't be able to tell one thing about one request vs another because IIS won't know who the remote User is.

But, if you look at the ISA logfiles you will see everything!

Note that you get a big bonus when ISA authenticates, standard ISA reporting will provide you with valuable information about such things as the "Top 10" in many categories, how efficiently you're running, Traffic Load at various times throughout the day, where your Users are going (although not broken down User/Website) and more. Depending on what you're looking for, you may never have to view the logfiles directly. Note also that although your raw logfiles will be overwritten regularly (1 week default), the reports "live forever" so you can compare going back as far as you want.

Lastly, I'm not sure why SBS2K3 doesn't set up monitoring by default, it was probably an oversight because IIRC it was setup by default in SBS2K (but my memory could be bad).

And, if you're running ISA2K, do look for postings from people who describe what the default install does <not> set up for you besides monitoring... Perhaps the most important thing to enable on your own is Packet Filtering and Intrusion Detection (Packet Filtering Properties).

Tony