Learning from the field - Understanding and Auditing Active Directory Group Policy

Hope you got a chance to read my previous blog post on understanding the basics of Active Directory (AD) Group Policy (GPO). If you haven't checked that, please do, as the same would serve as a base prerequisite for this current post.

This blog post tries to focus on exhaustive methods and ways to identify and extract various information pertaining to group policy and it's settings in an AD environment that could be used for auditing i.e it focuses majorly only on How part of auditing AD GPO to keep it as generic as possible. However, on a practical scenario only some of the details / testing methods mentioned in this post might be required depending on type of control or the audit flavour.

The Which (i.e. which configurations to check) part of auditing differs from standard to standard for which the audit is being carried out and is out of the scope for the current post.

If you would like me to write a blog post on auditing for a specific standard, feel free to drop it in your comments below and I would be more than happy to write a post on the same.

The examples demonstrated in this post were carried out on Windows 2008 R2 Server SP1 with Powershell v5 . However, there shouldn't be much challenge on following the same strategy on any other higher versions of Windows Server Editions as they have been tried and tested in various other Windows Server editions in real life audit engagements.

Now lets get into the topic.

Auditing Active Directory Group Policy

When we proceed for the audit phase of AD GPO, the following information should be gathered from the auditee organization.

The audit scope within the AD (specific site(s)/domain(s)/OU(s)) environment which should be audited.
Number of Domain Controllers for a given domain.
The required configuration that is supposed to be implemented at the policy level depending upon the type of Audit (Input Source: Audit Standard Requirements, Organization Policy and Procedure, Industry best practices, International Standards, Applicable Regulatory Standards, Compliance etc. ).
Design of AD Structure (To understand how different OUs and Sub-OUs are setup, the various types of privilege profiles/ groups that are maintained and the reason for the same etc..)
If there has been any other security settings employed apart from standard GPO settings such as third party AD plugins and security configuration softwares. (This will not be covered in this post. However, I might write another post soon on how to approach audit testing in case of such customizations in AD environment.)

Even in case there is a restricted scope within the AD for the audit engagement, we need to consider every GPO that has been configured in the domain as GPOs follow inheritance. So if a GPO has been enabled / enforced at the domain root level, it would get inherited / applied unless explicitly blocked at the in-scope OUs / Site within the AD through Block Inheritance setting. This has to be explained to the client in case there is any resistance to provide evidence of all the GPOs.

The above points are subjective and can be understood only with discussion with the client. Hence we assume that the above information is already present with the auditor before proceeding with the following methods.

To get a basic general overview of AD structure and basic security settings such as Administrative Privileges and Password Settings. Check out a Powershell Module here. It is very informative and gives you a beautiful MS Word Report.

General Disclaimer :-

Please note that the scripts / commands being referred in this post extract exhaustive informations from AD and may be memory intensive depending on the size of the Auditee's AD environment and in rare case may hang / corrupt the server. Hence we should notify the Auditee organization about the risk of execution of these scripts and proceed with audit accordingly.

The author of the post claims no responsibility in case execution of suggested scripts leads to any unforeseen / undesirable situations.

The scripts mentioned in this post for extracting informations have been collated from various online sources and customized as required by the author of this post. The author claims no ownership on the scripts used / mentioned in this post.

Note: The scripts mentioned in this post have the following requirements to be present in the target server to function properly.

Powershell v3 or above
Powershell Group Policy Module
Powershell Active Directory Module

Extract the Required Details for Auditing GPO

Following are the list of informations to be extracted from the AD.

List of all GPOs and their metadata / properties.
List of settings configured in each of the GPO
List of AD Objects with their properties within the audit scope of AD.
Resultant Set of Group Policy settings applied to each of the AD objects.

1. Extracting list of GPOs and their metadata / properties.

The list of all GPOs and their details can be obtained from Group Policy Management Console (GPMC).

List of GPOs configured in the domain can be found under the "Group Policy Objects Container" in GPMC.(Refer Figure 11 in the left side of the pane)

The details of the GPOs required for us to proceed with analysis phase of audit has been given below along with location where these details can be found in GUI.

SOM - Scope of Management (SOM) are containers i.e a site / domain / OU where user and computer accounts reside. In this case, it is a container where the corresponding policy is linked / applied. In the below picture , an example, an OU named "Chennai" is a the SOM for the corresponding policies "ChennaiWallpaperGPO" and "FinanceGPO" linked to it's container.

Figure 1

SOMPath -A distinguished name for the SOM. Distinguished Name identifies an object in a tree structure of the AD environment. It can be viewed in the "Attributes" tab of the corresponding OU's properties in "Active Directory Users and Computers" window.

Figure 2

Name - Name of the GPO. Name is highlighted below for a sample GPO in GPMC window.

Figure 3

GUID - Globally unique identifier of the concerned GPO

GPOPath - Fully Qualified Distinguished Name of the path where originally GPO object resides.It resides in a container named "System\Policies" under the Domain Schema.This container can be viewed from an in-built tool named "ADSI Edit". Open "ADSI Edit" tool and connect to the Policies container as given in the below image. The string highlighted in the image is for a test domain called test.com. The string has to be changed accordingly for the domain that is being audited.

Figure 4

In the below image, we can find the GUID of the policy in the "Details" tab on the right pane of the Group Policy Management Console(GPMC). The corresponding GPO Path can be found in the "ADSI Edit tool" in the right pane under "distinguishedname" column.

Figure 5

Link Enabled - Tells whether the policy has been linked / applied to the OU.

Enforced - Tells whether the concerned policy has been enforced. It means whether it has been configured not to be overridden by any of the policy settings down the inheritance order.

In the below image, in the right pane, we can see that "ChennaiWallpaperChangeGPO" has been linked to Chennai OU and has been enforced.The lock symbol in the GPO symbolizes it has been enforced.

Figure 6

Precedence - Tells the precedence value of the linked Group policy within the concerned container.

In the below image, we can see the precedence values of GPOs linked to the "Chennai" OU in the right pane under the "Group Policy Inheritance" .

Figure 7

Block Inheritance - This setting is applicable to the container where the GPOs are linked and not to the GPOs. It determines if the policies which are in the higher order of the AD Structure be inherited into the concerned container or not. Whenever this settings is enabled, the container is marked with an exclamation mark symbol.

Figure 8

LinksTo - This gives out the container paths in the Domain structure where the concerned policy has been linked. In the below case, we have "FinanceGPO" linked to two containers Chennai and Finance OU.

Figure 9

Creation Time - Date and time when the GPO was created.

Modification Time - Date and time when the GPO was modified.

Comment - Gives out a basic description about the GPO if it has been set by the GPO creator. It helps in determining why the GPO was created and linked. Helps during auditing.

Owner - One who can modify and assign permission for a given GPO.

GPOStatus - Tells which part of GPO has been enabled / disabled . Possible values are :-

Enabled - Both Computer and User Configuration Enabled
All Settings Disabled - Both Computer and User Configuration Disabled
Computer Configuration Settings Disabled - Self Explanatory
User Configuration Settings Disabled - Self Explanatory

The following two properties :-

Computer Version - Number of changes done to Computer Settings in a GPO
User Version - Number of changes done to Computer Settings in a GPO

are significant only when there are multiple domain controllers. The above two have further two sub properties namely

SysVolVersion - SYSVOL is a local folder of the Domain Controller where the local version of a given GPO resides. This property gives out the number of changes the concerned section (Computer / User Section) in the local GPO has undergone.

AD Version - AD Version gives out the most recent number of changes in the domain that the concerned section (Computer / User Section) of the GPO has undergone.

It should be ensured that the SysVol version and AD Version of both the sections of the GPOs are same. This further ensures that the GPOs are replicated correctly across all the domain controllers in the domain. This concept can be further appreciated by understanding role of multiple domain controllers and management of their replication in a domain. This would require further reading and is out of scope for the current post.

In the below image, we can see the creation and modification date and time; comment ; owner ; GPO status and Computer and User version of the "ChennaiWallpaperChangeGPO" in the right pane under the "Details" tab.

Figure 10

WMI Filter - This is a filter feature for determining further scope of application of a GPO within the linked container. It utilizes Windows Media Instrumentation (WMI) query language (WQL) to query the information required from the concerned workstation.Based on the response, the GPO is either applied or denied to the concerned workstation object.

For example, if a GPO is configured to be applied only to those systems which have Windows XP involved. Then by default, whenever this GPO is linked to an OU, it gets applied to all objects. If it has to be applied only to systems with Windows XP operating System, then there needs to be a way by which such systems can be found out automatically and then the GPO is applied. In this scenario, WMI Filter plays a role. We can create a WMI Filter object with a query to filter out such systems and then finally link it to the GPO which requires this filter.

The WMI Filters created and their properties can be found in "WMI Filters" container within the GPMC.

Figure 11

Figure 12

Figure 13

DACL (Discretionary Access Control List)- Shows various permissions of trustees on the concerned GPO. This is very critical property and it is a best practice to check for unauthorized permissions on a periodic basis.

In the below image, the steps have been marked to get the list of complete permissions for a given GPO.

Figure 14

SACL (System Access Control List)- Shows what kind of access attempts on a GPO is configured to be in system logs and for which trustees.

In the below image, the steps have been marked to get the list of complete configured audit entries for a given GPO.

Figure 15

The above given details are the metadata of the GPO. Depending on the audit, various informations can be inferred from the above details and observations can be found out.

Getting the above given metadata through observations and manually noting down is a big challenge.Such stunts should be applied only if the client does'nt allow to execute external scripts.

I use the script from this link to get all the above details. Use it with caution , as it is heavy on server since it extracts a lot of information from AD.

For WMI Filter details , I use the script from this link. This gives out the complete details of WMI Filters configured on the domain.

Below I have given out some sample generic vague scenarios that can help one appreciate on how the above details can be used in auditing.

Scenario 1 : The standard requires the organization's computers to have a specific setting during the in-scope audit period.

Sample Audit Test 1 - In this case, the created dates of the GPO(s) possessing the required settings (if present) can be checked and the date can be correlated with audit period. In case the created date does not cover the complete audit period then it could be an observation as one cannot ascertain if the computers were following the required settings without the existence of the GPO(s) from the start of the audit period to the date when the GPO(s) were created.

Sample Audit Test 2- To ensure if the GPO(s) are applied to all the workstations, we can check DACL to determine if there were any workstations that were exempted from following the GPO. This can be checked by looking out for setting configured for "Apply GPO". If it is configured with "Deny" , it means the concerned object has been exempted from following the GPO. It could be an observation.

Sample Audit Test 3 - In addition to the above exemption check, we can also further check if there are any WMI filters linked to the GPO. The WMI query configured to the WMI filter can be checked that is linked to the GPO if it exempts any workstation from following the concerned GPO.

Sample Audit Test 4 - In case, the organization has multiple secondary domain controllers depending on locations for Availability perspective, it should be ensured that any change of GPO in the primary or main domain controller is replicated across all the member domain controllers so that all systems are configured with updated GPO. So in case settings have been configured correctly in the primary DC but the secondary domain controllers have an older GPO setting then it can be an observation. This can be found by checking the Computer and User Version of a given GPO. To check the version of GPOs across various domain controllers, I use the script from this link to get details on replicated versions of GPOs across various domain controllers.

Scenario 2 : The standard requires that privileged access should be restricted to authorized individuals.

Sample Audit Test - In this case, the DACL of GPO can be checked if modifying permissions is given to unauthorised individuals . In many cases , under this scenario only Administrator rights are checked in local systems and AD; and GPO permissions are missed from getting tested. This is very critical as it can give an individual, control the settings of an AD object which could be used for malicious purposes.

Finally, it boils down to the creativity and ideas of the auditor to use these details on testing various audit controls.

2. Extracting list of settings configured in the GPOs.

Post auditing the GPO structure, and concluding on effective application of the required GPO(s) on the required AD objects, we can move on to check the settings within the GPO.

For auditing GPO, we would have to extract the policy report from the domain controller.

We can use the following command to extract the GPO reports of all the GPOs in html format.

Get-GPO -All -ReportType html | Out-File <Full path where the Html report is to be stored>

This would give us a single html file consisting of all the GPO's settings.

Along with the above command, I additionally also go with the following command , as this command gives the entire backup of all GPOs in xml format and other supporting files such as scripts that would have been configured as part of GPO, registry.pol files,Domainsysvol folders etc.

Backup-GPO -All -Path <Full path where all the GPOs backup should be exported>

The command results in creation of separate folders for each GPO named after it's GUID in the destination path along with the supporting files within the concerned folders. The advantage of this output is that one can check the source of the configured scripts and find out if there are any observations / security problems which would not be possible with the previous command as it does not export configured scripts as part of the output.

To understand and appreciate about various settings supported by GPO and their significance, refer to the document released by Microsoft in this link. It will help in setting the expectation levels for the audit pertaining to the security settings to be present as part of GPO(s) depending on the standard for which audit is being carried out.

3 Extracting AD Objects with their properties within the audit scope of AD.

The list of objects from in-scope container in the AD are necessary for an auditor to do cross testing / further analysis with GPOs to determine various issues such as which objects follow which GPO settings; if any objects have been exempted from any security based settings;if any user has been given higher privileges than required etc. The combination of observations one can find from this artifact is limited to the extent of the analysis made by the auditor.

Excel skills will help a lot in doing this analysis. :P

This export list also acts as a population file for further sampling. (Covered in Section 4)

The important thing while extracting the objects for GPO auditing is to decide the following :-

* Which attributes of the objects would we require for auditing for the standard ?

* Which are the in-scope containers within the domain to be considered for auditing?

Once we have the above answers, we can execute the following commands to get the result as a csv dump. Exporting the output as csv is useful , as we can play with various spreadsheet related tricks and formulas with the exported data.

csvde -d <Fully Qualified Domain Name of the in-scope container> -r <Filter which types of objects you want to dump> -l "Required attributes separated by , "-f <Destination path of the csv file>

For example :-

If our audit scope is restricted to Chennai OU in test.com domain and we need all objects that are either workstation or user objects under the scope OU with some attributes then our command will look something like this :-

csvde -d "OU=Chennai,DC=test,DC=com" -r objectClass=user -l "samaccountname,samaccounttype,description,useraccountcontrol,whenCreated,whenchanged,,lastlogon,lastlogontimestamp,msds-psoapplied,memberof" -f "C:\Users\Administrator\Desktop\export.csv"

Brief explanation about the attributes used in the above command :-

Samacoountname - Name of the account
Samaccounttype - Displays type of object in a decimal format. One can find different types of AD objects and it's corresponding value here.
Description - Displays the description of the object if set. Helps in finding out information pertaining to the object during audit.
User Account Control - Displays a decimal value which is a sum of various values corresponding to an account attribute. Refer the below table to get better clarity.

For example , an account has a useraccountcontrol attribute value 514 (512 +2) . It means it is a normal account( 512) that has been disabled (2). One has to do a reverse calculation from the table to find all the account types that maps to a given user account control number. For further info on user account control. Check the link here.

WhenCreated - When the object was created.
WhenChanged - When the object was modified.
Lastlogon and Lastlogontimestamp - Lastlogon is only updated on the domain controller that performs the authentication and is not replicated. LastLogontimestamp is replicated, but by default only if it is 14 days or more older than the previous value. Refer this link to know more about these attributes.

All the above attrbutes Whencreated,Whenchanged,lastlogon and lastlogontimestamp gives out time value in LDAP timestamp format. The values can be converted to a normal date time format using the following command :-

w32tm /ntte <LDAP Timestamp>

Tip: You can use the following formula in excel to convert the LDAP timestamp to a readable date format. Formula : "=IF(<cell_address>0,<cell_address>/(8.64*10^11) - 109205,"")"

msds-psoapplied - This attribute says if the object has been mapped with any Fine-Grain Password Policy.

If it is mapped, then I use the following command to export all the objects that are mapped to various fine grain password policy containers and the password settings configured.

Get-ADFineGrainedPasswordPolicy -Filter * -Properties *

This helps in understanding the password settings applied to various objects.

memberof- This display the list of groups to which the concerned object is a member.

To know more about the attributes and their details , refer the link here.

To know more about csvde and it's uses, refer this link.

The outputs for this section can also be obtained using powershell commands such as Get-ADObject, Get-ADComputer etc. Please refer this link for further info on the commands.

However, I prefer csvde in this case as I feel it is much simpler and does a neat job.

1.4 Resultant Set of Policy (RSOP) Settings applied to AD objects.

Till section 2 we have checked if the GPOs have been configured correctly and appropriate settings have been set as part of GPO. This ensures the effectiveness of configurations from server end and takes care of completeness standpoint of the control testing.

Now in order to check for accuracy of the control, we need to test if these settings have been appropriately replicated at the terminal end. Normally, this is tested as part of the floor / physical walk through and hence the testing approach should be kept practical enough to be executed within the time of the physical walk through.

Since in a real life scenario, there might be thousands of workstations cum users in a typical big organizations, getting the replicated settings in each of the workstation is not feasible. Hence , we normally proceed with the audit by testing RSOP settings for a sample of workstations / users.

Sampling Challenge 1:

Though we understand that a GPO has separate Computer and User section settings and a resultant GPO may differ with every combination of a given workstation and the user logged on to it depending on the settings configured , it is practically difficult to have a sample set consisting combinations of a workstation with a user, since users may not use the same workstations as how it has turned out to be in the sampling.

Hence it is better to take a sample set of only users or only workstations or an equal number from both , without having combinational sets.

Sampling Challenge 2:

Further, in some situations there might be working shifts for the employees. In case if one proceeds with sampling of Users and if the set consists of a user ID of an employee from another shift from the one during which the audit is being carried out, getting the evidence would be a challenge.

Additionally, stratifying the samples is a very important thing. Based on the understanding of the AD environment structure and the GPO structure (from section 3 and Section 1) , it is recommended to stratify the samples such that it covers across locations, OUs, Teams , various GPOs etc. to have an overall comfort on the testing. Better the coverage of sample sets, better the testing; better the testing, better the accuracy of the conclusion of the control audit.

The command to get the RSOP report in html from the terminal is :-

gpresult /h <Destination Path of the Html report>

The above command can also give outputs in case of "Sampling Challenge 1" (Combinational sample sets of workstation with a user) and "Sampling Challenge 2" (Samples with users working another shift from the one in which the audit is being carried out).

Command in case of combinational sample sets of workstations mapped to users:

gpresult /USER <User ID> /s <Workstation> /h <Destination Path of the Html report>

Command in case when a sample user works in another shift from the one in which the audit is being carried out:

gpresult /USER <User ID> /h <Destination Path of the Html report>

To know more about the command and it's supporting arguments refer this link.

But however , in both of the above cases, don't know the technical reason, but through experience I have found that it replicates the policy from AD and gives out the RSOP; which fails the entire purpose of auditing of the end point as the objective is to check if the terminal is replicated with required GPO settings at the time of the audit. Hence catching a system without replicated GPO is missed.

So I generally go with pure sampling of Users only / Workstations only, depending on the settings that are required for the standard for which the audit is being carried out.

3. Further Reading

In case you would want to know more about Active Directory Security in general, do follow the following security researchers / sites :-

https://sdmsoftware.com/group-policy-blog/
https://www.pingcastle.com/
https://adsecurity.org/
https://twitter.com/mattifestation
https://twitter.com/subTee
https://twitter.com/enigma0x3
https://www.twitter.com/_wald0
https://twitter.com/harmj0y
https://twitter.com/CptJesus
https://blogs.technet.microsoft.com/secguide/
https://www.ultimatewindowssecurity.com/blog/

BTW just a reminder, there is a comment section below.

So until next time , Ciao !!!! :) :)

Search This Blog

My Journey of finding answers to Ws and H