Tag Archive: GPO

GPO Basics:

1) Structure of a GPO:

Group Policy Container (GPC) which exists in Active Directory

and the Group Policy Template (GPT) where the actual content of your GPOs resides.

A third component, known as Client-Side Extensions (CSEs) can be found on client devices and are necessary for them to properly process the Group Policies assigned to them.

ref: http://blogs.technet.com/b/musings_of_a_technical_tam/archive/2012/02/13/understanding-the-structure-of-a-group-policy-object.aspx

2) GPO processing (LSDOU):

ref: http://blogs.technet.com/b/musings_of_a_technical_tam/archive/2012/02/15/understanding-the-structure-of-a-group-policy-object-part-2.aspx

3) GPO troubleshooting:




GPO management with PowerShell:

Powershell – how to translate a GPO GUID to Name?

Get-GPO -GUID “{AD7E3746-7135-496B-A1F5-B5B11871F96F}”

Powershell – how list all GPOs?

Get-GPO -all

Get-GPo -all | ft -autosize

Get-GPO -all | out-gridview

Powershell – how many GPOs?

(get-gpo -all).count

Powershell – how to translate a GPO Name to GUID?

PS Z:\ADGPO management> Get-GPO -all | where {$_.id -like “bd9df1be-3663-4cb4-bb71-35f7e27c691f”} | select id,displayname | ft -autosize

Id                                   DisplayName
—                                   ———–
bd9df1be-3663-4cb4-bb71-35f7e27c691f Corporate-A-All-Settings-Restore


Powershell – create and link a GPO?


PS C:\> Get-GPStarterGPO -Name “Laptops”
Next, you can use the New-GPO cmdlet to create the new GPO from your Starter GPO as follows:

PS C:\> New-GPO -Name “France-Laptops” -StarterGpoName “Laptop”

Finally, you can link the new GPO to the targeted OU as follows:

PS C:\> New-GPLink -Name “France-Laptops” -Target “ou=computers,ou=France,dc=hq,dc=mydomain,dc=com”

Alternatively, by using the Windows PowerShell pipeline feature, you can create and link the GPO using a single command.

Security update MS15-011 & MS15-014 installed which hardens the UNC paths for SYSVOL & NETLOGON & the following registry keys being pushed using group policy:

  • RequirePrivacy=1
  • RequireMutualAuthentication=1
  • RequireIntegrity=1

Other related article: https://blogs.technet.microsoft.com/askds/2016/06/22/deploying-group-policy-security-update-ms16-072-kb3163622/


After MS16-072 is installed, user group policies are retrieved by using the computer’s security context. This by-design behavior change protects domain joined computers from a security vulnerability.

Check if “Authenticated Users” group read permissions were removed intentionally by the admins. If not, then you should probably add those back. For example, if you do not use any security filtering to target specific group policies to a set of users, you could add “Authenticated Users” back with the default permissions as shown in the example screenshot above.

Get-GPO -All | Set-GPPermission -PermissionLevel GpoRead -TargetType Group -TargetName “Authenticated Users”

If “Authenticated Users” has more permissions, nothing is changed. The GPOs that do not have “Authenticated users”, will get the read permission.

Here are my recommendations to secure your computers and your domain:

Configuration\Windows Setting\Security Settings leaf.

Rename the Local Administrator Account: If the bad guy doesn’t know the name of your Administrator account, he’ll have a much harder time hacking it.

Disable the Guest Account: One of the worst things you can do is to enable this account. It grants a fair amount of access on a Windows computer and has no password. Enough said!

Disable LM and NTLM v1: The LM (LAN Manager) and NTLMv1 authentication protocols have vulnerabilities. Force the use of NTLMv2 and Kerberos. By default, most Windows systems will accept all four protocols. Unless you have really old, unpatched systems (that is, more than 10 years old), there’s rarely a reason to use the older protocols.

Disable LM hash storage: LM password hashes are easily convertible to their plaintext password equivalents. Don’t allow Windows to store them on disk, where a hacker hash dump tool would find them.

Minimum password length: Your minimum password size should be 12 characters or more. Don’t bellyache if you only have 8-character passwords (the most common size I see). Windows passwords aren’t even close to secure until they are 12 characters long — and really you want 15 characters to be truly secure. Fifteen is a magic number in the Windows authentication world. Get there, and it closes all sorts of backdoors. Anything else is accepting unnecessary risk.

Maximum password age: Most passwords should not be used longer than 90 days. But if you go to 15 characters (or longer), one year is actually acceptable. Multiple public and private studies have proven that passwords of 12 characters or longer are relatively secure against password cracking to about that length of time.

Event logs: Enable your event logs for success and failure. As I’ve covered in this column many times, the vast majority of computer crime victims might have noticed the crime had they had their logs on and been looking.

Disable anonymous SID enumeration: SIDs (Security Identifiers) are numbers assigned to each user, group, and other security subject in Windows or Active Directory. In early OS versions, non-authenticated users could query these numbers to identify important users (such as Administrators) and groups, a fact hackers loved to exploit.

Don’t let the anonymous account reside in the everyone group: Both of these settings, when set incorrectly, allow an anonymous (or null) hacker far more access on a system than should be given. These have been disabled by default since 2000, and you should make sure they stay that way.

Enable User Account Control: Lastly, since Windows Vista, UAC has been the No. 1 protection tool for people browsing the Web. I find that many clients turn it off due to old information about application compatibility problems. Most of those problems have gone away, and many of the remaining ones can be solved with Microsoft’s free application compatibility troubleshooting utility. If you disable UAC, you’re far closer to Windows NT security than you are a modern operating system.

Here’s the best part: Each of these settings is set correctly by default in Windows Vista/Server 2008 (and later). Most of my Windows security books were all about the settings I wanted you to more securely harden. These days, my best advice is don’t muck it up. When I see problems, it’s because people go out of their way to weaken them, and that’s never good.


  • Accounts: Rename administrator account — not highly effective but another security layer nonetheless (define a new name)
  • Accounts: Rename guest account (define a new name)
  • Interactive logon: Do not display last user name (set to “Enabled”)
  • Interactive logon: Do not require last user name (set to “Disabled”)
  • Interactive logon: Message text for users attempting to log on (define banner text for users to see – something along the lines of This is a private and monitored system…you abuse this system, you’re toast — just run it by your lawyer first)
  • Interactive logon: Message title for users attempting to log on — something along the lines of WARNING!!!
  • Network access: Do not allow enumeration of SAM accounts and shares (set to “Enabled”)
  • Network access: Let “Everyone” permissions apply to anonymous users (set to “Disabled”)
  • Network security: Do no store LAN Manager hash value on next password change (set to “Enabled”)
  • Microsoft Network client: send unencrypted password to third-party SMB servers (Set to “Disabled”)
  • Network security: LAN Manager authentication level (set to “Send NTLMv2 responses only. Refuse LM & NTLM”)
  • Shutdown: Allow system to be shut down without having to log on (set to “Disabled”)
  • Shutdown: Clear virtual memory pagefile (set to “Enabled”)

DFS dirty-shutdown stopping DFS replication: DFSR event ID 2213 in Windows Server 2008 R2 or Windows Server 2012:


How to disable the Stop Replication functionality in AutoRecovery

To have DFSR perform AutoRecovery when a dirty database shutdown is detected, edit the following registry value after hotfix 2780453

is installed in Windows Server 2008 R2. You can deploy this change on all versions of Windows Server 2012. If the value does not exist, you must create it.

Key: HKLM\System\CurrentControlSet\Services\DFSR\Parameters
Value: StopReplicationOnAutoRecovery
Type: Dword
Data: 0

You can push out registry keys or values using GP Preferences (GPPs):

Comparison results table : http://timstechnoblog.blogspot.fr/2010/10/group-policy-preferences-registry-items.html

If you are deploying multiple keys through GPPs, things to look out for are Order of GPP and the path of Key.

For e.g. You may be overwriting a key location which you created at order1 by using the Replace action on the key at Order2 because it falls in the same path.

For GPPs and deploying Registry Items:

All User Configuration Registry Keys fall under HKEY_CURRENT_USER (Deployed Under User Configuration–> Preferences)

All Computer Configuration Registry Keys fall under HKEY_LOCAL_MACHINE(Deployed Under Computer Configuration–> Preferences)

GP Preference (create,replace,update,delete) ?





Also, will help to have a GPResult /r Run from a Command Prompt (As an administrator to include computer policy results)

You may run a GpResult /h “FILENAME.HTML” which will give an easier read of what’s applying/what’s not.

This must be run from the client computer, logged in as user if possible.

Tip: RSOP.msc can also be used (more user friendly)

If you are looking for General Group Policy Troubleshooting Guidance, you can find some good info here.

Loopack processing explained by MS AD blog team:
Previous explanation:
Group Policies are normally applied to the user or their PC depending on where they are located in Active Directory. There are occasions, especially for terminal servers, when you wish users to have certain policies applied depending on which computer they log on to. This is where the loopback policy comes into its own.Two modes options when applying loopback processing:
  1.      Replace Mode: The user policy is defined entirely from the GPOs associated with the machine. Any GPOs associated with the user are ignored.
  2.      Merge Mode: The user policy settings applied are the combination of those included in both the machine and user GPOs. Where conflicts exist, the machine GPOs “win”.
A common use of loopback is on Terminal Services machines. In this scenario, it is common for the Group Policy administrator to set specific user policy settings for the server to ensure that all users using the machine receive a defined set of user policy settings.
In order to define the Loopback Processing setting, the following steps should be followed.
   1. Open the Group Policy Object editor (gpedit.msc). See Create/Edit GPOs for details.
   2. Expand the Computer Configuration node. Under Computer Configuration, expand the Administrative Templates node.
   3. Within the Administrative Templates node, expand the System node, and then the Group Policy node.
   4. Locate the setting “User Group Policy loopback processing mode”. Double click this setting, and define the setting as needed.
    * Merge Mode: When Merge mode is selected, application of user-based group policy begins as normal:
·         The distinguished name of the user is evaluated for it’s location in the Active Directory. For example, the user John Smith in the Boston OU at BigCompany Corporation might have a distinguished name of CN=John Smith,OU=Boston,DC=BigCompany,DC=Com.
·         Group policy parses the Distinguished Name, and attempts to locate policies that apply to users at each “stage” of the name. The search is performed from left to right (e.g. the Boston OU is searched first, then the domain root of BigCompany). Finally, the Active Directory Site of the user is evaluated for user policies.
·         Based on the effective permissions of the user, Group Policy determines which of these policy objects (if any) should apply to the user.
·         Policies are then applied in a last in, first out (LIFO) series. So, any policies that applied at the site level are applied first, then the domain, and finally at the OU containing the user. If multiple policies were defined at the OU or domain level, the policy with the highest precedence is added to the list first (so it will be processed last, and overwrite earlier policies).
To this point, policy processing is exactly like normal. However, once ‘normal’ processing has completed, a second iteration begins:
·         As before, Goup Policy evaluates the Distinguished Name – except this time, it is the Distinguished Name of the Computer, rather than the User. For our example, let’s say that the computer is in the Headquarters OU under the BigCompany root. The Distinguished Name is OU=Headquarters,DC=BigCompany,DC=Com.
·         The same processing rules apply as before: Group Policy evaluates policies at each level of the Distinguished Name, adding policies to the stack of policies to apply. The difference is that Group Policy is now searching for User policies that are defined in the computer’s organization structure.
·         This second set of policies is applied (again, Last In, First Out), with any policy setting conflicts being “won” by the last policy to apply the setting. So, if more restrictive settings are defined for users in a policy object linked to the Headquarters OU, those settings will apply to the user when logging onto a machine with Merge mode applied.
Typically, Merge mode is defined on Terminal Servers in an environment. The reason for this is that Administrators typically want to enforce a specific set of desktop and security settings, to help minimize potential variables that lead to unpredictable behavior on the Terminal Server. By enabling Merge mode, and defining all potential problem policy settings, the Administrator can enforce a consistent user experience.
    * Replace Mode: Replace mode is actually simpler to explain than Merge mode:
·         In Replace mode, the user’s Distinguished Name is not evaluated for Group Policy processing. Instead, we rely entirely on the Distinguished Name of the machine the user is logging onto.
·         Again using the previous example, the Distinguished Name OU=Headquarters,DC=BigCompany,DC=Com would be evaluated for User Policies, with any policies that the user has permissions to read and apply being enforced.
·         As before, the list of policies to apply is built from closest to farthest away (OU=Headquarters first, then DC=BigCompany, etc..). The list is then applied in reverse order, so that the OU settings have highest precadence.
·         The “normal policy set” for the user is ignored completely. Part of policy application is to delete the settings applied previously, so no (managed) settings will carry over to apply when Replace is defined, unless that setting was also defined in the User Settings applied during Replace mode.
Replace mode is useful for environments where specific policies are required regardless of the rights and settings of the user. Kiosk systems are a good example of this; an Administrator would typically have an unrestricted desktop experience. If that user logs onto a Kiosk machine, he or she would normally have a “wide open” desktop. This might be dangerous, so it may be useful to enable Replace mode to enforce a specific set of enforced settings.
Use case:Citrix XenApp
For the AD set-up I’d recommend the following set-up for the Citrix Xenapp environment:
·         Creation of a separate OU for your VDI/Xenapp environment.
·         This will allow to create a GPO with loopback processing enabled. Loopback processing will allow to apply user settings to computer objects in that OU, while normally you can only configure user settings in GPOs and apply them to OUs where the user objects reside. Loopback processing can be either configured in merge or replace mode. In merge mode, the users will receive both settings from GPOs applied to their own OU and from GPOs applied to the VDI/Xenapp OU. In replace mode, only the GPOs applied in the Xenapp/VDI OU will be applied. Normally I’d recommend replace mode to have better control and to avoid ripple effects.  Reasons for doing this? In the first place I’d strongly advice against storing user data and settings (profiles) on your VDI/Xenapp servers and move this data to a file server. The benefit of this approach is that the user data and settings is on the file server where it is properly backed up. Besides this it gives you more flexibility in case you want extend your environment: user settings are kept across your VDI/Xenapp infrastructure in case you add additional Xenapp servers or VDI machines or in case you need to rebuild your machine as a result of system crash. In addition to that, it will allow you to centrally manage your settings, such as specific drive mappings, applocker policies, registry keys and so on.. This can all be arranged with GPOs applied to the newly created OU.  At first sight it looks like introducing complexity in the environment, but once the principle of this is understood it’s actually very simple and it might prevent you from having to manually configure items and firefight issues. That’s the reason why this is considered as good practice in such type of environments.