Keep track of all of your Windows hosts the Unix way.
It’s hard enough to keep tabs on all the Event Logs for all your Windows hosts, but it’s even more difficult if your propensities predispose you to Unix. After all, Unix systems keep their logs in plain text files that are easily searchable with common shell commands. This is a world apart from the binary logs that Windows keeps in its Event Log. Wouldn’t it be nice if you could have your Windows machines work more like the Unix machines that you’re used to? Someone has already thought of it and has written a free Windows service that lets us do just that.
(http://ntsyslog.sourceforge.net/) is a freely
available service written for Windows that allows you to log to a
To set it up, just download and extract the ZIP file, and
then copy the
ntsyslog.exe files into your
To install the service, open up a command prompt and run this:
To verify that it was installed, open up the Administrative Tools Control Panel applet and double-click the Services icon. Then scroll around and look for the NTsyslog service. You should see something similar to Figure 4-1.
By default, NTsyslog installs itself to run under the Local System account, which has complete access to the resources of the local host. This is obviously not the optimal configuration, since the NTsyslog service needs access to the Event Log and nothing else. You can change this by double-clicking the NTsyslog line in the Services Control Panel applet as shown in Figure 4-1. This will bring up the Properties dialog for the service. However, before you do this, you might want to create an account specifically for the NTsyslog service that has only the necessary privileges for NTsyslog to run properly. To do this, go back to the Administrative Tools window and double-click the Computer Management icon. After clicking the Local Users and Groups icon, you should see something similar to Figure 4-2.
Right-click the Users folder and click New User. You should now see a dialog where you can enter the information for the new user. Enter information similar to that shown in Figure 4-3, and make sure you pick a strong password.
Now we need to give our new user the rights it needs to do its job. Locate the Local Security Policy icon in the Administrative Tools window and double-click it. Click the Local Policies folder in the left pane of the Local Security Settings window, and then double-click the User Rights Assignment folder in the right pane of the window. You should now see something similar to Figure 4-4.
Figure 4-4. Viewing the User Rights Assignments settings in the Local Security Settings Control Panel applet
The access right that we are looking for is “Manage auditing and security log”. Locate this in the Policy list and double-click it. You should then see a dialog like Figure 4-5.
Click the Add button, select the name of the user from the list, and then click OK.
We have the account and we’ve given it the proper access rights, so let’s go back to the Services window and double-click the NTsyslog service to bring up its Properties dialog. Click the Log On tab and you should see something like Figure 4-6.
Click the “This account” radio
button to enable the Browse... button.
Now click the Browse... button and locate and select the
account that you created. Then click
the OK button. You should now see
the account name in the text box to the right of the
“This account” radio
button. Enter the password you set
for the account and confirm it.
After clicking the Apply button, a dialog will appear
confirming that the Log On As A Service right has been granted to the
account. Click the OK button, then
click the General tab in the Properties dialog.
To start the service as the new user that you created,
click the Start button. If you get
an error dialog, you will need to change the ACL for the
ntsyslog.exe file and add Read and Execute
permissions for the new account.
Now we’ll use the included
configuration program to
configure the settings particular to NTsyslog. You can use this to
set up a primary and secondary syslogd to send
messages to, as well as the types of Event Log events to send and
their mappings to syslog facilities and severities. You can also
start and stop the NTsyslog service from this screen. To use the configuration program, run
You should see a window like Figure 4-7.
To start the service, click the Start Service button; to stop the service, click the Stop Service button. Clicking the Syslog Daemons button brings up the dialog shown in Figure 4-8.
Again, this is pretty straightforward. Just put in the host you want to log to, and if you have a secondary syslog host, put that in the appropriate field.
The most difficult part of the configuration is setting up the mappings of the Event Log entry types to the syslog facilities and severity levels, but even this is fairly easy. In the drop-down list (as seen in Figure 4-7) you can select between the Application, Security, and System Event Logs. To configure one, simply select it in the drop-down list and click the EventLog button. If you select the Security log and click the EventLog button, you should see something similar to Figure 4-9.
To enable the forwarding of a particular type of event, click the
checkbox next to it. Using the
drop-down listboxes, you can also configure the facility and severity
mappings for each type. Since this
is the security log, you should probably pick one of the
security/auth syslog facilities. For
the severity, choose something that sounds similar to the Event Log
type. For example, I selected
(6)information for the Information type for the
Security Event Log. You could,
however, pick a facility and severity that’s not
used on any of your Unix servers, and have your
syslogd log all Windows events to a common file
separate from your Unix logs. Of
course, if you’re using
you can use any facility you like and filter out your Windows hosts
by IP address.
Once you have it working, try logging in and out a few times using an incorrect password so that you can see that everything is working.
If it is, you should see login failure messages similar to this:
Oct 29 17:19:04 plunder security[failure] 529 NT AUTHORITY\\SYSTEM Logon Failure: Reason:Unknown user name or bad password User Name:andrew Domain:PLUNDER Logon Type:2 Logon Process:User32 Authentication Package:Negotiate Workstation Name:PLUNDER