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

Complément d’informations sur l’erreur “Failed to open the runspace pool. The Server Manager WinRM plug-in might be corrupted or missing”

Bonjour à tous

Lors du déploiement d’un serveur Windows 2012 Server R2, j’ai été confronté à un problème assez original. Il était impossible de gérer (ajout / suppression) les rôles ou les fonctionnalités Windows depuis la console Server Manager. En effet, une fois les rôles et/ou fonctionnalités à installer / supprimer sélectionnés, le Gestionnaire de Server affichait l’erreur suivante :
Failed to open the runspace pool. The Server Manager WinRM plug-in might be corrupted or missing”.
L’installation / suppression d’une fonctionnalité ou d’un rôle Windows fonctionnait parfaitement en PowerShell  (commandes comme Add-WindowsFeature du module PowerShell du Server Manager.

Le problème provenait en fait d’une stratégie de groupe qui définissait le paramètre « Allow Remote Shell Access » à la valeur « Désactivé » chez le client.
Pour plus d’informations sur Windows Remote Shell, je vous invite à lire les articles suivants :
https://blogs.technet.microsoft.com/arnaud_jumelet/2010/10/24/administration-laide-de-windows-remote-shell-winrs/
https://support.microsoft.com/en-us/kb/555966

Hypothèse à vérifier : il semblerait que le Server Manager considère la machine locale comme une machine distante comme les autres ! En effet, depuis Windows 2012 R1, le Server Manager permet de gérer les rôles et les fonctionnalités de plusieurs serveurs en même temps (le serveur local et des serveurs distants). Cette fonctionnalité s’appuie sur WinRM lorsque les serveurs du pool sont sous Windows 2012 / 2012 R2. Je vous invite à lire les articles ci-dessous pour plus d’informations :
https://technet.microsoft.com/fr-fr/library/hh921475(v=ws.11).aspx
https://support.microsoft.com/en-us/kb/555966

A+
Guillaume MATHIEU
Directeur Technique de Metsys

Publié dans Bug, Système, Windows 2012, Windows 2012 R2 | Laisser un commentaire

Livre sur la sécurité Active Directory -> la version numérique vous est offert !

Salut à tous.

Mon livre sur la sécurité d’Active Directory est en ligne et disponible gratuitement.
Vous pouvez le télécharger à cette adresse.
http://www.metsys.fr/livre/livre.html

Bonne lecture !

Plan du livre:
Introduction
1. Concevoir un annuaire sécurisé et qui répond aux besoins de l’entreprise
1.1 Les notions fondamentales
1.2 Analyser le besoin de votre entreprise
1.3 Choisir une topologie Active Directory
1.3.1 Exception 1 : une société avec des entités indépendantes
1.3.2 Exception 2 : des applications qui modifient le schéma Active Directory
1.3.3 Exception 3 : les hébergeurs
1.3.4 Exception 4 : les contraintes légales
1.3.5 Exception 5 : travailler avec les concurrents
1.3.6 exceptions 6 : applications hébergées dans le cloud
1.4 Utiliser Active Directory comme annuaire d’entreprise
1.4.1 Synchroniser l’annuaire avec d’autres sources de données (bases RH…)
1.4.2 Synchroniser Azure Active Directory avec Active Directory
1.4.3 Héberger les données de l’entreprise dans l’annuaire Active Directory
1.4.4 Comment et qui doit administrer ces attributs ?
1.4.5 Protéger les attributs qui contiennent des données sensibles
1.4.6 Permettre à un utilisateur de visualiser la valeur d’un attribut protégé
1.5 Renforcer la sécurité du service DNS
1.5.1 Quel est le lien entre Active Directory et le DNS
1.5.2 La mise à jour DNS dynamique
1.5.3 Quelles sont les attaques possibles avec le service DNS
1.5.4 Sécuriser vos serveurs DNS
1.6 Elévation de privilège avec l’utilisation du Sid History
1.6.1 Faire une augmentation de privilège avec le Sid History
1.6.2 Pour supprimer le Sid History
2. Les bonnes pratiques pour déléguer l’administration de son annuaire
2.1 Les principes fondamentaux de la délégation d’administration
2.1.1 Les différents types d’administrateurs Active Directory
2.1.2 Les groupes avec des privilèges d’administration
2.1.3 Déléguer l’administration à un utilisateur standard
2.2 Déléguer l’administration avec les unités d’organisation
2.3 Créer des comptes nominatifs et dédiés pour l’administration
2.4 Déléguer uniquement les permissions requises
2.5 Désactiver le compte Invite et renommer le compte Administrator
2.6 Auditer les permissions sur les objets Actives Directory
2.7 Auditer les permissions de l’objet Adminsdholder
2.8 Activer la veille écran avec mot de passe
2.9 Désactiver les comptes inactifs
2.10 Les outils tiers pour simplifier la délégation d’administration
3. Définir une politique de mots de passe d’entreprise
3.1 Analyser les besoins de l’entreprise pour la politique de mots de passe
3.2 Réduire le nombre de login / mots de passe différents
3.2.1 Limiter le nombre de login / mot de passe à retenir
3.2.2 Configurer vos applications pour s’authentifier avec Active Directory
3.2.3 Utiliser le coffre-fort Windows
3.2.4 Utiliser les protocoles de fédération d’identité
3.3 Les outils de gestion de mots de passe Microsoft
3.3.1 Les stratégies de mots de passe de la Default Domain Policy
3.3.2 Les objets PSO (fine-grained Password)
3.4 Les outils tiers de gestion des mots de passe
3.4.1 Réinitialiser son mot de passe sans contacter l’équipe informatique
3.4.2 Garantir l’identité de l’utilisateur
3.4.3 Configurer la complexité des mots de passe
3.5 Trouver le mot de passe d’un utilisateur via le réseau
3.6 Utiliser des objets MSA et GMSA pour les services et les taches planifiées
3.7 Lister tous les comptes qui n’ont pas changé de mots de passe depuis plusieurs années
3.8 Réinitialiser le mot de passe des utilisateurs avec des cartes à puces
3.9 Restreindre l’utilisation de l’option « Password Never Expires »
3.10 Le stockage des mots de passe avec Active Directory
3.10.1 Qu’est-ce qu’une empreinte (ou hash) ?
3.10.2 Le Lmhash (Lan manager hash
3.10.3 Le Nthash (NT Lan manager hash)
3.11 Récupérer le mot de passe d’un utilisateur avec le Lmhash
3.11.1 La procédure
3.11.2 Comment désactiver le Lmhash
3.12 Récupérer le mot de passe d’un utilisateur avec le Nthash
3.12.1 La procédure
3.12.2 Comment protéger les mots de passe
3.13 Protéger les mots de passe stockés sur les machines Windows
3.13.1 Les services et les taches planifiées
3.13.2 Le cache des sessions Windows
3.14 Définir une stratégie de mots de passe cible
4. Renforcer la sécurité des protocoles d’authentification
4.1 Le protocole Ldap
4.1.1 Ldap simple Bind
4.1.2 Ldap SASL Bind
4.2 Présentation du protocole Ntlm v2
4.3 Présentation du protocole Kerberos v5
4.4 La délégation d’authentification Kerberos
4.5 Les bonnes pratiques pour renforcer la sécurité de l’annuaire active directory
4.5.1 Bloquer les connexions Ldap Simple Bind sans SSL / TLS
4.5.2 Activer la signature du trafic Ldap
4.5.3 Désactiver les protocoles d’authentification Ntlm
4.5.4 Configurer algorithme de chiffrement Kerberos
4.5.5 Configurer la synchronisation horaire
4.5.6 Interdire la délégation Kerberos pour les comptes d’administration
4.6 Elévation de privilège avec la technique Ntlm Pass the hash
4.6.1 Comprendre une attaque Ntlm Pass the hash
4.6.2 La procédure pour une attaque Ntlm Pass the hash
4.6.3 Se protéger contre les attaques Ntlm Pass the hash
5 La gestion des accès avec Active Directory
5.1 Les Sid
5.2 Les permissions
5.3 Les privilèges
5.4 Les processus
5.5 Les services
5.6 Les jetons d’accès (Access Token)
5.7 Elévation de privilège avec le vol d’un jeton d’accès
5.7.1 Présentation de l’outil Incognito
5.7.2 Procédure d’utilisation de l’outil Incognito
5.7.3 Comment bloquer l’outil Incognito ?
6. Industrialiser et sécuriser le déploiement des contrôleurs de domaine
6.1. Déployer uniquement une version supportée de Windows server
6.2 Héberger les contrôleurs de domaine dans un emplacement sécurisé
6.2.1 Quels sont les risques si un attaquant a un accès physique à un contrôleur de domaine ?
6.2.2 Comment empêcher un attaquant d’accéder au fichier ntds.dit ?
6.3 Déployer les correctifs de sécurités sur les contrôleurs de domaine
6.3.1 Pourquoi est-il nécessaire de déployer les correctifs de sécurité ?
6.3.2 Installation des correctifs de sécurité sur les contrôleurs de domaine
6.4 Réduire la surface d’attaque des contrôleurs de domaine
6.5 Ne jamais arrêter le service Windows firewall
6.6 Configurer l’UAC
6.7 Désactiver la mise en cache hors connexion des sessions
6.8. Renforcer la sécurité du Bureau à Distance
6.8.1 Utiliser des stations de travail d’administration
6.8.2 Configurer le service Bureau à Distance
6.8.3 Autoriser uniquement les outils d’administration
6.8.4 Configurer le client Bureau à Distance
6.8.5 Utiliser la fonctionnalité « restrictedadmin »
6.9 Restreindre l’accès à Internet des contrôleurs de domaine
6.10 Configurer le mot de passe DSRM
6.11 Déployer une configuration standard sur tous les contrôleurs de domaine
6.11.1 Configurer IPV6
6.11.2 Déployer un antivirus a jour et configurer les exclusions
6.11.3 Utiliser l’assistant de configuration de la sécurité
6.11.4 Tester votre image dans un environnement de qualification
6.11.5 Quelques retours d’expériences sur le déploiement de Windows 2012 R2
7. Mettre en place une politique de prévention des risques
7.1 Auditer les changements effectués sur l’annuaire et les tentatives d’accès
7.1.1 Configurer le journal Security
7.1.2 Configurer les éléments à auditer
7.1.3 Collecter le journal Security des contrôleurs de domaine et générer un rapport quotidien
7.2 Auditer la sécurité de votre annuaire
7.3 Superviser votre annuaire active directory
7.3.1 Présentation de l’outil DCDIAG
7.3.2 Déploiement de la solution
7.4 Disposer d’un plan de reprise informatique (PRI) Active Directory
7.5 Protéger vos sauvegardes active directory et les fichiers IFM (Install From Media)
8. Annexes
8.1 Procédure de déploiement d’une autorité de certification Microsoft
8.2 Procédure d’activation de Bitlocker sur un contrôleur de domaine
8.2.1 Présentation de la solution pour chiffrer les disques durs des contrôleurs de domaine
8.2.2 Mise en œuvre de Bitlocker sur des contrôleurs de domaine Windows 2012 R2
8.3 Bibliographie :
8.3.1 Livres recommandés
8.3.2 Microsoft Active Directory Technical Specification
8.3.3 Pour comprendre les protocoles Ntlm et Kerberos avec Active Directory
8.3.4L es recommandations sur la sécurité active directory de l’ANSII
8.3.5 Recommandation Microsoft sur la sécurité de l’annuaire Active Directory
8.3.6 Recommandation sur la configuration du service terminal server
8.3.7 Autres liens

A+
Guillaume MATHIEU
Architecte Metsys
La connaissance s’accroît quand on la partage.

Publié dans Active Directory, Annuaire, Sécurité | 14 commentaires

Vidéo de ma session techdays sur la sécurité Active Directory

Salut à tous

La video de ma session Techdays sur la sécurité Active Directory.
Cette session se base sur 8 demonstrations :
1. Comment les hackers récupèrent les mots de passe Active Directory ?
Avec le fichier NTDS.DIT (démo)
Avec  le mot de passe d’un service Windows (démo)
Avec une capture réseau
2. Comment les hackers peuvent élever les privilèges ?
Via NTLM Pass The Hash (démo)
Via l’outil INCOGNITO (démo)
Via le SID History (démo)
3. Comment les hackers peuvent récupérer un accès SYSTEM ?
4. Comment effectuer un déni de service avec Metasploit ?
Bonne session !

https://www.youtube.com/watch?v=hD9NQppdVNQ

A+
Guillaume MATHIEU
Architecte et Responsable Avant-Vente Metsys
La connaissance s’accroît quand on la partage.

Publié dans Windows Server 2008 | 3 commentaires

Vener nombreux à la session Techdays sur la sécurité Active Directory !

Salut à tous

L’heure est venue pour moi d’animer ma première session Techdays.
Cette dernière aura lieu le mercredi 11 février 2015 de 14h à 14h45.
Le thème : la sécurité Active Directory.
Petit cadeau : un livre (au format papier, on fait les choses en grand chez Metsys) vous sera remis en fin de session.

Pour vous inscrire :
https://techdays.microsoft.fr/programmes/2015/fiche-session.aspx?ID=b960caa2-e29a-40c6-999d-491a7ed60373.

Bonne journée.

Guillaume MATHIEU
Architecte Metsys
La connaissance s’accroît quand on la partage.

Publié dans Windows Server 2008 | 7 commentaires