Receive alerts when user connects or disconnects from RDP

If you administer a forward facing terminal server or even if you have an RDP connection setup on your home Internet connection for quick access to your home network, then it serves as extra piece of mind to have a means to receive alerts when a user connects or disconnects from that RDP connection.  Using a combination of Scheduled tasks, powershell, and batch files, we can effectively enable alerting via email/text alert when users either Login/connect or Logoff/disconnect from an RDP session.

Script files

The key to being able to effectively log user activity are the script files.  Let’s start with the powershell side of things.  First we have a powershell script that essentially gets the user that is connected via port 3389.

get_loggeduser.ps1 contents

echo $env:username
netstat -an | select-string ":3389" | select-string "ESTABLISHED"

This powershell snippet echos the user name that is connected to the common RDP port 3389.  If you are using a different port for RDP, of course you would alter the command for that specific port.

In order to send that information to email or text, we use another powershell script to accomplish that:

sendmail_login.ps1 contents

$SMTPServer = “smtp.gmail.com”
$SMTPPort = “587”
$Username = “[email protected]”
$Password = “yourstrongpassword”

$to = “[email protected]”
$cc = “[email protected]”
$cc2 = “somenumber@@txt.att.net”
$subject = “Someone connected via RDP”
$body = “Attached are the user details”
$attachment = “C:yourdirectorylogin.txt”

$message = New-Object System.Net.Mail.MailMessage
$message.subject = $subject
$message.body = $body
$message.to.add($to)
$message.from = $username
$message.attachments.add($attachment)

$smtp = New-Object System.Net.Mail.SmtpClient($SMTPServer, $SMTPPort);
$smtp.EnableSSL = $true
$smtp.Credentials = New-Object System.Net.NetworkCredential($Username, $Password);

$smtp.send($message)
write-host “Mail Sent”

The code above will send an email using a valid gmail account for SMTP connectivity.  You can send to recipients email or text by using the email to text addresses from either ATT or Verizon.

Now we need a batch file to tie everything together in our scheduled task events:

login.bat contents

@echo off
C:WindowsSystem32WindowsPowerShellv1.0powershell.exe -command .get_loggeduser.ps1" > c:somedirectorylogin.txt
C:WindowsSystem32WindowsPowerShellv1.0powershell.exe -command .sendmail_login.ps1"

Above we use the get_loggeduser.ps1 file to echo into a text file which gets attached to our email in the script above as login.txt.  This will contain the user name that logged in as well as the remote IP address the user is connected from.

Scheduled Task

Now that we have the hard part of getting the files in place that we need, we simply need to create some scheduled tasks that fire an action when an event is logged for users logging in or reconnecting a session.

In the screenshots above, we have setup a scheduled task that begins the task “on an event” and we are going to watch the Log located at Microsoft-Windows-TerminalServices-LocalSessionManager/Operational and look for Event ID: 21 and 25.  The Actions tab contains the location of our login.bat file we have the contents of above.  Here it is located under c:windowsoptions.

Event IDs 21 and 25 are for login/reconnect and event IDs 23 and 24 are for logoff/disconnect.  You can use those to trigger off actions appropriately.

Putting it all together

So in thinking about what we have accomplished here to put it all together and logically see the chain of events.  When a user logs in/reconnects the scheduled task will call the login.bat file which runs the get_loggeduser.ps1 file and the sendmail_login.ps1 file which contains an attachment of the user information (user name and remote IP address) to recipients that are designated.

Shortly after a user logs in or reconnects, you should see an email pop in or text message come to the destinations of your choosing.

Final Thoughts

This is a relatively crude way to achieve good alerting when and if users connect to a terminal server via RDP.  The scripts can probably be engineered better and I may follow up the post with some streamlined coding and conditional statements to handle certain events a little better.  However, in a pinch, this solution has worked for me setting up alerting for myself and others on terminal servers.