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

Publié le 4 août 2016 par Guillaume Mathieu

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

Publié le 23 juin 2016 par Guillaume Mathieu

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 ?

Publié le 6 juin 2016 par Guillaume Mathieu

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”

Publié le 29 mai 2016 par Guillaume Mathieu

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 !

Publié le 2 mars 2015 par Guillaume Mathieu

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