ADMX
Rappel de Microsoft : introduction
Windows Vista and Windows Server 2008 introduce a new format for displaying registry-based policy settings. Registry-based policy settings (located under the Administrative Templates category in the Group Policy Object Editor) are defined using a standards-based, XML file format, known as ADMX files. These new files replace ADM files, which used their own markup language. The administrative tools you use—the Group Policy Object Editor and the Group Policy Management Console—remain largely unchanged. In the majority of situations, you will not notice the presence of ADMX files during your day-to-day Group Policy administration tasks.
There are some situations that require an understanding of how ADMX files are structured and the location where they are stored. This guide introduces you to ADMX files, showing you how ADMX files are incorporated when editing Administrative Template policy settings in a local or domain-based Group Policy object (GPO). ADMX files provide an XML-based structure for defining the display of the Administrative Template policy settings in the Group Policy Object Editor. You need to be using a Windows Vista-based or Windows Server 2008-based computer in order for the Group Policy Object Editor to recognize the ADMX files.
Unlike ADM files, ADMX files are not stored in individual GPOs by default; however, this behavior is supported for less common scenarios. For domain-based enterprises, administrators can create a central store location of ADMX files accessible by anyone with permission to create or edit GPOs. Group Policy tools will continue to recognize other earlier ADM files you have in your existing environment. Specifically, any custom ADM files will be consumed by Group Policy tools. (The tools will exclude ADM files that were included by default in the operating system, such as System.adm and Inetres.adm, because the ADMX files supersede these files.) The Group Policy Object Editor automatically reads and displays Administrative Template policy settings from both the ADMX and ADM files.
This guide covers two different scenarios to highlight the potential differences in the ADMX storage location and Group Policy tools needed when working with local and domain-based GPOs.
Donc les adml et admx sont au format XML et donc éditable dans un éditeur de texte.
Et donc nous pouvons créer nos propre configuration à déployer en GPO
Exemple ADML WS 2016 (partie langage du modèle d’administration)
<?xml version="1.0" encoding="utf-8"?> <!-- (c) 2014 Microsoft Corporation --> <policyDefinitionResources xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0" schemaVersion="1.0" xmlns="http://schemas.microsoft.com/GroupPolicy/2006/07/PolicyDefinitions"> <displayName>MS Security Guide</displayName> <description>MS Security Guide mitigations</description> <resources> <stringTable> <string id="Cat_SecGuide">MS Security Guide</string> <string id="RestrictRemoteSam_NAME">Network access: Restrict remote enumeration of SAM accounts and groups</string> <string id="RestrictRemoteSam_HELP">RestrictRemoteSam help text</string> <string id="Pol_PtH_LATFP">Apply UAC restrictions to local accounts on network logons</string> <string id="Pol_PtH_LATFP_Help">This setting controls whether local accounts can be used for remote administration via network logon (e.g., NET USE, connecting to C$, etc.). Local accounts are at high risk for credential theft when the same account and password is configured on multiple systems. Enabling this policy significantly reduces that risk. Enabled (recommended): Applies UAC token-filtering to local accounts on network logons. Membership in powerful group such as Administrators is disabled and powerful privileges are removed from the resulting access token. This configures the LocalAccountTokenFilterPolicy registry value to 0. This is the default behavior for Windows. Disabled: Allows local accounts to have full administrative rights when authenticating via network logon, by configuring the LocalAccountTokenFilterPolicy registry value to 1. For more information about local accounts and credential theft, see "Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques": http://www.microsoft.com/en-us/download/details.aspx?id=36036. </string> <string id="Pol_PtH_WDigestAuthn">WDigest Authentication (disabling may require KB2871997)</string> <string id="Pol_PtH_WDigestAuthn_Help">When WDigest authentication is enabled, Lsass.exe retains a copy of the user's plaintext password in memory, where it can be at risk of theft. Microsoft recommends disabling WDigest authentication unless it is needed. If this setting is not configured, WDigest authentication is disabled in Windows 8.1 and in Windows Server 2012 R2; it is enabled by default in earlier versions of Windows and Windows Server. Update KB2871997 must first be installed to disable WDigest authentication using this setting in Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012. Enabled: Enables WDigest authentication. Disabled (recommended): Disables WDigest authentication. For this setting to work on Windows 7, Windows 8,Windows Server 2008 R2 or Windows Server 2012, KB2871997 must first be installed. </string> <string id="Pol_PtH_LsassAudit">Lsass.exe audit mode</string> <string id="Pol_PtH_LsassAudit_Help">Enable auditing of Lsass.exe to evaluate feasibility of enabling LSA protection. For more information, see http://technet.microsoft.com/en-us/library/dn408187.aspx</string> <string id="Pol_PtH_LsassRunAsPPL">LSA Protection</string> <string id="Pol_PtH_LsassRunAsPPL_Help">Enable LSA protection. For more information, see http://technet.microsoft.com/en-us/library/dn408187.aspx</string> <string id="SUPPORTED_Windows10Server2016">At least Windows 10 or Windows Server 2016</string> </stringTable> <presentationTable> <presentation id="RestrictRemoteSam_Text"> <text>Some text</text> <text>Some more text</text> </presentation> </presentationTable> </resources> </policyDefinitionResources>
Exemple ADMX sécurité Windows Server (partie configuration du modèle d’administration)
<?xml version="1.0" encoding="utf-8"?> <policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0" schemaVersion="1.0" xmlns="http://schemas.microsoft.com/GroupPolicy/2006/07/PolicyDefinitions"> <policyNamespaces> <target prefix="SecGuide" namespace="Microsoft.Policies.SecGuide" /> <using prefix="windows" namespace="Microsoft.Policies.Windows" /> </policyNamespaces> <resources minRequiredRevision="1.0" /> <supportedOn> <definitions> <definition name="SUPPORTED_Windows10Server2016" displayName="$(string.SUPPORTED_Windows10Server2016)"/> </definitions> </supportedOn> <categories> <category name="Cat_SecGuide" displayName="$(string.Cat_SecGuide)"> </category> </categories> <policies> <policy name="RestrictRemoteSam" class="Machine" displayName="$(string.RestrictRemoteSam_NAME)" explainText="$(string.RestrictRemoteSam_HELP)" key="System\CurrentControlSet\Control\Lsa"> <parentCategory ref="Cat_SecGuide" /> <supportedOn ref="SUPPORTED_Windows10Server2016" /> <enabledList> <item key="System\CurrentControlSet\Control\Lsa" valueName="RestrictRemoteSam"> <value> <string>O:SYG:SYD:(A;;0xffffffff;;;BA)S:(AU;SAFA;0xffffffff;;;WD)</string> </value> </item> </enabledList> <disabledList> <item key="System\CurrentControlSet\Control\Lsa" valueName="RestrictRemoteSam"> <value> <delete /> </value> </item> </disabledList> </policy> <policy name="Pol_PtH_LATFP" class="Machine" displayName="$(string.Pol_PtH_LATFP)" explainText="$(string.Pol_PtH_LATFP_Help)" key="SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" valueName="LocalAccountTokenFilterPolicy"> <parentCategory ref="Cat_SecGuide" /> <supportedOn ref="windows:SUPPORTED_WindowsVista" /> <enabledValue> <decimal value="0" /> </enabledValue> <disabledValue> <decimal value="1" /> </disabledValue> </policy> <policy name="Pol_PtH_WDigestAuthn" class="Machine" displayName="$(string.Pol_PtH_WDigestAuthn)" explainText="$(string.Pol_PtH_WDigestAuthn_Help)" key="SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" valueName="UseLogonCredential"> <parentCategory ref="Cat_SecGuide" /> <supportedOn ref="windows:SUPPORTED_Windows7" /> <enabledValue> <decimal value="1" /> </enabledValue> <disabledValue> <decimal value="0" /> </disabledValue> </policy> <policy name="Pol_PtH_LsassAudit" class="Machine" displayName="$(string.Pol_PtH_LsassAudit)" explainText="$(string.Pol_PtH_LsassAudit_Help)" key="SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe" valueName="AuditLevel"> <parentCategory ref="Cat_SecGuide" /> <supportedOn ref="windows:SUPPORTED_Windows_6_3" /> <enabledValue> <decimal value="8" /> </enabledValue> <disabledValue> <decimal value="0" /> </disabledValue> </policy> <policy name="Pol_PtH_LsassRunAsPPL" class="Machine" displayName="$(string.Pol_PtH_LsassRunAsPPL)" explainText="$(string.Pol_PtH_LsassRunAsPPL_Help)" key="SYSTEM\CurrentControlSet\Control\Lsa" valueName="RunAsPPL"> <parentCategory ref="Cat_SecGuide" /> <supportedOn ref="windows:SUPPORTED_Windows_6_3" /> <enabledValue> <decimal value="1" /> </enabledValue> <disabledValue> <decimal value="0" /> </disabledValue> </policy> </policies> </policyDefinitions>
Comment les mettre en place dans notre infrastructure
Copier les AMDX dans c:\windows\policyDefinitions (dans le sous répertoire de sysvol si vous n’êtes pas sur un contrôleur de domaine)
Et copier les ADML dans le folder qui conviens ‘en-Us’ ou ‘fr-FR’ dans notre exemple.
Test :
Ouvrir GPMC.MSC
Ouvrir une GPO, aller dans stratégies / modelés d’administration / et là vous verrez les nouveaux ADMX
Exemple avec les Template de sécurité pour Windows Server 2016 (MS Security guide)
Exemple du modèle MSS legacy