Nous pouvons lire dans les deux articles mentionnés précédemment que le modèle de type ”code signing” est utilisé pour signer des macros. Nous allons donc créer un nouveau modèle de certificat nommé “Excel” à partir du modèle “code signing“. Ce modèle aura les caractéristiques suivantes:

• L’autoenrollment est configuré pour le groupe ldap389-excel-dev, ce groupe contient les utilisateurs autorisés à signer des projets VBA, à savoir vos dévelopeurs, dans notre exemple il contient l’utilisateur ldap389-dev.
• Clef privée: 2048 bits non exportable.
• Validité du certificat: 1 an.

Une fois le modèle de certificats “Excel” configuré, le certificat sera automatiquement installé par autoenrollment dans le magasin de certificats de notre utilisateur ldap389-dev faisant partie du groupe ldap389-excel-dev:

Il est conseillé de verrouiller par mot de passe son projet VBA avant de le signer, sous l’éditeur Visual Basic: click droit sur le projet, selectionner “propriétés” puis onglet “protection”. Pour signer son projet VBA: séléctionner son projet puis faire “outils\signature éléctronique”, cliquer sur “choisir”, le certificat présent dans son magasin local lui est alors proposé.

Le projet est maintenant protégé et signé pour la période de validité du certificat que vous avez configuré dans votre modèle, dans notre cas pour le modèle “Excel” 1 an. Il faudra ressigner la macro et la redéployer avant l’expiration du certificat (dans notre cas le 16/08/2012).

A moins que vous n’utilisez un serveur de TimeStamp conformément à la RFC 3161, ceci afin de dater la macro lors de sa signature. Le développeur devra éditer la clef HKEY_CURRENT_USER\Software\Microsoft\VBA\Security comme est indiqué dans le chapitre “Office files: enable time-stamping” de ce post. L’édition de cette clef peut être déployée via GPO pour le groupe  ldap389-excel-dev. Dans notre cas nous utiliserons les valeurs de registre suivantes:

• TimeStampURL (REG_SZ): http://timestamp.verisign.com/scripts/timstamp.dll.
• TimeStampRetryCount (REG_DWORD): 2.
• TimeStampRetryDelay (REG_DWORD): 2.

Une fois que vous avez signé les différents projets VBA qui ne l’étaient pas vous pouvez forcer le niveau de sécurité de Excel via GPO pour toutes les versions déployées dans votre entreprise, pour cela il vous faut utiliser les “Administrative Templates” de chaque version de Office:

• Office 2003 SP3 Administrative Template Files (ADM).
• Office 2007 Administrative Template Files (ADM,ADMX/ADML).
• Office 2010 Administrative Template Files (ADM,ADMX/ADML).

Vous pouvez créer une GPO qui empêche l’exécution des macros non signées pour toutes le versions de Excel des suites Office mentionnées ci dessus:

Les paramètres ci dessus sont les paramètres par défaut de Excel, mais il est toujours mieux de les forcer par GPO, au cas où ils seraient modifiés..

A propos du loopback processing je vous conseille la lecture de cet article en deux parties de 4sysops (partie 1, partie2).

Sur des serveurs TS/Citrix nous utilisons principalement le traitement par boucle de rappel en mode replace. Ceci afin de définir le même environnement utilisateur pour tout le monde, la GPO suivante est appliqué à tous les serveurs TS/Citrix de la même OU:

Dans cette OU sont donc situés différents serveurs Citrix/TS hébergeant chacun des applications différentes, celles ci peuvent nécessiter un paramétrage utilisateur différent: Dans notre exemple nous prendrons comme paramètre le titre de la barre Internet Explorer:

• Titre barre IE “Web Application 1″ pour les utilisateurs du groupe “Qualif-Xen-Usr-Param1″ se connectant aux objets ordinateurs TS/Citrix membres de “Qualif-Xen-srv-Param1″ situés dans l’OU “460-XenApp6″.
• Titre barre IE “Web Application 2″ pour les utilisateurs du groupe “Qualif-Xen-usr-Param2″ se connectant aux objets ordinateurs TS/Citrix membres de “Qualif-Xen-srv-Param2″ situés dans l’OU “460-XenApp6″.

Sans utiliser les GPP (Group Policy Preferences) nous ne pouvons appliquer un paramètre utilisateur en fonction du groupe d’ordinateur sur lequel l’utilisateur se connecte, nous ne pouvons qu’appliquer un filtrage de sécurité pour un groupe d’utilisateurs. Les GPOs avec paramétrage utilisateur liés à l’OU “460-XenApp6″ sont donc les suivantes:

Quand un utilisateur fait partie du groupe “Qualif-Xen-Usr-Param1″ le titre “Web Application 1″ est bien appliqué, de même quand un autre utilisateur fait partie du groupe “Qualif-Xen-Usr-Param2″ nous aurons le titre “Web Application 2″. Mais si un même utilisateur fait partie des groupes “Qualif-Xen-Usr-Param1″ et “Qualif-Xen-Usr-Param2″ alors il se verra toujours appliquer le paramétrage “Web Application 1″, quelque soit le serveur (donc application) auquel il se connecte, ceci à cause de l’ordre d’application des GPOs:

Le seul moyen de résoudre ce problème sans GPP est de placer les serveurs “Web Application 1″ et “Web Application 2″ dans des OU différentes et de lier chaque GPO avec paramétrage utilisateur à chaque OU . Ce qui n’est pas pratique en termes d’administration, car nos serveurs Citrix/TS ont des GPOs communes qu’il faudra penser à lier sur les deux OU (l’activation du loopback sur les objets ordinateurs par exemple).

Avec les GPP nous avons la fonction d’Item level Targeting, qui va nous permettre de conserver ces serveurs dans la même OU. En effet le paramètre de GPO “Title Bar Text” n’est rien d’autre que l’édition de la valeur “Window Title” de la clef HKEY_CURRENT_USER\Software\Microsft\Internet Explorer\Main. Il peut donc être déployé via GPP et nous utiliserons l‘item level targeting pour indiquer que le paramètre “Web Application 1″ ne s’applique que si l’utilisateur est membre du groupe  “Qualif-Xen-Usr-Param1″ et qu’il se connecte sur un serveur membre du groupe “Qualif-Xen-srv-Param1″:

les GPOs avec paramétrage utilisateur utilisant les GPP et liés à l’OU “460-XenApp6″ sont donc les suivantes:

Sur nos deux serveurs le titre de la barre IE est bien différent pour un utilisateur qui appartient aux groupes “Qualif-Xen-Usr-Param1″ et “Qualif-Xen-Usr-Param2″:

Ne pas oublier que pour obtenir le jeu de stratégies résultant pour les GPP il faut utiliser la GPMC comme expliqué dans mon dernier post.

Du moment que le paramétrage utilisateur est éditable via le registre ou tout autre objet de GPP (raccourci, map réseau…) alors cette méthode peut être appliquée pour éviter de multiplier les OUs de type Citrix/TS.

Nous allons parler DNS (dnsmgmt.msc), GPOs (rsop.msc et gpmc.msc) et finalement utilisateurs et ordinateurs AD (dsa.msc) et voir quels problèmes nous avons pu rencontrer lors de l’utilisation de ces consoles, que ce soit sous AD 2000/2003 et AD 2008.

DNS

• Vous ne pouvez pas gérer de serveurs DNS Windows 2008R2 avec une console d’administration DNS (dnsmgmt.msc) sous Windows 2003/XP et versions inférieures, car le niveau de sécurité a été augmenté au niveau RPC, pour plus de détails vous pouvez lire cette KB. La version 2003/XP de dnscmd.exe n’est pas compatible non plus: Attention lors de vos migrations de DCs vers 2008R2, vos anciens scripts utilisant la version 2003/XP de dnscmd.exe seront à mettre à jour.

• L’effacement de glue records fait freezer la console dnsmgmt.msc sous Windows 2008R2, il vous faudra faire cette manipulation avec dnscmd.exe.

GPOs

• Les paramètres de préférences de stratégies de groupe (GPP) n’apparaissent pas quand vous faites un rsop.msc sur une machine cliente: Par contre, si vous utilisez la GPMC pour obtenir les paramètres de GPOs appliqués à une machine vous aurez cette information. Pour cela utiliser le Group Policy Results Wizard:

• Vous ne pouvez pas installer la console gpmc.msc sur Windows 2003 x64, pour y arriver il vous faut modifier le package MSI avec un éditeur comme Orca. Les scripts vbs pour manipuler les GPOs ne fonctionneront pas (si quelqu’un a un solution ?), l’appel CreateObject(“GPMGMT.GPM”) vous retournera l’erreur:

Microsoft VBScript runtime error: ActiveX component can’t create object: ‘GPMGMT.GPM’

L’enregistrement de la DLL gpmgmt.dll ne résout pas le problème.

Utilisateurs et ordinateurs AD (ADUC ou DSA.MSC)

Lorsque vous utilisez la console dsa.msc avec les RSAT vous avez l’onglet attribute editor qui vous permet de vous séparer de votre console adsiedit.msc:

• Si vous gérez un AD 2000/2003 avec les RSAT vous ne verrez pas l’onglet attribute editor apparaitre sans réaliser cette manipulation.

 

• Sous AD 2008 cet onglet apparait dans l’ADUC, mais lorsque vous éditez un objet suite à une recherche, cet onglet n’est pas disponible. Par contre si vous utilisez la console ADAC (disponible nativement sous 2008R2), cet onglet apparaît bien dans la section “Extensions” quand vous faites une recherche sur un objet.

Malgré ces quelques comportements bizarres on continue a se servir de nos MMC qui nous facilitent bien la vie, sinon on aurait plus que du Windows Server Core , ce qui nous ferait gagner un peu de stockage… (voir chapitre Less disk space required)

Tout d’abord cherchez les règles nécessaires au bon fonctionnement de votre application en éditant les règles firewall locales de votre serveur de tests, ces règles auront un préfixe donné ($prefix=LDAP389 dans notre exemple). Nous exportons ces règles dans un ficher wfw avec la commande:

netsh advfirewall export $wfwfile

Nous voulons ensuite importer les règles $prefix=LDAP389 dans une GPO ($GPONAME), ceci afin de les appliquer à un ensemble de serveurs:

Pour importer ces paramètres vous devez utiliser netsh advfirewall puis vous connecter au magasin de données d’objets de stratégie de groupes. Or celui-ci n’est pas directement accessible via la commande “netsh advfirewall set store gpo=domain/gpo_name”:

Ce qui donne en PsH, merci VMdude

$stream = [System.IO.StreamWriter] $netshinput
$stream.WriteLine('advfirewall')
$stream.WriteLine('set store gpo=' + $domainfqdn + '\' + $GPONAME)
$stream.WriteLine('show store')
$stream.WriteLine('import ' + $wfwfile)
$stream.WriteLine('exit')
$stream.close()
 
 get-content $netshinput | netsh

Via cette commande tous les paramètres d’ouverture firewall sont importés dans la GPO, pas seulement ceux explicitement créés, ce qui peut ralentir l’application de cette dernière. Nous allons grace au cmdlet Remove-GPRegistryValue, effacer les règles dont le préfixe n’est pas $prefix=LDAP389 et donc garder seulement les règles qui nous intéressent.

Avant d’effacer ces paramètres nous devons déterminer sur quel DC ($bindserver) la commande netsh advfirewall les a édités, pour cela il faut déterminer la cible active correspondant au partage SYSVOL:

Pour avoir la valeur de $bindserver:

$dfs = dfsutil cache referral
foreach ($dfss in $dfs) {if (($dfss -like '*ACTIVE TARGETSET*') -and ($dfss -like '*sysvol*')) { $bindserver = $dfss.split("\")[1]}}

Reste donc a rechercher les règles pare-feu qui ne commencent pas par $prefix=LDAP389 et les effacer sur DC $bindserver, ceci afin de s’affranchir des problèmes de réplication:

# Get GPO reg settings for FW rules
$gporeg = get-GPRegistryValue -Name $GPONAME -server $bindserver -Key "HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\FirewallRules"
 
# Remove FW rules which do not match $prefix*
 
foreach ($gporegs in $gporeg)
 
{ if ($gporegs.Value -notlike '*Name=' + $prefix + '*')
 {Remove-GPRegistryValue -Name $GPONAME -server $bindserver -key "HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\FirewallRules" -ValueName $gporegs.ValueName}
 
}

Pour télécharger le script complet c’est ici:

Vous devez éditer les valeurs:

• $prefix: Péfixe des règles FW éditées manuellement.
• $GPONAME: Nom de la GPO à éditer pour importer les paramètres FW.

1. Commande: adprep /domainprep /gpprep: 
   • Problèmes de droits:

   Lors du lancement de cette commande, vous avez un code d’erreur “LDAP API ldap_modify_ext_s() finished, return code is 0×32” alors il s’agit problème de droits, la commande a pourtant bien été lancée avec un compte membre de “domain admins” . En ouvrant le fichier adprep.log nous avons les informations suivantes:

   [2010/11/26:15:12:19.468]
   Adprep was about to call the following LDAP API. ldap_modify_s(). The entry to modify is CN={64E2BDA7-0FC4-48DA-BB70-79261A7B4822},CN=Policies,CN=System
   ,DC=ldap389,DC=info.
   [2010/11/26:15:12:19.468]
   LDAP API ldap_modify_ext_s() finished, return code is 0×32

   Il s’agit d’un problème sur une GPO qui intervient lors de la partie gpprep du setup. Nous allons donc vérifier les permissions sur celle ci:

   

   L’administrateur qui a créé la GPO a retiré les droits au groupe “domain admins”, pour corriger cela il faut se mettre propriétaire de l’objet et rétablir les droits sur celui-ci. Une fois cela corrigé, la commande adprep /domainprep /gpprep passe sans problème.

   • Remarque concernant le staging:

   Si l’intervalle de réplication entre certains de vos contrôleurs de domaine est long (i.e. un de vos DCs réplique une fois tous les X jours avec ses partenaires de réplication) alors le répertoire de staging de votre SYSVOL peut augmenter de manière conséquente, ceci de manière temporaire. En effet, l’ensemble des GPOs de votre domaine étant modifiées par la partie gpprep du setup, toutes ces modifications doivent être répliquées sur l’ensemble des DCs, le répertoire de staging voit alors sa taille augmenter tant que le DC répliquant le moins souvent n’a pas répliqué les modifications, cette taille baisse au fur et à mesure que ce DC réplique les modifications sur son partage SYSVOL.

2. Commande adprep /rodcprep:

Si vous rencontrez le message d’erreur suivant: “Adprep could not contact a replica for partition DC=DomainDnsZones,DC=ldap389,DC=info“, alors il vous suffit de lancer le script correctif fournit dans cette KB.

Si vous désirez lire plus d’articles concernant les erreurs avec adprep je vous conseille la lecture de cet article technet et de ce post de askDS.

L’opération de remplacement de permission sur une GPO peut servir quand un administrateur d’une OU créé une GPO, il en est alors propriétaire et ne donne pas les droits en contrôle total au groupe d’administration auquel il appartient. Sur notre domaine composé de deux sites, un par OU, nous avons deux types de GPOs:

• Les GPOs nommés “GLOBAL-*” créés par les administrateurs du domaine, et communes au SITE1 et au SITE2, elles ne sont pas modifiables par les administrateurs de site:

• Les GPOs nommés “SITEx-*” créés par les administrateurs de l’OU SITE1 ou SITE2, lors de leur création par l’administrateur de site c’est le compte utilisateur de ce dernier (par ex: Site1-UserAdmin1 pour le SITE1) qui a les permissions sur la GPO:

Il faut alors remplacer les permissions de l’utilisateur Site1-UserAdmin1 avec le groupe SITE1-ADM pour que tous les administrateurs puissent modifier la GPO:

Le pack PowerShell utilisé sera Active Roles Management Shell for AD de Quest, le but du script est de remplacer les permissions des GPOs nommés “SITE1-*” si le groupe SITE1-ADM n’a pas de droits d’administration sur ces dernières (critère utilisé: peut effacer la GPO).

Une fois les GPOs nommés “SITE1-*” trouvées nous utilisons le CmdLet Get-QADPermission pour lire les permissions sur celles ci. Si le groupe SITE1-ADM n’a pas de droits d’administration sur une GPO, alors nous cherchons le compte ($AdminAccount) qui a les droits “effacer” sur celle ci à l’aide de la commande:

Get-QADPermission $gpo  |  foreach-object {if (( $_.AccountName -like $domain + '\*' ) -and ($_.Rights -like '*delete*')){$AdminAccount = $_.AccountName}}

Une fois le compte $AdminAccount trouvé il nous faut récupérer son SID ($oldsid) et exporter les permissions de la GPO au format SDDL, ceci grâce au CmdLet Get-QADObjectSecurity. Puis il faut remplacer dans la chaîne SDDL le SID du compte administrateur Site1-UserAdmin1 ($oldsid) par le SID du groupe d’administration SITE1-ADM ($newsid), enfin il nous faut injecter les nouvelles permissions dans la GPO grâce aux commandes suivantes, trouvées sur un post de BSonPoSH:

$sddlgpc2 = $sddlgpc.replace($oldsid,$newsid)
$DE = [ADSI]"LDAP://$gpodn"
$DE.psbase.ObjectSecurity.SetSecurityDescriptorSddlForm($sddlgpc2)
$DE.psbase.commitchanges()

A ce stade là vous avez édité la sécurité sur une seule partie de la GPO: Le Group Policy Container. Si vous allez sur la GPO dans GPMC vous aurez le message d’erreur suivant:

Le remplacement de permissions est à faire aussi sur la partie SYSVOL de la GPO (répertoire identifié par son GUID) à savoir le Group Policy Template. Cela se fait à l’aide du CmdLet Set-acl et la fonction SetSecurityDescriptorSddlForm comme décrit dans cet article.

Vous pouvez télécharger le script ici:

Il vous faudra remplacer les éléments suivants:

• $domain: Nom NetBios du domaine.
• $domainFQDN: FQDN du domaine.
• $siteadmgrp: Groupe d’administration du site.
• $gpoprefix: Préfixe du nom des GPOs gérées par les administrateurs de site.

Lancer le script REPLACE_SDDL_GPO.ps1, vous serez prompté avant le remplacement de la permission, le nom de la GPO et des comptes AD concernés sera affiché:

Afin de voir quelle requête est lancée par la GPMC lors de la recherche d’un paramètre de GPO nous allons activer le mode verbose de log de la console. Réalisons maintenant une recherche de toutes les GPOs ayant le paramètre “redirection de dossiers” de configuré dans la partie utilisateur de la stratégie.

Puis nous allons consulter le fichier %TEMP%\gpmgmt.log afin de voir quelle opération a été tracée:

[VERBOSE] CGPMSearch::DumpCriteria(): Dumping 1 criteria ================
[VERBOSE] CGPMSearch::DumpCriteria(): Property: “gpoUserExtensions”
[VERBOSE] CGPMSearch::DumpCriteria():    Operation – Contains
[VERBOSE] CGPMSearch::DumpCriteria():     Value (string) “{25537BA6-77A8-11D2-9B6C-0000F8080861}“.
[VERBOSE] CGPMSearch::DumpCriteria(): End criteria dump ==================

Le filtre de recherche se fait via un simple attribut LDAP de l’objet de GPO situé dans le container “CN=System,CN=Policies,DC=%domain%“. Utilisons adsiedit.msc afin de voir plus en détails les attributs d’un objet de stratégie de groupes:

On remarque que l’attribut gPCUserExtensionNames est de la forme [%GUID1% %GUID2% ....], Le GUID est une valeur fixe qui correspond au type de critère recherché: {25537BA6-77A8-11D2-9B6C-0000F8080861} pour la redirection de dossiers dans la partie utilisateur de la GPO. Une GPO pouvant avoir plusieurs types de paramètres d’activés, par exemple “script de logon” et “redirection de dossiers”, les GUIDs sont mis simplement les uns à la suite des autres dans cet attribut.

Pour la partie des paramètres ordinateur de la GPO c’est le même principe sauf qu’il s’agit de l’attribut gPCMachineExtensionNames de la GPO. Il nous reste donc à inventorier les différents GUID correspondant aux paramètres de GPOs proposés dans la liste déroulante en effectuant une recherche via la GPMC et en analysant le fichier de log. Vu le nombre de paramètres de recherche possibles, 30 pour la configuration utilisateur et 35 pour la configuration ordinateur, les résultats sont disponibles dans ce fichier Excel à télécharger:

En Powershell il nous suffit de faire une simple recherche avec Get-ADObject pour rechercher les GPOs contenant une redirection de dossiers, le filtre recherche les objets de type GPO (ObjectClass=GroupPolicyContainer) et ayant l’attribut gPCUserExtensionNames qui contient le GUID correspondant à la redirection de dossiers:

$ObjGPOs = Get-ADObject -Filter {(ObjectClass -eq "groupPolicyContainer") -and (gPCUserExtensionNames -like *{25537BA6-77A8-11D2-9B6C-0000F8080861}*)}

Si le résultat retourné par $ObjGPOs n’est pas nul, nous pouvons grâce au CmdLet Get-GPOReport (ne pas oublier d’importer le module Grouppolicy)  exporter le rapport des GPOs trouvées au format HTML, pour cela nous avons besoin d’entrer en paramètre de la commande (-guid) le GUID de la GPO, mais sans les caractères “{}”:

Import-Module GroupPolicy;
if ($ObjGPOs -ne $Null) {
foreach($ObjGPO in $ObjGPOs)
    {      $guid = [System.Text.RegularExpressions.Regex]::Replace($ObjGPO.Name,"[{}]","")
    $pathtosavef = "C:\export\" +  (get-GPO -guid $guid).DisplayName + ".html"
    get-GPOReport -guid $guid -ReportType html -Path $pathtosavef
    }
}

L’exemple ci dessus exporte les rapports de GPO au format %Nom_GPO%.html dans le dossier c:\export. Nous allons donc faire un script qui demande si nous recherchons un configuration ordinateur ou utilisateur puis le type de paramètre de GPO à chercher, nous lançons donc le script search_GPO_2008.ps1 avec comme paramètre optionnel -report qui indique le chemin de destination des fichiers html:

Dans l’exemple ci dessus nous recherchons une GPO ordinateur pour lequel un paramètre de service est configuré à travers les préférences de stratégie de groupe , nous indiquons donc 2 puis 20. Si vous n’indiquez pas de paramètre -report, aucun rapport html n’est généré mais les informations sur le nom de la GPO, son GUID et sa date de création sont tout de même affichés.Pour télécharger le script c’est ici:

Pour ceux qui ne sont pas encore sous Active Directory 2008, voici un script équivalent pour la version 2003, réalisé à l’aide des Quest AD Cmdlets, la fonction d’export au format HTML n’est pas disponible car il n’y a pas (à ce jour), de CmdLets pouvant réaliser cette opération. Ci dessous le lien pour télécharger search_GPO_2003.ps1:

Le principe de fonctionnement est le même:

Vous pouvez adapter le script search_GPO_2008.ps1 afin de faire d’autres types de manipulations sur les GPOs issues de vôtre filtre de recherche, par exemple les sauvegarder dans un dossier particulier avec le CmdLet Backup-GPO etc…

Cette solution de contournement est donc applicable sur vos postes qui ne sont pas encore à jour et qui ne peuvent recevoir le patch de sécurité fournit par MS. Son gros désavantage est la disparition des images d’icônes sur certains fichiers *.lnk. Il est donc très vivement conseillé de mettre à jour vos systèmes d’exploitation avec le bon Service Pack pour ne pas avoir à en arriver la. Si ce n’est pas réalisable dans des délais raisonnables nous allons voir comment déployer cette solution de contournement via GPO. Ce sujet a déjà été traité dans cet article du Group Policy Center, il nous indique comment activer ou désactiver la solution de contournement sous Windows 2008 via les préférences de stratégies de groupe. Nous allons dans ce post le compléter en indiquant comment se servir du filtrage WMI pour cibler le comportement de la GPO, à savoir activer la solution de contournement pour les postes qui n’ont pas le patch de sécurité d’installé et le désactiver sur les ordinateurs ayant la KB2286198 d’installée. Puis comment réaliser la même chose sans les GPO de préférences, avec un AD sous Windows 2003.

Nous allons tout d’abord voir comment activer le workaround en utilisant la méthode du Group Policy Center mais en ne ciblant que les postes qui n’ont pas le patch de sécurité d’installé. Afin de profiter des préférences de stratégie de groupe vous devez au minima avoir un DC sous Windows 2008 et appliquer cette KB sur tous vos clients, attention à ne pas oublier l’installation de XMLLite pour Windows 2003 et XP. Afin de ne cibler que les postes qui n’ont pas la KB2296198 d’installée nous allons utiliser le Item-Level targeting et filtrer via une requête WMI l’existence de nôtre KB. La grosse évolution est que avec un AD sous Windows 2003 nous ne pouvions réaliser un filtrage WMI que si le résultat retourné était TRUE, grâce au Targeting Collection nous pouvons réaliser le filtre suivant: Si la requête WMI retourne un résultat FALSE (i.e. KB non présente) alors j’applique l’élément de préférence de stratégie de groupe (Item options IS NOT):

La requête WMI permettant de savoir si la KB est installée se réalise en parcourant la classe Win32_QuickFixEngineering et en filtrant sur le HotFixID KB2286198:

En appliquant ces éléments de filtrage à l’édition des deux clefs de registre et la désactivation du service WebClient indiqués dans le post du Group Policy Center vous ne ciblerez l’activation du workaround que pour les postes qui n’ont pas le patch de sécurité. Cette nouveauté concernant le filtrage WMI (i.e. gérer la condition FALSE) n’est valable que pour les préférences de stratégies de groupe, les autres paramètres de GPOs sont soumis aux mêmes restrictions que sous Windows 2003: Le filtrage se fait sur la valeur TRUE renvoyée par la requête.

Pour désactiver la solution de contournement il vous suffit d’utiliser la même requête, en utilisant l’option par défaut du Targeting Editor à savoir filtrer si la condition est TRUE (Item options IS).

Maintenant nous allons voir le pire cas de figure: Vous désirez activer cette solution de contournement via GPO mais vous ne disposez pas des préférences de stratégie de groupe (AD 2003) et vous avez encore sur votre parc des clients avec un OS Windows 2000 (!):

Dans ce cas la GPO avec filtre WMI classique est appliqué si la requête renvoie TRUE, or on ne veut appliquer le workaround que si la KB n’est pas présente, donc renvoie FALSE… Nous allons donc créer deux GPOs et jouer sur l’ordre d’application de celles ci:

• Une première GPO (KB2286198-WOKAROUND-AD2003-Enable) qui applique le workaround à tous les postes (pas de filtrage) qui désactive le service WebClient et édite les valeurs default de clefs de registre HKCR\lnkfile\shellex\IconHandler et HKCR\piffile\shellex\IconHandler à vide. Cette GPO va s’appliquer en premier sur le poste et aura donc une priorité inférieure à la seconde GPO.
• Une seconde GPO (KB2286198-WOKAROUND-AD2003-Disable) qui désactive le workaround pour les postes qui répondent TRUE à la requête WMI indiquant que le poste est patché. Celle ci active le service WebClient (valeur par défaut) et édite les valeurs de clefs de registre à leur valeur par défaut ({00021401-0000-0000-C000-000000000046}). Cette GPO, ne s’appliquant qu’aux postes patchés, va désactiver le workaround en s’appliquant après la première GPO et a donc une priorité supérieure.

Afin de pousser les valeurs de registre via GPO nous allons générer deux fichiers .ADM à l’aide de reg2adm de Yizhar Hurwitz, vous trouverez un tutoriel ici. Pour télécharger les modèles d’administration pour nos deux GPOs c’est ici:

Le filtre WMI à appliquer sur la seconde GPO est toujours le même:

SELECT * FROM Win32_QuickFixEngineering WHERE HOTFixID = ‘KB2286198′

Le problème est qu’un OS Windows 2000 qui se voit appliquer une GPO avec filtrage WMI ignore le filtre et applique toujours la GPO. Donc KB2286198-WOKAROUND-AD2003-Disable sera toujours appliquée sur cet OS, or ce n’est pas le comportement que nous souhaitons car le patch de sécurité n’est pas disponible sur cette version…

Nous allons donc contourner le problème en recensant toutes nos machines Windows 2000 et en les mettant dans un groupe de sécurité W2K-WORKSTATIONS, pour cela utiliser la commande PowerShell des Quest AD CMDlets suivante:

get-QADComputer -OSName 'Windows 2000*' -ldapFilter '(!(userAccountControl:1.2.840.113556.1.4.803:=2))' -Sizelimit 10000 | Add-QADMemberof -Group 'ldap389\W2K-WORKSTATIONS'

Nous appliquerons ensuite un filtrage de sécurité sur KB2286198-WOKAROUND-AD2003-Disable indiquant de ne pas appliquer la GPO pour le groupe W2K-WORKSTATIONS.

La GPO KB2286198-WOKAROUND-AD2003-Enable est donc la suivante:

Et la GPO KB2286198-WOKAROUND-AD2003-Disable avec une priorité supérieure à la première GPO qui possède un filtrage WMI et un filtrage par groupe:

Voici donc le résultat d’une commande rsop.msc et l’état des icônes du menu démarrer sur un poste protégé avec la KB2286198, donc sur lequel le workaround n’est pas appliqué puis sur un poste non patché sur lequel la solution de contournement est appliquée:

En jouant sur l’ordre d’application des GPOs nous arrivons à nos fins, cependant cette méthode relève un peu du bricolage… En conclusion: Maintenez à jour vos versions d’OS et de Service Packs. Il n’est pas dit quand dans le futur des solutions de contournement soient disponibles pour combler une faille de sécurité.

L’application et la réplication des GPOs dans notre domaine fonctionnait normalement, par contre l’édition des stratégies de groupe sur le DC impacté devenait impossible, en même temps que la GPMC freezait une surcharge CPU du process lsass.exe survenait sur le contrôleur de domaine et ceci tant que la GPMC n’était pas killée sur la console. Nous avons donc continué à éditer nos GPOs à partir d’autres DCs et le fonctionnement de la production était quasi-normal le temps de la résolution de l’incident.

Afin de mieux comprendre le problème, la première chose à faire est de lancer lors du freeze de GPMC une analyse avec Server Performance Advisor sur le DC dont voici le résultat:

On voit que le DC a du mal à effectuer une recherche LDAP initiée par la GPMC et cela entraine une consommation anormale du process lsass.exe, afin d’en savoir plus nous réalisons deux analyses de trames avec WireShark sur nos consoles d’administration: La première en reproduisant le problème en lançant la GPMC connecté au DC impacté, la seconde en connectant la GPMC à un autre DC et sur lequel l’édition de GPOs est possible:

On voit que sur le DC posant problème la requête LDAP n’aboutit pas, au bout de plus de 2 minutes toujours pas de résultat. Lors d’un fonctionnement normal de la GPMC, les GPOs liées à notre OU sont trouvées en quelques secondes.

Il nous faut maintenant identifier quelle requête LDAP n’arrive pas à traiter notre DC, pour cela nous allons activer le diagnostique Active Directory Field Engineering, l’événement d’ID 1644 sera alors généré lorsque le problème survient, celui ci est caractéristique d’une requête LDAP consommant trop de ressources. Une fois l’audit activé, nous avons alors l’événement suivant qui apparaît lors du freeze de GPMC:

Les valeurs retournées par la requête sont GPLink et GPOptions (on peut d’ailleurs observer le résultat sur la capture de trames réseau).  Le filtre de recherche se fait sur ObjectCategory qui est un attribut indexé par défaut de la base AD. La requête LDAP devrait donc être réalisée rapidement, ce qui n’est pas du tout le cas, nous en avons malheureusement la confirmation en lançant la même requête avec ldp.exe, le résultat est le suivant:

———–
***Searching…
ldap_search_ext_s(ld, “DC=ldap389,DC=info”
, 2, “( |  (objectCategory=CN=Domain-DNS,CN=Schema,CN=Configuration,DC=ldap389,DC=info)  (objectCategory=CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=ldap389,DC=info) )”, attrList,  0, svrCtrls, ClntCtrls, 10, 0 ,&msg)
Error: Search: Timeout. <85>
Server error:
Error<94>: ldap_parse_result failed: No result present in message
Getting 0 entries:
———–

La requête tombe en Timeout, alors que sur les autres DCs aucun problème avec celle ci. Nous avons donc décidé dans un premier temps d’augmenter la valeur du paramètre MaxQueryDuration des stratégies LDAP de notre DC, ainsi que de configurer ldp.exe afin d’augmenter la période de TimeOut. Ces manipulations n’ont servi à rien.

Après quelques recherches nous sommes tombés sur cet article très instructif de Tim Springston. Il affirme que:

“if the attribute(s) which are showing as taking an extended amount of time to search for are already indexed then the lack of an index is clearly not your problem.  Sometimes indices, perhaps through frequent changes or other reasons, need to be re-indexed to remove “whitespace” or other problems.  So checking the integrity of the database or doing an offline defrag may be the way to go.”

Procédons donc d’abord à une analyse sémantique du ntds.dit de notre DC:

Le résultat est immédiat: des inconsistances dans la base ont été trouvées. Nous relançons cette fois la même analyse sur la base, mais en mode “fixer les problèmes” (voir point 11 de la KB). Pour terminer nous réalisons une défragmentation offline du ndts.dit et nous quittons le mode DSRM pour rebooter notre DC normalement.

Une fois le DC redémarré nous essayons d’utiliser la GPMC en étant connecté sur le DC qui posait problème: L’utilisation de l’éditeur de stratégies de groupe se fait normalement et nous pouvons à nouveau éditer des GPOs sur ce contrôleur de domaine.