Learning from the field - Understanding and Auditing Active Directory Group Policy - Part 1/2

The Background of this post :

When it comes to auditing for standards such as SSAE 16 (it has become SSAE 18 now , but the core testing principles remain the same) or ISAE 3402 or when you support a Financial Statutory audit from the Information Security perspective for verifying the Information Systems, user access management and it's related configurations are one of the critical areas to look for.  For a similar audit, I was given the task of auditing Active Directory Group Settings as part of my work.

Being a newbie back then (btw this is a very late post), I had to refer various articles and sources and correlate them to understand the working of the same so that I could proceed with the audit. Though the entire post and the process has been tested and shown in the Windows Server 2008 R2 version, this should apply well to other latest versions of Active Directory where only the path for accessing concerned features might differ.

Note:

• The objective of this article is to understand Active Directory Group Policy only from an auditing standpoint and not from holistic implementation perspective. Hence some topics have not been covered to restrict the article from deviating from the context.

• Some of the images used in this article have been taken from various online sources and the ownership rights completely belongs to the concerned authority and I do not claim any rights on the same. 

• I have given appropriate reference links to external articles wherever a new term pops up and explaining the same here would be out of scope of this article.

• The links  that were referred for compilation of this article have been provided in the "References" section.

P.S :-
The title "Learning from the field" was inspired from one of my friend's blog. His blog is a real treasure for pentesters and CTF junkies. You can check his blog here.

Now lets dive into the topic.

Understanding Active Directory Group Policy :

Active Directory in lay man terms can be considered as a centralized Microsoft Windows based server used to implement AAA (authenticate, authorize and account)  and manage users and workstations in an organization.

• Account Types in Active Directory

1. User Account Objects - User IDs
2. Group Objects - Groups of User IDs / Workstation / Both
3. Workstation Objects - Authorized Workstations
4. Organization Units (OU) - It is a grouping object. Apart from the default OUs that exists in AD for user objects , workstation objects etc. , this feature is used in organizations mainly to demarcate a region / Business Unit . 
5. Domain 

Active Directory Users and Computers Window

• Group Policy (GPO)

          GPOs are the configuration unit of the Active Directory. They are templates consisting of various set of configurations configured by the AD Administrator which are pushed to the end workstations belonging to the corresponding domain. 

Structure of GPO :-

• Computer Configuration : Set of configurations that applies only to a workstation object
• User Configuration : Set of configurations that applies only to a user object.

Different methods to create a GPO :- 

GPOs are created under the context of an OU / Domain. The following image would make this statement clear.

GPO can be created in following ways:-

• Create a completely new GPO from ground up  (or)
• An existing GPO can be linked to form a new similar GPO. 

Note: In the second case mentioned above, changes made to the newly created GPO will impact the pre-existing linked GPO as well. However, deleting the newly created GPO does not result in deletion of the pre-existing linked GPO.

Different Status of a GPO :-

Ø Linking a GPO :-

GPO applies to the OU context under which it is defined. The policy can be overridden ( in case of conflicts) by higher precedence policies. (Higher Precedence policies ?? It is explained in the coming section) 

Ø Linking  and Enforcing a GPO:-

GPO applies to the OU context under which it is defined and the parameters configured under the current GPO in case of a conflict, cannot be overridden by  any other linked GPOs with higher precedence that will be processed later. In case, there is / are any linked and enforced GPO(s) with conflicting parameters with higher precedence, the higher precedence GPO will always win.

Ø GPO Status : Enabled  :-

Policy is enabled and is link ready i.e. if a policy is linked now it will be applied on to the respective context. If it isn’t linked , it is same as being disabled.

Ø GPO Status : All Settings Disabled  :-

Policy is disabled irrespective of policy has been linked or not.

Ø GPO Status : Computer Configuration Disabled /  User Configuration Disabled / Both Disabled :-

Self Explanatory. Concerned part of Policy is disabled irrespective of policy has been linked or not.

Note :

•    In case a policy is not linked , that is equivalent of disabling the policy irrespective of the GPO status.

•    So effectively for a policy to be applied , it should be linked and should have its one of the two / both (Computer and User Configuration) enabled.

•    Enforcement of a policy is optional and it does not decide the status of the policy.

•    “Link” in the context of "Status of GPO" differs from the “Link” in “Creation GPO” context. “Link” in “Creation GPO” context,  means creating a GPO from pre-existing GPO . “Link” in “Application of GPO” context, means linking / enabling the policy for the respective context where it resides.

Precedence of Application of Policies :-

So the precedence is always a top down approach (with exception to local group policy which in spite being within the local scope of the system has least precedence). So when it comes to RSOP; the application of policies are as follows :-

Local group policy overridden by policies at Forest / Site Level  overridden by policies at domain level overridden by policies at OU level ......(keeps going until you hit the last sub-ou in which the object resides)

Further, one can block inheritance of policies at the OU level, by right clicking on a specific OU and selecting "Block Inheritance". This stops inheriting of policy settings for a OU from any of the policies mentioned at higher levels. This also applies to all sub-OUs within that OU.

So just getting a Default Domain Policy as evidence for auditing the policy in the Active Directory is not right. One should check the inheritance of the policies for a specific OU (i.e. in-scope OU) and then proceed with the collection of all policies that forms part of RSOP along with RSOP extracted from the sample workstation.

One can check the inheritance / precedence of policy applied to a specific OU to determine of RSOP by checking the "Group Policy Inheritance" tab of the in-scope OU.

In case of multiple policies under a given context (i.e. OU) , the policy with the lower numerical value link order or in other words higher precedence will override the other policies above it.

Problem Statements 

Q 1. If a user belongs to one specific OU say OU 1, and the workstation being used to login belongs to OU 2 and both OU has Password Policy configured under them. Which policy will take precedence for the user login session ?

Q 2. Can a specific object such as a user / group / workstation be exempted from following a policy even if a policy has been defined for the OU under which it resides ?

Q 3. In case the effective RSOP (Resultant Set of policies i.e net policies applied after applying all inheritance) for a workstation under an OU say OU 2, does not have any Computer configurations, but a user object under OU 1  has Computer Configurations set in  RSOP , which will be the effective RSOP for the user session in the concerned workstation?

(Take your time and think on it .... before you scroll down to Answer Section. )

...........

.......

....

Answers

Ans 1. Password Policy configured for the Workstation will take precedence.

Ans 2.  Yes. In Delegations > Add User / Workstation / Group / anything > Advanced > set the “Apply Group Policy” as Deny

Ans 3.  By default , the local policy which is set for the workstation shall prevail. In case loopback processing is enabled (covered in next section), it will depend on the mode it's set.

Points to remember

●      Computer configurations only apply to computer objects, user configurations only apply to user objects.

●     To phrase it another way, a GPO containing only computer configurations applied to an OU containing only users will have no effect whatsoever.  A GPO containing only user configurations applied to an OU containing only computer objects will have no effect - unless loopback policy processing mode is enabled. What is loopback policy processing mode ? Wait for next section .... 

●      Policies could be configured in such a way that it does not apply to a specific user / workgroup / workstation object under it’s given context OU. (RED ALERT)  Since , most of the times the controls that comes under the audit scope from AD perspective majorly falls under “Computer Configuration”, we would have to check if any Workstations are exempted from following any policy . Why only workstation ? Refer next point.

●      Workstation’s “Computer Configuration” part always takes precedence. A user’s  “Computer Configuration” will always lose to Workstation’s “Computer configuration”. Why ? Wait for the next section.....

Loopback Processing of Group Policy :-

Sample Test Case

        Lets take the above case for explanation of this concept. We have 2 OU's Red and Green. We have a computer object mapped to Green OU which has a policy with corresponding 2 sections being referred as Computer Configuration 2 and User Configuration 2. 

        Similarly we have a user object mapped to Red OU which has a policy with corresponding 2 sections being referred as Computer Configuration 1 and User Configuration 1. 

        So the problem statement is if the user from Red OU logs in to the Computer from Green OU. What will be the RSOP? 

        To answer this scenario :-

        We have 3 cases.

         Case 1 : When no loopback processing is enabled , the RSOP will be as given in the image.

       Case 2 : When loopback processing is enabled in "Replace" mode , the RSOP will be as given in the image.

       Case 3 : When loopback processing is enabled in "Merge" mode , the RSOP will be as given in the image. The settings are taken from both the User Configurations and merged and then applied.

Note: 

       In Merge mode, if there is a conflict, for example two policies provide different values for the same configuration setting, the Computer’s policy has more privilege. For example in our scenario, in case of the conflict the User Configuration 2 would be enforced.

        Where do you find the settings for Loopback Policy ?

        Ans : Group Policy Management Editor > Computer Configuration > Windows Settings > Administrative Templates > Group Policy > User Group Policy Loopback Processing Mode.

Fine-Grain Policy / Fine-Grain Password Policy :-

Solution for the scenarios where specifically user based password settings needs to be configured.o be configured.

•     It is NOT part of GPO.

•     It is part of User Object Attributes. i.e. It always supersedes the governing Group Policy for that concerned object.

•    It can be mapped to a user object or a user group object or in some cases OU consisting of users through something called shadow groups. 

(Refer http://itfreetraining.com/70-640/ou-and-shadow-groups)

For How to's of Configuration : 

Refer http://www.grouppolicy.biz/2011/08/tutorial-how-to-setup-default-and-fine-grain-password-policy/

Now we have understood the basic working of Group Policies in Windows Active Directory Environment. We will proceed to "Auditing the Group Policy in the Windows Active Directory environment " in the next blog post ..... 

Until then Ciao !!

Please feel free to drop in your feedback on the article.

References :-

https://emeneye.wordpress.com/2016/02/16/group-policy-order-of-precedence-faq/

https://groups.google.com/forum/#!topic/microsoft.public.windows.group_policy/rBn9Oa0qeBs

http://www.grouppolicy.biz/2010/05/how-to-apply-a-group-policy-object-to-individual-users-or-computer/

http://kudratsapaev.blogspot.in/2009/07/loopback-processing-of-group-policy.html

https://social.technet.microsoft.com/Forums/windows/en-US/dd09ace0-9ebd-4e27-9fb2-b4f914d63b31/setting-apply-group-policy-to-deny-for-a-gpo-group-through-powershell?forum=winserverpowershell

https://arstechnica.com/civis/viewtopic.php?f=20&t=596090

https://msdn.microsoft.com/en-us/library/windows/desktop/ms683980(v=vs.85).aspx

https://social.technet.microsoft.com/Forums/windowsserver/en-US/4ff0276e-ea43-40f1-84b7-47554de53137/can-i-change-a-gpos-status-tofrom-allsettingsdisabled-or-computersettingsdisabled-from-powershell?forum=winserverGP

http://serverfault.com/questions/538122/how-do-windows-domain-clients-behave-if-the-dc-is-offline

http://jeffwouters.blogspot.in/2009/08/built-inadministrators-vs-domain-admins.html

https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-ds/plan/security-best-practices/appendix-b--privileged-accounts-and-groups-in-active-directory

https://social.technet.microsoft.com/Forums/windows/en-US/dd09ace0-9ebd-4e27-9fb2-b4f914d63b31/setting-apply-group-policy-to-deny-for-a-gpo-group-through-powershell?forum=winserverpowershell

http://www.grouppolicy.biz/2011/08/tutorial-how-to-setup-default-and-fine-grain-password-policy/

https://social.technet.microsoft.com/Forums/windowsserver/en-US/c33ad536-a122-44fb-b2e5-b14183b18694/finegrained-password-policy-vs-default-domain-password-policy?forum=winserverGP

https://social.technet.microsoft.com/Forums/windowsserver/en-US/8da2aa4e-5ae6-47d9-ac1b-159e5e3f2612/pull-all-user-attributes-with-powershell?forum=winserverpowershell

https://technet.microsoft.com/en-us/library/hh852306(v=wps.630).aspx

https://blog.netwrix.com/2016/03/03/how-to-set-up-multiple-password-and-account-lockout-policies/

https://www.showmehowtodoit.com/step-by-step-fine-grained-password-policy-in-windows-2008/