Audit Login and Logout Events Using Login Scripts

Audit Login and Logout Events Using Login Scripts

Auditing network, and indeed local events on systems is becoming a big factor in the business world now, and while the Windows Server 2003 platform allows for extensive auditing, there is what I would loosely refer to as a major floor in the planning and eventual compiling of the auditing features. This floor resides within the Audit: Account Logon Events policy, and does not allow you to, nor is there a seperate policy for auditing of account logoff events.

A Windows Server 2003 Domain COntroller does not even keep any track of a user logging off. The only event records are when a user logs on, and the nearest DC is contacted for Kerberos Authentication.

This means that the in built auditing features are useless when faced with a situation whereby managers want to check the times that their staff log in and out of the system. There is a perfectly good work around however, by the means of some simple VB and using the scripts section of a GPO (Group Policy Object).

Log File Share
The first step in this process is to create a location for the log files to be created and stored within. Create a new folder on the D:\ drive (or a drive of your choice) called LogReports. You now need to share this folder, and i would suggest sharing it as LogReports$. The $ will cause the share to be hidden from the general network, and therefore from enquizitive users who may just stumble across their own logs. You now need to check the permissions on the share, setting these to Everyone – Full Control.

The VBS Scripts
Next up is the actualy VBS that we need to create the log files. We need to create two files here, .txt files renamed to .vbs, and I would recommend creating them in the following location:

\\ServerName\SYSVOL\ForestName\Scripts

LogonLog.vbs is the first file to create, and should contain the following code:

On Error Resume Next
Set objNetwork = Wscript.CreateObject(“Wscript.Network”)
Set objFSO = Wscript.CreateObject(“Scripting.FileSystemObject”)

set objTextFile = objFSO.OpenTextFile(“\\ServerName\LoginReports$\” & objNetwork.Username & “Usage.csv”,8,True)
objTextFile.WriteLine year(date()) & “-” & month(date()) & “-” & day(date()) & “,” & time() & “,Login,” & objNetwork.Username & “,” & objNetwork.ComputerName
objTextFile.close

So, a quick run through what this code is saying…First off we tell it to move onto the next script if there are any errors while executing this code. A network object is then created, and then a file system object is created. These are needed as we are catching network information, and placing it into our local file system. The second part of the code creates a text file object, sets the location of the file (our share) and specifies what data to log, and the file name. If you notice, we have specified objNetwork.Username which gives us who is logging in, and then concatonate that to Usage.csv. This will give us a file name of AdministratorUsage.csv for example. 8 specifies that the file is appendable, and true allows the file to be created if it does not already exist.

LogoutLog.vbs is up next, and is pretty much the same, but for the word logout.

On Error Resume Next
Set objNetwork = Wscript.CreateObject(“Wscript.Network”)
Set objFSO = Wscript.CreateObject(“Scripting.FileSystemObject”)

set objTextFile = objFSO.OpenTextFile(“\\ServerName\LoginReports$\” & objNetwork.Username & “Usage.csv”,8,True)
objTextFile.WriteLine year(date()) & “-” & month(date()) & “-” & day(date()) & “,” & time() & “,Logout,” & objNetwork.Username & “,” & objNetwork.ComputerName
objTextFile.close

Creating The Policy To Apply The Scipts
You now need to specify a policy to apply these new scripts. Create a new GPO called Audit Scripts, and link this to the Domain level. You could also link this to the OU level as well should you only want to apply the audits to specific departments etc. Open the GPO in the GP Editor, and expand the tree to:

User Configuration\Windows Settings\Scripts (Logon/Logoff)

For both logon and logoff, view the poperties, hit the add button, and browse to the relevent script you have just created in the SYSVOL folder.

Testing The Policy
That is all there is to this, and all you now have to do is refresh the policy, and run some test logins and logouts. Try it with a few different usernames if possible to get an idea of what csv files are produced here.

Viewing The Log Files
To view the logs, browse to the share you created before, and simply find the log for the user you need to check up on. They should be viewable in either notepad or excel, and should resemble something similar to the following text:

2008-12-17, 0:04:55 AM, Login, Administrator, ComputerName
2008-12-17, 0:05:55 AM, Logout, Administrator, ComputerName
2008-12-17, 0:07:32 AM, Login, Administrator, ComputerName

One Last Consideration
One last thing you may want to consider is the fact that the share has Everyone – Full Control share permissions. You may want to lock this down with the use of NTFS permissions, but you need to remember that its the user who is running the scripts, and as such needs sufficient permissions to create and update the csv file within the share.

Group Policy Desktop Lockdown Guide

Group Policy Desktop Lockdown Guide

So, what am i going to tackle in this first installment? Well, at work there is a company policy which states that no machine should have a desktop background image, the background should be standard windows blue, and the theme should be windows classic.

As things were we had some policies defined in our Default Domain Policy which locked it down to a certain extent, but it was still open to loop holes. So here is what i needed to acheive this morning:

• Users must not have a desktop background image
• Users desktops must be standard windows blue
• Users Windows theme must be set to classic (XP applicable)
• Users must not be able to use the web feature with active desktop
• All settings must be checked/applied on every login

There is no nice and simple way of doing all of the above in one place, and for the full effect, you need to use a combination of policies withing a GPO, and adding in some custom .adm files to that GPO.

The first thing to do in this situation is to enter your AD structure and open the GPO you wish to use to apply these settings. This can be your Default Domain Policy, although i would recommend using a new GPO and applying it to the correct OU as required, rather than having it effect all your servers and DC’s as well.

Desktop Functionality Settings
First things first, you need to expand your GPO to the Desktop folder:

User Configuration\Administrative Templates\Desktop

Within this folder there are three policies which need to be defined, and by defined i mean set to enabled or disabled. Be careful when defining policies in a GPO as the option to turn something on can actually be “disabled”. It’s all in the wording of the policy details. The policies should be configured as in the image 1.

Display Properties Settings
The next step in implementing this solution is to lock down what the users are able to do in terms of display settings. This as above is pretty straight forward. Navigate to the following location in your GPO:

User Configuration\Administrative Templates\Control Panel\Display

Here there is just one policy which must be defined. You could argue that you could define more, but they are not needed for this complete lock down. The policies in question are “Hide Appearance and Themes Tab” and “Prevent Changing Wallpaper”. Appearance and Themes is a personal choice, and i found it best not to block this tab as some users prefer to have larger text on screen etc. Without this they cannot alter the text sizes. Prevent Changing Wallpaper is pointless being set as there will be no Desktop Tab anyway. Configure the policies in this folder as follows (image 2).
You now need to drill down one more level into the following folder:

User Configuration\Administrative Templates\Control Panel\Display\Desktop Themes

There is only one policy to be defined in this folder. Define as below, and make sure you leave the image path field empty. (image 3)
Working With The .ADM Files
We have now set all the required policies with in the GPO and need to turn our attention to two things that the GPO cannot diretly effect. This is where we need .adm files. In this situation we need a .adm file to acheive the following:

• Set the default background colour reg key
• Remove any default manufacturer background or background users have previously applied

To keep things simple, i will do the following with a seperate .adm for each of the above. For each of the following code snips, create a new text document, paste the code in, and save as suggested filename with the .adm extension.

This is the .adm file to set the background colour. 85 110 165 is the RGB value for the windows default blue. This .adm will set the HKEY_Current_User\Control Panel\Colors\Background key value to the RGB value. This will get applied at every login/GPUPDATE so should the user manage to get round the system, it will just get reset when they login.

CLASS USERCATEGORY “Custom”
POLICY “Background Colour”
KEYNAME “Control Panel\Colors”
PART “Background”
EDITTEXT
DEFAULT “85 110 165″
VALUENAME “Background”
END PART
END POLICY

END CATEGORY

This second .adm is responsible for removing any manufacturer or current user desktop image. As with the above, this gets set on every login/GPUPDATE. This edits the HKEY_Current_User\Control Panel\Desktop\Wallpaper key value.

CLASS USERCATEGORY “Custom”
POLICY “Remove BG Image”
KEYNAME “Control Panel\Desktop”
PART “Wallpaper”
EDITTEXT
DEFAULT “”
VALUENAME “Wallpaper”
END PART
END POLICY

END CATEGORY

These 2 .adm files now need to be added into the GPO you have just been working with. to do this right cick on Administrative templates within User Configuration, and select “Add/Remove Templates”. Click the add button, browse, and add in the 2 .adm files you have just created. Once they are both listed, click close. At this point it may freeze for a few seconds while the settings are imported.

Once the import is complete you should have a new folder withing the Administrative Templates of User Config called “Custom” – just as it was defined in the .adm code. With the Custom folder highlighted, click on “view” and select “filtering”, then uncheck the option to “only show policy settings which can be fully managed”. Once done you should now see your two new policies listed within the custom folder. We now need to define these as below. (image 4)
For each of these policies, when you click the enabled option, the text value field becomes available. Leave these as they are. The BG Colour should already be at 85 110 165 and the BG Image should be, and remain blank.

Finishing Touches
That is essentially everything we need to do. I did manage to get confused with the time delay on GPUPDATE, and found some screens having a default colour of black where they had not yet fully updated the GPO settings. This is resolved with a quick local GPUPDATE /FORCE and it is worth running standard GPUPDATE on your domain controller at this point also.

This should be the job done, and once all Group Policy updates are completed, it should effectively have acheived all the original objectives