Le but de ce script est d’exporter au format XML les Firewall Policies de chacun de vos serveurs TMG:

Pour nous connecter à chacun des serveurs TMG nous allons utiliser la méthode ConnectToConfigurationStorageServer . Puis nous ferons appel à la collection FPCPolicyRules pour parcourir les différentes règles firewall. Pour chaque serveur les informations suivantes seront affichées:

• Nom de la règle.
• Si celle ci est active.
• Type d’action: Accepter traffic (0), Rejeter le traffic (1).

Ce qui donne:

Chaque règle est exportée au format XML dans un fichier %NOMSERVER%_%NOMREGLE%.xml situé dans répertoire courant. Ceci grâce à la méthode FPC.ExportToFile:

$oFPC = New-Object -comObject FPC.root
$cArrays = $oFPC.Arrays
Foreach ($oArray in $cArrays){
    $policyrules = $oArray.ArrayPolicy.policyrules
    foreach ($policyrule in $policyrules){
        $policyrule | select name,enabled,action
        $szOutFilePath = 'C:\' + $policyrule.name + '.xml'
        #See options for $iOptionalData at <a href="http://msdn.microsoft.com/en-us/library/aa490382.aspx">http://msdn.microsoft.com/en-us/library/aa490382.aspx</a>
        $iOptionalData =  0x00000001 -bor 0x00000002 -bor 0x00000004 -bor 0x00000008
        $szPassword = "12345678"
        $szComment = ""
        $policyrule.ExportToFile($szOutFilePath, $iOptionalData, $szPassword, $szComment)
    }
}

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

Changer les valeurs:

• $servers: noms de vos serveurs TMG.
• $iOptionalData: Type d’export (données Radius etc…) Voir ce lien pour plus détails.
• $szPassword: Mot de passe utilisé pour exporter les données confidentielles (ex: données Radius)

Get-OwaVirtualDirectory | ft server,InternalURL,externalURL

Dans notre exemple l’URL interne est mail.internal.ldap389.info et l’externe mail.ldap389.info. Seul le trafic SSL est accepté, sur chacun de nos CAS un certificat SAN issu de notre PKI d’entreprise avec ces deux URLs  est mis en place.

Les clients accédant à l’URL interne mail.internal.ldap389.info se connectent directement au serveur CAS, le trafic est réparti entre les différents membres du CAS array via un équipement HLB (trafic en vert dans le schéma ci-dessous).

Les clients se connectant depuis l’internet via l’URL mail.ldap389.info accèdent tout d’abord aux serveurs TMG, le trafic est réparti sur les cartes réseau externes des différents membres de l’array TMG via un équipement HLB, ces IPs sont accessibles depuis Internet et situés dans une “DMZ publique”. Le trafic entre les clients internet et le CAS array est indiqué en rouge sur le schéma et expliqué ci-après:

Un certificat a été acheté auprès d’un CA externe et déclaré sur le listener OWA des serveurs TMG afin de permettre aux machines  ne faisant pas partie du domaine internal.ldap389.info, de communiquer via SSL avec votre array TMG. Si vous utilisez un certificat issu de votre PKI interne alors le root CA devra être déclaré comme de confiance sur tous les clients externes, sous peine d’avoir ce type d’avertissement lors de la connexion:

Les serveurs TMG communiquent, à partir de leur carte réseau interne situé en “DMZ privée”, de manière sécurisé avec le CAS array.  Pour cela le certificat de votre CA d’entreprise est déclaré comme autorité de certification de confiance sur les serveurs TMG. Ceci afin de permettre le traffic SSL avec le certificat SAN mis en place sur les membres du CAS array et issu de votre PKI d’entreprise.

L’authentification des clients auprès du TMG est de type “HTML Form Authentication”, les credentials de l’utilisateur sont validés via LDAP over SSL auprès d’un RODC sous Windows 2008R2 Core membre du domaine internal.ldap389.info. Plusieurs RODC peuvent être configurés via le LDAP Server Set. La mise en cache des mots de passe pour les utilisateurs accédant à la messagerie est conseillée, dans ce cas utiliser un RODC par site AD. La configuration de l’authentification se fait au niveau du listener OWA sur le TMG:

Pour que TMG puisse communiquer en SSL auprès du RODC le nom rodc.internal.ldap389.info doit être résolu via un fichier host. De même pour une communication sécurisée entre TMG et le CAS array, le nom mail.ldap389.info doit pointer vers le HLB répartissant le trafic externe sur le CAS array (voir host file sur le schéma).

Afin de bénéficier de toutes les fonctionnalités d’une array TMG entreprise, dont la réplication EMS, celle-ci doit être membre d’un domaine (dmz.local). Pour déployer un domaine en DMZ nous vous conseillons la lecture de document. Dans notre cas, le domaine en DMZ n’a pas de relation d’approbation avec le domaine interne, ni aucune redirection DNS (d’où l’emploi de fichiers host dans le paragraphe ci-dessus). Seules les communications sécurisées sont autorisées de la “DMZ privée” vers le réseau interne.

Afin de sécuriser ce domaine en DMZ (trafic en bleu sur le schéma), les contrôleurs de domaine sont placés dans un subnet dédié de la “DMZ privée”, qui n’accepte aucun trafic venant de l’internet. Les TMG s’authentifient uniquement auprès de RODC 2008R2 core, le port DNS TCP 53 doit tout de même être ouvert vers le PDCe, seul RWDC du domaine, afin de permettre la mise à jour DNS des clients (voir How does the client DNS update referral mechanism work?). Pour joindre vos serveurs TMG auprès d’un RODC utiliser ce script. Si vous désirez sécuriser encore plus ce domaine vous pouvez aussi mettre en place un administrateur local pour les RODC et interdire la mise en cache des mots de passe des administrateurs du domaine. Vous pouvez aussi paramétrer la valeur CachedLogonCounts sur vos TMG à 0, mais vous ne pourrez pas vous loguer sur la machine avec un compte du domaine dmz.local si aucun contrôleur de domaine n’est disponible.

Dans cette configuration votre TMG est membre d’un domaine en DMZ sécurisé et vous permet de bénéficier de toutes les fonctionnalités du produit dans sa version Enterprise.

Pour connaitre le statut d’une mise à jour nous allons utiliser  l’espace de nom Microsoft.UpdateServices.Administration (enumeration UpdateApprovalAction), le code suivant parcoure toutes les KB et retourne son statut de validation pour l’ensemble des groupes d’ordinateurs.

[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($wsusserver,$False)
$updateScope = new-object Microsoft.UpdateServices.Administration.UpdateScope;
$updateScope.UpdateApprovalActions =[Microsoft.UpdateServices.Administration.UpdateApprovalActions]::Install -bor [Microsoft.UpdateServices.Administration.UpdateApprovalActions]::Uninstall -bor [Microsoft.UpdateServices.Administration.UpdateApprovalActions]:: All -bor [Microsoft.UpdateServices.Administration.UpdateApprovalActions]::NotApproved
 
$updates = $wsus.GetUpdates($updateScope)
 
$groups = $wsus.GetComputerTargetGroups()
 
foreach( $update in $updates){
 
    foreach($group in $groups) {
 
    $status = "Pending"
 
    #MSDN update status:
    #All: Use to query all updates, regardless of their action.
    #Install: Client installs the update.
    #NotApproved :The Update will not be available for clients. This value can be used in a simple targeting ComputerTargetGroup to "override" a UpdateApproval made to the "All Computers" ComputerTargetGroup.
    #Uninstall: Client removes the update.
 
        if ($update.GetUpdateApprovals($group).Count -ne 0)
        {$status = $update.GetUpdateApprovals($group)[0].Action}
    write-host ($update.Title + ';' + $group.Name + ';' + $status)
    }
}

Les deux groupes de production et de test héritent du groupe ”All Computers”:

Sont récupérés le statut de chaque KB pour les groupes suivants:

• $Allstatus: Groupe WSUS “All computers”, valeur par défaut “Not Approved“.
• $statusprod: Groupe WSUS comportant vos machines de production, valeur par défaut “Pending“, dans ce cas hérite de “All computers”.
• $statusqualif: Groupe WSUS avec vos machines de qualification, valeur par défaut “Pending“, dans ce cas hérite de “All computers”.

Si $statusprod est différent de $statusqualif alors le statut de chaque groupe est donné, si aucune valeur n’est renseignée pour l’un des deux groupes (Pending) alors le statut du groupe All computers est donné.

Pour télécharger le script comparant le statut de validation des patchs WSUS entre deux groupes c’est ici:

Le script retourne un fichier .csv avec comme informations:

• Le Nom de la KB.
• Le statut de validation pour le groupe de production en indiquant l’héritage de All Computers si besoin.
• Le statut de validation pour le groupe de test en indiquant l’héritage de All Computers si besoin.
• La classification MSRC du patch (voir cet article MSDN pour les valeurs possibles).
• Le bulletin de sécurité MS auquel il se rapporte.
• Les produits auxquels cette KB s’applique.

Changer les valeurs par défaut suivantes:

• $wsusserver: Nom de votre serveur WSUS.
• $grqualif: Nom du groupe WSUS des ordinateurs de tests.
• $grprod: Nom du groupe WSUS des ordinateurs en production.

Si vous voulez plus de scripts PowerShell sur WSUS je vous conseille ce lien du technet script center.

Ok vous avez terminé votre migration sous 2008R2 et vous avez plein de nouvelles features, comme la corbeille AD avec un niveau fonctionnel de forêt sous 2008R2…

Et bien en termes de PRA béton: Il ne vous reste plus qu’à passer sous Windows 8… Ceci afin de pouvoir faire des snapshots de vos V-DC La phrase suivante fera plaisir à mes collègues Hypervisor et VMDude:

Microsoft is working with other virtualization vendors to make sure they include this technology in the latest version of their hypervisors as well. It’s in their interest to do so.

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..

Nous allons considérer que le SP1 de Windows Vista n’est plus supporté, car le support MS se termine le  12 juillet 2011. Dans un premier temps nous allons donc inventorier avec Powershell les machines qui ne peuvent plus recevoir des patchs de sécurité du fait de leur obsolescence, ceci en s’inspirant de cet article de AskDS.

$base = 'OU=Servers,DC=ldap389,DC=info'
$d = [DateTime]::Today.AddDays(-30)
 
$computers = Get-ADComputer -Filter 'PasswordLastSet -ge $d' -Searchbase $base -Properties OperatingSystemVersion,OperatingSystemServicePack,dNSHostName,OperatingSystem
 
foreach($computer in $computers) {
 
if (($computer.OperatingSystemVersion -lt "5.1") -or (($computer.OperatingSystemVersion -like "5.1*") -and ($computer.OperatingSystemServicePack -ne "Service Pack 3")) -or (($computer.OperatingSystemVersion -like "5.2*") -and ($computer.OperatingSystemServicePack -ne "Service Pack 2")) -or (($computer.OperatingSystemVersion -like "6.0*") -and ($computer.OperatingSystemServicePack -ne "Service Pack 2")))
{$computer.Name + ';' + $computer.OperatingSystem + ';' + $computer.OperatingSystemServicePack  | Out-file NOK-OSVersion.csv -append}
}

Nous cherchons donc les machines actives, i.e. qui ont renouvelé leur mot de passe avec un DC au cours des 30 derniers jours, situées dans l’OU “Servers” et dont la version d’OS et de Service Pack n’est plus supportée par Microsoft. Ces machines listés dans le fichier NOK-OSVersion.csv ne peuvent plus recevoir des mises à jour de sécurité via WSUS, il faudra les mettre à jour.

Nous allons dans un second temps chercher les machines qui sont éligibles à recevoir des mises à jour mais qui ne remontent pas dans votre serveur WSUS. Il existe alors un problème au niveau du client WSUS de la machine où celui ci n’est pas configuré et elles téléchargent directement les patchs de sécurité sur Internet, ce qui n’est pas conseillé dans un environnement d’entreprise, car vous n’avez aucun contrôle quant à leur déploiement.

A partir de WSUS 3.0 SP2 il est possible d’utiliser PowerShell pour gérer vos mises à jour comme nous montre ce tutoriel de Boe Prox, ceci à l’aide du Namespace Microsoft.UpdateServices.Administration. Nous allons donc lister toutes les machines contenues dans nos groupes WSUS (sauf le groupe All Computers qui est un groupe qui contient au fait tous les groupes) et les comparer aux ordinateurs issus de notre requête faite sur l’annuaire Active Directory ($computer):

$wsusserver = "WSUS-server"
 
[void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($wsusserver,$False)
$groups = $wsus.GetComputerTargetGroups()
 
foreach($group in $groups) {
if ($group.Name -ne "All Computers"){
($wsus.getcomputertargetgroup($group.Id)).GetComputerTargets() |%{if ($_.FullDomainName -eq $computer.dNSHostName){ ....}}
}
}

Le FQDN de la machine est la clef commune entre l’objet ordinateur sous WSUS (attribut FullDomainName) et celui sous Active Directory (attribut DNSHostName). Les objets dont le matching est trouvé seront inscrits dans un fichier $file portant le nom du groupe WSUS auxquels ils appartiennent. Les ordinateurs pour lesquels il n’y a pas de matching, qui donc ne sont pas remontés sur votre serveur WSUS, sont indiqués dans un fichier NOK-wsus.csv. Pour ces derniers il faudra donc voir si vous les avez configurés pour pointer sur votre serveur WSUS, ou si le client WSUS a un problème.

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

Il vous faudra modifier les variables suivantes:

• $wsusserver: Nom de votre serveur WSUS.
• $base: DistingushedName de la base de vôtre recherche sur l’annuaire AD.

Nous lançons notre script à partir d’une console d’administration et devons utiliser le PSRemoting pour créer le fichier CSR sur le serveur IIS avant de l’envoyer à l’autorité de certification, puis une fois le certificat émis le récupérer dans le magasin local du serveur Web et configurer la partie IIS.

Tout d’abord voyons le modèle de certificat utilisé, il est nommé dans notre cas 2008-Webserver:

Une fois demandé le certificat devra être approuvé par le CA Manager, par ailleurs les informations du certificat seront contenues dans la requête (CSR). La clef privée à une longueur minimale de 2048 bits et n’est pas exportable. Le CSR sera généré avec certreq.exe à partir d’un fichier RequestPolicy.inf. Dans ce fichier, nous déclarons le Subject Alternate Name de notre certificat (i.e. nos multiples URL), à des endroits bien précis du fichier RequestPolicy.inf:

Comme l’indique la capture d’écran ci-dessus de cet article technet, les SAN seront déclarés dans la section Extension du fichier. Attention sur un CA d’entreprise ne jamais permettre l’obtention de certificats SAN en éditant la section RequestAttributes du fichier RequestPolicy.inf, ceci pour des raisons de sécurité, cela n’est valable que pour un CA en standalone.

Voyons donc à quoi va ressembler notre fichier RequestPolicy.inf:

[Version]
Signature=”$Windows NT$”

[NewRequest]
Exportable = FALSE
KeyLength = 204
RequestType = CMC
[RequestAttributes]
CertificateTemplate= 2008-WEBSERVER

[Extensions]
2.5.29.17 = “{text}”
_continue_ = “dns=webURL1.ldap389.info&”
_continue_ = “dns=webURL2.ldap389.fr&”
_continue_ = “dns=webURL3.ldap389.info&”

Pour lancer la génération du CSR sur le serveur IIS ($webserver) avec la commande certreq -new, ceci à partir de notre console nous utilisons le CmdLet Invoke-Command. A propos du PSRemoting et WinRM je vous conseille la lecture des séries d’articles de Ravikanth Chaganti.

Le fichier CSR ($iisreq) doit ensuite être soumis au CA ($CAPath):

$array = @($CAPath,$iisreq)
$Requestforsigning = invoke-command $webserver {param($argarray);certreq.exe -config $argarray[0] -submit $argarray[1]} -ArgumentList $array,$null
$reqt = $Requestforsigning[0].replace('RequestId: ','')

L’ID de la requête est alors récupéré dans la variable $reqt. Il devra ensuite être validé sur la console d’administration par un CA Manager (vous ), à l’aide de la commande certutil -resubmit $reqt.

Reste ensuite à récupérer le certificat sur le serveur IIS et à l’intégrer dans le magasin local de l’ordinateur, toujours avec le CmdLet Invoke-Command:

$array = @($reqt,$iiscrt,$CAPath)
invoke-command $webserver -scriptblock {
 param($argarray)
 certreq -config $argarray[2] -retrieve $argarray[0] $argarray[1]
 certreq -accept $argarray[1]
} -ArgumentList $array,$null

Notre certificat SAN est alors importé dans le magasin local de notre serveur IIS:

Ne reste plus qu’à configurer IIS, pour cela nous allons utiliser les WebAdministration CmdLets qui sont installées sur le serveur et suivre les instructions données dans ce post. Il nous faut donc tout d’abord récupérer le thumbprint du certificat à partir de notre console avec la commande certutil -view:

$thumbprint = ((((certutil -view -restrict "RequestID=$reqt" -out CertificateHash csv)[1]).replace(' ','')).replace('"','')).ToUpper()

Puis lancer les commandes suivantes sur notre serveur IIS:

import-module WebAdministration
New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https
cd IIS:\SslBindings
Get-Item cert:\LocalMachine\MY\$thumbprint | new-item 0.0.0.0!443

En utilisant toujours Invoke-Command (alias: icm). Voilà, votre IIS est configuré et vous pouvez appeler les URL désirées en HTTPS:

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

Ne vous reste plus qu’à changer les variables suivantes:

• $CAPath: Chemin de votre CA, sous la forme %FQDN_Serveur_CA%\%Nom_CA%
• $webURL1, $webURL2, $webURL3: Les URLs à mettre dans le SAN, attention adapter le script pour un nombre d’URLs différent.
• $CertTemplate: Nom du modèle de certificat utilisé.
• $webserver: Nom du serveur IIS 7.

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é:

Le template Kerberos Authentication peut être installé pour remplacer le modèle Domain Controller Authentication à partir d’un DC sous Windows 2003 SP2. Ci dessous un tableau comparatif entre l’ancien et le nouveau modèle:

Pour plus d’informations concernant l’utilisation de la clef KDC Authentication qui permet d’assurer que vos utilisateurs de cartes à puce s’authentifient auprès d’un contrôleur de domaine valide  vous pouvez lire ce document : Enabling Strict KDC Validation in Windows Kerberos.

Le fait d’avoir le nom du domaine dans le Subject Alternate Name du certificat et non seulement le nom du contrôleur de domaine permet à un DC de prouver qu’il appartient bien au domaine mentionné dans le Subject Alternate Name. Par ailleurs cette information doit être contenue dans le certificat afin d’activer la Strict KDC Validation.

Nous allons décrire comment distribuer les nouveaux certificats de type  Kerberos Authentication sur vos contrôleurs de domaine et révoquer les anciens certificats de type Domain Controller Authentication une fois que ceux ci ne servent plus. Nous distribuons les certificats aux DCs en utilisant l’autoenrollment qui est à configurer via GPO et en paramétrant correctement les modèles de certificats pour contrôleurs de domaine.

Pour indiquer au nouveau template de remplacer l’ancien il vous suffit de démarrer la console certtmpl.msc et d’éditer le template Kerberos Authentication afin d’indiquer qu’il écrase (“supersedes“) le modèle Domain Controller Authentication. Voir paragraphe “Superseding Certificate Templates” de ce lien.

Une fois que le template est bien configuré pour l’autoenrollment, le nouveau certificat va se déployer automatiquement, au besoin lancer la commande certutil -pulse sur les DCs pour accélérer le processus.

Le certificat du contrôleur de domaine est alors automatiquement remplacé dans le magasin local de certificats, lors de l’installation du nouveau certificat les événements de la source  AutoEnrollment vous indiquent que le certificat avec le modèle Kerberos Authentication est installé.

Avec ActiveRoles Management Shell for Active Directory v1.4 de Quest, vous pouvez en powershell gérer les certificats grâce au CmdLets de “Certificate and PKI management“. Nous allons tout d’abord vérifier le bon déploiement des nouveaux modèles de certificats sur nos DCs avec la commande suivante:

Get-QADComputer -computerRole 'DomainController' | Get-QADCertificate -Revoked:$false -template:'*kerberos authentication*' | format-table template,IssuedTo -autosize

Si tout vos DCs ont bien autoenrollé le nouveau certificat, et que vous avez validé leur bon fonctionnement, vous pouvez désactiver l’ancien modèle Domain Controller Authentication avec la console certsrv.msc afin qu’aucun nouveau certificat avec ce modèle ne soit délivré. Finalement il ne vous reste plus qu’à révoquer les anciens certificats  ayant pour modèle Domain Controller Authentication sur tous vos contrôleurs de domaine.

Pour cela nous allons combiner les CmdLets de Quest et la commande Certutil -revoke, il suffit donc de récupérer le numéro de série des certificats ayant pour template Domain Controller Authentication liés à nos objets AD contrôleurs de domaine et indiquer le code correspondant à la raison de la révocation: A savoir 4 pour Superseded.

Get-QADComputer -computerRole 'DomainController' | Get-QADCertificate -Revoked:$false -template:*domain controller authentication* | foreach {certutil -config %SRV_CA_FQDN%\%CA_Common_Name% -revoke $_.SerialNumber 4}

Les variables suivantes sont à adapter:

• %SRV_CA_FQDN%: FQDN du serveur délivrant les certificats.
• %CA_Common_Name%: Nom du CA.

En combinant l’outil Certutil et les nouvelles fonctionnalités de gestion de certificats apportées par les Quest AD CmdLets v1.4, nous pouvons automatiser une partie des tâches d’administration liées à votre PKI.

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é.