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

Problème d’ouverture de session lente à cause d’un Repository WMI corrompu

Salut à tous.

1. Description du problème
Sur certaines stations de travail, l’ouverture d’une session nécessitait plus de 1 heure.
Ce problème se posait aléatoirement.

2. Analyse du problème
Le problème provenait d’une défaillance du service WINMGMT (Infrastructure de gestion liée au passage du SP1 sur le serveur SCCM 2012 :
https://social.technet.microsoft.com/Forums/en-US/84972757-8b82-44ff-95a7-8ccdfaf3d0ba/upgrade-to-system-center-configuration-manager-sp1-caused-wmi-dcom-http-errors?forum=configmanagergeneral
La taille du répertoire %windir%\System32\Wbem\Repository était de plus de 1,5 Go sur certaines machines.
SCCM bloque l’arrêt de WMI ce qui bloquait la procédure de réparation automatique du service WINMGMT.
Le log suivant apparaissait sur les machines posant problème :
Nom du journal :Application
Source : Microsoft-Windows-WMI
Date : 17/10/2014 09:58:51
ID de l’événement :65
Catégorie de la tâche :Aucun
Niveau : Avertissement
Mots clés : Classique
Utilisateur : N/A
Ordinateur : MSREPORT95.msreport.local
Description :
Le service WMI (Windows Management Instrumentation) commence la restauration du référentiel WMI

3. Correction du problème
Pour corriger le problème, il est nécessaire :
De reconstruire le répertoire C:\Windows\System32\wbem\Repository des stations de travail qui ont l’erreur Microsoft-Windows-WMI ID 65 en appliquant la procédure suivante :
http://blogs.technet.com/b/askperf/archive/2009/04/13/wmi-rebuilding-the-wmi-repository.aspx
De réparer le client SCCM sur les stations de travail pour que SCCM ajoute les classes WMI qui ont été supprimés à l’aide du script ci-dessous ou d’une réparation manuelle du client SCCM : https://gallery.technet.microsoft.com/SCCM-Client-Utility-WMI-ec270313

4. Correctifs à déployer
Je vous invite à déployer aussi les correctifs suivants.
Pour corriger les problèmes de corruption WMI : http://support.microsoft.com/kb/2617858/en-us
Pour corriger les problèmes de lenteur d’ouverture de session à cause d’un bug dans les GPO de Préférences : http://support.microsoft.com/default.aspx?scid=kb;EN-US;2561285

5. Comment diagnostiquer les autres problèmes d’ouverture de session lente
Etape 1 : Faire un premier état des lieux
Le but est de déterminer les changements qui ont été effectués depuis l’apparition de problème.
– Vérifier le bon fonctionnement du réseau. Je vous invite à utiliser la commande suivante : Ping IP_DC –l 56000 –t.
Vérifier que vous n’avez pas de problème de perte de paquets.
– Vérifier le bon fonctionnement de votre annuaire Active Directory en lançant la commande : DCDIAG /V /E > c:\Dcdiag.txt.
– Sur les stations de travail qui rencontrent des problèmes de lenteur d’ouverture de session, lancer la commande SET pour afficher le contrôleur de domaine utilisé pour ouvrir la session. Vérifier que votre sous réseau IP est bien rattaché à un site Active Directory dans la console Sites et Services Active Directory. Valider aussi que vous utilisez bien le contrôleur de domaine légitime.
– Sur les stations de travail qui rencontrent des problèmes de lenteur d’ouverture de session, lancer un jeu de stratégie résultant (console rsop.msc) pour lister toutes les paramètres de GPO / scripts qui s’appliquent aux machines et aux utilisateurs. Essayer à cette étape de déterminer si des paramètres GPO / scripts ont été modifiées depuis l’apparition du problème.
– Désactiver TCP Offline Engine sur quelques machines qui ont déjà rencontrées le problème. C’est particulièrement vrai sur les anciennes générations de machines. Voir :
http://support.microsoft.com/kb/951037/en-us
http://technet.microsoft.com/fr-fr/library/gg162682(v=ws.10).aspx
– Analyser les observateurs d’événements (journal Application et Système) d’une station de travail. Filtrer l’affichage que sur les erreurs, événements critique et avertissement pour gagner du temps.

Etape 2 : Créer un environnement de tests
Si vous n’avez pas pu identifier l’origine des problèmes, sur un échantillon de machine qui ont déjà rencontrés le problème, effectuer les actions suivantes :
– Définissez une configuration simplifiée de scripts / GPO. Ne mettre que les paramètres nécessaires comme le proxy ou les paramètres pour lancer correctement vos applications.
– Configurer les utilisateurs pour utiliser un profil local (si utilisation d’un profil itinérant) et désactiver les fichiers hors connexions et si possible la redirection de dossiers.
Je vous invite à lire cet article http://msreport.free.fr/?p=436.
– Déployer sur ces machines Windows 7 les 2 correctifs suivants :
http://support.microsoft.com/kb/2617858/en-us
http://support.microsoft.com/default.aspx?scid=kb;EN-US;2561285
– Simplifier la configuration de votre antivirus. Vérifier que toutes les exclusions antivirus sont bien configurées comme indiqué dans cet article :
http://support.microsoft.com/kb/822158/en-us
– Désactiver la fonctionnalité Fast Logon en activant le paramètre de GPO suivant : Computer Configuration | Policies | Administratives Templates | System | Logon | Always wait for the network at computer startup and logon.
Pour plus d’informations sur la fonctionnalité « Fast Logon », je vous invite à lire l’article suivant :
http://support.microsoft.com/kb/305293/en-us
– Désactiver le pare feu sur ces machines. Vérifier que vous autoriser bien le trafic nécessaire pour la communication avec vos contrôleurs de domaine.
– Désactiver l’UAC. Pour rappel, sous Windows 8.1, pour désactiver complètement l’UAC, il faut désactiver l’UAC par stratégie de groupe en désactivant le paramètre « Exécuter les comptes d’administrateurs en mode d’approbation d’administrateur ».
Laisser tourner environ 1 semaine et demander aux utilisateurs d’ouvrir / fermer leur session tous les jours. Ces derniers doivent consigner dans un fichier Excel la durée d’ouverture / fermeture de session tous les jours.
– Analyser systématiquement les observateurs d’événements Application et Système sur les stations de travail et le contrôleur de domaine utilisé pour ouvrir la session (commande SET). IL faut rapidement comprendre si le problème provient de la configuration des contrôleurs de domaine ou des stations de travail.

Etape 3 : Passage en mode avancé
Si vous n’arrivez toujours pas à trouver l’origine du problème, je vous invite à lire très attentivement ces 3 excellents articles.
L’article ci-dessous est une véritable base de connaissance sur les causes possible de lenteur à l’ouverture de sessions :
http://social.technet.microsoft.com/wiki/contents/articles/10130.root-causes-for-slow-boots-and-logons-sbsl.aspx
Les deux autres articles expliquent comment mettre en place les logs avancés dans le système pour trouver l’origine des problèmes de lenteur d’ouverture de session
http://blogs.technet.com/b/instan/archive/2008/04/17/troubleshooting-the-intermittent-slow-logon-or-slow-startup.aspx
http://social.technet.microsoft.com/wiki/contents/articles/10123.troubleshooting-slow-operating-system-boot-times-and-slow-user-logons-sbsl.aspx

A+
Guillaume MATHIEU
Architecte METSYS
La connaissance s’accroît quand on la partage.
http://msreport.free.fr

Publié dans Active Directory, Annuaire, Bug, Outils, Performance, Système, Troubleshouting, Windows 2003 Server, Windows 2012, Windows 2012 R2, Windows Server 2008 R2 | Marqué avec , | 2 commentaires

Mise en oeuvre d’une PKI, du chiffrement EFS et de BitLocker

Salut à tous

Ce dossier a pour but de présenter 2 solutions pour optimiser le niveau de sécurité de votre entreprise :
– Le chiffrement EFS pour protéger vos fichiers.
– Le chiffrement de disque BitLocker pour protéger vos ordinateurs.
Une version V2 de ce dossier permettra de présenter la mise en œuvre du chiffrement email / signature email avec le protocole S/MIME et la mise en œuvre du protocole IEEE 802.1X pour contrôler les accès aux réseaux WIFI et filaires de votre entreprise.
Pour mettre en œuvre ces 4 solutions, nous allons nous appuyer sur l’autorité de certification de Microsoft appelée Active Directory Domain Services.
L’environnement de maquette présenté dans cet article est installé sous Windows 2008 R2 Entreprise en version anglaise.

1. Présentation des différentes solutions
1.1 Présentation d’EFS
Les permissions NTFS ne permettent pas réellement de protéger les fichiers de l’entreprise.
– Un administrateur local dispose du droit de s’approprier les fichiers. Ce droit permet d’outrepasser les permissions NTFS et donc d’accéder aux données. La mise en œuvre d’EFS permet de garantir que seules les personnes habilitées peuvent accéder aux données de l’entreprise.
– En cas de vol de votre ordinateur, le pirate pourra installer un système d’exploitation Windows (ou démarrer sur un système BartPE / WinPE…) et connecter votre ancien disque dur en tant que disque non système. Il pourra alors devenir propriétaire de vos fichiers, réinitialiser les permissions NTFS et ainsi accéder à vos fichiers confidentiels.
EFS permet de chiffrer le contenu de vos fichiers à l’aide d’une clé symétrique, elle-même protégée à l’aide des clés privées / publiques associées à un certificat de type Utilisateur (modèle Msreport-Utilisateur dans ce dossier).
Même si vous disposez des permissions sur le fichier, si vous ne disposez pas du certificat, il vous sera impossible de lire le contenu du fichier. Pour plus d’informations sur EFS, voir :
http://windows.microsoft.com/fr-fr/windows/what-is-encrypting-file-system#1TC=windows-7
http://technet.microsoft.com/fr-fr/library/cc721923(v=ws.10).aspx

1.2 Présentation de BitLocker et de MBAM
BitLocker permet de chiffrer le disque système, un disque fixe (non système) ou un disque amovible (clé USB…).
Il permet de demander la saisie d’un mot de passe pour pouvoir accéder aux disques fixe et amovible.
BitLocker nécessite un système d’exploitation sous Windows 7 Entreprise / Intégrale ou Windows 8 Professionnel.
Le disque système devra formatée en NTFS. BitLocker crée automatiquement 2 partitions : une partition de 100 Mo qui est marquée comme active et qui contient les fichiers de démarrage et la partition système qui contient les données du système (C:\windows). Seule la partition système est chiffrée.
La solution BitLocker peut utiliser différents périphériques pour stocker la clé de chiffrement / déchiffrement :
– Une Clé USB (clé de démarrage uniquement) : cette méthode chiffre uniquement le lecteur. Elle ne fournit aucune validation des composants de la séquence de démarrage et aucune garantie contre la falsification du matériel. Pour utiliser cette méthode, votre ordinateur doit prendre en charge la lecture des périphériques USB dans l’environnement de prédémarrage.
– Une carte à puce : BitLocker s’appuie alors sur le certificat contenu dans la carte à puce pour chiffrer / déchiffrer le disque dur.
– Un module TPM (Trusted Plateform Module). C’est la méthode recommandée par Microsoft. Elle permet de protéger le disque dur et de valider que les composants de la séquence de démarrage n’ont pas été altérés.
Dans la configuration présentée dans ce dossier, l’activation de BitLocker nécessitera une station de travail équipée d’un TPM (Trusted Platform Module).
Pour utiliser BitLocker avec un TPM, il est nécessaire d’activer le TPM dans le BIOS de l’ordinateur.
Lors de l’activation de BitLocker, le TPM est initialisé, c’est-à-dire que la clé de chiffrement / déchiffrement BitLocker est copié sur le TPM.
La console TPM.MSC permet de gérer le TPM (activation, désactivation, initialisation). Ces tâches de gestion nécessitent de connaître le « Trusted Platform Module (TPM) owner password ».
Lors de l’activation de BitLocker, une « BitLocker Recovery Key » est générée. Elle permet d’accéder aux données sur le volume disque chiffré avec BitLocker en cas de perte de la clé principale de chiffrement (défaillance du TPM ou de la machine…). Il est possible de sauvegarder cette clé sous forme de fichier, de l’imprimer ou de la sauvegarder dans l’annuaire Active Directory.
Pour pouvoir visualiser la « BitLocker Recovery Key » depuis la console Utilisateurs et Ordinateurs Active Directory, il est nécessaire d’installer la fonctionnalité « BitLocker Recovery Password Viewer » sur tous les contrôleurs de domaine et vos stations d’administration.
BitLocker s’enrichit de nouvelles fonctionnalités avec Windows 8 :
– BitLocker peut être déployé pendant l’installation de Windows 8. Avec Windows 7, le système devait être installé puis BitLocker pouvait alors être activé.
– BitLocker permet de chiffrer que l’espace disque utilisé (nouveauté) ou sur tout le volume disque (comme auparavant). Ce paramètre peut être contrôlé à l’aide d’une stratégie de groupe.
– Sous Windows 7, BitLocker nécessite des droits « Administrateur local » pour pouvoir être activé. Avec Windows 8, il faut toujours des droits administrateur pour activer BitLocker. Cependant, il est maintenant possible de déléguer aux utilisateurs standards la possibilité de changer le mot de passe BitLocker pour les disques fixes et systèmes.
– Windows 8 prend en charge les disques qui disposent d’un mécanisme (composant matériel) pour accélérer le chiffrement du disque.
Pour plus d’informations sur BitLocker, voir :
http://technet.microsoft.com/fr-fr/library/dd875530(v=ws.10).aspx
http://technet.microsoft.com/fr-fr/library/dd875534(v=ws.10).aspx
http://technet.microsoft.com/fr-fr/library/hh831412.aspx.

Présentation de la solution MBAM (Microsoft BitLocker Administration and Monitoring)
La solution MBAM permet de configurer BitLocker automatiquement sur les postes de travail et de disposer de nombreux rapports. MBAM remplace le composant BitLocker du panneau de configuration sur les stations de travail Windows 7 / Windows 8. Cette solution est très intéressante mais nécessite de disposer de la Software Assurance pour les licences Windows et d’installer 3 serveurs dédiés (dont un serveur SQL Server).
La version 1.0 de MBAM ne prend en charge que Windows 7. La version 2.1 de MBAM qui prendra en charge Windows 8.1. Nous ne présenterons pas dans ce dossier le déploiement de BitLocker avec MBAM car peu de clients disposent de la Software Assurance.
Pour plus d’informations sur MBAM :
http://technet.microsoft.com/fr-fr/windows/hh826072.aspx
http://www.microsoft.com/fr-fr/windows/enterprise/products-and-technologies/mdop/mbam.aspx
http://technet.microsoft.com/fr-fr/library/dn505770.aspx

1.3 Présentation du Credential Roaming
Le Credential Roaming (itinérance des informations d’identifications) permet de stocker au niveau de l’annuaire Active Directory le contenu des magasins de certificats Windows (une partie du coffre-fort de Windows). Depuis Windows 7, le Credential Roaming ne permet plus de stocker les mots de passe réseau, seulement les magasins de certificat. Cette fonctionnalité s’appuie sur les attributs suivants d’un compte utilisateur Active Directory :
– msPKIDPAPIMasterKeys : cet attribut contient la clé principale (change tous les 90 jours, elle permet de chiffrer les clés privés sur le poste de travail).
– msPKIAccountCredentials : contient les login / mots de passes réseaux, les clés privées, les certificats et les demandes de certificats. Cet attribut peut être très volumineux.
– msPKIRoamingTimeStamp : cet attribut contient la date de dernier changement pour la valeur des msPKIAccountCredentials et msPKIDPAPIMasterKeys.
Seuls les administrateurs du domaine et le propriétaire du compte utilisateur ont des accès en écriture sur ces 3 attributs. Un certificat nouvellement généré est téléchargé dans l’annuaire en moins de 10 minutes (hors délais de réplication des contrôleurs de domaine).
Le correctif KB 973502 doit être déployé sur les machines Windows 2003 SP2 et Windows XP SP3.
Le correctif 2520487 doit être déployé sur les machines Windows Vista / 7 / 2008 / 2008 R2.
La fonctionnalité du Credential Roaming et les profils itinérants sont incompatibles. Il faut donc exclure les répertoires suivants de la liste des répertoires synchronisés avec les profils itinérants :
– Pour Windows XP : Application Data\Microsoft\Crypto, Application Data\Microsoft\Protect, Application Data\Microsoft\SystemCertificates
– Pour Windows Vista / 2008 et versions ultérieures : AppData\Roaming\Microsoft\Credentials, AppData\Roaming\Microsoft\Crypto, AppData\Roaming\Microsoft\Protect, AppData\Roaming\Microsoft\SystemCertificates
L’activation du Credential Roaming augmente la taille de la base de données de l’annuaire Active Directory
Si un utilisateur ouvre une session sur de nombreuses machines, le Credential Roaming va faire converger les certificats (tous différents) déployés sur l’ensemble des machines. Le risque est de se retrouver avec plusieurs dizaines de certificats.
Le Credential Roaming est incompatible avec les RODC (contrôleur de domaine en lecture seule).
Pour des raisons de sécurité, il est préconisé de ne pas activer le Credential Roaming pour un compte utilisateur avec un certificat Agent de récupération de fichiers (EFS) ou Agent de récupération de clés privées (Key Recovery Agent) ou Msreport-BitLockerDRA (modèle de certificat créé dans ce dossier). Il faut en effet maitriser les machines où se trouvent ces types de certificats qui disposent de droits très importants.
Si le même certificat a été déployé manuellement sur plusieurs machines mais avec des paramètres différents (paramètre d’exportation de la clé privée), le Credential Roaming applique des règles de gestion des conflits.
Pour plus d’informations sur le Credential Roaming :
http://support.microsoft.com/kb/2607862
http://social.technet.microsoft.com/wiki/contents/articles/11483.credential-roaming.aspx

2. Définition de l’architecture cible
2.1 Prérequis à la mise en œuvre de la solution
Vous devez disposer d’un domaine Active Directory géré par des contrôleurs de domaine Windows 2003 R2 ou version ultérieure. Dans cet exemple le domaine sera appelé MSREPORT.LOCAL et géré par 2 contrôleurs de domaine Windows 2008 R2.
Vous devez disposer d’une messagerie compatible avec le protocole S/MIME comme Exchange On-Premise / Online.
Pour activer EFS, S/MIME, BitLocker et IEEE 802.1X, nous avons besoin de certificats. Pour cela, une autorité de certification d’entreprise Microsoft sera déployée sur le serveur MSREPORTDC1.
Une architecture d’autorité de certification 1 tiers a été retenue car :
– Cette configuration est simple à mettre en place et à maintenir. Une architecture 2 TIERS / 3 TIERS est intéressante si vous devez générer un grand nombre de certificats.
– Le nombre de certificats à délivrer sera relativement faible (1 pour chaque compte utilisateur Active Directory et 1 pour chaque machine membre du domaine Active Directory).
– La configuration 1 tiers ne nécessite qu’un seul serveur.
L’autorité de certification sera déployée sur un serveur Windows 2008 R2 (ou une version ultérieure) membre du domaine Active Directory MSREPORT.LOCAL.et disposera de la configuration suivante :
– L’autorité de certification ne doit pas être installée sur un contrôleur de domaine car cette configuration n’est pas recommandée. La commande DCPROMO (inverse) échoue si le contrôleur de domaine est serveur d’autorité de certification. Dans cet exemple, l’autorité de certification sera installée sur le serveur MSREPORTDC1.
– Le site interface web d’administration (CERTSRV) sera installé sur le serveur.
– L’archivage des clés privées sera activé pour les certificats utilisés pour S/MIME et EFS. Cette fonctionnalité permet de régénérer le certificat à l’aide de la base de données de certificats et d’un certificat spécial basé sur le modèle « Key Recovery Agent ».
– Les informations AIA (clé publique de l’autorité de certification) et la CDP (emplacement de la liste de révocation des certificats alias CRL) seront ajoutées au niveau des certificats émis (chemin LDAP et HTTP).
– L’audit sera activé sur l’autorité de certification (toutes les tâches). Toutes les actions effectuées sur l’autorité de certification (génération d’un certificat, modification de la configuration) seront consignés dans le journal de sécurité du serveur d’autorité de certification.
Les modèles de certificats suivants seront configurés sur l’autorité de certification :
– Utilisateur-Msreport : validité : 3 ans, clés de 2048 bits, exportation de la clé privée autorisée, archivage de la clé publique.
– Ordinateur-Msreport : validité : 3 ans, clés de 2048 bits, exportation de la clé privée autorisée, pas d’archivage de la clé publique.
– BitLockerDRA-Msreport : validité : 5 ans, clés de 2048 bits, exportation de la clé privée autorisée, pas d’archivage de la clé publique.
– Agent de récupération de clés (Key Recovery Agent) : validité : 5 ans, clés de 2048 bits, exportation de la clé privée autorisée, pas d’archivage de la clé publique.
– Agent de récupération EFS (EFS Recovery Agent) : validité : 5 ans, clés de 2048 bits, exportation de la clé privée autorisée, pas d’archivage de la clé publique.
– Authentification Contrôleur du domaine : validité : 3 ans, clés de 2048 bits, exportation de la clé privée autorisée, pas d’archivage de la clé publique.
Chaque ordinateur du domaine MSREPORT.LOCAL disposera d’un certificat basé sur le modèle « Ordinateur-Msreport ». Pour cela ce modèle de certificat sera configuré pour être déployé automatiquement pour tous les comptes ordinateurs membres du groupe « DEPLOY-CERTIFICAT-COMPUTERS ».
Chaque utilisateur du domaine MSREPORT.LOCAL disposera d’un certificat basé sur le modèle « Utilisateur-Msreport ». Pour cela ce modèle de certificat sera configuré pour être déployé automatiquement pour tous les utilisateurs membres du groupe « DEPLOY-CERTIFICAT-USERS ».
Le Credential Roaming sera activé pour garantir qu’un utilisateur disposera toujours du même certificat basé sur le modèle Utilisateur-Msreport si ce dernier travaille sur plusieurs machines.

2.2 Configuration d’EFS :
Les utilisateurs chiffreront leurs données confidentielles à l’aide du certificat basé sur le modèle « Utilisateur-Msreport ». Un agent de récupération EFS sera configuré (utilisation du modèle de certificat Agent de récupération EFS généré pour le compte AdminPKI). Il permettra à l’équipe informatique de récupérer les données chiffrées par un utilisateur perd sa clé privé de son certificat Utilisateur-Msreport ou son certificat (corruption de son profil, perte de sa machine).

2.3 Configuration de BitLocker
BitLocker sera configuré dans cet exemple pour des stations de travail Windows 7 Entreprise ou Windows 8 Professionnel équipé d’un TPM.
Une GPO sera configurée pour sauvegarder dans l’annuaire Active Directory le mot de passe du propriétaire du TPM (Trusted Platform Module (TPM) owner password) et la clé de récupération BitLocker (BitLocker Recovery Key).
Un agent de récupération des données chiffrées avec BitLocker (Data Recovery Agents with BitLocker) sera utilisé pour permettre à une personne disposant d’un certificat basé sur le modèle BitLockerDRA-Msreport de déchiffrer les données.

3. Déploiement de l’autorité de certification
3.1 Installation de l’autorité de certification
La première étape est d’installer le rôle « Active Directory Certificates Services ».
Il faut sélectionner les composants « Certification Authority » et « Certificate Authority Web Enrollment ».
Choisir ensuite une autorité de certification d’Entreprise de type racine.
Configurer l’autorité de certification avec une durée de vie de 10 ans et une paire de clés de 2048 bits.
Laisser les autres options par défaut.

3.2 Installation de la fonctionnalité « Chiffrement de lecteur BitLocker »
Il est nécessaire d’installer la fonctionnalité BitLocker Drive Encryption sur le serveur d’autorité de certification pour que les extensions BitLocker Drive Encryption et BitLocker Data Recovery Agent soient disponibles lors de la création du modèle de certificat BitLockerDRA-Msreport. Pour plus d’informations :
http://social.technet.microsoft.com/Forums/windowsserver/en-US/fcb6cf1e-0196-4338-ac83-e737a34a98cb/bitlocker-data-recovery-agent-certificate

3.3 Configuration de la CA pour émettre des certificats avec une durée de vie de 10 ans
Par défaut, une autorité de certification Microsoft impose une limite de 2 ans pour un certificat (même si le modèle de certificats permet d’aller au-delà). Pour pouvoir générer des certificats avec une durée de vie égale à la durée de vie de l’autorité de certification, taper la commande suivante :
Certutil –setreg ca\VALIDITYPeriodUnits 10

3.4 Configuration de l’AIA et de la CRL
Le but est de configurer l’AIA et de la CRL pour être publiés sur le site IIS du serveur d’autorité de certification (URL interne dans un premier temps). Lancer la console « Certification Authority ».
Aller dans les propriétés de l’autorité de certification dans l’onglet « Extensions ».
Sélectionner « CRL Distribution Point (CDP) ».
Sélectionner la ligne avec http et cocher la case « Include in the CDP extension of issued certificates ».
Sélectionner « Authority Information Access (AIA) » et sur la ligne « http », cocher la case « Include in the AIA extension of issued certificates ».

3.5 Configuration des modèles de certificats
3.5.1 Création des groupes locaux « DEPLOY-CERTIFICAT-COMPUTERS » et « DEPLOY-CERTIFICAT-USERS »
Créer les groupes de domaines locaux « DEPLOY-CERTIFICAT-COMPUTERS » et « DEPLOY-CERTIFICAT-USERS » dans l’annuaire MSREPORT.LOCAL pour permettre respectivement de déployer automatiquement les certificats basés sur les modèles « Ordinateur-Msreport » et « Utilisateur-Msreport ».

3.5.2 Création du modèle Utilisateur-Msreport
Lancer la console « Certification Authority ». Faire un clic droit sur « Certificate Templates » puis sélectionner « Manage » au niveau de modèle de certificats.
Dans la console « Certificate Templates », sélectionner le modèle « User » et cliquer sur « Duplicate Template ».
Sélectionner « Windows Server 2003 Enterprise ». Configurer le modèle de la manière suivante :
– Nom de modèle « Utilisateur-Msreport ».
– Durée de validité de 3 ans
– Durée de renouvellement de 6 semaines.
– Publier le certificat dans l’annuaire Active Directory. Cocher la case « Do not automatically reenroll if a duplicate certificate exists in Active Directory ».
– Cocher la case « Allow private Key to be exported ».
– Configurer une taille de clés de 2048 bits.
– Construire les informations à l’aide d’Active Directory et cocher les cases « User Principal Name(UPN) » et « Email name ».
– Décocher la case « Ca certificate manager approval ».
– Aller dans l’onglet « Security » et donner les droits « Read », « Enroll » et « Autoenroll » au groupe « DEPLOY-CERTIFICAT-USERS ».

3.5.3 Création du modèle Ordinateur-Msreport
Lancer la console « Certification Authority ». Faire un clic droit sur « Certificate Templates » puis sélectionner « Manage » au niveau de modèle de certificats.
Dans la console « Certificate Templates », sélectionner le modèle « Computer » et cliquer sur « Duplicate Template ».
Sélectionner « Windows Server 2003 Enterprise ». Configurer le modèle de la manière suivante :
– Nom de modèle « Ordinateur-Msreport ».
– Durée de validité de 3 ans
– Durée de renouvellement de 6 semaines.
– Ne pas publier le certificat dans l’annuaire Active Directory.
– Cocher la case « Allow private Key to be exported ».
– Configurer une taille de clés de 2048 bits.
– Construire les informations à l’aide d’Active Directory et cocher la cases « DNS name ».
– Décocher la case « Ca certificate manager approval ».
– Aller dans l’onglet « Security » et donner les droits « Read », « Enroll » et « Autoenroll » au groupe « DEPLOY-CERTIFICAT-COMPUTERS ».

3.5.4 Création du modèle BitLockerDRA-Msreport
Lancer la console « Certification Authority ». Faire un clic droit sur « Certificate Templates » puis sélectionner « Manage » au niveau de modèle de certificats.
Dans la console « Certificate Templates », sélectionner le modèle « Key Recovery Agent» et cliquer sur « Duplicate Template ».
Sélectionner « Windows Server 2003 Enterprise ». Configurer le modèle de la manière suivante :
– Nom de modèle « « BitLockerDRA-Msreport».
– Durée de validité de 5 ans
– Durée de renouvellement de 6 semaines.
– Ne pas publier le certificat dans l’annuaire Active Directory.
– Cocher la case « Allow private Key to be exported ».
– Configurer une taille de clés de 2048 bits.
– Construire les informations à l’aide d’Active Directory et cocher les cases « User Principal Name(UPN) ».
– Décocher la case « Ca certificate manager approval ».
– Aller dans l’onglet « Security » et donner les droits « Read », « Enroll » à AdminPKI. Laisser le droit « Read » à Authenticated users.
– Aller dans l’onglet « Extensions », sélectionner « Application Policies » puis cliquer sur « Modify ». Ajouter les extensions « BitLocker Drive Encryption» et « BitLocker Data Recovery Agent ».

3.5.4 Reconfiguration des modèles Key Recovery Agent et EFS Recovery Agent
Reconfigurer le modèle de certificats avec les paramètres suivants :
– Durée de validité de 5 ans
– Cocher la case « Allow private Key to be exported ».
– Aller dans l’onglet « Security » et donner uniquement au compte AdminPKI le droit « Inscrire ».
– Décocher la case « Ca certificate manager approval ».

3.5.5 Configurer l’autorité de certification pour émettre des certificats « Utilisateur-Msreport », « Ordinateur-Msreport », « BitLockerDRA-Msreport », « Agent de récupération de clé », « Agent de récupération EFS », Serveur web et « Authentification des contrôleurs de domaine »
Lancer la console « Autorité de certification ». Faire un clic droit sur « Certificate Templates » puis cliquer sur « New | Certificate Template to Issue ».
Supprimer les anciens modèles de certificats.

3.6 Activation de l’archivage des clés privées
Créer un compte appelé AdminPKI avec un mot de passe complexe. Ce compte doit être administrateur local sur le serveur d’autorité de certification. Il faut ensuite générer un certificat basé sur le modèle « Key Recovery Agent » pour le compte AdminPKI.
Pour cela, créer une console MMC vierge (mmc.exe) et ajouter le composant logiciel enfichable Certificats.
Ouvrir le composant certificat utilisateur et faire une demande d’un certificat basé sur le modèle de certificat « Key Recovery Agent ». Sauvegarder ensuite ce certificat au format PFX en le protégeant avec le mot de passe du compte AdminPKI.

3.7 Activation des paramètres d’audit de l’autorité de certification et configuration du journal de sécurité avec une taille de 512 Mo
Toutes les actions effectuées au niveau de l’autorité de certification seront inscrites dans le journal « Security » du serveur. Lancer la console « Certification Authority » puis aller dans les propriétés de l’autorité de certification au niveau de l’onglet « Audit ». Cocher toutes les cases comme « Back up and restore the CA database».
Il faut maintenant configurer le journal « Security » avec une taille de 512 Mo pour disposer d’un historique des actions effectuées sur l’autorité de certification.
Créer un objet GPO et l’appliquer au serveur d’autorité de certification. Configurer les 2 paramètres suivants (dans Paramètres de sécurités) :
– Taille maximale du journal de sécurité : 512000 Ko
– Méthode de stockage du journal de sécurité : Overwrite events as needed

3.8 Autoriser l’autorité de certification à émettre des certificats SAN
Le but est de configurer l’autorité de certification pour autoriser les certificats SAN (Subject Alternative Names).
Taper la commande suivante :
CertUtil -SetReg Policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc & net start certsvc

3.9 Activation du Credential Roaming dans l’annuaire MSREPORT.LOCAL
Lancer la console GPMC.MSC.
Editer la Default Domain Policy.
Aller dans User Configuration | Windows Settings | Security Settings | Public Key Policies.
Dans la fenêtre de droite, double cliquer sur « Certificate Serbices Client – Credential Roaming »
Activer ce paramètre et laisser les autres paramètres par défaut.
Comme expliqué lors de l’activation du Credential Roaming, cette fonctionnalité est incompatible avec les profils itinérants. Pour cette raison, l’activation du Credential Roaming active aussi une exclusion au niveau des répertoires pris en compte avec les profils itinérants.
Pour plus d’informations sur le Credential Roaming :
http://technet.microsoft.com/en-us/library/cc700848.aspx
http://technet.microsoft.com/en-us/library/cc771348.aspx
http://social.technet.microsoft.com/wiki/contents/articles/11483.credential-roaming.aspx
http://blogs.technet.com/b/instan/archive/2009/05/26/considerations-for-implementing-credential-roaming.aspx
http://blogs.technet.com/b/askds/archive/2009/12/18/troubleshooting-credential-roaming.aspx
http://blogs.technet.com/b/instan/archive/2009/05/26/considerations-for-implementing-credential-roaming.aspx
http://blogs.technet.com/b/askds/archive/2009/01/06/certs-on-wheels-understanding-credential-roaming.aspx

3.10 Configuration de l’autoenrollment (déploiement automatique de certificat) pour les modèles de certificats « Utilisateur-Msreport» et « Ordinateur-Msreport »
Un des objectifs est de délivrer automatiquement un certificat basé sur le modèle « Utilisateur-Msreport » pour chaque utilisateur. Pour atteindre cet objectif, il faut :
– Configurer le modèle de certificat Msreport-User pour autoriser l’inscription automatique de certificat pour les utilisateurs membres du groupe « DEPLOY-CERTIFICAT-USERS ».
– Editer la Default Domain Policy. Aller dans User Configuration | Windows Settings | Security Settings | Public Key Policies. Dans la fenêtre de droite, double cliquer sur « Enroll user and computer certificate automatically ». Activer ce paramètre et cocher la case « Update certificates that use certificate templates » pour permettre le bon fonctionnement de l’autoenrollment.
Pour déployer automatiquement les certificats « Ordinateur-Msreport », il faut
– Configurer le modèle de certificat Ordinateur-Msreport pour autoriser l’inscription automatique de certificat pour les comptes ordinateurs membres du groupe « DEPLOY-CERTIFICAT-COMPUTERS ».
– Editer la Default Domain Policy. Aller dans Configuration Computer Configuration | Windows Settings | Security Settings | Public Key Policies. Dans la fenêtre de droite, double cliquer sur Enroll user and computer certificate automatically ». Activer ce paramètre et cocher la case « Update certificates that use certificate templates » pour permettre le bon fonctionnement de l’autoenrollment.
Il est possible d’activer un log détaillé de l’autoenrollement en configurant les entrées de registre suivantes :
– Pour l’autoenrollment des certificats ordinateurs : HKEY_CURRENT_USER\Software\Microsoft\Cryptography\AutoEnrollment
– Pour l’autoenrollment des certificats utilisateurs : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\AutoEnrollment

3.11 Sauvegarder l’autorité de certification
Créer le fichier C:\_adm\scripts\BackupCertificates.cmd avec le contenu suivant :
Echo Backup Certification Authority, Certificates, Templates and CSP
c:
cd C:\_adm\scripts
Echo O| del C:\backup-ca\database
rd C:\backup-ca\database
Echo O | del c:\backup-ca
Echo Backing up the Certification Authority and Certificates
certutil -backup -p P@sswordfpvmch c:\backup-ca
Echo Backing up the registry keys
reg export HKLM\System\CurrentControlSet\Services\CertSvc\Configuration c:\backup-ca\regkey.reg
Certutil –getreg CA\CSP > C:\Backup-ca\CSP.txt
Echo Documenting all certificate templates published at the CA
Certutil –catemplates > C:\Backup-ca\CATemplates.txt
Créer la tâche planifiée qui va lancer le script ci-dessus tous les jours. Il sera nécessaire de sauvegarder le répertoire c:\Backup-ca avec votre outil de sauvegarde.

3.12 Mise en œuvre des rapports sur l’activité de l’autorité de certification
Je vous invite à utiliser le plugin PSPKI si vous disposez d’une autorité de certification sous Windows 2008 R2. Avec Windows 2012, Microsoft fournit des commandes PowerShell permettant de générer le même type de rapport.
Pour installer le module PowerShell PSPKI
Autoriser l’exécution des scripts PowerShell non signés.
Set-ExecutionPolicy Unrestricted
Installer .Net Framework 4.0.
Installer PowerShell V3.0, téléchargeable à cette adresse :
http://www.microsoft.com/en-us/download/details.aspx?id=34595
Installer le module PSPKI disponible à cet emplacement (installation complète).
http://poweradmin.se/blog/2011/08/09/adcs-certificate-expiration-report-tool/
http://pspki.codeplex.com/
Le script ci-dessous permet de lister tous les certificats révoqués :
Import-Module PSPKI
Get-CertificationAuthority -Name Msreport | Get-RevokedRequest | Select-Object Request.RequestID,CommonName, SerialNumber, Request.RevokedReason | Export-Csv –Path c:\_adm\scripts\revoque.csv -Encoding UTF8 –UseCulture
Le script ci-dessous va afficher les certificats qui vont expirés dans un mois.
On s’appuie toujours sur le module PowerShell PSPKI. Créer le fichier c:\_adm\script\certificats-expirés.ps1 et copier le contenu du script ci-dessous :
param(
[string] $computername = “$ENV:COMPUTERNAME”,
[string] $reportfile = “$ENV:USERPROFILE\Desktop\PKIRAPPORT.html”
)
# Variables
$caname = $computername.ToLower()
$domaindns = $ENV:USERDNSDOMAIN.ToLower()
$todaysdate = Get-Date
$findaldate = $todaysdate.AddMonths(1)
$reportfile = “c:\_adm\scripts\certificats-expires.html”
# Vérifie que PSPKI est installé.
if(Get-Module -ListAvailable -Name PSPKI | Where-Object { $_.name -eq “PSPKI” })
{
# Vérifie que PSPKI est chargé
if (!(Get-Module -Name PSPKI | Where-Object { $_.name -eq “PSPKI” }))
{
Write-Host “Importation du module PSPKI” -ForegroundColor “Yellow”
Import-Module -Name PSPKI
}
# Génère le rapport
$htmlpre = “
Generated by user: $ENV:USERNAME
Les certificats vont suivant expirés avant $findaldate (date au format englais)

$htmlpost = “
Certificate expiration information retrived from $caname.$domaindns

$htmltitle = “Autorité de certification : $caname.$domaindns”
$htmlinput = Get-CertificationAuthority “$caname.$domaindns” | Get-IssuedRequest -Filter “NotAfter -ge $(Get-Date)”, “NotAfter -le $findaldate”
$htmlinput | ConvertTo-Html -Body (Get-Date) “Report date:” -Property RequestID,RequesterName,CommonName,NotBefore,NotAfter,SerialNumber -Pre $htmlpre -Post $htmlpost -Title $htmltitle | Out-File -FilePath $reportfile
# Chargement du rapport
Invoke-Item $reportfile
}
else
{
Write-Host “PSPKI is not installed. Please install it from http://pspki.codeplex.com/ ” -ForegroundColor “Yellow”
}

4. Configuration d’EFS
4.1 Générer le certificat certificats « Agent de récupération EFS » pour AdminPKI
Il faut ensuite générer un certificat « EFS Recovery Agent » pour le compte AdminPKI.
Pour cela, créer une console MMC vierge (mmc.exe) et ajouter le composant logiciel enfichable Certificats.
Ouvrir le composant certificat utilisateur et faire une demande d’un certificat basé sur le modèle de certificat « EFS Recovery Agent ». Sauvegarder ensuite ce certificat au format PFX en le protégeant avec le mot de passe du compte AdminPKI.

4.2 Configurer ADMINPKI comme agent de récupération EFS pour le domaine MSREPORT
Exporter le certificat de l’agent de récupération EFS du compte ADMINPKI au format CER (clé publique uniquement).
Lancer la console GPMC.MSC. Editer la GPO Default Domain Policy.
Aller dans Configuration Ordinateur | Stratégies | Paramètres Windows | Paramètres de sécurité | Stratégie de clé publique Computer Configuration | Windows Settings | Security Settings | Public Key Policies | Encrypting File System.
Supprimer le certificat existant si applicable et lancer l’assistant d’ajout d’un agent de récupération. Importer le certificat « EFS Recovery Agent » du compte AdminPKI.
Forcer la réplication Active Directory.
Sur les stations de travail, lancer la commande GPUPDATE /FORCE ou attendre 120 minutes.

4.3 Utilisation d’EFS
Ouvrir une session avec un compte utilisateur mélanie.mathieu membre du groupe « DEPLOY-CERTIFICAT-USERS ». Vérifier qu’un certificat « Utilisateur-Msreport » a été généré automatiquement pour le compte melanie.mathieu. Créer un dossier appelé « Données confidentielles ».
Aller dans l’onglet « General » puis cliquer sur le bouton « Advanced ». Dans la fenêtre « Advanced Attributes », cocher la case « Encrypt contents to secure data ».
Cliquer dans l’onglet « Detail» et vérifier que les données sont chiffrés avec un certificat « Utilisateur-Msreport » du compte melanie.mathieu. Vérifier que le certificat AdminPKI est configuré comme « Recovery certificate ».

5. Mise en œuvre de BitLocker
Toutes les informations ci-dessous sont extrait du guide « BitLocker Drive Encryption » de Microsoft.
http://technet.microsoft.com/fr-fr/library/dd875547(v=ws.10).aspx  et du guide des paramètres de GPO http://technet.microsoft.com/en-us/library/jj679890.aspx
http://technet.microsoft.com/fr-fr/library/hh831412.aspx

5.1 Configuration des GPO pour BitLocker et le TPM
Les paramètres listés dans le tableau ci-dessous ont été définis au niveau de la GPO « COMPUTER – CERTIFICAT – BITLOCKER ».
Ils permettent entre autres de sauvegarder la « BitLocker Recovery Key » et le « Trusted Platform Module (TPM) Owner password » dans l’annuaire Active Directory.
L’activation d’un Agent de récupération des données chiffrées avec BitLocker nécessite aussi d’activer le champ identification. Nous avons utilisé la chaîne de caractères suivant : 14127487 comme identifiant.
Aller dans Computer Configuration | Administrative Templates | Windows Components | BitLocker Drive Encryption to show the policy settings | Provide the unique identifiers for your organization. Activer ce paramètre et sélectionner les paramètres suivants
BitLocker Identification Field : 14127487
Allowed BitLocker Identification Field : 14127487
Ce paramètre permet à BitLocker de déterminer si un disque est géré par l’entreprise ou un disque personnel. Pour plus d’informations : http://technet.microsoft.com/fr-fr/library/dd875560(v=ws.10).aspx
Aller dans Computer configuration | Policies | Administratives Templates | Windows Components | BitLocker Drive Encryption | Operating System Drives | Require additional authentication at startup. Activer le paramètre de GPO avec la configuration suivante :
Décocher la case « Allow BitLocker without a compatible TPM » :
Sélectionner les choix suivants :
« Require TPM »
« Do not allow startup PIN with TPM »
« Do not allow startup LKey with TPM »
« Do not allow startup Key and PIN with TPM »
Aller dans Computer configuration | Policies | Administratives Templates | Windows Components | BitLocker Drive Encryption | Operating System Drives | Choose how BitLocker-protected operating system drive can be recovered
Activer le paramètre de GPO avec la configuration suivante :
Cocher la case « Allow data recovery agent ».
Sélectionner les paramètres suivants :
“Allow 48-digity recovery password”
“Allow 256-bit recovery key”
Cocher la case “Omit recovery options from the BitLocker setup wizard”.
Cocher la case “Save BitLocker recovery information to AD DS”.
Sélectionner “Store recovery passwords and key packages”.
Cocher la case “Do not enable BitLocker until recovery information is stored to AD DS for operating system drive”.
Ces réglages permettent de forcer la sauvegarde de la clé de récupération BitLocker dans l’annuaire Active Directory.
Aller dans Computer configuration | Policies | Administratives Templates | Windows Components | BitLocker Drive Encryption | Fixed Data Drives | Choose how BitLocker-protected fixed drives can be recovered
Activer le paramètre de GPO avec la configuration suivante :
Cocher la case « Allow data recovery agent ».
Sélectionner les paramètres suivants :
“Allow 48-digity recovery password”
“Allow 256-bit recovery key”
Cocher la case “Omit recovery options from the BitLocker setup wizard”.
Cocher la case “Save BitLocker recovery information to AD DS”.
Sélectionner “Store recovery passwords and key packages”.
Cocher la case “Do not enable BitLocker until recovery information is stored to AD DS for operating system drive”.
Ces réglages permettent de forcer la sauvegarde de la clé de récupération BitLocker dans l’annuaire Active Directory.
Aller dans Administratives Templates | Windows Components | BitLocker Drive Encryption | Removable Data Drives | Choose how BitLocker-protected removable drives can be recovered Activer le paramètre de GPO avec la configuration suivante :
Cocher la case « Allow data recovery agent ».
Sélectionner les paramètres suivants :
“Allow 48-digity recovery password”
“Allow 256-bit recovery key”
Cocher la case “Omit recovery options from the BitLocker setup wizard”.
Cocher la case “Save BitLocker recovery information to AD DS for removable data drives”.
Sélectionner “Store recovery passwords and key packages”.
Cocher la case “Do not enable BitLocker until recovery information is stored to AD DS for operating system drive”.
Ces réglages permettent de forcer la sauvegarde de la clé de récupération BitLocker dans l’annuaire Active Directory.
Aller dans Computer configuration | Policies | Administratives Templates | Windows Components | BitLocker Drive Encryption | Fixed Data Drives | Configure use of passwords for fixed data drives
Activer ce paramètre de GPO avec la configuration suivante :
Cocher la case « Require password for fixed data drive ».
Sélectionner « Require password complexity ».
Sélectionner 8 pour le « Minimum password length for fixed data drive ».
Ce paramètre permet de forcer la saisie d’un mot de passe quand on accède à un disque protégé.
Aller dans Administratives Templates | Windows Components | BitLocker Drive Encryption | Removable Data Drives | Control use of BitLocker on removable drives
Activer ce paramètre de GPO avec la configuration suivante :
Cocher la case « Allow users to apply BitLocker protection on removable data drives ».
Cocher la case « Allow users to suspend and decrypt BitLocker protection on removable data drives ».
Les utilisateurs peuvent choisir s’ils activent ou non BitLocker sur les disques amovibles.
Aller dans Computer configuration | Policies | Administratives Templates | Windows Components | BitLocker Drive Encryption | Removable Data Drives | Configure use of passwords for removable data drives
Activer ce paramètre de GPO avec la configuration suivante :
Cocher la case « Require password for removable data drive ».
Sélectionner « Require password complexity ».
Sélectionner 8 pour le « Minimum password length for removable data drive ».
Ce paramètre permet de forcer la saisie d’un mot de passe quand on accède à un disque amovible protégé par BitLocker.
Aller dans Computer configuration | Policies | Administratives Templates | System | Trusted Platform Modules Services | Turn on TPM Backup to Active Directory Domain Services
Activer ce paramètre de GPO avec la configuration suivante :
Ce paramètre permet de forcer la sauvegarde du mot de passe propriétaire du TPM au niveau de l’annuaire Active Directory.

5.2 Définir l’agent de récupération des données chiffrées BitLocker au niveau des stratégies de groupe
Un agent de récupération de données BitLocker permet à un utilisateur disposant d’un certificat « Agent de récupération de données chiffrées avec BitLocker » de déchiffrer un disque système, un disque fixe ou un disque amovible chiffré avec BitLocker. Les disques chiffrés doivent cependant pour cela être connectée à la station de travail et l’utilisateur en charge de la récupération des données doit disposer du certificat Agent de récupération de données BitLocker. La procédure ci-dessous est basée sur la documentation suivante :
http://blogs.technet.com/b/askcore/archive/2010/10/11/how-to-use-bitlocker-data-recovery-agent-to-unlock-bitlocker-protected-drives.aspx
Pour cela, il faut disposer d’un certificat généré avec le modèle de certificat appelé BitLockerDRA-Msreport
Il faut ensuite modifier la GPO « COMPUTER – CERTIFICAT – BITLOCKER ». Aller dans “Computer Configuration | Windows Settings | Security Settings | Public Key Policies | Bitlocker Drive Encryption”.
Importer le fichier CER de l’agent de récupération de données chiffrées BitLocker (admin-pki).

5.3 Configuration d’Active Directory pour autoriser la sauvegarde du mot de passe propriétaire du TPM
Les paramètres ci-dessous ont été définis au niveau de la GPO « COMPUTER – CERTIFICAT – BITLOCKER ».
Exporter le certificat (clé publique uniquement) de l’agent de récupération des données chiffrées avec BitLocker (ADMINPKI).
Ajouter ce certificat au niveau de Computer Configuration | Windows Settings | Security Settings | Public Key Policies | BitLocker Drive Encryption.
Ce paramètre permet de définir un agent de récupération de données chiffrées avec BitLocker.
Importer le fichier CER de l’agent de récupération de données chiffrées BitLocker.

5.4 Ajout des droits dans l’annuaire pour mettre à jour le mot de passe du propriétaire du TPM
Comme expliqué dans l’article Technet http://technet.microsoft.com/fr-fr/library/dd875529(v=ws.10).aspx, il est nécessaire d’utiliser le script Add-TPMSelfWriteACE.vbs pour pouvoir permettre l’enregistrement du mot de passe du propriétaire de TPM dans l’attribut msTPM-OwnerInformation.
Par défaut seuls les utilisateurs membres du groupe « Admins du domaine » ont le droit de visualiser :
– La BitLocker Recovery Key
– LeTrusted Platform Module (TPM) owner password
Il est possible d’utiliser le script Get-TPMOwnerInfo.vbs pour visualiser le Trusted Platform Module (TPM) owner password ou d’utiliser le script Get-BitLockerRecoveryInfo.vbs pour visualiser la BitLocker Recovery Key.
Le code source du script Get-BitLockerRecoveryInfo.vbs sur le site Microsoft est mal formaté.
Sub ShowUsage
Wscript.Echo “USAGE: Get-BitLockerRecoveryInfo [Optional Computer Name]”
Wscript.Echo “If no computer name is specified, the local computer is assumed.”
WScript.Quit
End Sub
Set args = WScript.Arguments
Select Case args.Count
Case 0
‘ Get the name of the local computer
Set objNetwork = CreateObject (“WScript.Network”)
strComputerName = objNetwork.ComputerName
Case 1
If args(0) = “/?” Or args(0) = “-?” Then
ShowUsage
Else
strComputerName = args(0)
End If
Case Else
ShowUsage
End Select
Function HexByte(b)
HexByte = Right(“0” & Hex(b), 2)
End Function
Function ConvertOctetGuidToHexString(ByteArray)
Dim Binary, S
Binary = CStr(ByteArray)
On Error Resume Next
S = “{“
S = S & HexByte(AscB(MidB(Binary, 4, 1)))
S = S & HexByte(AscB(MidB(Binary, 3, 1)))
S = S & HexByte(AscB(MidB(Binary, 2, 1)))
S = S & HexByte(AscB(MidB(Binary, 1, 1)))
S = S & “-“
S = S & HexByte(AscB(MidB(Binary, 6, 1)))
S = S & HexByte(AscB(MidB(Binary, 5, 1)))
S = S & “-“
S = S & HexByte(AscB(MidB(Binary, 8, 1)))
S = S & HexByte(AscB(MidB(Binary, 7, 1)))
S = S & “-“
S = S & HexByte(AscB(MidB(Binary, 9, 1)))
S = S & HexByte(AscB(MidB(Binary, 10, 1)))
S = S & “-“
S = S & HexByte(AscB(MidB(Binary, 11, 1)))
S = S & HexByte(AscB(MidB(Binary, 12, 1)))
S = S & HexByte(AscB(MidB(Binary, 13, 1)))
S = S & HexByte(AscB(MidB(Binary, 14, 1)))
S = S & HexByte(AscB(MidB(Binary, 15, 1)))
S = S & HexByte(AscB(MidB(Binary, 16, 1)))
S = S & “}”
On Error GoTo 0
ConvertOctetGuidToHexString = S
End Function
Function GetStrPathToComputer(strComputerName)
‘ Uses the global catalog to find the computer in the forest
‘ Search also includes deleted computers in the tombstone
Set objRootLDAP = GetObject (“LDAP://rootDSE”)
namingContext = objRootLDAP.Get (“defaultNamingContext”) ‘ e.g. string dc=fabrikam,dc=com
strBase = “”
Set objConnection = CreateObject (“ADODB.Connection”)
Set objCommand = CreateObject (“ADODB.Command”)
objConnection.Provider = “ADsDSOOBject”
objConnection.Open “Active Directory Provider”
Set objCommand.ActiveConnection = objConnection
strFilter = “(&(objectCategory=Computer) (cn=” & strComputerName & “))”
strQuery = strBase & “;” & strFilter & “;distinguishedName;subtree”
objCommand.CommandText = strQuery
objCommand.Properties(“Page Size”) = 100
objCommand.Properties(“Timeout”) = 100
objCommand.Properties(“Cache Results”) = False
‘ Enumerate all objects found.
Set objRecordSet = objCommand.Execute
If objRecordSet.EOF Then
WScript.echo “The computer name ‘” & strComputerName & “‘ cannot be found.”
WScript.Quit 1
End If
Do Until objRecordSet.EOF
dnFound = objRecordSet.Fields (“distinguishedName”)
GetStrPathToComputer = “LDAP://” & dnFound
objRecordSet.MoveNext
Loop
Set objConnection = Nothing
Set objCommand = Nothing
Set objRecordSet = Nothing
End Function
Set objDSO = GetObject(“LDAP:”)
strPathToComputer = GetStrPathToComputer (strComputerName)
WScript.Echo “Accessing object: ” + strPathToComputer
Const ADS_SECURE_AUTHENTICATION = 1
Const ADS_USE_SEALING = 64 ‘0x40
Const ADS_USE_SIGNING = 128 ‘0x80
‘ Get all the recovery information child objects of the computer object
Set objFveInfos = objDSO.OpenDSObject (strPathToComputer, vbNullString, vbNullString, ADS_SECURE_AUTHENTICATION + ADS_USE_SEALING + ADS_USE_SIGNING)
objFveInfos.Filter = Array(“msFVE-RecoveryInformation”)
‘ Iterate through each recovery information object
For Each objFveInfo in objFveInfos
strName = objFveInfo.Get(“name”)
strRecoveryGuidOctet = objFveInfo.Get(“msFVE-RecoveryGuid”)
strRecoveryGuid = ConvertOctetGuidToHexString(strRecoveryGuidOctet)
strRecoveryPassword = objFveInfo.Get(“msFVE-RecoveryPassword”)
WScript.echo “”
WScript.echo “name: ” + strName
WScript.echo “msFVE-RecoveryGuid: ” + strRecoveryGuid
WScript.echo “msFVE-RecoveryPassword: ” + strRecoveryPassword
If len(strRecoveryGuid) <> 38 Then
WScript.echo “WARNING: ‘” & strRecoveryGuid & “‘ does not appear to be a valid GUID.”
End If
Next
WScript.Quit

5.5 Extension du schéma Active Directory
5.5.1 Pourquoi mettre à jour le schéma Active Directory
L’activation de BitLocker échoue sur les stations de travail Windows 8 échoue avec les réglages définies car la sauvegarde du mot de passe administrateur du TPM nécessite une mise à jour du schéma Active Directory.
Après activation du chiffrement BitLocker, au redémarrage, le message d’erreur ci-dessous apparaît :
« Cet objet ne se trouve pas sur le serveur ».
Dans le journal d’événement System de la machine, le message ci-dessous apparaît.
Nom du journal :System
Source : Microsoft-Windows-TPM-WMI
Date : 01/10/2014 11:10:57
ID de l’événement :514
Catégorie de la tâche :Aucun
Niveau : Avertissement
Mots clés :
Utilisateur : SERVICE RÉSEAU
Ordinateur : MSREPORTW81.msreport.local
Description :
Échec de la sauvegarde des informations d’autorisation du propriétaire du module de plateforme sécurisée (TPM) dans les services de domaine Active Directory.
Code d’erreur : 0x80072030
Assurez-vous que votre ordinateur est connecté au domaine. Si votre ordinateur est connecté au domaine, demandez à votre administrateur de domaine de vérifier que le schéma Active Directory est approprié à la sauvegarde des informations d’autorisation du propriétaire du module de plateforme sécurisée (TPM) de Windows 8 et que l’objet Ordinateur actif dispose d’une autorisation d’accès en écriture à l’objet Module de plateforme sécurisée (TPM). Les installations de Windows Server 2008 R2 (ou versions antérieures) nécessitent une extension de schéma pour pouvoir gérer la sauvegarde des informations d’autorisation du propriétaire du module de plateforme sécurisée (TPM) de Windows 8. Pour plus d’informations sur la configuration des services de domaine Active Directory pour le module de plateforme sécurisée (TPM), voir la documentation en ligne.
Il faut mettre à jour le schéma pour Windows 2012 pour pouvoir bénéficier de la sauvegarde du mot de passe de propriétaire du module TPM dans l’annuaire Active Directory avec Windows 8.
“For Windows 8 a change to how the TPM owner authorization value is stored in AD DS was implemented in the AD DS schema. The TPM owner authorization value is now stored in a separate object which is linked to the Computer object. This value was stored as a property in the Computer object itself for the default Windows Server 2008 R2 schemas. Windows Server 2012 domain controllers have the default schema to backup TPM owner authorization information in the separate object. If you are not upgrading your domain controller to Windows Server 2012 you need to extend the schema to support this change. If Active Directory backup of the TPM owner authorization value is enabled in a Windows Server 2008 R2 environment without extending the schema, the TPM provisioning will fail and the TPM will remain in a Not Ready state for computers running Windows 8. There are two schema extensions that you can copy down and add to your AD DS schema:
TpmSchemaExtension.ldf
This schema extension brings parity with the Windows Server 2012 schema. With this change, the TPM owner authorization information is stored in a separate TPM object linked to the corresponding computer object. Only the Computer object that has created the TPM object can update it. This means that any subsequent updates to the TPM objects will not succeed in dual boot scenarios or scenarios where the computer is reimaged resulting in a new AD computer object being created. To support such scenarios, an update to the schema was created.
TpmSchemaExtensionACLChanges.ldf
This schema update modifies the ACLs on the TPM object to be less restrictive so that any subsequent operating system which takes ownership of the computer object can update the owner authorization value in AD DS. However, this is less secure as any computer in the domain can now update the OwnerAuth of the TPM object (although it cannot read the OwnerAuth) and DOS attacks can be made from within the enterprise. The recommended mitigation in such a scenario is to do regular backup of TPM objects and enable auditing to track changes for these objects”.
Pour plus d’information : http://technet.microsoft.com/fr-fr/library/jj592683.aspx

5.5.2 Procédure de mise en œuvre
Les actions suivantes ont été effectuées :
– Télécharger les sources d’installation de Windows 2012 R2 sur un contrôleur de domaine Windows 2008 R2 appelé MSREPORTDCA
– Transférer le rôle de maître de schéma sur MSREPORTDCA et forcer la réplication pour propager le changement.
Ouvrir une session en tant qu’administrateur de l’entreprise sur MSREPORTDCA. Ouvrir une invite de commande et taper la commande suivante : regsvr32 schmmgmt.dll
Créer une MMC vierge et ajouter le composant logiciel enfichable « Schéma Active Directory ».
-Désactiver l’antivirus temps réel.
– Faire une sauvegarde du contrôleur de domaine MSREPORTDCA (Bare metal) avec Windows Server Backup.
– Ouvrir en tant qu’administrateur du schéma.
– Désactiver la réplication entrante et sortante.
repadmin /options MSREPORTDCA +DISABLE_OUTBOUND_REPL
repadmin /options MSREPORTDCA +DISABLE_INBOUND_REPL
Pour plus d’informations, voir : http://support2.microsoft.com/kb/321153/en-us
Lancer adprep /forestprep
Test l’ouverture de session avec un compte utilisateur créé après l’update du schema sur le contrôleur de domaine ROUMER.
Si tout fonctionne correctement, réactiver la replication entrante et sortante
Lancer adprep /domainprep comme expliqué dans l’article :
http://support2.microsoft.com/kb/2737129/en-us
Remettre le rôle FSMO sur le contrôleur de domaine initial.

5.6 Activation de BitLocker sur une station de travail Windows 7
Activer dans le BIOS le composant TPM. Sur les machines Dell, cette option se trouve généralement dans Security | TPM Security. Il faut activer le TPM puis redémarrer la machine.
Ouvrir une session avec un compte administrateur local de la machine. Aller dans le Panneau de Configuration
L’assistant BitLocker va commencer par préparer le TPM.
Au redémarrage (avant démarrage de Windows), le message suivant apparaît.
A request to change the configuration of this computer’s TPM (Trusted Platform Module) is pending….When you have made your selection, press the Enter Key.
Sélectionner le bouton « Modify ». La machine redémarre alors.
Au redémarrage, ouvrir la session avec le compte administrateur local. Le message ci-dessous apparaît automatiquement. Cliquer sur « Start Encrypting » pour démarrer le chiffrement du disque.
Pendant la phase de chiffrement du disque, les stations de travail avec des disques lents seront fortement pénalisées. Il sera recommandé de désactiver l’antivirus temps réel (Kaspersky) pendant cette phase.
Cette action peut aussi être effectuée avec la commande Manage-Bde
Le TPM doit avoir été activé dans le BIOS de la machine.
Lancer un invite de commande avec un compte administrateur local de la machine et entrer la commande suivante :
manage-bde -on C: -RecoveryPassword
Si vous voulez éviter le test matériel du TPM
manage-bde -on C: -RecoveryPassword -SkipHardwareTest
Bien qu’on n’est pas spécifié d’agent de récupération de données BitLocker, ce paramètre s’applique via la GPO comme on peut le voir avec la commande MANAGE-BDE –STATUS.
Pour plus d’informations sur les options de cette commande, taper :
manage-bde -on /?
Si l’attribut msTPM-OwnerInformation est vide (ce cas arrive si le TPM avait déjà été initialisé et donc avoir déjà un mot de passe propriétaire de TPM), lancer la console TPM.MSC et sélectionner « Change Owner Password ».
Entrer l’ancien mot de passe du TPM et finaliser la demande de changement. L’attribut msTPM-OwnerInformation est alors mis à jour.

5.7 Comment récupérer la valeur du mot de passe du TPM
Le script get-TPMOwnerInfo.vbs est disponible à l’adresse suivante :
http://gallery.technet.microsoft.com/ScriptCenter/f75bf414-9fa6-4569-b2c6-e63d57352d3a/
Il renvoie un Hash du mot de passe du propriétaire du TPM.
Pour convertir ce HASH en mot de passe, il faut appliquer la procédure suivante :
http://blogs.technet.com/b/askcore/archive/2010/08/03/how-to-use-hash-of-tpm-from-ad-to-reset-your-tpm-password.aspx
Créer un fichier tpm.tpm et copier le contenu ci-dessous
WBf+tYDp1tPs6nol5jLQ5g3NOOs=
Remplacer la valeur entre les balises par la valeur du Hash du TPM dans l’annuaire.
Lorsque vous souhaitez effectuer une action qui nécessite le mot de passe du propriétaire du TPM, sélectionner le choix « I have the owner password file » et sélectionner le fichier TPM.txt.

A+
Guillaume MATHIEU
Architecte Metsys
La connaissance s’accroît quand on la partage.
http://msreport.free.fr

Publié dans Active Directory, Annuaire, BitLocker, Certificats, EFS, PowerShell, Sécurité, Scripts, Windows 2003 Server, Windows 2012, Windows 2012 R2, Windows Server 2008 R2 | Marqué avec , , , | 3 commentaires

10 retours d’expérience sur ADMT 3.2

Salut à tous.

ADMT est l’outil de Microsoft qui permet de restructurer les annuaires Active Directory (migration des ressources d’un domaine Active Directory A vers un domaine Active Directory B). Cet article a pour but de vous présenter 10 retours d’expérience sur cet outil.
– Comment se former sur ADMT ?
– Est-il possible d’utiliser ADMT 3.2 si on dispose de contrôleurs Windows 2012 R2 dans l’annuaire Active Directory source ou dans l’annuaire cible ?
– Quelle édition de SQL Server dois-je utiliser avec ADMT ?
– Quelle est la valeur ajoutée des commandes ADMT USER, ADMT COMPUTER et ADMT GROUP ?
– Pourquoi est-il nécessaire de sauvegarder le serveur ADMT et comme le sauvegarder ?
– Comment configurer les attributs à migrer avec ADMT ?
– ADMT prend-il en charge la migration des données sur une baie NETAPP ?
– A quoi sert l’option « Translate Roaming profile » au niveau de l’assistant de migration d’un compte utilisateur
– Comment migrer les profils itinérants si les données sont hébergées sur un NAS NETAPP ?
– Pourquoi et comment supprimer le SID History ?

1. Comment se former sur l’outil ADMT ?
Avant de se lancer dans un projet ADMT 3.2, je vous invite par commencer la lecture de documentation officielle disponible à cet emplacement :
http://www.microsoft.com/en-US/download/details.aspx?id=19188
Je vous invite aussi à lire cet article qui contient de nombreux retours d’expérience sur l’outil :
http://blogs.technet.com/b/askds/archive/2010/07/09/admt-3-2-common-installation-issues.aspx

2. Est-il possible d’utiliser ADMT 3.2 si on dispose de contrôleurs Windows 2012 R2 dans l’annuaire Active Directory source ou dans l’annuaire cible ?
La réponse est OUI. Il faut pour cela télécharger la dernière version d’ADMT 3.2 sortie en juin 2014 à cet emplacement :
http://technet.microsoft.com/en-us/library/active-directory-migration-tool-versions-and-supported-environments(v=ws.10).aspx

3. Quelle édition de SQL Server dois-je utiliser avec ADMT ?
La page 19 du guide ADMT indique qu’il est possible d’utiliser n’importe quelle version de SQL Server : “You can use any version of SQL Server for the ADMT database”.
En réalité, c’est beaucoup plus compliqué !
– L’installation d’ADMT 3.0 permet de déployer automatiquement SQL Server Express. Avec ADMT 3.2 cette fonctionnalité a été retirée. C’est donc à l’administrateur de choisir la version de SQL Server à installer. Je vous invite à déployer SQL Server Express Advanced car cette édition est gratuite, permet de disposer d’une base de données de 10 Go maximum (suffisant pour ADMT) et de disposer de l’outil d’administration SQL Server Management Studio. Ce dernier permet de sauvegarder la base ADMT, de visualiser son contenu et/ou de la gérer (reconstruction des index, défragmentation en ligne…).
– SQL Server Express autorise les connexions distantes (depuis des machines distantes). Cependant comme expliqué à la page 54 du guide de déploiement, l’installation d’ADMT ne prend en charge qu’une base de données SQL Express installée sur le serveur ADMT. Cette contrainte ne s’applique pas à SQL Server Standard / Enterprise (version complète payante).
If you use SQL Server Express, the ADMT console must be installed and run locally on the server that hosts the SQL Server Express database instance. If you use a full version of SQL Server, you can install and run the ADMT console on a remote computer, and you can run multiple ADMT consoles on different remote computers”. Ce point est aussi évoqué dans l’article ci-dessous :
http://blogs.technet.com/b/askds/archive/2010/07/09/admt-3-2-common-installation-issues.aspx
– Si vous souhaitez utiliser les commandes ADMT USER, ADMT GROUP et ADMT COMPUTER, il est nécessaire d’installer ADMT sur un contrôleur de domaine ! En effet dans le cas contraire, il ne sera pas possible de migrer le SID History comme expliqué à la page 82 du guide ADMT.
When you start a user migration with SID history from the command line or from a script, you must perform the migration on a domain controller in the target domain. It is recommended that you use a full version of SQL Server when you install ADMT on a domain controller.
Il n’est pas recommandé d’installer SQL Server Express sur un contrôleur de domaine. L’installation d’ADMT refuse l’utilisation d’un serveur SQL Server Express distant. En conséquence, pour utiliser les commandes ADMT USER, ADMT COMPUTER et/ou ADMT GROUP, il est recommandé d’utiliser une base SQL Server complète (version Standard ou Entreprise) sur un serveur A et de déployer ADMT sur un contrôleur de domaine B. Ce dernier devra disposer d’une interface graphique (pas de serveur Core).
Pour plus d’informations sur les différentes éditions de SQL Server :
http://www.microsoft.com/fr-fr/server-cloud/products/sql-server-editions/sql-server-express.aspx
http://msdn.microsoft.com/library/cc645993.aspx

4. Quelle est la valeur ajoutée des commandes ADMT USER, ADMT COMPUTER et ADMT GROUP ?
Ces commandes intègrent les mêmes options que l’interface graphique d’ADMT. Elles permettent cependant :
– D’écrire des scripts de migration avec des actions de pré-migration et de post-migration par exemple.
– A un utilisateur qui ne disposent d’aucun droit dans l’annuaire de lancer les tâches de migration ADMT. Pour effectuer cela, il faut créer des tâches planifiées qui vont lancer les commandes ADMT USER, ADMT GROUP et ADMT COMPUTER dans le contexte du compte de migration ADMT. Pour rappel, le compte de migration ADMT nécessite par défaut des droits Admins du domaine au niveau du domaine source pour migrer le SID History.

5. Pourquoi est-il nécessaire de sauvegarder le serveur ADMT et comment le sauvegarder ?
Lorsque vous migrez un compte utilisateur avec ADMT, une entrée est ajoutée à la base de données ADMT. Cette entrée associe le SID du compte utilisateur du domaine Active Directory source avec le compte utilisateur du domaine Active Directory cible. C’est le même principe pour la migration des comptes ordinateurs et des groupes.
Lorsque les agents ADMT s’exécute sur les machines pour traduire les permissions au niveau des fichiers / clés de registres, ce sont ces entrées qui sont utilisé par ADMT pour déterminer les permissions / ACL qu’ADMT doit ajouter ou remplacer.

Pour sauvegarder le serveur ADMT, il est nécessaire de sauvegarder la base ADMT. Cette action peut être effectuée avec SQL Server Management Studio. Il est aussi possible d’utiliser Windows Server Backup, l’outil intégré de base dans Windows Server 2008 et versions ultérieures. Je vous invite alors à configurer une sauvegarde complète du serveur sur un disque dédié. Cela vous permettra de restaurer très facilement le serveur ADMT en démarrant le serveur depuis le DVD d’installation de Windows Server 2008 ou versions ultérieures et en sélectionnant l’option « Réparer ».

En cas de perte du serveur ADMT, si vous ne disposez pas de sauvegarde de la base ADMT, il est nécessaire de migrer de nouveau toutes les ressources (comptes utilisateurs, groupes et comptes ordinateurs). Il n’est heureusement pas nécessaire de supprimer les ressources (comptes utilisateurs, groupes, comptes ordinateur) dans le domaine Active Directory cible car ADMT autorise la fusion avec un compte utilisateur / groupe ou un comptes ordinateur qui existe déjà.

6. Comment configurer les attributs à migrer avec ADMT ?
ADMT dispose d’une liste d’attribut dit « SYSTEM » exclus par défaut. Il est possible de modifier cette liste à l’aide d’un script fournis par Microsoft disponible à cette adresse :
http://support.microsoft.com/kb/937537/en-us
Attention, il faut utiliser le « CSCRIPT » dans C:\windows\sysWOW64 pour que le script fonctionne sur une machine 64 bits comme Windows Server 2008 R2.
Pour lancer le script (appelé attributsexclus.vbs), taper la commande suivante :
c:\windows\SysWOW64\cscript.exe C:\_adm\AttributsExclus\attributsexclus.vbs
Par défaut, ADMT exclut les attributs suivants de la migration :
– Mail, OtherMailbox, manager
– LegacyExchangeDN, objectSid, sAMAccountName, Rid, pwdLastSet, userPrincipalName, , managedBy, isCriticalSystemObject, legacyExchangeDN, lastLogonTimestamp, dNSHostName, msDS-AuthenticatedAtDC
– Les attributs userPassword et ObjectSID et Member sont migrés de manière spécifique par ADMT.
En cas d’update de schéma, il est nécessaire de mettre à jour la liste des attributs exclus car les nouveaux attributs seront disponibles par défaut comme expliqué à la page 41 du guide ADMT 3.2.
The first time that you run an ADMT user migration, ADMT generates a system attribute exclusion list, which it stores in its database. The system attribute exclusion list contains two attributes by default: mail and proxyAddresses. ADMT also reads the schema in the target domain, and adds any attributes to the list that are not part of the base schema. Attributes in this list are excluded from migration operations even if the attribute is not specified in the attribute exclusion list. An administrator can change the system attribute exclusion list only by using a script. This protects attributes that are important in order for server-based applications, such as Microsoft Exchange, to work. If the target domain schema is further extended after ADMT has generated the list, administrators must manually add the new attributes to the list, unless they are certain that copying the values of these attributes from the source domain will not interfere with server-based applications. For more information about creating a script to exclude system attributes, see article 937537 (http://go.microsoft.com/fwlink/?LinkId=207024) in the Microsoft Knowledge Base.

7. ADMT 3.2 prend-il en charge la migration des données sur une baie NETAPP ?
ADMT 3.2 ne supporte pas la traduction des permissions sur des fichiers hébergés sur un NAS NETAPP comme expliqué dans l’article Microsoft ci-dessous :
http://technet.microsoft.com/en-us/library/cc974389%28v=ws.10%29.aspx
Il est cependant possible de contourner cette limitation avec l’outil SUBINACL. Cet outil peut être téléchargé à cette adresse :
http://www.microsoft.com/en-us/download/confirmation.aspx?id=23510
SUBINACL permet :
– D’afficher les permissions (ACL, DACL, SACL) et le propriétaire d’un fichier, d’une entrée de registre.
– De changer les permissions sur un partage de fichiers (partage SMB).
– De Changer le propriétaire d’un fichier, d’une entrée de registre.
– De Remplacer les permissions sur un fichier ou une entrée de registre
SUBINACL dispose de très nombreux paramètres :
– Changedomain=oldDomainName=NewDomainname : permet de remplacer toutes les permissions d’objet d’un domaine source par un objet du domaine cible.
– Migratetodomain=sourceDomain=DestinationDomain : permet de copier les ACL du domaine source en ACL du domaine cible. Les ACL du domaine source sont conservées.
– Suppresssid=DomainName\account : supprimer les permissions associés à l’objet domainname\ account.
– Replace=[DomainName\]OldAccount=[DomainName\]NewAccount : permet de migrer les permissions d’un objet utilisateur uniquement.
– Cleandeletedsidsfrom : supprime les permissions avec un SID défini.
– Subdirectories C:\TEMP\* : permet d’analyser tous les fichiers dans le dossier et les sous dossiers de c:\Temp.
– Share : permet d’analyser les permissions de partage.
– Subkeyreg : permet d’analyser une clé de registre et tout son contenu (sous-clés ou entrées de registre).
Le mode /changedomain permet de créer un fichier de mappage. Cela permet de gérer le cas où les ressources auraient été renommées dans le domaine cible.

Pour que SUBINACL traduise les permissions de fichier sur une baie NETAPP, il faut :
– Que les deux domaines disposent d’une relation d’approbation.
– Que l’outil SUBINACL soit lancé depuis une machine membre du domaine source.
– Mapper un lecteur réseau vers le partage du NAS NETAPP. Dans l’exemple ci-dessous, ce lecteur aura la lettre Z.
– Mapper le lecteur Z créé précédemment en tant que Y à l’aide de la commande ci-dessous :
Subst Y: Z:\
Le lecteur Y apparaît et est vu comme un lecteur local.
– Lancer la commande suivante :
C:\Program Files\Windows Resource Kits\Tools\subinacl.exe” /subdirectories Z:\PARTAGE\* /migratetodomain=MSREPORTOLD=MSREPORTNEW
Dans l’exemple ci-dessous MSREPORTOLD est le nom du domaine NETBIOS du domaine source, MSREPORTNEW est le nom NETBIOS du domaine cible.

8. A quoi sert l’option « Translate Roaming profile » au niveau de l’assistant de migration d’un compte utilisateur ?
Cette option sert pour les comptes utilisateurs disposant d’un profil itinérant.
Quand on coche cette option, ADMT effectue lors de la migration d’un compte utilisateur les actions suivantes :
– Analyse le champ Profil d’un compte utilisateur. Si ce dernier n’est pas vide, ADMT se connecte sur le dossier réseau.
– ADMT duplique alors les ACL du domaine source en ACL du domaine cible.
– ADMT change le propriétaire du dossier.
– ADMT charge le fichier NTUSER.DAT et modifie les permissions sur les entrées de registre. Il modifie aussi les entrées ProfileImagePath pour associer les profils existants aux comptes utilisateurs du domaine cible.

On retrouve les entrées suivantes dans le fichier de log ADMT.
2014-09-12 13:07:30 Starting Account Replicator.
2014-09-12 13:07:30 CN=Msreportuser1 – Created
2014-09-12 13:07:31 CN=Msreportuser1 – Strong password generated.
2014-09-12 13:07:31 WRN1:7874 Disabled the “password never expires” account option for account ‘CN=Msreportuser1’.
2014-09-12 13:07:45 Processing \\DC2003B\C$\Profiles\Msreportuser1.v2
2014-09-12 13:07:45 Updated user rights for CN=Msreportuser1
2014-09-12 13:07:45 Operation completed.

9. Comment migrer les profils itinérants si les données sont hébergées sur une baie NETAPP ?
Deux solutions :
– Le contournement. Migrer la machine de l’utilisateur et son compte utilisateur dans le domaine cible. Renommer le dossier correspondant à la copie du profil itinérant de l’utilisateur sur le NAS NETAPP. Recréer uniquement un dossier vide sur le NAS NETAPP. Demander à l’utilisateur d’ouvrir sa session. Lors de l’ouverture de la session, les données sont recopiées vers le partage sur le NAS NETAPP. Attention, cela peut s’avérer très couteux en bande passante !
– La prise de tête : il faut utiliser la commande SUBINACL pour traduire les permissions sur les fichiers et modifier manuellement les permissions sur les entrées de registre et modifier les entrées ProfileImagePath dans le fichier NTUSER.DAT pour réassocier les utilisateurs avec le bon dossier profil.

10. Pourquoi et comment supprimer le SID History ?
Lorsque l’utilisateur ouvre une session, Windows génère un TGT avec les SID / SID History du compte utilisateur et de tous les groupes auxquels l’utilisateur appartient directement ou indirectement (utilisateur membre du groupe A qui est membre du groupe B qui est membre du groupe C).
Hors la limite maximum est de 1014 SID par TGT après modification de la clé MaxTokenSize. Je vous invite à lire cet article Microsoft qui traite du problème :
http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-and-kerberos-token-bloat.aspx

Il n’est pas possible de supprimer le SID History avec l’outil ADMT ou via ADSIEDIT.MSC. Pour effectuer cette action, il faut :
– Télécharger les outils ADFIND et ADMOD et les installer dans le dossier c:\_adm\tools sur le serveur ADMT. Ils sont disponibles à ces adresses :
http://www.joeware.net/freetools/tools/adfind/
http://www.joeware.net/freetools/tools/admod/
– Lancer PowerShell et taper la commande suivante pour supprimer le SID History pour l’utilisateur Guillaume MATHIEU
C:\_adm\tools\adfind -b “CN=Guillaume MATHIEU,OU=USERS,OU=IT,DC=MSREPORT,DC=LAN” sidhistory -adcsv | .\AdMod.exe -sc csh –unsafe

A+
Guillaume MATHIEU
Architecte Metsys
La connaissance s’accroît quand on la partage.
http://msreport.free.fr

Publié dans Active Directory, ADMT, Annuaire, Outils, Scripts, Troubleshouting, Windows 2003 Server, Windows 2012, Windows 2012 R2, Windows Server 2008, Windows Server 2008 R2 | Marqué avec , , | Laisser un commentaire