A GPO exist that can be configured to automatically delete old user profiles and a process such as CircularLogArchivercan be used to clean up log or old data but what about user data?

UserResouceCleanup can take care of this by monitoring the user data folders and Active Directory.


a) Download and extract (here is VirusTotal scan) to a folder of your choice on the computer which it will be scheduled to run on.

b) Run Configurator.exe (Configurator Editor).

c) On the Encrypt tab, enter the password for the account that will be performing the automated placement task. Encrypt it with key bRK92kDpCqpnPMEtFp1cdJXixgqOqSKFUZ and record encrypted password

d) On the Settings tab, enter the domain information, connection username and the encrypted password recorded in step c. Configure UserNameMatch to a RegEx query that will match user account format. If you do not have a specific format, use .*

e) On the UserFolderLocations tab, specify folders to monitor to redundant user data

f) On the UsersToSkip tab, specify user folders to skip

g) Save configuration files

h) Schedule UserResourceCleanup.ConsoleApp.exe as a scheduled tasks


Using this process will keep recover space by removing old/redundant user data, just make sure that you have backups to cheap/slower storage in case you need to recover data.

Automated object placement using AutoAD


1) Computer Description Update Process

a) Delegation

To be able to update computer descriptions you need to delegate rights.

Add the following permissions to Active Directory either to the root of the domain or any other Organizational Unit. You would add it to an Organizational Unit if you only want to use this process for some computers

b) Powershell Script

Below is the Powershell script used to update the computer description.

It is important to note that you should not change the format of the message if you are planning to use my automated object placement process.

This script will be used within a group policy in step c

        # Get current user name
        $strUserName = $env:username;

        # Get current computer name
        $strComputerName = $env:computername;

        $objADSystemInfo = New-Object -ComObject ADSystemInfo;
        $objType = $objADSystemInfo.GetType();

        # Get current site name
        $strSiteName = $objType.InvokeMember('SiteName', 'GetProperty', $null, $objADSystemInfo, $null);

        # Get current date and time
        $strLogonDate = Get-Date -Format "dd-MM-yyyy HH:mm:ss";

        # Build message
        $strMessage = "$($strUserName) logged in on $($strLogonDate) at $($strSiteName) site";

        # Get computer object from Active Directory
        $strFilter = "(&(objectCategory=Computer)(name=$strComputerName))"
        $objSearcher = New-Object System.DirectoryServices.DirectorySearcher
        $objSearcher.Filter = $strFilter
        $objPath = $objSearcher.FindOne()
        $objComputer = $objPath.GetDirectoryEntry()

        # Update computer object description with message in Active Directory
        $objComputer.InvokeSet("Description", $strMessage)

c) Group Policy Object

Create a GPO and link it to the root of a domain or Organizational Unit used in step a

Add the PowerShell script from step b as a User Logon script

d) Result

After these steps, notice how the computer descriptions are automatically populated once the users log on to their computers

2) AutoAD

a) Download and extract (here is VirusTotal scan) to a folder of your choice on the computer which it will be scheduled to run on.

b) Run Configurator.exe (Configurator Editor).

c) On the Encrypt tab, enter the password for the account that will be performing the automated placement task. Encrypt it with key 2xCJvezFBYWQPBeHy7USdajK55M8skww and record encrypted password

d) On the Settings tab, enter the domain information, connection user name and the encrypted password recorded in step 2c.

Specify which objects AutoAD should create automatically

e) Specify Active Directory information. The format for these are Subnet/Bit Mask|AD Site Name|Computer DN|User DN

Subnet/Bit Mask: The subnet and mask (in bit format) for the specific entry

AD Site: The Active Directory site to which the subnet belongs

Computer DN: The distinguished name of the organizational unit where to move computers to for computer objects in this subnet

User DN: The distinguished name of the organizational unit where to move users to for user objects in this subnet

Please Note: Ensure that you do not allow users/admins to gain any additional permissions by moving users from one container to another. The reason for this is that a user move might be forced to an incorrect OU if descriptions are tampered with. 

f) Specify any user DNs that should be skipped

g) Specify any computer DNs that should be skipped


After implementing ComputerDescriptionUpdate.ps1 notice how computer descriptions are automatically updated

AutoAD.exe output

Sites and subnets automatically created by AutoAD

Organizational Units automatically created by AutoAD

Object placement (example 1)

Object placement (example 2)

Object placement (example 3)

Object placement (example 4)


Using this process will keep Active Directory organized and objects in the correct Organizational Units

Active Directory Cleanup Tool (ADCleanup)


ADCleanup is my implementation of a set-and-forget Active Directory cleanup tool. Once this tool is implemented correctly, you never need to worry about dormant accounts ever again.


1) Download and extract (here is VirusTotal scan) to a folder of your choice, saved on the computer on which it will be scheduled to run.

2) Create a location in Active Directory to store inactive user accounts and record the distinguished name (DN).

3) Create a location in Active Directory to store inactive computer accounts and record the distinguished name (DN).

4) Run Configurator.exe (Configurator Editor).

a) On the Encrypt tab, enter the password for the account that will be performing the cleanup task. Encrypt it with key 9hOK7AtlGOCRyBtBdhF9pnTQuk8ES176 and record encrypted password

b) On the Settings tab, enter the fully qualified domain name, cleanup account user name and the encrypted password recorded in step 4a

c) Set userCleanup to true to enable the process to clean up user accounts. Set user cleanup parameters

d) Set userDisabledOUto value recorded in step 2

e) Set computerCleanup to true to enable the process to clean up user accounts. Set computer cleanup parameters

f) Set computerDisabledOU to value recorded in step3

g) On the userExcludedDNs tab, specify any distinguished name of an organizational unit that should be excluded from the cleanup process  (+ or INS to add, – or DEL to delete, Enter or double-click to edit)

g) On the computerExcludedDN stab, specify any distinguished name of an organizational unit that should be excluded from the cleanup process (+ or INS to add, – or DEL to delete, Enter or double-click to edit)

h) Schedule ADCleanup.exe to execute via a scheduled task. Upon every execution, the tool will clean up user and computer objects as per your configuration


Using this process, (or one similar) will keep Active Directory clean from the unused computer and user objects, and increases server security in the process.

How to run commands using SYSTEM account


This is a process I use whenever I get an “Access Denied” message. One example of this is when I do not have access to SQL Server directly, only administrative rights to the actual server.


1) Download PsExec which is part of the PsTools suite

2) Extract to a convenient location. I usually copy PsExec.exe to the System32 folder. This allows PsExec.exe to be executed from any folders without specifying the full path.

3) Execute the following command

PsExec.exe -s -i -d CMD.exe

4) From within this new command prompt, everything you open will open as the SYSTEM account.


Viewing NT Secrets

Open Regedit.exe and you will be able to see content of HKEY_LOCAL_MACHINE\SECURITY

  • This allows you to view passwords that were stored as NT Secrets

Opening SQL Server Management Studio as SYSTEM

Open SQL Management Studio and you will be able to log on with SYSTEM

  • This allows you to access SQL without directly having been granted SQL right yet you have administrative rights to SQL Server

You will be able to browse to any folder that only allows SYSTEM account

  • You can export permissions with SetACL/ICACLS to folders that administrators group might have been removed on
  • Kill processes that give error Access Denied when you try to terminate it with normal Administrator rights

WinDirStat/TreeSize etc.

Running something like TreeSize as SYSTEM will actually give you a better view and understanding of what is using space because you will get less access denials

Some others…

  • Simulate GPO start scripts
  • Simulate GPO based MSI installation
  • Diagnose why scheduled tasks that run as SYSTEM don’t run as intended
  • Start/stop protected services


Using this process, (or one similar) will allow you to start processes as the SYSTEM account allowing you to access parts of files system, registry and application not accessible with normal Administrative rights.

How to extract hashes from IFM backup

Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed.
Methods exist to extract hashes directly for a live domain however this article describes a process to extract user data, including hashes from an IFM backup.

1) Overview

Overpermission and weak/reused passwords are probably the most common security issues found in Active Directory. To address the password issues, it is important to do regular password audits, to address over permissions, see my article about Active Directory delegation.


2) Password Hashes

Passwords are stored in Active Directory (NTDS.dit encrypted with a boot key) as an unsalted MD4 hash and as such, to check for password reuse it is a simple case of checking for duplicate hashes in the extracted hashes list.


Finding weak passwords are a little trickier. You need to lookup hashes against a rainbow table to ensure you do not have any weak/compromised hashes within your environment.


Both of these are out-of-scope for this article, this article focuses on extracting password hashes.


3) Extracting Password Hashes

a) On a Domain Controller


Start an elevated command prompt and run:


activate instance ntds
create sysvol full C:\Temp\Backups\IFM\


Command Output

IFM Files


b) On Administrative Computer


Copy the IFM folder and run the following PowerShell script elevated (just copy and paste):


//Download DSInternals from PowerShell Gallery
Save-Module -Name DSInternals -path 'C:\temp\DSInternals'

//Install DSInternals
Install-Module -Name DSInternals

//Import DSInternals Module
Import-Module DSInternals

//Get Boot Key from Registry section of the IFM. If Boot Key is blank, Get-ADDBAccount will still return usernames
$key = Get-BootKey -SystemHivePath 'C:\Temp\Backups\IFM\registry\SYSTEM'

//Store objects data
$hashes = Get-ADDBAccount -All -DBPath 'C:\Temp\Backups\IFM\Active Directory\ntds.dit' -BootKey $key

//Convert object data to the desired format
$hashes | Format-Custom -View Ophcrack | Out-File C:\Temp\Backups\Hashes.txt


Hashes.txt File



Weak Passwords Found (Getting password from hashes out-of-scope for this article)



Active Directory – Simple Tier Isolation

This article demonstrates probably the easiest way to configure domain-wide tier isolation within Active Directory.
If you do not know tier isolation read

1) WMI Filters

Create WMI filter that will identify devices for each tier. In the article three tiers are used, domain controllers, servers and workstations. This provides a balance between security and simplification but this can easily be extended to other devices
or server types.





2) Groups

Create a group for each tier. This will hold the members for each tier.



3) Group Policies

Create a group policy for each tier. It should filter based on the tier type and will contain the allow/deny rules.








4) Add members to tier groups

Finally, add your dedicated DA accounts to tier 0 group, dedicated server administrators accounts to tier 1 group. Accounts will now only be able to log in locally or via RDP if they are meant for the specific tier



How to find Active Directory Group Policy (GPO) that applies a particular setting

This article shows the method of using the Resultant Set of Policy Tool to locate Group Policy that applies a particular setting.

Suppose we have a computer to which we cannot Remote Desktop to but we are unsure which policy configured this.

This article shows the method of using the Resultant Set of Policy Tool to locate these settings with ease.

1.pngStep 1) Open RSOP.msc and change query to the user and computer to which the
setting, Allow log on through Remote Desktop Services is this case, is applied to


From the Properties Menu on the root of the RSOP tree, select Change Query

1a.pngFrom the Resultant Set of Policy Wizard specify the computer to generate RSOP
report for. If the RSOP is for the local computer, select the This computer option and click Next

1b.pngFrom the Resultant Set of Policy Wizard specify the user to generate RSOP
report for. If the RSOP is for the current computer, select the Current user option and click Next, Next and Finish

1c.pngStep 2) From the Resultant Set of Policy Main Screen (1),
browse to the setting to which the Group Policy is unknown, Allow log on through Remote Desktop Services (2) is this case. As seen below, this setting originates from the Problematic GPO (3)

2.pngStep 3) Editing GPO Problematic GPO via Group Policy Management Editor shows that indeed, the setting is part of this policy


Configure Photo Screensaver via Active Directory Group Policy

This article explains the steps required to use the default Photos screensaver to display branding/corporate images

1) On reference computer, configure the default Photo screensaver including location. This is done because this value is stores as an encrypted value within the Registry. In the article C:\Winstoredranding\Dundermifflin is used.

1.jpg2) Open Regedit and browse to HKCU\SOFTWARE\Microsoft\Windows Photo Viewer\Slideshow\Screensaver and record value for EncryptedPIDL

2.jpg3) Store images that will be used for the screensaver in a network location The Domain DFS is perfect for small
files like these

5.jpg4) Create a new policy and add the EncrypedPIDL registry value to User Configuration > Preferences > Windows Settings > Registry
new3.png5) From the Common tab enable the Remove the item when it is no longer applied option

4.jpg6) Add the images to  User Configuration > Preferences > Windows Settings > Files. The
Source File(s) should be the network location used in Step 3.

TIP: Press F3 to open Variable Reference List

6.jpg7) For the Destination File, specify filename with location from Step 1

7.jpg8) From the Common tab enable the Remove the item when it is no longer applied option

8.jpg9) Configure the rest of the policy as per norm for screensaver.

9.jpg10) For the Force specific screen saver specify %Systemroot%\System32\PhotoScreensaver.scr



Delegation the proper way

This article describes my battle tested process for setting up delegation.
I use this process anywhere that I need to setup delegation.

In the article I will show how it applies to Active Directory

This delegation model consists of Delegation Groups and Role Groups. These groups are explained in the following sections.

delegate.pngDelegation Group

Delegation groups are named according to the permission that they grant. The permission that it grants can be, but is not limited to, AD permission to do a specific task.



  • Can only contain Role Groups
  • Cannot be members of any groups

Some examples of a built-in Delegation Group

  • Domain Administrators
  • Account Operators

Some examples of a custom Delegation Group

  • Password Reset
  • Manage Group Memberships


roles.pngRole Group

Role groups should be created based on a specific role that group of people fulfil.


These groups are used to add delegation permissions to via delegation groups.This is done by adding the Role group as a member of the delegation groups for the permissions required.

It is worth noting that this delegation is not limited to AD permissions.


If the Help Desk supports SharePoint environment, a delegation group with certain SharePoint rights can be created and assigned to the Help Desk role group. This way when a new Help Desk employee starts, it is only required to add a user account to the
Help Desk Role group.



  • Can only contain privileged user accounts
  • Can only be member of Delegation Groups

Some examples of a Role Group

  • Help Desk
  • Server Administrators


  • No delegation against individual user accounts
  • Reuse of Delegation Groups
  • Easy to manage
  • Quick to determine permissions
  • Uncomplicated to assign correct permissions to an individual based on their function


Real world example

Typically help desks will be given delegated permissions to reset passwords. Instead of delegating permissions to various individuals or directly to the help desk group, the following should be done:


  1. Create an intermediate group, DG-ResetPassword in this example. This is the delegation group.
  2. Delegate the Reset Password permission to the DG-ResetPassword group.
  3. Add the help desk group role group, RG-HelpDesk in this example, to the DG-ResetPassword delegation group


By utilising this delegation process, all delegation done to role groups is easily visible from the Member Of tab. In the example below, it is easy to see that the role group for Help Desk, RG-HelpDesk, have join domain,
modify group and reset password rights.


2.jpgIt also enables the reuse of delegation groups. In the example below, the same delegation group used for Help Desk,
DG-JoinDomain, can be used to assign join domain rights to the Workstation Technician group.


3.jpgThe reverse is also true. It is quick to see which groups have a particular permission. In the example below, looking
at the members of the DG-JoinDomain delegation group, it shows which role groups, RG-HelpDesk and RG-WorkstationTechnician in this case, have permissions to join computers to the domain.




Active Directory Locked Account Investigation Process

This article outlines the process to identify and resolve account lockout in an Active Directory environment.



1) Change lockout policy according to Microsoft Recommendation


The lockout policy’s ultimate goal is to protect against automated password guessing (brute-force attack) and as such, the value should be high enough so that accounts are not accidentally locked out by an end user or incorrect saved password.




As per the following articles, I would recommend the following lockout settings


  • Account lockout threshold 50
  • Reset account lockout counter after 10 minutes



2) Enabling Auditing


Identifying the source of the account lockouts in a complex environment will be virtually impossible without auditing enabled.


Please note: Only events that occurred after enabling auditing will be logged. It also might be necessary to increase Security log file size




3) Identify source device that lockout occurred on


3.1) Event Comb



Part of Account Lockout and Management Tools


Still a useful tool in a pinch.

Please note: Built-in search for account lockout is not using the newer event IDs. To search newer IDs, add 4625 4740 4771 4768 4776 to the list


For details on these events, see




All gathered events from selected domain controllers will be saved into text files in the temp folder

3.2) Lockout Status



Part of Account Lockout and Management Tools


When you start tool you specify the user account to inspect.


Please note: If the lock device is a Domain Controller, you have to follow the trail until you get to the actual source device name



3.3) AD Audit





My personal favorite, AD Audit makes finding the source account that locks device super easy, just use built-in reports




4.1) Powershell





4) Identify source process that locked account


4.1) NetWrix Account Lockout Examiner





Install NetWrix Account Lockout Examiner on another computer. After that run it and point to the device that generates lockouts.



4.2) ADAudit





As I said before, my personal favorite. After finding source account that locks device using built-in reports, the Account Lockout Analyzer can show the source process that locks accounts




5) Implement processes to prevent future lockouts


5.1 Windows Services, Scheduled Tasks and COM Objects

Utilize service accounts with strong non-expiring passwords or managed service accounts.

5.2 Drive Mappings

Do not map drives with explicit username and password. Utilize Group Policy User Drive Map Preference to map the drive mappings.


Drive-Map-2.png5.3 Logon Sessions

Implement RDP inactive/idling session logoff.



5.4 Credential Manager


Disable Credential Manager service. This will prevent users from saving/using stored passwords



If your account that you are using for the investigation is locking, rename your username for the duration of the investigation