Tout d’abord nous allons ajouter le rôle ADCS via Server Manager:

Choisir ensuite “Role-based installation or Feature-based installation“, passer à l’écran suivant. Dans Server Manager nous allons ensuite sélectionner un serveur sur lequel installer le rôle, sur Windows 8 nous pouvons gérer des serveurs distants

Choisir le rôle Active Directory Certificate Services:

Passer l’écran Features, puis dans les role services nous ne choisissons que Certification Authority:

Valider l’écran d’après pour commencer l’installation du rôle. Maintenant nous ouvrons une session Powershell sur le serveur sur lequel le rôle a été installé et lançons la commande:

Get-Module –ListAvailable

On remarque l’apparition d’un nouveau module: CertificateServicesCmdlets.

Listons les Cmdlets de ce module avec:

(get-module CertificateServicesCmdlets).exportedcommands

Voilà la liste des cmdlets disponibles:

Get-AdcsCertificationAuthorityConfigurationDefaults
Get-AdcsConfigurationState
Get-AdcsEnrollmentPolicyWebServiceConfigurationDefaults
Get-AdcsEnrollmentWebServiceConfigurationDefaults
Get-AdcsNetworkDeviceEnrollmentConfigurationDefaults
Get-SSLCertificates
Import-AdcsCertificationAuthorityCACertificatePfx
Install-AdcsCertificationAuthority
Install-AdcsEnrollmentPolicyWebService
Install-AdcsEnrollmentWebService
Install-AdcsNetworkDeviceEnrollmentService
Install-AdcsOnlineResponder
Install-AdcsWebEnrollment
Uninstall-AdcsCertificationAuthority
Uninstall-AdcsEnrollmentPolicyWebService
Uninstall-AdcsEnrollmentWebService
Uninstall-AdcsNetworkDeviceEnrollmentService
Uninstall-AdcsOnlineResponder
Uninstall-AdcsWebEnrollment

Nous allons donc utiliser le cmdlet Install-AdcsCertificationAuthority pour configurer notre serveur rootCA. En s’inspirant de ce que le script setupCA.vbs faisait nous lançons la commande suivante:

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CACommonName LDAP389-CA -KeyLength 4096 -HashAlgorithmName SHA256 -CryptoProviderName "RSA#Microsoft Software Key Storage Provider"

Et voilà, notre RootCA est installé, nous lançons la console Certification Authority et on vérifie que notre installation est conforme aux paramètres configurés via PowerShell:

Sous Windows 8 on pourra donc configurer notre PKI avec Powershell, mais peut-être pas nous passer de l’excellent PS PKI module de Powershell Crypto Guy, l’avenir nous le dira

Attention: Comme il s’agit d’une Developer Preview ces cmdlets ainsi que la procédure d’installation ne sont peut être pas définitifs.

Une fois l’installation terminée j’ai lancé la commande Powershell suivante:

(get-module ActiveDirectory).exportedcommands

Ceci afin de lister tous les cmdlets du module Active Directory. On remarque alors l’apparition, entre autres, de nouveaux cmdlets permettant de gérer la replication ADDS:

Get-ADReplicationAttributeMetadata
Get-ADReplicationConnection
Get-ADReplicationFailure
Get-ADReplicationPartnerMetadata
Get-ADReplicationQueueOperation
Get-ADReplicationSite
Get-ADReplicationSiteLink
Get-ADReplicationSiteLinkBridge
Get-ADReplicationSubnet
Get-ADReplicationUpToDatenessVectorTable
New-ADReplicationSite
New-ADReplicationSiteLink
New-ADReplicationSiteLinkBridge
New-ADReplicationSubnet
Remove-ADReplicationSite
Remove-ADReplicationSiteLink
Remove-ADReplicationSiteLinkBridge
Remove-ADReplicationSubnet
Set-ADReplicationConnection
Set-ADReplicationSite
Set-ADReplicationSiteLink
Set-ADReplicationSiteLinkBridge
Set-ADReplicationSubnet

La topologie du domaine ldap389.local est la suivante:

Nous allons tout d’abord lister nos sites AD avec la commande:

Get-ADReplicationSite -filter {cn -like "*"}

Notre domaine est composée de deux sites HQ-LDAP389 et BRANCH-LDAP389, on récupère aussi via cette commande l’ISTG de chaque site.

Puis nous listons les liens entre sites AD avec la commande:

Get-ADReplicationSiteLink -filter {cn -like "*"}

Le seul lien de site est celui par défaut DEFAULTIPSITELINK, configuré pour lancer une réplication toutes les 15 minutes entre HQ-LDAP389 et BRANCH-LDAP389.

Finalement nous allons lister toutes les connexions de replication avec la commande:

Get-ADReplicationConnection -filter {cn -like "*"}

Nous avons deux connexions: Une pour répliquer de ldap389-pdce vers ldap389-dc2 et une autre pour répliquer dans le sens inverse.

Je vous rassure la commande repadmin existe toujours dans la Developer Preview, ce qui n’est pas le cas de dcpromo entièrement remplacé par Powershell.

Attention: Comme il s’agit d’une Developer Preview ces cmdlets ne sont peut être pas définitifs. Mais cela nous indique que nous pourrons gérer notre topologie Active Directory sous Windows 8 avec Powershell

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)

Inventaire BlackBerry:

Toutes les informations de configuration de votre solution BES sont stockées dans la base SQL BESMGMT, vous trouverez donc entre autres toutes les informations concernant les mobiles BlackBerry. Pour cela trois tables sont intéressantes:

• UserConfig: Contient entre autres l’adresse Email de l’utilisateur (MailboxSMTPAddr).
• SyncDeviceMgmtSummary: Modèle du blackberry et version d’OS (ModelName et AppsVer).
• UserStats: Date du dernier Email reçu (LastFwdTime).

En utilisant SQL Management Studio vous pouvez naviguer dans les tables pour retrouver les informations utiles:

Il ne vous reste plus qu’à utiliser PowerShell pour vous connecter à la base SQL et récupérer les informations qui vous sont utiles. La clef commune entre les trois tables est la valeur ID. Nous ne prenons en compte que les BlackBerry ayant reçu un Email au cours des 60 derniers jours.

$days = 60
$dbServer = "SQLBES-SRV"
$db = "BESMgmt"
 
#If you use SA account to connect database, change pwd=XXXXXX!, or use Windows Authentication, see below
$connString = "Server=$dbServer;Database=$db;uid=sa;pwd=XXXXXX"
 
#If you use Windows Authentication to connect BESMGMT SQL Database, need setup the database
#$connString = "Server=$dbServer;Database=$db;Integrated Security=True"
 
#SQL Query to retrieve BB devices Info (only devices who recieved mail in the last $days)
$Query = "Select UserConfig.DisplayName,MailboxSMTPAddr,ModelName,LastFwdTime,AppsVer from UserConfig,SyncDeviceMgmtSummary,UserStats where UserConfig.ID=SyncDeviceMgmtSummary.UserConfigID AND UserConfig.ID=UserStats.UserConfigID AND DeviceType <> 0 AND ModelName <> '' AND DateDiff(dd,LastFwdTime,GETDATE()) < "+$days
 
#Connect to Database, run Query, Disconnect
 
$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = $connString
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $Query
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$SqlConnection.Close()
$bbs = $DataSet.Tables[0]

Si vous voulez plus d’exemples de requêtes SQL sur BES vous pouvez lire ce post ou bien ce forum qui nécessite l’utilisation des Cmdlets SQL 2008. Le script ci dessus fait appel directement au Namespace System.Data.SqlClient et ne nécessite que PowerShell v2.

Il ne vous reste plus qu’à parcourir $bbs pour avoir les informations sur vos clients BlackBerry.

Inventaire ActiveSync:

En ce qui concerne l’inventaire de vos autres mobiles se connectant via ActiveSync c’est plus simple, car l’information est stockée dans Active Directory. En effet comme l’indique Florian’s blog ces données sont un sous objet de votre compte utilisateur: Pour vous en convaincre, ouvrez une console dsa.msc:

Grâce à l’Exchange Management Shell (2007 et 2010), le cmdlet Get-ActiveSyncDeviceStatistics permet de fournir très facilement des statistiques sur vos mobiles utilisant ActiveSync: Pour des exemples lire ce post de Ben Lye sur le sujet. Les valeurs suivantes sont particulièrement intéressantes:

• DeviceType: Le type de mobile (ex: Iphone, WP, Android…)
• DeviceModel: Le modèle de mobile (ex: HTC, LG, Samsung, Iphone…)
• DeviceUserAgent: Figure la build de l’OS (Iphone, WP, Android…)
• LastSuccessSync: Dernière synchronisation ActiveSync réussie, nous filtrons tout comme les BlackBerry, les mobiles ayant répondu au cours des 60 derniers jours.

Nous retrouvons donc à peu près les mêmes informations que celles obtenues sur les BlackBerry via notre requête SQL.

Fonctionnement général du script:

Nous commençons donc par faire un inventaire BlackBerry en requêtant la base SQL BESMGMT. Pour chaque adresse Email MailboxSMTPAddr nous vérifions si il possède aussi un mobile utilisant le protocole ActiveSync (et oui quand on est vraiment VIP on a un BlackBerry et un Ipad ), ceci via la commande:

$acts = Get-ActiveSyncDeviceStatistics -Mailbox $bb.MailboxSMTPAddr
 
if (($acts | Measure-object).count -eq 0) {User has just one BB no ActiveSync device}
 
else {User has one ActiveSync device in addition to BB}

Une fois l’inventaire BlackBerry terminé nous chargeons l’ensemble des boites aux lettres utilisateur Exchange via la commande:

$Mailboxes = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited

Puis nous comparons leur PrimarySmtpAddress (récupéré via le cmdlet Get-Mailbox) avec les MailboxSMTPAddr ($BESsmtpArray) afin d’exclure les utilisateurs déjà traités dans l’inventaire BlackBerry. Pour ces utilisateurs restants nous vérifions si ils possèdent un mobile utilisant ActiveSync.

Le résultat sort sous la forme d’un fichier CSV avec les informations suivantes:

• Adresse Email de l’utilisateur.
• Nombre de mobiles (ActiveSync + BlackBerry).
• Type de mobile: BlackBerry, IPhone, WP, Android…
• Modèle du mobile: Modèle de BlackBerry, Samsung, HTC, LG…
• Version d’OS.
• Dernière connexion: Dernier Email reçu sur BlackBerry, dernière synchronisation ActiveSync.

Voici un exemple de résultat obtenu:

Il vous faudra modifier les paramètres suivants dans le script et le lancer à partir de l’Exchange Management Shell:

• $days: Si vous souhaitez alonger ou réduire le seuil d’inactivité (60 jours par défaut).
• $dbServer: Nom de votre serveur SQL BES.
• La variable $connString: Selon le type d’authentification à la base SQL que vous utilisez.

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

PS: Le script n’a été testé que sous Exchange 2010 et BES 5.02, merci de vos retours sur les autres versions. A valider sous Exchange 2007, le cmdlet utilisé étant le même.

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.

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.

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.

Get-QADUser -NotMemberof 'ldap389\domain users' | export-csv domusers.csv

Après avoir retiré du fichier les comptes qui ne doivent pas être membre du groupe utilisateurs du domaine, comme le compte guest par exemple. Il nous reste à ajouter les comptes mal migrés dans le groupe utilisateurs du domaine et surtout définir ce groupe comme étant le groupe primaire du compte:

$csv = import-csv domusers.csv
 
foreach ($line in $csv) { Add-QADMemberOf $line.UserPrincipalName -Group 'ldap389\domain users' ; Set-QADUser $line.UserPrincipalName  -ObjectAttributes @{primaryGroupID=@(513)} }

Vous remarquez que 513 est l’ID pour définir le groupe primaire utilisateurs du domaine, pour une liste complète des groupes primaires connus et les IDs correspondants vous pouvez vous référer à cette KB.

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