Category: Tips & Tricks

Plink – or – Issuing SSH Commands on Demand

ingmar.koecher 0 Comment EventSentry, Tips & Tricks, Tools & Utilities

We have a Linux server running Samba on our network which we use mostly to store ISO images which can be mounted and served on-demand through Samba.

I was looking for a way to issue commands on the Linux machine through SSH yesterday when the Winbind daemon (which is part of Samba and ensures that Linux users are authenticated against our domain controller) on the machine was acting up again. Every time we reboot our Windows 2003 domain controller (which is fortunately not very often but security updates usually require this), the Winbind daemon starts logging a particular error message every 5 minutes to the Syslog daemon which in turn is forwarded to EventSentry by the Linux Syslog daemon.

Since warnings and errors are forwarded to me via email, getting this particular error message every 5 minutes starts getting old after about half an hour – especially when I’m out of the office and get them on my phone. Logging on to the Linux box and restarting the Winbind daemon however solves the problem – and this is what I have been doing for a long time now. Well, until recently.

I thought to myself that if there were a utility that could issue commands through SSH from a Windows box, then I could configure EventSentry to automatically restart the Winbind daemon as soon as the Syslog packet containing the error message is received.

I have been using the free SSH-Client PuTTY for quite some time now, but didn’t know that it “included” Plink, a SSH utility that allows you to issue commands through the SSH tunnel and even see the output from the remote command. Perfect!

Setting up EventSentry to automatically restart windbind using plink is a straight-forward 3-step process, assuming you already have the Syslog Daemon in EventSentry up and running:

1. Create a batch file that issues the command you need to run. The batch file I created looks like this:

C:\Batch\plink.exe
root@mylinuxhost -pw SecretPass “/etc/init.d/winbind restart”

Make sure you run the script once from the command-line to ensure that it is working.

2. In EventSentry, create a process action that references the above script. You do this by right-clicking the Actions container and selecting Add Action. Then just select the Process tab and point to the batch file you just created.

3. Under the Event Log Packages container, add a filter in an existing package or create a new package. The filter will match the Syslog event that you want to trigger our script. The event source for that filter will always be Application, and the event id should be 9999. Since we don’t want the process to be triggered every time a Syslog event comes in, we will also specify the text from the Syslog event – *winbindd*: cli_nt_setup_creds: request challenge failed* in my case. Then just select the process action you created in step 2 and you are all set.

There are a couple of things I need to point out of course. First, make sure that the batch file is secure as it contains the username and password to your Linux host – the appropriate NTFS permission might be enough in most cases. If you cannot keep it secure then you should create a user on the Linux box that is just used for the purpose of issuing particular commands through SSH. Second, make sure that plink.exe is present on the host where the EventSentry Syslog daemon is running, as the file will be executed on that host.

Plink of course is a great utility for automation in any case, regardless of whether you use EventSentry to consolidate Syslog messages. I hope this helps automate some tasks in Windows/Linux environments.

Vista Event Log Changes

ingmar.koecher 1 Comment Event Log, EventSentry, Tips & Tricks

As you may already know, Microsoft significantly changed the Windows event log in Windows Vista. I always found the Windows event log to be a very well designed logging infrastructure, at least compared to the logging facilities that are available in other major network operating systems. The Windows event log however hasn’t changed much since it was originally included in Windows NT. It has actually been 13 1/2 years since the core event log service and event viewer underwent a major improvement – other than updating security event ids to accommodate new events related to various security components – Windows NT 3.1 was first released in 1993. I have never actually seen the event viewer in Windows NT 3.1, but Windows NT 3.51’s event viewer for example was not too much different than Windows 2003’s.

So it appears that Microsoft finally realized that a good system can be improved (especially with compliance becoming more and more important over the last years), and so the event log subsystem, including the event viewer, appear to have been rewritten completely in Windows Vista and of course the upcoming Windows Server 2008.

As we are continuing to improve Vista support in EventSentry,  I will cover the changes that I believe are relevant to IT professionals that need to manage their event logs. Just as a side note, EventSentry already monitors the Vista event log since the end of 2006, however ES 2.81 currently accesses the Vista event log through the legacy API that Vista (fortunately) still provides to pre-Vista event log software.

Before I dig into the technical details about the new event log, I need to point out that Microsoft made a large amount of changes to the event log, and didn’t leave a stone unturned. While the overall logic is the same (you have event logs and events 🙂 ), a lot has changed under the hood.

While this will affect IT professionals that need to manage event logs (since they need to make sure that their software works with Vista & Windows 2008), it will affect software developers even more. While I like a lot of the changes that were introduced, and we all know improvements were overdue for a long time, I personally feel that the new event log has been over-engineered. A lot of the features that were added are a bit of overkill and accessing, especially writing to, the event log is significantly more involved with the new version (at least if you take advantage of the new XML functionality). I think it would have been better to gradually introduce improvements over the last 10 years, rather than ignoring the event log for a long time and then introduce a myriad of new functionality to it – some of which has yet to make sense (I will prove my point below with future posts).

In any case, I will get off my soapbox now and focus on the relevant changes that were introduced.

Keywords
One of the new fields added to the properties of an event is called “Keywords”. I find the most interesting thing about this field that security events now have their severity stored in the Keywords field instead of the Type field (Type was renamed to Level in Vista and later). As you know, events in Windows Server 2003 and earlier used to have their severity stored in the Type property of an event (Information, Warning, Error, Audit Success, Audit Failure), but in Vista and later the severity of security events (Audit Success, Audit Failure) have been moved to the new Keywords field.

This of course leaves the question what the Level is set to for audit events. Well, the answer is Information. All Audit Success and Audit Failure events have their main severity stored in the Keywords field, whereas the Level field is always set to Information. An Audit Failure event that is informational, yeah – that makes a lot of sense!

So in theory it would be possible to have an Audit Failure event logged with a level of Information/Warning/Error, but I am not sure how useful this would be. After all, an Audit Failure is an Audit Failure.

Why was this changed? I am not sure. After asking the head of the Windows Auditing Team at Microsoft I received an explanation that, unfortunately, failed to eliminate my confusion. The original Type field could obviously accommodate the two attributes (since had always been there), and there would have been room for even more. There was some consensus between the two of us that the keywords field, at least in combination with the security events, was maybe not implemented in the best way.

In EventSentry we currently ignore the Keywords field and merge it with the original Type field, so that you can search across Pre-Vista machines and Vista machines using the same field name.

So this is it for now, we will cover a lot more about the new Windows Event Log here in the future. As always, let us know if you have any questions or feedback.

Who Is In My Server Room?

tames.mctigue 0 Comment EventSentry, Tips & Tricks, Tools & Utilities

As some of you already know, EventSentry allows you to use different environment sensors to be alerted about changes in your server room. One of these happens to be a motion sensor (scroll down).

It is great to be alerted when somebody is moving around in there, but it would also be helpful to know who it is. We picked up an Axis 207 network enabled camera from Axis Communications so we can take a peak in there though any available web browser. This works great as long as we are near a computer at the time we get the motion alerts from EventSentry, but not very useful if we aren’t.

Luckily, our Axis camera has a pretty good API that you can access. It has the ability to grab a .jpg image by going to a URL (http://cameraIP/jpg/image.jpg). I needed a way to attach this .jpg to an email so that not only am I alerted, but I also have an image of who or what caused it.

There may be other cameras out there that can do this as well. If you know of one please post it in the comments section.

I came up with a batch file that uses some free utilities to accomplish this task. For good measure, I also decided to allow you to grab a series of pictures, put them to a web site directory, thumbnail them, and finally create an HTML page that displays them.

Building maintenance entering a server room at night. Image quality depends on lighting, and camera quality.

This could probably have been done easier using Perl or another scripting language, but I had already started with a batch file and wanted to just finish it! Feel free to come up with a better way.

The tools needed are included in this zip file:

  • gethttp.exe – Taken from our free EventSentry SysAdmin Tools, used to grab the image from the camera
  • sleep.exe – Also taken from EventSentry SysAdmin Tools. Allows you to put pauses in your script
  • blat.exe – Blat is a great command line utility that allows you to send emails
  • printf.exe – Taken from the GNU tools for Windows. A lot more flexibility than using ECHO
  • convert.exe – Command line utility from ImageMagick. Used to create the thumbnails.

The zip file also contains the actual script used named “getimages.cmd”. You will need to change some of the settings inside of it to get started. Most are self-explanatory and include:

  • cameraIP – IP address of the camera
  • binPath – Path to the needed utilities above
  • imagePath – Where you want the images stored
  • numImages – The number of images you want to capture each time
  • timePause – Miliseconds to wait between images
  • netLocation – URL to your web server hosting the images
  • eMail – Email address you want the alerts sent to. Comma separate for multiple people.
  • eSender – Address email comes from
  • subj – The subject for the email
  • server – Your SMTP server

Now to make it run when EventSentry detects motion. To do this, create a new action in EventSentry. I named mine “Motion Alert”. Go to the “Process” tab at the top and put in the path to the “getimage.cmd”.

Next, we will need an event filter to trigger the action. Here are the settings you need:

  • Event Log: Application
  • Type:  Error
  • Source: EventSentry
  • Category: Environment Sensors
  • Event ID: 10912

That is it, from now on you should know who is setting off your motion sensor.

You can download the entire package from here.

If you have any comments or suggestions, we would love to hear them.

Automatically shutting down workstations

ingmar.koecher 0 Comment EventSentry, Tips & Tricks

tree_fall_small.jpgThere has been a lot of talk lately about “green” computing, it seems
like every other IT magazine covered this topic over the last few
months.

Since power isn’t free, companies are fortunately interested in saving power for the sake of saving money, if not for the environment as well.

A lot of attention has been given to the power consumption of data centers and how to save money with blade servers and newer processors, but I feel that not enough attention is being paid to workstations, of which there are many more than servers.

Now there are a lot of power-save options available for workstations and software to centrally manage those settings, but how many users are not shutting down their workstations when they leave for the day?

I don’t have the resources to calculate how much power is being wasted every day by computers that are running over night across the US – when they really don’t have to be – but I imagine it’s a good amount.

True, there are some advantages to keeping computers running over night. For example, you might have software and patches pushed to workstations after hours (and we can get around that as well) and it’s always nice to come into the office in the morning without having to wait for the computer to boot up.

If you’re in charge of managing workstations then I recommend that you take a look to see how many workstations are running after most of the employees have left for the day. If you have a lot of idle PCs sitting on the floor sucking power then please read on. 😉

Using third-party tools we can automatically schedule a workstation shutdown using the shutdown.exe utility that ships with Windows XP and Vista. The tool is flexible enough to give users a grace period where they can abort the shutdown. And if you have a software management solution in place that pushes updates to your workstations, then you should be able to adjust the schedule so that the shutdown occurs after the deployment of any packages you might have. You can also limit the shutdown to particular weekdays, for example Mon-Thu only.

If you are using EventSentry to monitor not only your servers but also workstations, then you are lucky and setting this sort of scheme up shouldn’t take longer than 5 minutes.

EventSentry includes the Application Scheduler feature, which allows you to schedule tasks (similar to the task scheduler in Windows) on one or more computers. Simply create a new system health package, add an application scheduler object and create a new schedule. The command line you want to run can be similar to this:

shutdown.exe -s -f -c “To conserve power, this computer will now be shut down. To abort, click START – RUN and enter SHUTDOWN -A” -t 300

This will give the user 5 minutes before the computer will actually be shutdown. Then, assign the package to your workstations and you are set to go.

If you are not using EventSentry then you can also write a batch script and schedule the script to run from the server as well, the shutdown.exe tool supports shutting down remote computers as well.

If you are still scared about shutting computers down, then take a look at the WakeOnLan feature from the EventSentry Web Reports Hardware Inventory. If the web reports are installed on the same collision domain than your workstations, then you can wake up computers (that support the WakeOnLan feature) with the click of a button from there. Or, you can use wakeonlan.exe from the free NTToolkit to accomplish the same thing from the command-line. You could even write a batch script to wake computers up every morning!

I hope this gives you some ideas on how you can save power, save money and conserve the environment with little effort.

P.S.: Don’t forget to tell your fellow coworkers that you will be shutting down their computers at night so that those hard-working individuals won’t be caught by surprise!

Setting Service permissions with subinacl.exe

ingmar.koecher 3 Comments Tips & Tricks, Tools & Utilities

I recently stumbled across a lesser known Microsoft utility (again) called subinacl.exe that you should take a look at if you haven’t already done so. It can be downloaded for free from Microsoft.

The tool is incredibly versatile and lets you change permissions of various system objects, such as files, printers, shares, services, registry keys and more from the command line.

I came across it because we needed a way to change the permission of the EventSentry service to allow a particular user account to read the current service status. So I’m only going to cover the service aspect of the tool in this post.

So how is this useful? Imagine you have a junior admin that you want to allow to manage a particular service on one or more of your servers. You don’t want the guy to be a local admin or be able to control all services but instead only be able to control one (or more) particular service.

In this case Windows doesn’t actually offer any native way of doing this without using a third party tool – with the exception of using group policy.

So let’s say you have user “Johnny” and you want Johnny to be able to stop and start the World Wide Web Publishing service. Simply run the following subinacl.exe command:

subinacl /service W3SVC /GRANT=YOURDOMAIN\Johnny=TO

Obviously you will want to replace YOURDOMAIN with the name of your domain. The TO at the end are the identifiers that tell subinacl which actions you actually want grant to Johnny. T is used for “Start Service” and O is for “Stop Service”. The complete list is here:

   F : Full Control
   R : Generic Read
   W : Generic Write
   X : Generic eXecute
   L : Read controL
   Q : Query Service Configuration
   S : Query Service Status
   E : Enumerate Dependent Services
   C : Service Change Configuration
   T : Start Service
   O : Stop Service
   P : Pause/Continue Service
   I : Interrogate Service 
   U : Service User-Defined Control Commands

So after running the command, Johnny will be able to stop and start the service without having any other permissions on the system.

But don’t stop there. Run subinacl.exe /help to see all the other options that are available to you. Of course you can also run the tool remotely by specifying the remote computer name.

You should also check out the MS KB article 288129 that has information on how to accomplish the same thing with group policies and security templates. This might be a better way especially if you have a large number of servers you want to apply this to.

Hope this is useful!