GUIDE OFFICE 365 -> disponible en ligne et gratuitement !

Bonjour à tous

Mon guide Office 365 est disponible à cette adresse :
https://docs.metsys.fr/ebooks/METSYS%20-%20Livre%20Blanc%20-%20Office%20365.pdf

Bonne lecture.

A+
Guillaume MATHIEU
Directeur Technique Metsys
La connaissance s’accroît quand on la partage.
http://www.metsys.fr/blog
http://msreport.free.fr

Publié dans Windows Server 2008 | Laisser un commentaire

Supprimer des emails indésirables à l’aide de la commande Search-Mailbox avec Exchange

Bonjour à tous

Cet article a pour but de :
– Présenter une technique permettant de copier puis supprimer des emails indésirables (spam / virus) sur un serveur Exchange.
– Présenter la commande Exchange Search-Mailbox qui permet d’effectuer cette action.
– Présenter les prérequis pour la mise en place de la solution (permissions requises sur Exchange) et les contraintes légales.

Mon client disposait de l’architecture suivante :
– Une passerelle SMTP (antivirus / antispam) en DMZ.
– Un serveur Windows 2008 R2 avec Exchange 2010 Standard SP3 (machine et antivirus à jour). Ce serveur ne disposait pas d’une solution antivirus / antispam dédiée à l’analyse du contenu des bases de données Exchange. L’antivirus (analyse des fichiers) installé sur le serveur était configuré pour exclure les bases de données Exchange conformément aux articles Microsoft :
https://technet.microsoft.com/en-us/library/bb332342(v=exchg.141).aspx
https://blogs.technet.microsoft.com/rmilne/2014/02/04/exchange-and-antivirus-exclusions-a-critical-conversation/
– Des clients Windows 7 avec Outlook 2010 (machines et antivirus à jour).

La problématique :
Une grande partie des utilisateurs de mon client avaient reçu plusieurs centaines d’emails indésirables qui n’avaient pas été détectés en tant que tel par la passerelle SMTP.

Plan d’action mise en œuvre :
Les règles de filtrage de la passerelle SMTP ont rapidement été mis à jour pour filtrer ces emails indésirables. Il restait cependant la problématique des emails déjà reçus sur les boîtes aux lettres Exchange. Pour supprimer ces emails, nous avons alors utilisé la commande Search-Mailbox avec le paramètre DeleteContent. Cette commande permet en effet :
– D’effectuer des recherches à l’aide de mots clés au niveau des éléments d’une ou plusieurs boîtes aux lettres.
– De copier ces éléments vers une autre boîte aux lettres.
– De supprimer automatiquement des éléments dans une boîte aux lettres sans possibilité de restauration.

Commande pour déterminer le nombre d’éléments dans la boîte aux lettres GMATHIEU avec un titre contenant la chaîne de caractère « Bonjour Monsieur » :
Search-Mailbox -Identity gmathieu -SearchQuery ‘Subject:”Bonjour Monsieur”‘ -EstimateResultOnly

Commande pour copier les emails de la boite aux lettres gmathieu avec « Virus Terrible » dans le corps de l’email vers un dossier Quarentine-Virus (déjà existant ou non) de la boîte aux lettres QuarantaineMessagerie :
Search-Mailbox -Identity gmathieu -SearchQuery ‘Body:”Virus terrible”‘ -TargetMailbox service-ars -TargetFolder Quarentine-Virus

Commande permettant de supprimer tous les emails avec la chaîne de caractère « Virus Terrible » :
Search-Mailbox -Identity gmathieu -SearchQuery ‘Body:”Virus terrible”‘ -DeleteContent

Astuce :
Si la chaîne de caractères contient une apostrophe ou des guillemets, passez par une variable intermédiaire :
$KeyWords = “J’essaie de vous joindre”
Get-Mailbox -ResultSize Unlimited | Search-Mailbox -SearchQuery “Subject: $KeyWords” -EstimateResultOnly
Get-Mailbox -ResultSize Unlimited | Search-Mailbox -SearchQuery “Subject: $keywords” -TargetMailbox service-ars -TargetFolder Quarentine-Virus
Get-Mailbox -ResultSize Unlimited | Search-Mailbox -SearchQuery “Subject:$Keywords” -DeleteContent.

Pour plus d’informations sur la commande Search-Mailbox :
https://technet.microsoft.com/en-us/library/dd298173(v=exchg.160).aspx
https://technet.microsoft.com/en-us/library/ee633452.aspx
https://technet.microsoft.com/en-us/library/dd638205(v=exchg.160).aspx

Quels sont les prérequis pour utiliser la commande Search-mailbox :
Pour utiliser la commande Search Mailbox avec Exchange 2010, il faut avoir le rôle Mailbox Search.
Pour utiliser cette commande avec le commutateur -DeleteContent, il faut aussi avoir le rôle Mailbox Import Export.
Sous Exchange 2010, le rôle Mailbox Search est assigné au groupe Discovery Management par défaut. Ce groupe se trouve dans l’OU Microsoft Exchange Security et est vide par défaut.
Le rôle Mailbox Import Export n’est pas assigné à un groupe.

Pour pouvoir utiliser la commande Search-Mailbox avec le commutateur DeleteContent, il faut donc :
– Créer le groupe Import_Export_Mailbox en tant que groupe Universel dans l’OU Microsoft Exchange Security.
– Assigner le rôle Mailbox Import Export à ce groupe avec la commande :
New-ManagementRoleAssignment -Name “Import Export_Enterprise Support” -SecurityGroup “Import_Export_Mailbox” -Role “Mailbox Import Export”
– Ajouter le compte de l’administrateur en charge de l’opération dans les groupes Discovery Management et Import_Export_Mailbox. Fermer puis rouvrir la session pour prise en charge des nouveaux groupes.

Notes :
Il est possible de lister les permissions Exchange assignées aux groupes à l’aide de la commande ci-dessous :
Get-ManagementRoleAssignment | Export-Csv -Path c:\role.csv
Le commutateur DeleContent n’est pas disponible si l’on ne dispose pas du droit Mailbox Import Export.
https://social.technet.microsoft.com/Forums/exchange/en-US/81a39682-6f9d-4625-9546-78970982a220/searchmailbox-deletecontent?forum=exchange2010
Il est recommandé d’inclure dans la charte informatique une clause qui explique aux utilisateurs que le contenu de leur boite aux lettres pour être analysé par la direction informatique.

A+

Guillaume MATHIEU
Directeur Technique de Metsys
http://www.metsys.fr

Publié dans antivirus, Exchange, Messagerie, Outils, PowerShell, Sécurité, Scripts | Laisser un commentaire

Vue d’ensemble d’Active Roles 7 et présentation du module Office 365 de Metsys

Bonjour à tous

Cet article a pour but de vous présenter les nouveautés d’Active Roles 7 ainsi que les principales fonctionnalités du module Office 365 développé par Metsys.

1. Active Roles 7 :
Active Roles peut être téléchargé (version d’évaluation sans limitation de fonctionnalités) depuis le site de Dell Software à l’adresse suivante :
http://software.dell.com/products/active-roles
On notera que le produit ne s’appelle plus ActiveRoles Server mais Active Roles.

2. Un déploiement simplifié avec la console Active Roles Configuration Center
Le nouveau mode de déploiement est top. On installe tout d’abord la console Active Roles Configuration Center et les modules PowerShell associés. La configuration du service d’administration et de l’interface web se font ensuite depuis cette nouvelle interface ou en PowerShell.

image012

image014

image016

Depuis la console Active Roles Configuration Center, il est maintenant possible de configurer le mappage entre les répertoires virtuels IIS et les différentes configurations d’interface web Active Roles (outil d’administration séparé dans les versions précédentes).

image018

Il est aussi possible d’activer tous les différents fichiers de logs pour le dépannage avancé de la solution.

image028

3. Une nouvelle interface web plus moderne !
La nouvelle interface est au standard Dell.
Le menu centrale (avec toutes les commandes comme Rename user, Edit user…) disparaît au profit d’un menu à droite de l’écran.
Ce menu de droite peut être masqué (très pratique sur les petits écrans).
On notera qu’il est maintenant nécessaire de sélectionner les objets (comptes utilisateurs, groupes, comptes ordinateurs) pour effectuer les changements.
Le menu de droite affiche uniquement par défaut les commandes pour l’OU / conteneur parent.
Les fonctionnalités de personnalisation de l’interface web évoluent peu cependant (toujours basées sur des fichiers XML stockés au niveau de l’objet CN=Web Interface,CN=Application Configuration,CN=Configuration.
On peut créer des nouvelles commandes, masquer certains éléments dans le menu de gauche comme l’affichage du conteneur Managed Unit ou AD LDS.

image029

image030

image032

image033

On peut limiter le nombre d’objets à pré-calculer. Cela permet de bien meilleure performance dans l’affichage des OU contenant un très grand nombre d’objets.

image037

4. Les Workflows, policies et les scripts modules
Les workflows s’appuient sur des activités (Modify user, Move User, Create object, Add to group, exécution de scripts).
Active Roles permet maintenant de disposer de 2 nouvelles activités Save Objects Properties et Modify Requested Change.
Ces deux activités permettent de comparer la valeur d’un objet avant et après le changement effectué par une activité du workflow (change user). Cela permet d’éviter l’utilisation de scripts modules Active Roles basés sur les objets $Request, $DirObj et $Workflow (SDK d’Active Roles 7). Metsys peut vous accompagner dans l’écriture de script modules pour Active Roles.
On notera qu’il est maintenant possible de lancer un script PowerShell avant le démarrage du workflow.

image038

image039

Active Roles 7 n’intègre pas de changement au niveau du moteur de scripts, Policies. Les anciens scripts / Policies Active Roles fonctionnent donc toujours avec la version 7.

5. Refonte complète du module Exchange / Lync
L’intégration de Lync est maintenant simplifiée avec Active Roles .
On notera cependant qu’Active Roles 7 ne supporte toujours pas Exchange 2016 et Skype for Business 2015 comme expliqué dans cette article :
https://support.software.dell.com/active-roles/kb/181755
Metsys peut cependant sur demande développer des commandes web personnalisées (basées sur des scripts modules) pour prendre en charge Exchange 2016 et/ou Skype For Business.

6. Intégration de Quick Connect dans Active Roles
Quick Connect
(produit séparé) est maintenant intégré à Active Roles 7, se nomme maintenant Active Roles Synchronization Services et devient gratuit.
Dell a  cependant arrêté le développement de tous les connecteurs non Microsoft (Oracle…). Ces derniers ne sont donc pas inclus / compatibles avec Active Roles 7.
On notera qu’il y a toujours une console séparée pour Active Roles Synchronization Services. Le module PowerShell pour Active Roles Synchronization Services est aussi installé de base maintenant.

image047

7. Le module Office 365 de Metsys
Dell fournit un module Office 365 pour Active Roles mais ce dernier permet en pratique que d’assigner des licences Office 365. Il est disponible à l’adresse suivante : https://support.software.dell.com/active-roles/kb/196052
Il s’appuie sur Synchronization Services et son connecteur Office 365 pour exécuter des commandes PowerShell Azure Active Directory.

Le module Office 365 de Metsys part d’un principe totalement différent.
La solution Active Roles est une sorte d’interface web personnalisable qui s’appuie sur un interpréteur de commande PowerShell.
Il est donc tout à fait possible de créer des fomulaires web personnalisés qui exécutent des commandes PowerShell Exchange Online, Skype For Business Online, Azure Active Directory.
Le module Office 365 de Metsys est présenté en détail à l’adresse suivante :
https://experiences.microsoft.fr/channel/metsys-organise-ladministration-des-comptes-office-365-de-technip/7744f48d-7044-4470-b9fc-90935db4d0c7#rgVYJhm1ik676CuB.97

Bonne journée et bon test.

Guillaume MATHIEU
Directeur Technique Metsys
http://www.metsys.fr

Publié dans Active Directory, ActiveRoles for Server, Annuaire, Messagerie, Outils, Sécurité, Système | Laisser un commentaire

Migrer vos ressources Exchange vers une nouvelle organisation sans impacter vos utilisateurs

Bonjour à tous

Lorsque qu’un client souhaite migrer ses comptes utilisateurs, ses groupes et ses machines vers une nouvelle forêt Active Directory, une question revient systématiquement. Disposez-vous d’une messagerie Microsoft Exchange ? Nous allons voir dans cet article que cette question à priori hors sujet est très structurante pour ce type de projet.
Exchange stocke en effet sa configuration dans la partition de configuration d’Active Directory (exemple : CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=metsys,DC=intra). Pour cette raison, il ne peut y avoir qu’une seule organisation Exchange par forêt et une organisation Exchange ne peut pas s’étendre sur 2 forêts Active Directory différentes.

Dans notre cas, le client disposait d’Exchange et il souhaitait migrer toutes ses ressources (comptes utilisateurs, groupes, comptes ordinateurs, boîtes aux lettres Exchange et dossiers publics) vers une nouveau domaine / forêt Active Directory. Le client souhaitait aussi que la migration se fasse progressivement et sans perte de fonctionnalités pendant la phase de migration. Un utilisateur migré devait par exemple pouvoir accéder au(x) calendrier(s) d’un utilisateur non migré et à ses données sur un serveur de fichiers non migré.
Le client souhaitait aussi utiliser uniquement des outils de migration fournis par Microsoft (outils gratuits) pour des raisons budgétaires principalement.

Comment migrer les comptes utilisateurs, groupes et les machines dans la nouvelle forêt sans impacter les utilisateurs ?
Microsoft fournit gratuitement un outil appelé Microsoft ADMT (actuellement en version 3.2) qui permet de migrer de manière relativement transparente les comptes utilisateurs, les groupes et les comptes ordinateurs d’un domaine / forêt Active Directory source vers un domaine / forêt Active Directory cible.
Cet outil dispose d’une fonctionnalité appelée SIDHistory qui permet à un utilisateur migré de continuer à accéder à ses données même si elles sont hébergées sur un serveur non migré.

Comment migrer les boîtes aux lettres et les dossiers publics vers la nouvelle forêt Exchange sans impacter les utilisateurs ?
La réponse est simple. Cela ne se fera pas sans impact. Il est en effet nécessaire dans ce cas de créer une nouvelle organisation Exchange dans le domaine / forêt cible et d’effectuer une migration inter-organisation Exchange.
Hors une migration inter-organisation Exchange est tout sauf sans impact.

Ce qui marche avec les outils natifs de migration inter-organisation Exchange :
Microsoft fournit deux scripts PowerShell pour déplacer une boîte aux lettres entre 2 organisations Exchange différentes. Je vous invite à lire l’article http://msexchangeguru.com/2013/11/03/e2013crossforestmigration.
Microsoft fournissait avec Exchange 2003  un outil pour migrer les dossiers publics entre 2 organisations Exchange différentes. Cet outil bien que non supporté sous Exchange 2007 / 2010 semble fonctionner (non testé). On notera que l’on est obligé de déployer un serveur Windows 2003 comme expliqué dans l’article :
https://blog.gothamtg.com/2012/10/19/interorg-public-folder-replication-exchange-2007-to-exchange-2010/
Une autre technique consiste à recréer une topologie de dossiers publics vierge à l’aide de commandes PowerShell puis de migrer le contenu des dossiers publics à l’aide d’un client Outlook ! Il faut pour cela configurer le client Outlook avec un compte dans l’organisation Exchange source et un compte dans l’organisation Exchange cible. Les amoureux des scripts PowerShell basés sur les objets COM Outlook pourront toujours automatiser cette tâche mais c’est bien compliqué tout de même !

Ce qui marche partiellement ou pas du tout lors d’une migration inter-organisations Exchange :
Microsoft permet depuis Exchange 2010 de fédérer 2 organisations Exchange différentes. Cette fonctionnalité permet de partager les informations de disponibilité entre les 2 organisations Exchange et de partager le calendrier entre utilisateurs de 2 organisations Exchange différentes.
On notera cependant qu’un utilisateur de l’organisation Exchange A ne peut pas ouvrir la boîte aux lettres d’un utilisateur d’une organisation Exchange B.
Il n’est pas non plus possible de synchroniser le contenu des dossiers publics entre serveurs de 2 organisations Exchange différentes.
Le point le plus critique reste cependant le besoin de reconfigurer les clients Outlook et les terminaux mobiles après la migration de la boîte aux lettres sur le nouveau serveur.
On comprend donc à la lecture de ces quelques lignes qu’une migration inter-organisation est tout sauf sans impact. Nous allons maintenant voir quelques astuces pour contourner ces différentes problématiques.

Comment limiter les impacts d’une migration inter-organisations Exchange :
Il faut pour cela réduire au maximum la durée de la migration des boîtes aux lettres / dossiers publics entre les 2 organisations.
Il est cependant difficile d’envisager une migration Active Directory sur quelques jours / semaines surtout quand on dispose de plusieurs milliers de stations de travail / serveurs à migrer. L’outil ADMT permet en plus de faire coexister très correctement les utilisateurs migrés / non migrés.
Pour cette raison, la bonne approche est de séparer complètement la migration Exchange et la migration Active Directory et de les traiter comme 2 tâches indépendantes. Pour cela, il faut découper le projet en 4 phases.

Phase 1 : configuration du serveur ADMT 3.2 et mise en œuvre de la fédération entre les 2 organisations Exchange
La première étape est de créer une relation d’approbation entre les 2 forêts, déployer l’outil Microsoft ADMT et d’activer la prise en charge du SID History.
La seconde étape sera de créer la relation (fédération) entre les 2 organisations Exchange comme expliqué dans l’article Microsoft :
https://technet.microsoft.com/fr-fr/library/dd351260(v=exchg.141).aspx
La troisième étape sera d’exporter les permissions sur les boîtes aux lettres Exchange et sur les dossiers publics.

Phase 2 : migration des dossiers publics de l’organisation Exchange source vers l’organisation Exchange cible
Il n’est pas possible de synchroniser les dossiers publics entre deux organisations Exchange 2007 et versions ultérieures. En conséquence il est nécessaire de :
– Sauvegarder le contenu de la base de dossiers publics de l’organisation Exchange source au format PST à l’aide du client Outlook.
– Exporter la topologie de dossiers publics (script Metsys) de l’organisation Exchange source et la recréer dans l’organisation Exchange cible (script Metsys).
– Migrer le contenu des dossiers publics à l’aide d’un client Outlook (script Metsys).
– Convertir tous les accès en lecture / écriture au niveau des dossiers publics de l’organisation Exchange source en accès en lecture seule (script Metsys).
Le but est de migrer les dossiers publics sur les serveurs de l’organisation Exchange cible et d’empêcher les modifications par des utilisateurs de l’organisation Exchange source.

Remarque :
A titre personnel, je préconise de ne pas migrer les dossiers publics vers des boîtes aux lettres de site car cette solution nécessite l’achat de licences SharePoint Server Standard ou Entreprise. De plus, elle est complexe à paramétrer et limitée en terme de fonctionnalités. Un pas à pas complet est disponible à cette adresse :
https://spasipe.wordpress.com/2013/03/19/sharepoint-2013-les-site-mailboxes-44-limitations-et-utilisation-de-logiciels-tiers

Phase 3 : migration des boîtes aux lettres et reconfiguration des clients Outlook / terminaux mobiles puis suppression de l’organisation Exchange source
La première étape sera d’utiliser le script Microsoft pour créer le compte utilisateur avec adresse de messagerie externe. Pour cela, il faut appliquer la procédure expliquée dans cet article :
http://msexchangeguru.com/2013/11/03/e2013crossforestmigration/
La seconde étape est de lancer une migration de tous les comptes utilisateurs et de tous les groupes du domaine / forêt Active Directory source vers le domaine / forêt Active Directory cible. Il faudra configurer l’outil Microsoft ADMT pour faire une fusion avec le compte créé par le script de migration Exchange (étape précédente).
La troisième étape sera de migrer toutes les boîtes aux lettres de l’organisation Exchange source en tant que boîte aux lettres liée dans l’organisation Exchange cible. Les utilisateurs accéderont à leur nouvelle boîte aux lettres en s’authentifiant avec leur compte utilisateur du domaine / forêt source. L’article Microsoft ci-dessous présente la fonctionnalité de boîte aux lettres liées :
https://technet.microsoft.com/fr-fr/library/jj673532(v=exchg.150).aspx
La quatrième étape sera d’importer les permissions sur les boîtes aux lettres et les dossiers publics (script Metsys).
La cinquième étape sera de reconfigurer les clients Outlook à l’aide d’un script PRF pour qu’il modifie le profil Outlook afin d’utiliser le nouveau serveur de messagerie. La procédure est expliquée dans l’article : http://www.howto-outlook.com/howto/deployprf.htm.
La sixième étape sera de reconfigurer les entrées DNS / SRV pour l’Autodiscover Exchange dans le domaine / forêt source afin de pointer vers les serveurs de l’organisation Exchange cible. Cette action ne pourra être effectuée que lorsque toutes les boîtes aux lettres seront migrées vers l’organisation Exchange cible.
La septième étape sera de supprimer le ou les serveurs de l’organisation Exchange source.

Phase 4 : migration des ressources Active Directory (comptes utilisateurs, groupes et comptes ordinateurs), migration des machines membres puis suppression de l’ancien domaine et du SID History :
Cette phase peut être effectuée progressivement. Il est recommandé de faire des lots de 20 utilisateurs / stations de travail par jour par technicien. Elle consiste à effectuer les actions suivantes pour chaque utilisateur / station de travail :
– Migrer une seconde fois le compte utilisateur dans le domaine / forêt cible (pour la mise à jour du mot de passe, utilisation du mode fusion de l’outil Microsoft ADMT).
– Activer le compte utilisateur et convertir la boîte aux lettres liée en boîte standard. L’utilisateur accédera à sa boîte aux lettres avec son compte dans le domaine / forêt cible.
– Migrer la station de travail de l’utilisateur dans le domaine / forêt cible avec l’outil Microsoft ADMT.
– Réappliquer les permissions au niveau des boîtes aux lettres et des dossiers publics (script Metsys).

Remarques :
Afin de tenir la cadence de 20 stations de travail par jour et par technicien, il est important d’effectuer les actions suivantes :
– Dans la mesure du possible, les stations de travail portables doivent être migrées dans un banc d’intégration.
– Les mots de passe de démarrage doivent être désactivés temporairement.
– Une GPO doit être configurée pour désactiver l’antivirus temps réel, la veille écran et permettre un accès aux partages administratifs (ADMIN$, C$) depuis le serveur Microsoft ADMT.
– ADMT 3.2 ne prend pas en charge les OS antérieurs à Windows 2003 (https://technet.microsoft.com/fr-fr/library/active-directory-migration-tool-versions-and-supported-environments(v=ws.10).aspx). Il sera nécessaire de prévoir une procédure spéciale pour ce type de machine.
Une fois l’ensemble des stations de travail et des serveurs membres migrés vers le nouveau domaine / forêt, il est nécessaire de supprimer le SID History et l’ancien domaine / forêt Active Directory.

C’est seulement à ce moment que l’on peut affirmer que la migration est terminée et qu’elle est un succès.

Bonne journée.

A+
Guillaume MATHIEU
Directeur Technique de Metsys
www.metsys.fr

 

Publié dans Active Directory, ADMT, Annuaire, Exchange, Messagerie, Relation d'approbation, Système | Laisser un commentaire

Active Directory Certificates Services – quelle architecture dois-je déployer ?

Bonjour à tous,

Lorsque je déploie une nouvelle autorité de certification, 3 questions reviennent systématiquement :
– Dois-je déployer une autorité de certification 1 tiers, 2 tiers ou 3 tiers ?
– Quel algorithme de chiffrement et quelle taille de clé privée / publique dois-je utiliser ?
– Quel algorithme de Hash dois-je utiliser ?

1. Architecture d’autorité de certification : 1 tiers, 2 tiers ou 3 tiers
Si un attaquant arrive à obtenir la clé privée du certificat de votre autorité de certification, il peut alors restaurer/réinstaller cette dernière et générer tous les certificats qu’ils souhaitent en usurpant l’identité de votre entreprise. Votre autorité de certification est alors compromise et doit être complètement réinstallée avec l’utilisation d’une nouvelle paire de clés privées / publiques. Tous les certificats que vous avez émis avec votre ancienne autorité de certification doivent être révoqués et remplacés par des certificats de la nouvelle autorité de certification.

Les entreprises qui émettent des milliers voir des millions de certificats utilisent en général plusieurs autorités de certification. Ce mode de fonctionnement permet de limiter l’impact en cas de compromission d’une des autorités de certification. De plus dans le cas d’une autorité de certification Microsoft, certains paramètres comme la configuration de CRL (durée de vie, emplacement), l’archivage des clés privées, l’audit ou la mise en œuvre de la séparation des rôles ne peuvent être configurés qu’au niveau de l’autorité de certification et non au niveau du modèle de certificats.
Les autorités de certification comme Microsoft Active Directory Certificates Services permettent de créer des arborescences d’autorités de certification.

On parle d’autorité de certification 1 Tier, soit à un niveau, quand l’autorité de certification racine est aussi l’autorité de certification qui émet les certificats pour les utilisateurs finaux. Dans le cas d’une autorité de certification Microsoft, elle doit être de type Entreprise pour permettre de bénéficier de toutes les fonctionnalités comme les modèles de certificats ou l’archivage des clés privées. Cette architecture est la plus simple à mettre en œuvre et à maintenir (un seul serveur).
Ce type d’architecture convient parfaitement si vous devez émettre moins de 10000 certificats et si votre autorité de certification n’est pas reconnue comme autorité racine de confiance par les autres entreprises.

On parle d’autorité de certification 2 tiers, soit à 2 niveaux quand on dispose :
– D’une autorité de certification racine qui sert uniquement à générer le certificat des autres autorités de certification. Comme la clé privée de cette autorité de certification est très critique, son niveau de sécurité doit être maximum. Microsoft recommande que l’autorité de certification racine soit déployée dans un groupe de travail (machine non membre du domaine), dans un réseau et un centre de données sécurisé et qu’elle soit arrêtée. Microsoft recommande uniquement une maintenance périodique pour renouveler la CRL de l’autorité de certification racine.
– Une ou plusieurs autorités de certifications émettrices. Cette architecture permet de disposer d’une configuration spécifique pour chaque autorité de certification et de dédier chaque autorité de certification pour une fonction spécifique ou à un client spécifique.
Ce type d’autorité de certification convient parfaitement aux entreprises qui souhaitent émettre plusieurs milliers de certificats ou/et qui sont soumises à des règles de sécurité renforcée (secteurs comme les banques, assurances).

On parle d’autorité de certification 3 tiers, soit 3 niveaux, quand on ajoute un niveau supplémentaire de protection entre l’autorité de certification racine et l’autorité de certification émettrice de certificats pour les utilisateurs finaux. Cette autorité de certification est appelée autorité de certification subordonnée.
Ce type d’architecture est recommandée si votre autorité de certification est reconnue comme une autorité racine de confiance par défaut sur tous les systèmes d’exploitation (cas d’une autorité de certification publique) ou que vous émettez plusieurs milliers / millions de certificats.

Avec une architecture 2 ou 3 tiers, si une autorité émettrice est compromise, l’administrateur peut révoquer le certificat de l’autorité de certification émettrice depuis l’autorité de certification subordonnée (3 tiers) ou racine (2 tiers). Cette simple action suffira pour invalider tous les certificats générés par l’autorité de certification compromise. En effet, pour qu’un certificat soit valide, il faut que :
– Le certificat ne soit pas révoqué ou expiré.
– Le certificat de toutes les autorités de certification du chemin d’approbation ne soit pas révoqué ou expiré. Pour rappel, le chemin d’approbation d’un certificat contient la signature de l’autorité de certification qui a émis le certificat et le certificat de l’autorité de certification qui a elle même signé le certificat de l’autorité de certification émettrice (et ainsi de suite).
On notera qu’il n’est pas possible de révoquer le certificat d’une autorité de certification racine. Sous Windows, le système est préconfiguré avec une liste d’autorité de certification racine de confiance. Il est possible d’ajouter ou supprimer des autorités de certification dans cette liste. Pour visualiser sous Windows 10, le magasin Autorité de certification racine de confiance, taper la commande CERTLM.MSC puis aller dans le nœud Trusted Root Certification Authorities | Certificates.

2. Choix de l’algorithme de chiffrement et de la taille de clés
Une autorité de certification sous Windows 2012 R2 supporte plusieurs types d’algorithme de chiffrement :
– Microsoft Enhanced Cryptographic Provider v1.0 : ancien algorithme de chiffrement non sécurisé.
– Microsoft Base Cryptographic Provider v1.0 : ancien algorithme de chiffrement non sécurisé.
– Microsoft Strong Cryptographic provider : ancien algorithme de chiffrement non sécurisé
– RSA#Microsoft Software Key Storage Provider : algorithme de chiffrement asymétrique basé sur RSA. Cet algorithme est sécurisé avec une taille de clé importante (2048 ou 4096).
– ECDSA_P256, ECDSA_P384 et ECDSA_P521 : il s’agit d’un algorithme de chiffrement asymétrique qui permet un niveau de sécurité équivalent à RSA mais avec une clé plus petite. Une clé ECDSA 256 bits permet un niveau de sécurité identique/ supérieure à une clé RSA 2048 bits comme expliqué dans l’article https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/.
Cependant cet algorithme n’est pas pris en charge par tous les périphériques.

Microsoft ne supporte plus l’utilisation de clé de chiffrement RSA dont la taille est inférieure à 1024 bits comme expliqué dans l’article :
https://support.microsoft.com/en-us/kb/2661254
Des chercheurs de l’Université de Michigan ont récemment remis en cause la sécurité de l’algorithme de chiffrement asymétrique RSA avec une taille de clés de 1024 bits :
http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits
Les clés RSA de 2048 bits seront supportées jusqu’en 2030 comme indiqué dans les articles suivants :
https://www.yubico.com/2015/02/big-debate-2048-4096-yubicos-stand
Certains équipements ont des problèmes pour prendre en charge des tailles de clés supérieurs à 2048 bits comme certains téléphones VOIP Polycom ou certains équipements réseaux Cisco. Pour plus d’informations :
https://www.yubico.com/2015/02/key-size-matter-cryptography/

Je vous préconise donc d’utiliser l’algorithme de chiffrement RSA#Microsoft Software Key Storage Provider avec une taille de clé de 2048 bits au niveau des autorités de certification racine et émettrice.

3. Choix de l’algorithme de Hash
L’algorithme de Hash SHA 1 est déprécié et ne doit plus être utilisé.
SHA 256 est correctement pris en charge par tous les navigateurs récents :
https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility
Les algorithmes de Hash SHA 2 (SHA 256, SHA 384 et SHA 512) nécessitent l’installation d’un correctif sur les machines Windows XP Pro et Windows 2003 Server. Pour un fonctionnement optimal sur ces 2 systèmes, il est recommandé de déployer le correctif http://support2.microsoft.com/kb/2868626 qui apporte la bonne version de la DLL Crypt32.dll (5.131.3790.5235). Ce correctif peut être téléchargé à cette adresse :
https://technet.microsoft.com/en-us/library/security/ms13-095.aspx
Il remplace les correctifs KB 968730 et KB 938397 sur les machines Windows XP / 2003 :
https://support.microsoft.com/fr-fr/kb/968730
https://support.microsoft.com/en-us/kb/938397
Le correctif 2763674 (https://support.microsoft.com/en-us/kb/2763674) doit être déployé sur les machines Windows 2008 R1 et Vista pour la prise en charge des algorithmes SHA 2. On notera que :
– Il n’est pas possible de faire du S/MIME sur une machine Windows XP avec des certificats utilisant un des algorithmes de Hash SHA2 même après l’installation du correctif ci-dessous.
– SHA-224 n’est pas supporté par Microsoft et ne doit pas être utilisé.
– SHA 512 n’est pas activé par défaut et nécessite l’installation d’un correctif spécifique sur Windows 7 / Windows 2008 R2 :
https://support.microsoft.com/en-us/kb/2973337
Pour cette raison, je vous préconise de sélectionner SHA 256 comme algorithme de Hash pour le certificat de l’autorité de certification.

Pour aller plus loin
Je vous invite à lire ces articles :
http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx
http://social.technet.microsoft.com/wiki/contents/articles/31296.implementing-sha-2-in-active-directory-certificate-services.aspx
http://ammarhasayen.com/2015/02/02/pki-certificate-services-sha-1-deprecation/
http://blogs.technet.com/b/pki/archive/2011/02/08/common-questions-about-sha2-and-windows.aspx

Bonne journée.

Cordialement

Guillaume MATHIEU
Directeur Technique de Metsys

Publié dans Certificats, Sécurité, Système, Windows 2012 R2 | Laisser un commentaire