Introduction
|
Having a complete visibility over AD-integrated critical servers is usually difficult and can be expensive to
achieve. IT administrators can enable multiple layers of auditing
to track changes but it can be very complex to keep track of all the events.
Also, some applications are not capable of recording all changes done on
them. One of the ways to overcome these complexities and limitations is to
have a video recording of all activities done by administrators when they are
connected locally or via RDP on critical servers. Achieving that is feasible by
using third party tools but it is also feasible to have the same using
Microsoft tools and technologies.
This article shares a way that can be used to implement User Activity
Recording for AD-Integrated Critical servers by combining the use of Group Policy, Powershell
and Orchestrator . This is explained through a scenario detailed below.
|
Scenario
|
CONTOSO is a company that has a Critical application
hosted on AD-Integrated Windows Server 2012 R2 servers. Changes on the
application are strictly controlled and CONTOSO managers would like to have
an implementation that allows them to track all the changes done by
administrators when they are connected locally or via RDP on the servers. The
application does not have an advanced auditing feature and a User Activity
Recording for this server became mandatory.
CONTOSO have the following Microsoft technologies
in use:
CONTOSO have requested the assistance of a
Microsoft partner to develop and deliver a User Activity Recording
implementation that:
Stores the recorded videos on a dedicated File Server
named FileServer1 Archives the recorded videos on Weekly basis Removes the videos that were archived since 90
days or more Does not require extra licensing costs
|
Solution
|
The target setup could be achieved with the
following implementation:
A Powershell script will be used to take periodic
screen captures when an administrator has a local or an RDP session on the
servers. The screen captures will be stored on CONTOSO File Server Orchestrator will be used to distribute the previously
described Powershell script on the servers. A Group Policy will be used to apply the
previously described Powershell script for every user connected locally or
via RDP on the servers A Powershell script will be used to convert the
screen captures to videos Orchestrator will be used to archive the videos
on Weekly basis Orchestrator will be used to remove videos that
were archived 90 days or more in the past
Three folders will be then used on the File
Server to maintain this setup (They will be created on the D driver in our
case):
D:\Images: It will be used to store screen
captures. This folder need to be shared: The share name is
\\FIleServer1\Images in our case D:\Videos: It will be used to store the recorded
videos D:\Archive: It will be used to store the Video
archives
|
Implementation
|
Implementation of periodic screen
captures for locally and RDP connected users
|
The following Powershell script
can be used to take periodic screen captures. It uses Take-Screenshot function published by Boe Prox in Technet Gallery. It will take screen
captures periodically and you can specify the frequency by updating $capturefrequency variable
value. The screen captures will be stored in the shared folder mentioned in $storageshare variable.
|

|
|
Using this Powershell script, the screen captures
will be stored in PNG files with the following names: img[number].png where
[number] is an eight (8) digit number that increments each time a new
screen capture is token (The first value is always 00000001). The PNG files
will be stored under the following path \\FileServer1\Images\YYYY-MM-DD-HH-mm-ss_sAMAccountName
where:
YYYY represents the year when the first screen
capture of the local or RDP session was captured MM represents the month when the first screen
capture of the local or RDP session was captured DD represents the day when the first screen
capture of the local or RDP session was captured HH represents the hour when the first screen
capture of the local or RDP session was captured mm represents the minute when the first screen
capture of the local or RDP session was captured ss represents the second when the first screen
capture of the local or RDP session was captured sAMAccountName represents the User Logon Name
(pre-Windows 2000) of the user havng the local or RDP session
|

|
The following permissions can be delegated to the administrators to allow
storing the PNG files when the script is launched under their credentials:
In our case, these permissions were set on the share
\\FileServer1\Images.
The Powershell script code can be compiled to have an executable file
where the source code is hidden. PowerGUI
Script Editor can be used to achieve that.
|
Screen Capture script automatic
distribution
|
Orchestrator will be used to distribute the Screen Capture Powershell
script on servers that will use it. All you need are:
An SQL table that will be used to store the name of the
servers. Only one column is required:
|

|
Two Orchestrator Runbooks will be used:
A Runbook to get the list of servers to which the
script should be distributed and invoke the second Runbook A Runbook to check if the script is present or
not on the target servers and copy it if it is missing
Let’s start with the second Runbook. You will
need to use six (6) activities:
|

|
|

|
Get File Status: It will allow checking the Powershell script is present on the target
server. In our case, we have chosen C:\Tracking
folder as the script location on target servers so we are
checking the following location \\\c$\tracking\video_tracking.exe
where
is the name of the target server and video_tracking.exe is
the name of the compiled Powershell script.
|

|
The link between Get Computer/IP Status
and Get File Status activities
need to be set with the following include condition: Get Computer/IP Status returns success.
This means that the checks are initiated only if the server is reachable.
|

|
|

|
The link between Get File Status and Copy File activities
need to be set with the following include condition: File exists from Get File Status
equals False.
|

|
|

|
The link between Get File Status and Create Folder activities
need to be set with the following include condition: Get File Status returns warning or
failed.
|

|
|

|
Below is a screen capture of all
the activities included in the second Runbook:
|

|
Once you have created the second Runbook, you can
proceed with the creation of the first one. You will then need to use four
(4) activities:
|

|
|

|
|

|
|

|
Below is a screen capture of all
the activities included in the first Runbook:
|

|
Applying User Activity Recording
script as a log on script
|
Once the User Activity Recording script was automatically distributed by
Orchestrator on the Critical servers, a Group Policy can be created to run
the script when a user logs on them.
As applying log on scripts is a User Policy and we need to target
computers, we need to involve the use of Group Policy Loopback processing.
The following can be implemented:
An interactive log on message will
be displayed to inform the logged on administrator that his activity will be
video recorded. This could be achieved by using the following GPO settings which are under Computer
Configuration\Policies\Windows Settings\Local Policies\Security
Options\Interactive Log on:
|

|
|
Below is a screen capture of the
applied settings – Loopback processing included:
|

|
The left part here is to configure the Security Filtering. You can refer to
the article below for the configuration:
Back to the Loopback: Troubleshooting Group Policy loopback processing,
Part 2:
http://blogs.technet.com/b/askds/archive/2013/05/21/back-to-the-loopback-troubleshooting-group-policy-loopback-processing-part-2.aspx

|
Conversion of screen captures to
videos
|
The previous steps shared how to take screen captures for a local or RDP
user session. With the captured and stored images, we will be able to create
videos for the User Activities. At this step, we will need to use a tool that
is capable of converting images to videos. One of these tools is FFMPEG which is a freeware.
Once downloaded (In our case, we have extracted the tool to be under
c:\FFMPEG folder on the File Server), you need to apply and schedule the
script below to run periodically on the File Server. You will have to specify
the values of the following variables: - $capturefrequency: You
need to specify the same frequency you have set in the previous script
- $foldernotupdate: A
folder containing PNG files will be considered as containing all the required
data if the current time exceeded the number of minutes you specify for this
variable since the last update. The script can then proceed by creating the
video using PNG files in this folder
- $path: You need to
specify the local path for the Images folder
|
|

|
Remark: If you have
extracted the tool to be under a different folder then you need to update
ffmpeg.exe path in the script.
The script works as described below:
It will check the folders containing PNG files
that were not updated recently (using the parameter described previously) It will copy the missing file structures from
D:\Images to D:\Videos It will convert PNG files to a Video It will remove the PNG files after the conversion
|
Implementation of video archiving
|
Orchestrator can be used to implement video
archiving and a single Runbook would be enough.
You will need to use four (4) activities:
|

|
|

|
|

|
|

|
Below is a screen capture of all
the activities included in the Runbook:
|

|
Implementation of archive
automatic retention
|
To implement an automatic retention for archives
using Orchestrator, you will need to use three (3) activities:
|

|
|

|
|

|
Below is a screen capture of all
the activities included in the Runbook:
|

|
Example of recorded Video
|
|
|
Conclusion
|
This article shared a way to
implement User Activity Recording by combining the use of Group Policy,
Powershell, Orchestrator and a freeware. It allows companies to implement an
advanced tracking of changes done by local or RDP sessions on critical servers.
The created videos have few Megabytes of size but IT administrators should
properly estimate the required size for the storage before implementing the
solution.
|