📜 ⬆️ ⬇️

Immersing in templates and taming Windows GPO


In the next article from the cycle "admin summary" I would like to refresh in my memory a few nuances of using group policies. At the same time we have fun with the creation of our templates and with the automation of working with these same policies.


Refreshing memory


I will not tell you what group policies are, and I’ll dwell only on the main points that should be borne in mind when working with them.


In addition to domain systems, there are local group policies in Windows systems - you can manage them using the gpedit.msc snap-in on Professional and higher edition systems. It is often assumed that without a domain, you can configure local group policies only for all users on the computer. This is not entirely true - with the release of Windows Vista, it became possible to use multiple local group policies or MLGPO . This mechanism allows you to configure individual policies for different users.


You can reach it via the mmc console call: when adding the “Manage Group Policy Objects” snap-in, click the Browse button. Further, on the “Users” tab, you can already select a specific user or the “Administrators” and “Non-Administrators” groups. Unfortunately, management for a group of users is not implemented.



Manage Group Policy for individual users.


It also happened that on a stand-alone terminal server, Active Directory was deployed only in order for an individual user to configure the driver behavior for EasyPrint. Do not do it this way.

When adding domain group policies, it is worth remembering the order in which they are applied - the policy applied by the latter will have the highest priority (and often asked during interviews).


So, suppose that we have a computer in the domain and four group policies: local on this computer; the policy on the unit in which the computer is located; policy on the domain and policy on the forest. The order of their application will be as follows:


  1. Local Group Policy.
  2. Group Policy Site.
  3. Group Policy Domain.
  4. Group policy upper divisions.
  5. Group Policy Subsidiary.

That is, the closer to the object, the more priority, with the exception of the local group policy. If you need to disable the application of higher-level policies, then set the inheritance lock.



Blocking inheritance


Any group policy can be divided into two configurations - the user and the computer. Usually, policies with computer settings are assigned to the department where the computers are located. A policy with user settings - on users.


If you need to apply the computer settings to the division with users and vice versa, use the so-called closure group policy. For example, such a setting is useful when you need to apply specific policies to users to work on terminal servers.


The operation of the circuit is configured directly in the policy - "Computer Setup - Administrative Templates - System - Processing Mode of the closure of the user group policy." More details about the mechanism have already been written in the article about using Merge \ Replace in a GPO . I will only add that the closure mode of group policy is also a frequent question at the interview.



Configuring closure group policy.


Physically, domain group policies are located in the SYSVOL folder on domain controllers. The folder is replicated between controllers. Each group policy looks like a folder with a name in the form of a GUID.



Group domain policies.


The filtering rules that are configured through the Group Policy Editor correspond to the settings of the NTFS rights to the corresponding subfolder.


Speaking about the filtering rules, we cannot but mention the MS16-072 update, which “broke” group policies. Now, in order for the filtering rules to work, you need to add a “read” rule to each filter, but not “apply” to the Domain Computers group.

In each folder with Group Policy, there are subfolders Machine and User , corresponding to the settings of the user and the computer. If you delve into the subfolders, you can easily understand the structure of group policy:



More information about the structure can be found in the material Group Policy Basics , so let's go straight to the templates.


Administrative Templates


In essence, administrative templates are special files with instructions on how to change the client registry ( HKCU or HKLM branches ) and settings for displaying the parameters to be changed through the “Group Policy Management”. In principle, the registry can be changed through the “Group Policy Preferences”. But the difference here is not only in the beautiful interface.


Registry change methodHow it behaves when deleting a policy with standard settingsIs it possible to change the parameter manuallyIs it possible to change the parameter through the application
TemplatesThe registry value is restored to the default value if the default settings are in the template--
Policy preferencesRegistry Parameter Does Not Change++

Comparison of group policy preferences and administrative templates.


In other words, registry configuration through group policy templates is more restrictive. Whereas the setting through group policy preferences is reminiscent of the periodic use of the reg file. Of course, preferences allow not only changing registry settings, but also quite flexible settings. That and valuable.


This is relevant when changing the Policies branch, and the custom application must store its settings in the registry. Simply changing the settings through Preferences and Templates will work in a similar way, only templates can be more convenient.

Before the advent of Windows Vista \ 2008, only the .adm standard was taken as a template for group policies. Being with a simple structure that was easy to edit by hand, this standard also had several disadvantages:



To replace the outdated standard, a new one has appeared. New templates are two files: the template itself, not dependent on the language - .admx and the language “package” to it - the .adml file. Now the templates can be “put” in the central repository, and access it without generating identical files in the SYSVOL folder.


Not without a fly in the ointment - now the contents of the file is a popular XML format in the industry. And creating new templates in notebook has become less convenient.


Under most of the parameters that may be needed, the templates already exist. In addition, many application manufacturers release their administrative templates. Here are some examples:



If there is a need to develop and implement your administrative template, then the simplest option is to create the old .adm file and convert it to admx with a special utility . The more difficult option is to start right away with .admx.


Create your template


To begin with, let's take a simple example. Create a group policy template that allows us to turn on and off the display of hidden and system files, and at the same time the display of extensions.


I’ll say at once that this can be turned through the “Group Policy Preferences” —in the control panel settings — the folder options. But we are not looking for easy ways and at the same time we do not want the display parameters to be changed manually.

Three keys in the registry answer for the parameters we need:



The contents of the ADM-template, which we analyze below, under the spoiler.
CLASS USER CATEGORY !!ShowExplorer POLICY !!ShowHiddenFiles KEYNAME "Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" EXPLAIN !!ShowHiddenFilesExplanation VALUENAME "Hidden" VALUEON NUMERIC "1" VALUEOFF NUMERIC "2" END POLICY POLICY !!ShowFileExtensions KEYNAME "Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" EXPLAIN !!ShowFileExtensionsExplanation VALUENAME "HideFileExt" VALUEON NUMERIC "0" VALUEOFF NUMERIC "1" END POLICY POLICY !!ShowSuperHiddenFiles KEYNAME "Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" EXPLAIN !!ShowSuperHiddenFilesExplanation VALUENAME "ShowSuperHidden" VALUEON NUMERIC "1" VALUEOFF NUMERIC "0" END POLICY END CATEGORY [strings] ShowExplorer="   " ShowHiddenFiles="  " ShowHiddenFilesExplanation="   ,     ." ShowSuperHiddenFiles="  " ShowSuperHiddenFilesExplanation="   ,     " ShowFileExtensions="  " ShowFileExtensionsExplanation="   ,     " 

Let us examine the syntax of the file in more detail.



In addition to the options involved, there are others, for example:



More information about all the parameters can be found in the MSDN ADM Format section.


Installing a new template is not easy, but very simple - just right-click on the “Administrative templates” item, select “Add and remove templates” and add our newly created template.



Added template.


After the template is installed, it will be displayed in the “Classic Administrative Templates” branch.



Now you can convert our template to .admx using the faAdmxConv utility from ADMX Migrator .



Convert the template.


After converting, the resulting .admx template and the Ru-ru folder with the .adml localization file need to be copied to the% Systemroot% \ PolicyDefinitions folder for local policy or to the Sysvol \ PolicyDefinitions folder on the domain controller.



Installed .admx template.


Full listing of the resulting template and localization file under the spoiler.

Template:


 <?xml version="1.0" encoding="utf-8"?> <policyDefinitions revision="1.0" schemaVersion="1.0"> <policyNamespaces> <target prefix="fullarmor" namespace="FullArmor.6fb075d6-ddee-4302-9d06-50c4d83e1910" /> <using prefix="windows" namespace="Microsoft.Policies.Windows" /> </policyNamespaces> <supersededAdm fileName="E:\1\explorer.adm" /> <resources minRequiredRevision="1.0" /> <supportedOn> <definitions> <definition name="SUPPORTED_NotSpecified" displayName="$(string.ADMXMigrator_NoSupportedOn)" /> </definitions> </supportedOn> <categories> <category name="ShowExplorer" displayName="$(string.ShowExplorer)" /> </categories> <policies> <policy name="ShowHiddenFiles" class="User" displayName="$(string.ShowHiddenFiles)" explainText="$(string.ShowHiddenFilesExplanation)" presentation="$(presentation.ShowHiddenFiles)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" valueName="Hidden"> <parentCategory ref="ShowExplorer" /> <supportedOn ref="SUPPORTED_NotSpecified" /> <enabledValue> <decimal value="1" /> </enabledValue> <disabledValue> <decimal value="2" /> </disabledValue> </policy> <policy name="ShowFileExtensions" class="User" displayName="$(string.ShowFileExtensions)" explainText="$(string.ShowFileExtensionsExplanation)" presentation="$(presentation.ShowFileExtensions)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" valueName="HideFileExt"> <parentCategory ref="ShowExplorer" /> <supportedOn ref="SUPPORTED_NotSpecified" /> <enabledValue> <decimal value="0" /> </enabledValue> <disabledValue> <decimal value="1" /> </disabledValue> </policy> <policy name="ShowSuperHiddenFiles" class="User" displayName="$(string.ShowSuperHiddenFiles)" explainText="$(string.ShowSuperHiddenFilesExplanation)" presentation="$(presentation.ShowSuperHiddenFiles)" key="Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" valueName="ShowSuperHidden"> <parentCategory ref="ShowExplorer" /> <supportedOn ref="SUPPORTED_NotSpecified" /> <enabledValue> <decimal value="1" /> </enabledValue> <disabledValue> <decimal value="0" /> </disabledValue> </policy> </policies> </policyDefinitions> 

Localization file:


 <?xml version="1.0" encoding="utf-8"?> <policyDefinitionResources revision="1.0" schemaVersion="1.0"> <displayName></displayName> <description></description> <resources> <stringTable> <string id="ShowExplorer">   </string> <string id="ShowHiddenFiles">  </string> <string id="ShowHiddenFilesExplanation">   ,     .</string> <string id="ShowSuperHiddenFiles">  </string> <string id="ShowSuperHiddenFilesExplanation">   ,     </string> <string id="ShowFileExtensions">  </string> <string id="ShowFileExtensionsExplanation">   ,     </string> <string id="ADMXMigrator_UnresolvedString">ADMX Migrator encountered a string that is not present in the source ADM string table.</string> <string id="ADMXMigrator_NoSupportedOn">ADMX Migrator encountered a policy that does not have a supportedOn value.</string> </stringTable> <presentationTable> <presentation id="ShowHiddenFiles" /> <presentation id="ShowFileExtensions" /> <presentation id="ShowSuperHiddenFiles" /> </presentationTable> </resources> </policyDefinitionResources> 

Indeed, the xml in the new format is read a little worse than the old .adm. To facilitate the work with the new format in the ADMX Migrator package there is the utility faAdmxEditor.msc . In addition to this utility, there are scripts for converting reg-files into templates, and third-party paid utilities.


Of course, you can do without this and that and figure it out yourself - I will leave it as a homework. Fortunately, MSDN has a detailed description of the XML schema , and there are some good materials with examples on the web. For example, Administrative Group Policy Templates .


We now turn to automation.


Automatic control


Working with group policies from the command line is pretty dreary. There are three main tools.


PowerShell . There are a set of cmdlets for backing up, restoring, and managing group policies. Creating new policies is limited - you can only change the registry. However, in most cases this is enough. As an example, create a group policy that disables the automatic update of Adobe Reader DC.


The bUpdater registry key in the [HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Adobe \ Acrobat Reader \ DC \ FeatureLockDown] branch is responsible for disabling automatic updating. By setting the parameter to 0, we will disable the option.


Creating a group policy on PowerShell will look like this:


 Import-module -Name GroupPolicy Write-Host "      Adobe_Reader_disable_autoupdate" New-GPO -Name Adobe_Reader_disable_autoupdate Write-Host "    " Set-GPRegistryValue -Name "Adobe_Reader_disable_autoupdate" -key "HKLM\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown" -ValueName bUpdater -TypeDWord -value 0 Write-Host "     OU" Set-GPLink -Name Adobe_Reader_disable_autoupdate -Target "ou=Computers,dc=domain,dc=com" -LinkEnabled Yes 


Newly created group policy.


A complete list and description of cmdlets are available in Technet Group Policy Cmdlets in Windows PowerShell .


COM interface to GPMC (Group Policy Management Console). The method allows you to do a lot with policies in any programming language that supports COM interfaces. Unfortunately, he has not gained popularity and there are few examples on the net, despite the rich description of interface methods on the MSDN portal. A few examples of use are available for download in the Technet Gallery.


LGPO.exe. Not so long ago, Microsoft replaced the set of utilities for working with local group policies with a single utility. You can download it on the official website . The utility is convenient for copying and deploying local group policies. MLGPO support has been announced. You can also create your own policies. The program is also convenient for creating and modifying registry.pol registry files. For example, we’ll change the local group policy by adding the disabling update of the unfortunate Acrobat Reader DC to it.


Make a backup of the local group policy with the command


 lgpo.exe /b C:\Temp /n "Backup" 

In the folder C: \ Temp, a sub-folder will appear with the GUID structure similar to domain group policies:


Now we will deploy registry.pol to a text file:


 LGPO.exe /parse /m C:\temp\{GUID}\DomainSysvol\GPO\Machine\registry.pol >> reg.txt 

The syntax of the text file is obvious. Add the registry values ​​to it to disable the automatic update of "Acrobat":



Added registry key to file.


Now it remains to wrap our reg.txt back to registry.pol and import the changed file back to the local group policy:


 LGPO.exe /r C:\Temp\reg.txt /w C:\Temp\registry.pol LGPO.exe /m C:\Temp\registry.pol​ 

Of course, all these frauds can be wrapped in one script and used to massively change the local group policy with the usual tool for running commands on remote computers. More information about the methods of launching commands can be found in our article "1000 ++ way to run commands on a remote computer . "


Of course, knowing the structure of the domain group policy, nothing prevents you from making a convenient tool for you to create and manage policies. Share in the comments, do you have your own ways to customize the registry of user machines?


')

Source: https://habr.com/ru/post/351152/


All Articles