Téléchargez DFSRMon V1.1.0 

 Il manquait à DFSR un outil graphique permettant de monitorer en temps réel l'état de la réplication entre les différents serveurs, particulièrement des éléments tels que:

-          Le niveau de convergence d’un membre par rapport à ses partenaires de réplication, c'est-à-dire le nombre d’éléments modifiés ou créés sur ces derniers et qui lui restent à récupérer.

-          L'état d'avancement d'une réplication initiale, c'est-à-dire le nombre d'éléments restant à répliquer à un membre avant qu'il n’ait terminé sa phase de synchronisation initiale.

-          Le nombre d’éléments modifiés sur chaque membre et qui n’ont pas encore été récupérés par ses partenaires de réplication (c'est ce que l'on appelle le backlog).

-          La taille courante des répertoires du staging area et Conflicts&Deleted associés aux différents répertoires répliqués des membres.

-          Les modifications réalisées sur les répertoires répliqués au fur et à mesure qu'elles apparaissent (afin de détecter d’éventuelles modifications intempestives pouvant survenir sur un membre).

Pour combler ce manque, voici DFSRMon, un outil que notre stagiaire Fabien Gautier a développé pendant les stages qu'il a réalisé au sein des équipes support et PFE de Microsoft France.

DFSRMon se présente ainsi:

N'hésitez pas à poster en commentaire ce que vous pensez de cet outil ainsi que toute demande d'améliorations ou de nouvelles fonctionnalités.

Pré-requis:

Le .Net Framework doit être préalablement installé sur le poste sur lequel on désire exécuter DFSRMon. Il est automatiquement inclus à Windows Server 2003R2, il est donc possible de l'exécuter directement à partir de cette version et sur les versions de Windows suivantes.

Il est possible de récupérer la version 3.5 SP1 du .net Framework à l'adresse suivante:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ab99342f-5d1a-413d-8319-81da479ab0d7

Utilisation:

DFSRMon peut être exécuté à partir de n'importe quel membre du domaine (workstation ou serveur). Il est préférable de l'exécuter sur un poste dédié plutôt que sur les serveurs DFSR ou les contrôleurs de domaine afin de ne pas leur induire une charge supplémentaire. Il peut monitorer toutes les versions de DFSR (Windows Server 2003R2, Windows Server 2008 et Windows Server 2008R2).

Une fois lancé, cliquer sur "Connect" pour afficher la liste des groupes de réplication existant dans le domaine dans lequel la session a été ouverte. Il est aussi possible de sélectionner un domaine différent avec un compte et un mot de passe associé en cliquant sur "Change Domain credentials".

Sélectionner un de ses groupes de réplication pour afficher ses membres et leurs caractéristiques dans le tableau « Members of Replication Group ».

Les différentes colonnes de ce tableau sont les suivantes:

-          Member Name: Nom du membre.

-          Updates to be received for the selected replication group: Nombre d’éléments qui restent à répliquer par le membre de tous ses partenaires de réplication pour tous les répertoires répliqués du groupe de réplication sélectionné.
Cette colonne est particulièrement utile pour les réplications initiales car elle  permet de contrôler en temps réel le nombre d’éléments restant à répliquer par le membre avant qu'elle ne soit achevée.
Elle permet aussi de visualiser en un coup d’œil l’état de convergence de la réplication entrante de chacun des membres pour le groupe de réplication sélectionné.

A noter que cette information est liée au cycle de réplication en cours, c'est-à-dire pendant la période où le schedule est ouvert. Les valeurs affichées ne sont donc valables que vis-à-vis des partenaires de réplication avec lesquels le schedule est ouvert. Lorsque des schedules avec des partenaires de réplication sont fermés, leur nombre est affiché entre parenthèse avec l'indication (partners not connected).  Pour connaitre le backlog des partenaires avec lesquels le schedule est fermé, voir la colonne "Backlog" détaillée plus bas.

-          Updates to be received for all replication groups :  Nombre d’éléments qui restent à répliquer par le membre de tous ses partenaires de réplication pour tous les répertoires répliqués de tous les groupes de réplication auxquels il appartient.
Cette colonne permet de d’obtenir l’état de la convergence globale du serveur, tous groupes de réplication confondus.
Comme la colonne précédente, cette information est liée au cycle de réplication en cours, c'est-à-dire pendant la période où le schedule est ouvert. Les valeurs affichées ne sont donc valables que vis-à-vis des partenaires de réplication avec lesquels le schedule est ouvert. Lorsque des schedules avec des partenaires de réplication sont fermés, leur nombre est affiché entre parenthèse avec l'indication (partners not connected).  Pour connaitre le backlog des partenaires avec lesquels le schedule est fermé, voir la colonne "Backlog" détaillée plus bas.

-          Group with the most updtaes: Nom du groupe de réplication pour lequel le membre sélectionné possède le plus de mise à jour à récupérer de ses partenaires de réplication. Dans le cas ou le membre sélectionné appartient à de nombreux groupes de réplication, cette colonne permet de visualiser vis-à-vis duquel il est le plus en retard.

-          RPC Port assignment : Port sur lequel le service DFSR du membre sélectionné est en écoute.

-          Debug Log File Path: Répertoire contenant les fichiers de log de DFSR.

-          Max Debug Log Files: Nombre maximum de fichiers de log DFSR.

-          Max Debug Log Messages: Nombre maximal d’enregistrements que DFSR peut enregistrer par fichier de log.

-          Replication Debug Log Severity: Niveau d’information enregistré par DFSR dans ses fichiers de log.

-          Enable Light DS Polling: Indique si DFSR effectue une interrogation rapide de l’Active Directory  pour récupérer d'éventuels changements de sa configuration, des groupes de réplication et des répertoires répliqués.

-          DS Polling Interval in Min: Intervalle au bout duquel DFSR va interroger un DC pour récupérer d’éventuels changements de sa configuration, des groupes de réplication et des répertoires répliqués.

-          Last Change Time: Date de dernière modification de la configuration DFSR.

-          Member GUID: GUID associé au membre par DFSR.

Un clic droit sur un membre affiche un menu contextuel avec l'option "Poll AD" qui permet de déclencher l'interrogation de l'AD de la part du membre sélectionné afin de récupérer d'éventuelles modifications.

En sélectionnant un membre dans la première colonne du tableau précédent, ses répertoires répliqués appartenant au groupe de réplication sélectionné sont affichés dans le tableau du bas.

Les différentes colonnes de ce tableau sont les suivantes :

-          Replicated Folder Name: Nom du répertoire répliqué.

-          Version for replicated folder volume: Cette colonne affiche la version courante des modifications réalisées sur le membre sélectionné. A chaque opération réalisée sur un répertoire répliqué (créations, modifications du contenu ou suppression d’un fichier ou d’un répertoire), DFSR incrémente son  numéro de version. C’est ce numéro qu’il communique à ses partenaire de réplication afin qu’ils évaluent les d’éléments à répliquer. 
Cette information est particulièrement utile pour  détecter d’éventuelles modifications intempestives apparaissant sur un volume.

A noter que  DFSR partage des numéros de versions pour tous les répertoires répliqués stockés sur le même volume. Un bond de la version d’un répertoire répliqué (par exemple de 100 à 1000) peut être lié à 900 modifications réalisées sur un autre répertoire répliqué situé sur le même volume.

-          Root Path: Racine du répertoire répliqué sur le membre sélectionné.

-          Membership status: Etat du membre sélectionné pour le répertoire répliqué.

-          Current Staging Size in Mb: Taille actuelle du répertoire du staging area du répertoire répliqué sur le membre sélectionné.

-          Staging Quota: Taille maximale que peut posséder le staging area du répertoire répliqué sur le membre sélectionné.

-          Staging Path: Path vers le répertoire du Staging Area du répertoire répliqué sur le membre sélectionné.

-          Current Conflict Size In MB: Taille actuelle du répertoire Conflicts&Deleted du répertoire répliqué sur le membre sélectionné.

-          Last Conflict Cleanup Time: Date à laquelle le répertoire Conflicts&Deteted à été ramené à son quota (Conflict Low Watermark Percent) sur le membre sélectionné.

-          Conflict Path: Path vers le répertoire Conflicts&Deleted du répertoire répliqué sur le membre sélectionné.

-          Enabled: Indique si la réplication du répertoire répliqué est activée sur le membre sélectionné.

-          File Filter: Filtres positionné sur les fichiers du répertoire répliqué du membre sélectionné.

-          Directory Filter: Filtres positionné sur les sous répertoires du répertoire répliqué du membre sélectionné.

-          Description: Description du répertoire répliqué sur le membre sélectionné.

-          Is Primary: Indicateur si le membre sélectionné est configuré en tant que primaire lors de la réplication initiale du répertoire répliqué.

-          Database GUID: Guid affecté par DFSR à la base associée au volume sur lequel est situé le répertoire répliqué du membre sélectionné.

-          Replicated Folder GUID: Guid affecté par DFSR au répertoire répliqué.

Lorsque l’on sélectionne un répertoire répliqué dans la première colonne de ce tableau, tous ses partenaires de réplication s’affichent dans un tableau à droite avec le nombre d’éléments modifiés sur le membre sélectionné qu’ils n’ont pas encore récupéré. C’est ce que l’on appelle le backlog.
Cette information est particulièrement utile pour visualiser en temps réel l’évolution du backlog que possède le serveur sélectionné vis-à-vis de chacun de ses partenaires de réplication.

A noter qu’il est nécessaire que la version du membre sélectionné ait été récupérée pour que le tableau soit affiché. Tant que la colonne correspondante n'est pas renseignée, le tableau ne sera pas affiché.

Un clic droit sur un partenaire de réplication dans le tableau de droite affiche un menu contextuel avec les options:

Ø "Force replication" qui permet de forcer la réplication du partenaire répliqué en ouvrant artificiellement son schedule pendant une heure.

Ø "Stop replication" qui permet de bloquer la réplication du partenaire sélectionné en fermant artificiellement son schedule pendant une heure.

Le rafrachissement des informations:

Par défaut, l’intervalle de rafraichissement des différents éléments est fixé à 600 secondes (10 minutes). Il est possible de modifier cette valeur en la saisissant dans la boite « Refresh Interval ». Il est possible de le positionner à zéro pour un rafraichissement en continu

Lorsque DFSRMon récupère des informations, son activité est affichée dans la fenêtre d'état en haut à droite de l'écran.  A noter que les temps de récupération d’information peuvent être assez long. Il est fortement conseillé de ne pas cliquer sur les différents éléments affichés tant que l’activité indiquée n’est pas “Idle”.

Didier Gautier

Principal PFE – Microsoft France

Configuration d’une autorité de certification

Cet article est une présentation de la configuration d’une autorité de certification (CA) dans l’objectif de délivrer des certificats pour une plateforme RDS. La configuration d’une telle plateforme fait l’objet d’un autre billet, posté par un de mes collègues.

http://blogs.technet.com/b/windowsinternals/archive/2012/01/30/remoteapp-comment-faire-du-sso-avec-remote-desktop-service-2008-r2.aspx

La préparation de son article a mis en évidence le besoin de détailler au préalable la configuration de la CA pour être en mesure de délivrer les certificats nécessaires.

Autorité de certification

En cryptographie, l'Autorité de certification (AC ou CA) a pour mission, après vérification de l'identité du demandeur du certificat par une autorité d'enregistrement, de signer, émettre et maintenir

• Les certificats (CSR : Certificate Signing Request)
• Les listes de révocation (CRL : Certificate Revocation List)

Sur le plan technique, cette infrastructure de gestion des clés permet ainsi d'assurer que

• Les données transmises n'ont pas été modifiées durant le transfert : intégrité par hachage des données
• Les données proviennent bien de l'émetteur connu : utilisation de clés et répudiation

La clé de chiffrement-déchiffrement est identique lors d'algorithmes symétriques dits à clef secrète (connue de l'émetteur et du destinataire) et différentes lors d'algorithmes asymétriques dits à clé publique (publique pour tout le monde, privée personnelle gardée secrètes). Les clés en jeu sont celles de l'émetteur et du destinataire.

Microsoft propose un rôle de serveur de certificat sur les versions serveur de Windows.

Certificate Revocation List Distribution Point (CDP)

Les listes de révocation contiennent les références des certificats que l'administrateur a révoqués. Elles ne contiennent pas les certificats expirés. Cette information est indispensable pour vérifier la validité d'un certificat. Chaque CA publie une CRL, qu'elle signe (avec sa clé privée donc).

Deux types de CRL existent. Les CRLs complètes, qui reprennent tous les certificats révoqués, et les delta CRLs qui ne contiennent que les certificats révoqués depuis la dernière publication de CRL complète. La fréquence de publication des secondes est supérieure à celle des premières.

Dans certains cas, l'utilisation de certificat privé par des clients sur Internet, il peut être nécessaire de rajouter un CDP public (ie accessible depuis Internet).

Pour cela, allons dans la console "Certification Authority" et ouvrons les propriétés de la CA.

Exemple d'extension CRL Distribution Point à ajouter :

http://MyPublicWebServer.myCompany.com/CerEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Ce CDP doit être inscrit dans les certificats émis et dans les CRL émises.

Il faudra ensuite mettre en place un mécanisme qui recopie la CRL depuis la CA (c:\windows\system32\certSrv\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl) vers ce serveur web.

Authority Information Access (AIA)

Basiquement, il s'agit de l'emplacement où trouver le certificat de l'autorité de certification. Elle permet de télécharger le certificat pour construire la chaîne de publication, en cas d'architecture à plusieurs niveaux, et de comparer le certificat de la CA racine avec ceux présents dans le magasin de confiance.

En cas de client sur Internet, il faut également publier les informations de la CA de manière publique. C'est la seconde extension qu'il faut modifier de la même façon

AIA à ajouter :

_.crt">http://MyPublicWebServer.myCompany.com/CerEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

Comme pour le CDP, ce fichier (c:\windows\system32\certSrv\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt) devra être copié depuis la CA vers le serveur web publique.

Modèles de certificat

Microsoft propose des modèles de certificat pour les rôles les plus courants de certificats. Ceux-ci peuvent d'ailleurs être personnalisé pour les adapter à chaque besoin (durée de vie, contenu, protection des clés, …).

Les modèles de certificat existent dans toute Active Directory, mais seules les autorités de certification installée sur une version entreprise de Windows peuvent les prendre en charge.

En fait de personnalisation de modèle de certificat, c'est la duplication d'un modèle existant que l'on réaliser et on personnalise le nouveau modèle.

Exemple avec la personnalisation du modèle Web Server pour créer un modèle adapté à une architecture RDS par exemple. Etant donné que le même certificat doit être installé à plusieurs endroits, il faut pouvoir en exporter la clé privée. Voici comment procéder.

Première étape, ouvrons la console "Certificate Templates" et dupliquons le modèle Web Server.

Il nous fait au moins un modèle Windows Server 2003 Enterprise.

Appelons ce modèle "RDS Server"

Et marquons la clé privée comme exportable.

(La sécurité à mettre en œuvre au niveau de l’autorité de certififcation et au niveau du modèle est détaillée dans le paragraphe “Permissions”, plus loin dans cet article.)

Il faut maintenant rendre ce modèle disponible. Pour cela, allons dans la console "Certification Authority" et publions un nouveau modèle.

Clés exportables

Nous venons de modifier le modèle de certificat pour autoriser l'export des clés privées. Par défaut cela est désactivé, pour éviter de la mettre en danger. Une clé privée est générée sur la machine qui fait la demande et est associé au certificat une fois celui-ci émis. La clé privée est associée à la machine et n'a pas de raison d'être ailleurs.

Dans certains cas, il est nécessaire d'exporter cette clé. Soit pour des raisons de sécurité (sauvegarde du certificat et de sa clé, en parallèle de la sauvegarde de la machine) ou de fonctionnalité (utilisation d'un même nom pour plusieurs machines). C'est ce second scénario qui est suivi quand on construit une ferme de serveur IIS par exemple (utilisation d'un même nom DNS pour plusieurs adresses IP par exemple). Dans ce cas, le même certificat doit être présent sur plusieurs machines.

Il faut alors demander un certificat avec le nom "virtuel", partagé par toutes les machines depuis un des nœuds, exporter le certificat et la clé privée, puis l'importer sur les autres nœuds de la ferme.

Voici, par exemple, comment exporter le certificat depuis le magasin de certificat utilisateur et l'importer dans le magasin de certificats machine. C'est la même logique pour une copie entre machine.

Tout d'abord, ouvrir une console MMC et charger deux fois le composant certificat, une fois pour la machine, une fois pour l'utilisateur. Ensuite, depuis le magasin personnel de l'utilisateur, exporter le certificat avec sa clé privée.

L'option d'exporter la clé privée ne sera disponible que si elle est exportable. Cela se définit dans le modèle, comme vu plus haut, ou au moment de l'import, comme nous verrons plus bas.

Il faut ensuite l'importer dans le magasin de l'ordinateur.

A cette étape également on peut marquer la clé privée comme exportable

Attention ! Bien qu'il soit possible de faire un glisser-déplacer du certificat d'un magasin vers un autre, cela ne déplace pas la clé privée. Il en résulte un certificat dans le magasin machine, mais une clé privée dans le magasin utilisateur. Comme l'utilisateur affichant la console aura accès aux deux, il verra que la clé privée est bien accessible, mais en pratique, elle ne le sera pas par la machine.

Voici les informations d'un certificat déplacé. Dans un premier temps récupéré dans le contexte de l'utilisateur.

C:\>certutil –verifystore my
================ Certificate 3 ================
Serial Number: 14890a70000000000005
Issuer: CN=vpcw2k3ca, DC=vpcw2k3, DC=local
Subject: CN=Administrator, CN=Users, DC=vpcw2k3, DC=local
Certificate Template Name: EFSRecovery
Non-root Certificate
Template: EFSRecovery, EFS Recovery Agent
Cert Hash(sha1): 4d e5 b3 2e c7 94 2d 23 31 27 cb 3f 55 fa 0b 92 e9 c6 0e 6e
Key Container = d6d60d2163c8e2970602738b1de8c5fa_5f5cc49c-de6b-442e-a698-c10048765884
Provider = Microsoft Base Cryptographic Provider v1.0
Encryption test passed
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.4.1.311.10.3.4.1 File Recovery
Certificate is valid
CertUtil: -verifystore command completed successfully.

Voici les informations d'un certificat déplacé. Dans un premier temps récupéré dans le contexte machine.

C:\>certutil –verifystore my
================ Certificate 3 ================
Serial Number: 14890a70000000000005
Issuer: CN=vpcw2k3ca, DC=vpcw2k3, DC=local
Subject: CN=Administrator, CN=Users, DC=vpcw2k3, DC=local
Certificate Template Name: EFSRecovery
Non-root Certificate
Template: EFSRecovery, EFS Recovery Agent
Cert Hash(sha1): 4d e5 b3 2e c7 94 2d 23 31 27 cb 3f 55 fa 0b 92 e9 c6 0e 6e
Key Container = d6d60d2163c8e2970602738b1de8c5fa_5f5cc49c-de6b-442e-a698-c10048765884
Provider = Microsoft Base Cryptographic Provider v1.0
No stored keyset property
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.4.1.311.10.3.4.1 File Recovery
Certificate is valid
CertUtil: -verifystore command completed successfully.

Subject Alternative Name

Il peut parfois être nécessaire d'avoir plusieurs noms dans un même certificat. Par exemple quand deux noms différents peuvent être utilisés pour accéder à la même machine. Imaginons le cas particulier d'un serveur web accédé depuis l'intranet avec un nom du type webserver.mycompany.intra et depuis l'extérieur avec un nom du type www.mycompany.com. Il faudra alors mettre ces deux noms dans le certificat. Pour cela, on va utiliser un champ supplémentaire nommé "Subject Alternative Name".

Il faut donc configurer l'autorité de certification pour activer cette extension, puis, dans la demande, remplir ce champ. La configuration de la CA se fait en ligne de commande, cette opération n'est à réaliser qu'une seule fois et est décrite dans l'article technique suivant

931351 How to add a Subject Alternative Name to a secure LDAP certificate
http://support.microsoft.com/default.aspx?scid=kb;EN-US;931351

C:\>certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
C:\>net stop certsvc
C:\>net start certsvc

Nous verrons plus loin, dans la partie demande de certificat comment renseigner ce champ.

Les méthodes de demande de certificat

Pour demander un certificat, plusieurs pré-requis sont nécessaires.

• Le contexte de sécurité utilisé pour faire la demande, doit avoir le droit de demander un certificat à la CA.
• Le contexte de sécurité utilisé pour faire la demande, doit avoir le droit de demander un certificat du modèle souhaité.

Permissions

Sur la CA, les permissions se consultent dans la console Certification authority, dans les propriétés de la CA, onglet security.

Pour le modèle de certificat, c'est dans les propriétés du modèle de certificat, onglet sécurité.

Authenticated users incluant les machines et les utilisateurs, c'est la façon la plus simple de permettre la distribution de certificat à tout le monde.

Par la console certificat

Cette demande utilise le contexte de sécurité de la machine. Il faut donc que le compte ordinateur ait le droit de demander des certificats à la CA, et ait le droit de demander des certificats des modèles désirés.

Sur le serveur, on démarre une mmc (démarrer / exécuter / mmc.exe) puis on charge le composant logiciel enfichable certificat pour le compte ordinateur. Dans la console ainsi ouverte, on effectue une demande de certificat à partir du magasin personnel.

On utilise alors le modèle RDS Server et on spécifie les noms à insérer dans le certificat. Le champ Subject Name est assez explicite, le champ Alternative name servira à alimenter l'extension Subject Alternative name du certificat.

Par la page web

Si vous avez installé le rôle Certification Authority Web Enrollment, vous pouvez réaliser cette même demande depuis la page web. Par défaut, celle-ci est accessible via http://<serveur>/certsrv

Depuis la page d'accueil, on sélectionne "Request a certificate" puis "Submit an advanced certificate request" et enfin "Create and submit a request to this CA"

On choisit le modèle de certificat désiré (ici RDS Server). Dans le champ Name, on saisit le subject Name. Dans le champ Attributes de la section Additionnal Options, on saisit

san:dns=<DNS name> [&dns=<DNS name>]

Cette opération, réalisée dans le contexte de sécurité de l'utilisateur, crée la clé privée et le certificat dans le magasin utilisateur. Il convient donc suivre la procédure décrite au paragraphe "Clés exportables" pour les copier dans le magasin de l'ordinateur.

En ligne de commande

Dans un fichier texte, on va définir les informations nécessaires à la demande de certificat.

Pour mon exemple, voici le fichier request.inf

[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=vpcw2k8r2pdc.vpcw2k8r2.local"
Exportable = TRUE
KeyLength = 2048
KeySpec = 1 ; Key Exchange
KeyUsage = 0xA0 ; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[RequestAttributes]
CertificateTemplate = RDSServer
SAN="dns=RDSFarm.vpcw2k8r2.local"

Ensuite, en utilisant l'outil certreq.exe, cette demande va être convertie en un format binaire.

C:\temp>certreq.exe -new request.inf request.req
Active Directory Enrollment Policy
{6EC1EAFF-EC09-47AD-A2D4-31391828E67A}
ldap:
DumpVariantStringWorker: 0: "Microsoft RSA SChannel Cryptographic Provider"
DumpVariantStringWorker: 1: "Microsoft DH SChannel Cryptographic Provide

Il est ensuite à soumettre à l'autorité de certification

C:\temp>certreq.exe -submit request.req request.cer
Active Directory Enrollment Policy
{6EC1EAFF-EC09-47AD-A2D4-31391828E67A}
ldap:

Il vous sera demandé quelle autorité de certification solliciter

RequestId: 12
RequestId: "12"
Certificate retrieved(Issued) Issued

Enfin, il faut enfin insérer le certificat reçu dans le magasin de la machine

C:\temp>certreq -accept request.cer

Le certificat est désormais présent dans le magasin Personal de l'ordinateur et sa clé privée est exportable.

Par la console IIS

Si la console IIS est installée sur le serveur il est possible de l'utiliser pour demander un certificat. Celle-ci est cependant limitée au sens où elle ne permet que de demander des certificats de type WebServer, impose de remplir tous les champs et ne donne pas accès au champ Subject Alternative Name. Par contre, la clé privée générée est exportable.

La virtualisation étant de plus en plus répandue et simple à mettre en place, il est important de valider et respecter certains pré-requis pour éviter de mettre en production un DC potentiellement dangereux pour votre environnement.

Le but de cet article est de partager des règles de base à respecter lors de la mise en place d’un DC dans un environnement virtuel.

1- Support de l’environnement de virtualisation

Microsoft met gratuitement en ligne un petit assistant permettant de vérifier la supportabilité des différents environnements virtuels en 3 étapes:

http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpwizard.htm

Par exemple : Est-ce que mon DC virtuel Windows Server 2000 SP4 est supporté sur Hyper-V ?

Etape 1 : Le choix du produit

Dans la liste des produits disponibles, on ne retrouve pas « active directory » puisque c’est un « rôle » que l’os peut posséder au même titre que les services DNS, DHCP, etc.

Je choisi donc Windows 2000 version SP4.

Etape 2 : Le choix du « Host » et du « guest »

Dans cette étape, nous devons choisir la technologie de virtualisation communément appelé le « host » et la version d’OS du client communément appelé le « guest ».

Pour notre exemple, je choisie donc un « host » de type hyper-V et un « guest » Windows 2000 SP4 x86.

Etape 3 : Le résultat

Dans la partie « Summary Support Statement » vous trouverez le résultat de votre requête :

Pour notre exemple de DC Windows 2000 sous hyper-v, notre configuration est bel et bien supportée.

2- Les recommandations

Les contrôleurs de domaines font parti des serveurs critiques d’un environnement de production. Pour éviter des heures de dépannage inutiles sur des problèmes pouvant allez jusqu’à une corruption d’une forêt entière, il est fortement recommandé de respecter certains points.

Prévoir de garder quelques contrôleurs de domaine physiques

- Il est recommandé, dans la mesure du possible, de garder 1 ou 2 DC physique, pour éviter qu’un souci qui toucherait le logiciel de virtualisation, rendre indisponible un domaine voir une forêt entière.

Attention à la sécurité du host

- Les comptes ayant les droits d’administration locale d'un serveur qui héberge les DCs virtuels, doivent avoir la même politique de sécurité que les comptes administrateur de domaine/forêt.

- Les fichiers VHD sont équivalents aux disques physiques d’un serveur. Il est donc important que seul les gens habilités ait accès aux fichiers.

Service de temps

- Pour tous les DCs virtuels sans exception, il faut désactiver la synchronisation de temps avec le host dans les options d’intégrations. Ce paramètre entre en conflit avec le mécanisme de synchronisation de temps de la forêt : W32Time. Des arrêts de production majeurs ont déjà été répertoriés au support suite à une simple maintenance hardware de la machine host provoquant un retour arrière de plus d’un an de la date du bios et donc de tous les DCs hébergé sur celle-ci…

Sauvegarde

- Les sauvegarde et restauration de domaine contrôleurs virtuels doivent être réalisés à l’identique des serveurs physiques : « système » + « système state ». Les backups/restaures de VHD sont totalement proscrits et non supporté aux même titre que les snapshots, les disques diférentiels ou autre logiciel de type Norton Ghost.

Eléments à BANIR !

- Ne jamais utiliser les outils de snapshots ou de disques différentiels sur un domaine contrôleur virtuel. Un retour arrière sur un DC vous générera au minimum un problème d’USN rollback !

- Ne jamais cloner une machine virtuelle sans avoir effectué au préalable un sysprep. Une duplication sans sysprep n’est d’ailleurs pas supportée ref: http://support.microsoft.com/kb/162001. Il ne faut pas cloner un contrôleur de domaine, seules les machines en workgroup peuvent être clonées.

- Il n’est pas supporté d’utiliser la fonctionnalité Hyper-V « export » pour exporter une machine virtuelle de type domaine contrôleur.

Vous pouvez retrouver les explications détaillées de ces différentes recommandations dans les articles suivants :

Running Domain Controllers in Hyper-V
http://technet.microsoft.com/en-us/library/dd363553(WS.10).aspx

Considerations when hosting Active Directory domain controller in virtual hosting environments
http://support.microsoft.com/kb/888794

Pour terminer, vous pouvez consulter le site TechNet « Virtualization TechCenter » entièrement dédié à la virtualisation :

http://technet.microsoft.com/en-us/virtualization/default.aspx

Marc Bouchard

Lsass est le module qui traite toute la sécurité de Windows. Entre autre les demandes d'authentification, la gestion de l'Active Directory, de la réplication, etc.

Lsass.exe est souvent la "victime" d'un autre processus générant un très grand nombre de requêtes LSA. Cela peut être des demandes d'authentification, des recherches de site, de serveur, l'évaluation des groupes d'un utilisateur, la traduction de nom d'utilisateur (vers un SID par exemple), ...

La première étape consiste à vérifier si l'activité Lsass est causée par des sollicitations réseau ou si elles sont causées par une activité interne. Pour cela, le test consiste à débrancher le câble réseau ou à désactiver la carte réseau (attention aux logiciels de prises de main à distance) pendant une dizaine de seconde. Si l'activité baisse à partir de ce moment-là, il faut se concentrer sur les requêtes réseau. Autrement, il faut se concentrer sur l'activité locale.

Origine réseau

Une trace réseau pendant une durée significative (une à cinq minutes) permettra d'obtenir une idée précise des requêtes adressées au contrôleur de domaine. Il faut ensuite analyser la trace pour identifier quel type de trafic est le plus important, s'il provient d'une machine identifiée ou de tout type d'ordinateur. Des exemples de 100% CPU causé par le réseau sont des demandes d'énumération des groupes par un applicatif, des accès massif à un partage, des requêtes LDAP très complexe ne pouvant tirer parti des index en place (en particulier avec des filtres contenant des chaînes partielles en utilisant des wildcards).

Il convient alors de vérifier en fonction du type de trafic et de son origine quel composant ou application en est à l'origine et déterminer s'il est normal ou pas.

Origine locale

Plusieurs actions complémentaires sont possibles : suivre les performances des modules exploitant lsass.exe (annuaire ldap, authentification, réplication, …) et capturer l'image de l'exécution du processus lsass.exe,

Performance

Pour cela, lancez le moniteur de performance avec les compteurs suivants :

• L’objet thread avec les compteurs  % Temps processeur  et ajouter toutes les instances LSASS et ID Thread.
• L’objet Process avec le compteur lsass avec toutes les instances LSASS
• L’objet Processeur avec le compteur % Temps processeur et %Temps Utilisateur avec l’option toutes les instances sélectionné
• L’objet NTDS avec les compteurs : DRA Inbound Bytes Total/sec, DRA Inbound Object Updates Remaining in Packet, DRA Outbound Bytes Total/sec, DRA Pending Replication Synchronizations, Kerberos Authentications/sec, NTLM Authentications, LDAP Bind Time, LDAP Successful Binds/sec, LDAP Client Sessions, LDAP Searches/sec

Pour votre information voici quelques détails sur les compteurs NTDS :

• DRA Inbound Bytes Total/sec : Nombre d'octets reçus par secondes résultants de réplications entrantes (somme des données compressées et non compressées).
• DRA Inbound Object Updates Remaining in Packet : Nombre d'octets reçus de réplications entrantes qui n'ont pas été enregistrés dans la base. Indique que le serveur reçoit des réplications entrantes mais est trop chargé pour les appliquer rapidement.
• DRA Outbound Bytes Total/sec : Nombre d'octets émis par secondes résultants de réplications sortantes (somme des données compressées et non compressées).
• DRA Pending Replication Synchronizations : Nombre de réplications mises en queue en attente d'être effectuées (réplication backuplog). Revient à ce qui est affiché par repadmin/queue.
• Kerberos Authentications/sec : Nombre d'authentifications par secondes par dessus Kerberos effectuées par secondes.
• NTLM Authentications : Nombre d'authentifications par secondes par dessus NTLM effectuées par secondes.
• LDAP Bind Time : Temps en millisecondes nécessaire pour effectuer un bind à l'AD.
• LDAP Successful Binds/sec : Nombre de binds LDAP par seconde gérés par le serveur.
• LDAP Client Sessions : Nombre de sessions LDAP courantes gérées par le serveur.
• LDAP Searches/sec : Nombre de recherches LDAP effectuées par secondes

Vous pouvez également utiliser le "Performance Monitor Wizard" disponible sur le site web Microsoft. Il permet de configurer l'analyseur de performance facilement. (http://www.microsoft.com/downloads/details.aspx?FamilyID=31FCCD98-C3A1-4644-9622-FAA046D69214&displaylang=en)

Image du processus

Pour cela, il faut installer les Debugging Tools for Windows disponibles sur le site web Microsoft à l'adresse
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx

Ensuite, via le script AdPlus.vbs (installé par défaut dans \Program Files\Dubugging tools for Windows), générez plusieurs dump du processus lsass à l'aide de la commande
   cscript adplus.vbs -hang -pn lsass.exe -r <nombre de snapshot> <intervalle en secondes>
L'idéal étant d'avoir au moins 3 dumps à 1mn d'écart.

Exemple
   Cscript adplus.vbs -hang -pn lsass.exe -r 3 30

Un dossier sera alors créé :
   Hang_Mode__Date_01-16-2009__Time_15-36-2525
avec, entre autre le fichier
   PID-436__LSASS.EXE__full_0650_2009-01-16_15-47-12-110_01b4.dmp

L'analyse de ces dumps est assez complexe, mais une première vérification peut être faite.

Avec WinDBg, ouvrez le fichier PID-436__LSASS.EXE__full_0650_2009-01-16_15-47-12-110_01b4.dmp (File, Open Crash Dump...). Il faut ensuite configurer les symboles pour pouvoir interpréter son contenu. Cela se fait via la commande
   .sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
le dossier c:\symbols sera utilisé pour mettre en cache les fichiers téléchargés.

Exécutez ensuite la commande !runaway. Cela vous affiche, par ordre croissant de temps d 'activité chacun des thread de lsass.exe

Exemple :
   0:000> !runaway
   User Mode Time
   Thread Time
   40:40c 0 days 0:00:00.110
   35:2fc 0 days 0:00:00.090
   32:2d8 0 days 0:00:00.080
   49:608 0 days 0:00:00.070
   51:658 0 days 0:00:00.060
   30:2cc 0 days 0:00:00.060

Identifiez le ou les threads les plus consommateurs et, pour chacun, exécuter la commande.
   ~<thread>k

Vous aurez ainsi la pile d'appel de fonction et donc le ou les modules en cours d'exécution. Ainsi que les éventuels modules tierces chargés.

Ces manipulations permettent une première analyse et l'identification de suspect. Pour une analyse plus avancée, il sera nécessaire d'ouvrir un incident auprès de votre support Windows.

Cyrille de Pardieu

Définir la taille du “staging area” d’un dossier répliqué n’est pas une chose évidente à calculer.

Elle dépend de plusieurs paramètres, comme la volumétrie , taille des fichiers, le nombre de modifications effectués à ses éléments, le planning de réplication.

Néanmoins, nous pouvons tenir compte des valeurs générales suivantes pour définir la taille du Staging Area d’un dossier répliqué (en fonction des versions).

Ces valeurs sont toutefois à titre indicatif et à adapter à votre architecture.

Augmenter la taille du staging pour être au minimum égale aux :

• 9 plus volumineux fichiers sur Windows Server 2003 R2.
• 32 plus volumineux fichiers sur Windows Server 2008 - 2008 R2 (dossier répliqué en Read-Write).
• 16 plus volumineux fichiers sur Windows Server 2008 R2 (dossier répliqué en READ-ONLY).

Il est possible de trouver ceci avec la commande DIR :

Par ex : “Dir /o-s” pour lister les fichiers par taille

Ou “Dir /o-s /s” pour avoir l’ensemble des sous-dossiers.

Mais ceci n’est pas très clair et simple …

Pour avoir une liste complète ( dossier et sous dossiers) classés par taille, vous pouvez plutôt utiliser une comande Powershell afin de déterminer les fichiers les plus volumineux.

1/ Activer le composant Windows Powershell si ce n’est pas déjà fait :

2/ Saisir la commande suivante :

Get-ChildItem C:\data1 -recurse | Sort-Object length -descending  | select-object -first 32 | ft directory,name,length -wrap –auto

où :

C:\data1 est le chemin du dossier, et 32 est le nombre d’éléments que vous souhaitez lister.

Tous les éléments du dossier et des sous-dossiers sont listés et classés par taille :

Vous pouvez ainsi connaitre la taille des fichiers les plus volumineux et déterminer la taille du dossier adéquate.

Liens complémentaires :

Edit the Quota Size of the Staging Folder and Conflict and Deleted Folder

http://technet.microsoft.com/en-us/library/cc754229(WS.10).aspx

Staging folders and Conflict and Deleted folders

http://technet.microsoft.com/en-us/library/cc782648(WS.10).aspx

Staging Folder Guidelines for DFS Replication

http://blogs.technet.com/filecab/archive/2006/03/20/422544.aspx

Joseph Besançon
Domain & Security Team