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.
Ntsyslog (http://ntsyslog.sourceforge.net/) is a freely available service written for Windows that allows you to log to a remote syslogd. To set it up, just download and extract the ZIP file, and then copy the NTSyslogCtrl.exe and ntsyslog.exe files into your %SystemRoot%\system32 directory.
To install the service, open up a command prompt and run this:
C:\> ntsyslog -install
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.
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 NTSyslogCtrl.exe. 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 (4)security/auth1 and (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 syslog-ng [Hack #59], 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
One of the best things about doing this is that now you can use the wealth and flexibility of Unix log-monitoring tools to help monitor all your Windows systems.