Monitoring Windows Server Interactive Logins

I’m sure many of you realise that for systems with high value in terms of information held or impact to business due to outage or data breach, you would probably want to crank up the monitoring of such systems. Best practices say you should pretty much monitor all activity associated with local users and groups, but today I want to focus on interactive logins to servers.

This has mainly come about from my own need recently to provide the ability to notify on any interactive login to a particular server, be it using remote desktop or a console session.

My first thought was to create a SCOM Rule that would report on Security Log EventID 4624 and if the Logon Type was 3 (console logon) or 10 (RDP Logon), send an email. As it turned out, this was much harder than I expected, as I found that Logon Type was not getting consistently passed as a parameter, and doing a text search on the entire message is not good practice.

My next trick was to go back to the Windows Eventlog itself. From Windows Server 2008 and Above, you are now able to attach a schedule task to be triggered by an EventID. However support for Email directory from the task was deprecated in Windows Server 2012, to the point where you cannot use it. This is not as big a deal as it sounds, as you can just use the send-mailmessage cmdlet to achieve the same thing in a script, and attach the script as the triggered task.

However, EventID 4624 can be quite verbose. There is a lot of information in the event message. Powershell would need to parse it and turn it into something readable. This my friends was where things while definitely possible, could have turned very messy.

It was while I was poking around in all the other available logs that ship in Windows Server that I came across the Microsoft-Windows-TerminalServices-LocalSessionManager and from there discovered EventID, which had a message that looked something like this:

Remote Desktop Services: Session logon succeeded:

User: domain\user
Session ID: 3
Source Network Address: 192.168.1.1

Perfect! Perhaps I can get SCOM to simply monitor this log for this EventID, and I won’t have to then filter based on parameter or details in the message! Oh if only…

The Version of  SCOM currently in use where I work has no support for Windows Event Logs outside of the usual Application, Security and System. So back to Powershell scripts and EventID triggered scheduled tasks we go!

The Powershell looks something like this:

$logentry = get-winevent -filterhashtable @{ Logname = 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational'; ID = 21} -MaxEvents 1
$logArray = $logentry.Message.Split("`n")

[string]$emailSubject = ("Local Login to CA - " +($logarray |select -Index 2)).Trim()
$emailBody = $logentry.message
$emailFrom = "servername@mydomain.com"
$emailTo = "alertsemaillist@mydomain.com"
$smtp = "smtp.mydomain.com"

Send-MailMessage -To $emailTo -From $emailFrom -Subject $($emailSubject) -Body $emailbody -SmtpServer $smtp

As you can see, there is still a little bit of manipulation of the event message, mainly to split each line into an array to format the subject. Get-WinEvent is used to access the log as, like SCOM, Get-Eventlog only deals with the 3 main log files.

From here, it is just a matter of selecting the task in the event viewer, and choosing to “attach task to this event…” from the action pane on the right:

A wizard will then guide you through the steps.

I’ll be the first to admit there are probably better ways to do this – 3rd party tools, Heck, SCOM 2016 may well support these log names now. This however works within the constrains I have. It also is not something that would scale, and I acknowledge that.

If there are better solutions, why not leave a comment below to discuss – I’d love to hear from you!

 

Advertisements