Blocked Site Based GPO due to Blocked SOM

I recently came across a problem with applying a site linked GPO to some Citrix servers that were giving Blocked SOM (see below) as the reason for being denied. For the longest time I could not figure out why the GPO was being blocked. It was then with some help that I found out that the computer was in an OU that had blocked Inheritance enabled. This meant that Windows also blocked site link GPO if the computer is in an OU with inheritance blocked.

This behaviour was confusing to me as Site Based GPO on the surface seem to have nothing to do with OU’s. But this behaviour is exactly as designed due to the order or precedents that GPO are applied (Local, Site, Domain then OU). As the OU based policy settings take precedence over the Site this also means that OU based blocking will take precedence over Site based GPO as well.

So if you come across this same problem there a number of way that you can work around this problem:

  1. The obvious, and remove the the Blocked Inheritance on the OU that the computer object is located.
  2. Link the Site based GPO to an OU below the Blocked Inheritance. If you do this you lose the ability to dynamically apply the setting based on the site that the computer is located which then defeats the purpose of having the GPO linked at the site. But if it is something like a Citrix server, then you’ll be able to create a Site based OU (e.g. PAW\SiteName ) and then you can link the GPO to the SiteName OU.
  3. You can enabled the “Enforced” option to ignore the “Blocked Inheritance” option.
  4. If it is a Group Policy Preference then you can also use the Item Level Targeting to apply the policy only when the computer is in the correct IP address range and/or Site (see below).

Reference for Order of Precedence:

Thanks to Darren Mar-Elia for helping me figure this one out…


Group Policy Resources for Windows 10 build 1709

Windows 10 a.k.a. Redstone 3, a.k.a. 1709 a.k.a. Fall Creators Update has now been released to the public for download. If you would like to get a copy of the new version early to start testing you can download the PRO version using the Windows 10 ISO/USB download tool at . Alternatively, you can download the images from your MSDN or Volume licencing web site.

Now normally, with any release of Windows 10 I would go though the new list of Group Policy features. But in this new version of Windows 10 there is no new major (or minor) Group Policy engine changes. This meaning that the delivery mechanism of Group Policy has not changed.

But of course, there are many new settings that come with every new version of Windows. So for your easy reference, below is a list of essential reference for any Group Policy Administrator:

  • Group Policy Settings Reference for Windows and Windows Server – This is a spreadsheet with that list all the new, updated or replaced Group Policy setting in the 1709 build. Just for the record, there is 55 new Group Policy setting in 1709 which you can find easily in this spreadsheet. You can download this spreadsheet here .
  • Administrative Templates (.admx) for Windows 10 Fall Creators Update (1709) – This is a downloadable version of the updated ADMX and ADML files that are used to define the new Group Policy settings (See above point). If you already have a copy of Windows 10 1709 installed then you can find these files in the C:\Windows\PolicyDefenitions folder. In the past, you could blindly copy the ADMX/ADML files of the new version of the OS with the old version of the OS but since Windows 10 1703 some of the old policy settings have been removed. This would not cause anything to break, but it might show up as undefined setting the Group Policy Management Console when viewing GPO reports. You can get these files from
  • Remote Server Admin Tools – Yes… Yet another new version of the Remote Server Admin Tools (a.k.a. RSAT) has been released for the Windows 10 1709. These tools are essential for anyone performing admin work with a new version of Windows 10 or Windows Server 2016 in their environment. Generally, I always recommend that any Group Policy Administrator upgrade their RSAT tools to the latest version ASAP. However, I would note that the Windows Server 2016 1709 release of Windows it is *ONLY* available as a Server Core image (see . This means that if you are going to install the latest version of Windows Server 2016 then these new admin tools are essential as there is no GUI option to install on the server.
  • Security baseline for Windows 10 “Fall Creators Update” – The new 1709 security templates have been added to the Microsoft Security Compliance Toolkit . These provide updated guidance and group policy settings that Microsoft recommends are applied to all new Windows 10 computers. The new settings in this security template all revolve around new 1709 features and details of these changed can be viewed here Security baseline for Windows 10 “Fall Creators Update” (v1709) – FINA
  • SMB1 Off by Default – While not a Group Policy specific change I think it is important to note that there are new ADMX setting (see above) that do have have a way to SMB1 client and server protocols. These are especially important as SMB1 is disabled in 1709 by default (in some circumstances). If you have not already disabled SMB1 then definitely something to look at ASAP and Microsoft has also published an SMB1 Clearing House list (a.k.a. name and shame list) of vendors that still required SMB1 see SMB1 Product Clearinghouse

Why you should never use a Preshared Key with IPSEC

IPSEC is an amazing, but not often used technology that allows you to authenticate, allow, deny, protect and/or encrypt network traffic between windows and non-window computers. It has been around since at least Windows 2000 days but it is some time difficult to set up.  

Recently, Microsoft has released a how to article explaining how you can use it to restrict network connections to your domain controllers so that only your Privileged Access Workstations can make RDP connection to your domain controllers (see ). It’s a great article that got me to test out the feature myself and I highly recommend that you look at it this article yourself especially if you are setting a dedicated Admin Workstations for your Domain Admins.  

One of the first things that IPSEC needs to do when negotiating the protocol is to authenticate the users and/or the computer. IPSEC can do this is via many ways (see below): 

  1. Kerberos – This is on by default way to authenticate any Windows user and computers and is a relatively easy and reliable way of authenticatio
  2. NTLM – This is of course the old method of authenticating Windows users and computers and while it is easy to use, it is in no way as strong as Kerberos method.
  3. Certificate – This is the uses industry standard PKI certificates again for the computers and/or users. It strength is based on the type of certificate you have deployed, but generally it’s considered very strong authentication. It can however take a lot of setting up as you have to deploy a full PKI environment first and issues the computers and users certificates
  4. Preshared key – This option allows you to select a preshred key that you specify as the authentication for IPSEC. As it clearly says (Below) this is a “not recommended” way of setting up authentication for IPSEC. Its only described as being “less secure” than the other authentication methods. This method is really used if you are not communicated with other non-windows computers via IPSEC and you have no other way to authenticate.

(Yes my super-secure password highlighted below ‘ABC123’)

 Now is also a good time to explain that a few years ago Microsoft released a patch MS14-025 to address how it stored password in AD. In short, the Group Policy Preferences passwords were saved using a 32 bit AES encrypted value. Previous to this hotfix when you set the value in Group Policy you were warned that the password was being only “lightly encrypted”. Microsoft went out if its way to warn you in a blog post about this in 2009 (see and I also did a post in 2013 (see explaining how bad it was to use these Preferences password option.  

Then, Metasploit released a module for their toolkit to scan for scanning and decrypting these password value saved in the AD System Volume. So Microsoft released a patch that blocked the UI from being able to make changes to any Group Policy Passwords. Put simply Microsoft drew the line in the sand and prevented anyone from saving Preferences password in the AD SYSVOL. 

So, with the knowledge and Microsoft deliberate attempts to block any sort of “secret” values in AD. So when I then stumbled across this dialogue box that specifically mentioned a preshared Key. This got me thinking about how this key is stored in AD and how Microsoft addressed the same issues of saving the preshared key for IPSEC. 

Firstly you can see (image above) that after you set the value you can still clearly see it in the Group Policy UI. This told me at the very least however they key was stored using encryption and not hashsed. This at the very least told be the valued could in theory be reversed engineered and did get me a bit worried.


 So kept digging into the SYSVOL of the Group Policy Object and almost immediately opened up the “Registry.pol” file to see if it gave any clues to the storage of the key.

 I did a quick “find” in the file for the string ‘ABC123’ but could not find it, so I did a quick visual scan for anything that looked like an obfuscated field and to my surprise the key was there in plain text as ‘A B C 1 2 3’.

 That’s right, the method of storage of the preshared key for IPSEC is to simply add a space between each character and then just save is in the SYSVOL as clear text. So as far as algorithms go, I think this one could be cracked by my 5 year old…

Update: Thanks to the comment from SODER to my article he explains that the spaces are actually just the way the text is displayed in notepad. Other text editors that display unicode will actually not have any spaces at all.

So the warning message is certinly correct, the preshared key is stored “less secure”. More accurately you could describe it as being not secure at all.

Then, if you have read the blog post by fellow MVP Darren Mar-Elia at you will realise that the System Volume is an open book readable by all computers (and most users) in your Active Directory domain. So, the permission to read the Group Policy Object information that has this preshared key is by default “Authenticated Users” or maybe only “Domain Computers” if you have locked it down. Put simply, assume everyone on your domain can read this value. It must, otherwise how else can your computer read the information required to setup a preshared key authentication in the first place.

 So, to summaries we have a pre-shared key, saved in a place that is readable by all users and computer in the domain and is saved in clear text unicode.

But why is this an issues? Microsoft is clearly warning people that it is “less secure” so let them make the decision about whether to use this option or not. Well, if you remember earlier Microsoft has already gone to the effort of disabling featured that save password values in AD SYSVOL using just light encryption. What I fail to see here in this case why this is really any different.

If I had to guess, this is just a legacy setting that has been around for many years that is used mainly used for testing and/or IPSEC with non-Windows based computers. I am sure the usage rate of such an option if very low. But this does not mean that it is not likely that there are some people out there that are using IPSEC thinking that it gives them some level of protections. 

So let me be clear, in my opinion IPSEC with preshared key should not be considered secure at all. If you have deployed IPSEC using this method of authentication then you really need to look at moving to PKI, Kerberos or event NTLM. Also, at the very least I think Microsoft should address this issues in a similar way to how it prevented people using Group Policy Preferences Passwords.

But don’t get me wrong I am not saying IPSEC is not secure, it’s just that one of the available method of authentication is not secure. So, if you are going to use IPSEC then for goodness sake NEVER USE PRESHARED KEYS.

How to Disable SMB1 using Group Policy Administrative Templates

So, incase you have not heard, SMB1 is Bad… Really BAD. Not only is it woefully old and inefficient protocol it’s also now widely known to be the attack vector for the recent WannaCry virus. By now you probably have seen my very popular previous blog post called How to disable SMB 1 on Windows 7 via Group Policy to Prevent WannaCry . This article explains how to disable SMB1 Server and Client protocols by setting custom registry keys by configuring Group Policy Preferences Registry key option. But as with any thing you do with Group Policy configured the exact registry key can be a bit tricky and is of course prone to typos and errors that could cause all sorts of issues.

To make it easier to disable SMB1 in your environment Microsoft has now release an ADMX/ADML file that adds defines the required registry keys so they can be configured as Administrative Template setting.

To get the SMB1 policy setting visit and download the Windows-10-RS2-Security-Baseline ZIP file.

Open the ZIP file and navigate to the “Templates” folder where you then need to extract the SecGuide.adml and SecGuide.ADMX files.

Then copy the two files you extracted ro your “PolicyDefinitions” folder in your SYSVOL. Once you copy these files as with adding any ADMX/ADML file to the Policy Definitions folder you will then see your Group Policies get the new “MS Security Guide” under Computer Administrative templates.

Now, as per the guidance text of the policy you need to do the following and you will have disabled SMB1 on all your Windows computers.

APPLIES ONLY TO: Windows 7 and Windows Servers 2008, 2008R2 and 2012 (NOT 2012R2):

To disable client-side processing of the SMBv1 protocol (recommended), do ALL of the following:
* Set the SMBv1 client driver to “Disable driver” using the “Configure SMB v1 client driver” setting;
* Enable this setting;
* In the “Configure LanmanWorkstation dependencies” text box, enter the following three lines of text:


Does Windows 10 S Support Group Policy?

Recently Microsoft has revealed there will be a new SKU of Windows 10 that will only run signed Apps from the Windows App Store. This new version of the OS will be called Windows 10 S. This version of the OS is specifically designed to only be able to run Universal Windows Platform (a.k.a. UWP) or Centennial packaged apps. This give the OS the advantage of being able to run only application that have been explicitly reviewed and signed by Microsoft to ensure they are of high quality in terms of security, performance and easy of install/uninstall.

However, as you can see from the chart below that was provided in the FAQ at  the Windows 10 S does not support domain joining much like Windows RT did not and therefore you will not be able to deliver Domain Based Group Policy settings to the OS.

It is however easy to upgrade a Windows 10 S to the PRO version via the Windows Store so if you do purchase a Windows 10 S device you will be able to upgrade it to support Domain Joining and Group Policy if needed.