Comme l’a déjà détaillé Christophe Jourdan dans ce billet, il est nécessaire de créer et d’attribuer un certificat à chaque serveur situé dans un domaine non approuvé ou dans un workgroup/DMZ et que l’on souhaite monitorer à l’aide de SCOM .

Cependant, cette tâche peut s’avérer fastidieuse et répétitive si elle concerne un nombre important de serveurs… Il est possible de contourner le problème en faisant appel à des serveurs Gateway, mais cette solution n’est pertinente que si les serveurs à monitorer se trouvent majoritairement dans le même domaine distant.

Dans le cas où il s’agit de serveurs répartis dans de nombreux domaines différents, ou principalement situés en Workgroup ou en DMZ, cette solution du serveur Gateway ne présente pas d’avantage particulier puisqu’il faudra toujours générer un certificat par serveur à monitorer.

Heureusement, l’équipe de développement de SCOM a mis à disposition deux outils bien utiles pour automatiser en grande partie ce procédé : CertGenWizard et CertInstaller, réunis dans le package certgenbinaries.

CertGenWizard permet de requêter votre Autorité de Certification (CA) pour demander en une seule fois la création des certificats pour la liste de serveurs que vous lui indiquerez, puis les télécharge et les enregistre dans le dossier de votre choix. Il récupère également le certificat d’autorité racine (Root CA).

CertInstaller permet quant à lui d’automatiser l’installation des certificats machine et root CA dans le magasin de certificats du serveur à monitorer, ainsi que de les inscrire dans la configuration SCOM à l’aide de MOMCertImport automatiquement.

Aperçu de leur utilisation :

Pré-requis:

-.NET Framework 3.0

-Une autorité de certification (Win2K3/Win2K8 Enterprise/Stand-alone CA)

-S’il s’agit d’une CA Entreprise, un template OpsMgr doit être créé (cf. http://blogs.technet.com/b/ptsblog/archive/2011/12/28/monitoring-machines-using-certificates-with-system-center-operations-manager-2007-r2-part-1.aspx )

– createReqFile.bat doit rester dans le même dossier que CertGenWizard.exe

–Copier le MOMCertImport.exe correspondant à votre version de SCOM (2007/R2/2012) ainsi qu’aux serveurs visés (32 ou 64bit) depuis votre media d’installation de SCOM (dossier SUPPORTTOOLS) dans le même dossier que CertInstaller.exe.

–Attention, CertInstaller ne fonctionne pas sous Windows XP et ne pourra donc pas être utilisé si les machines que vous souhaitez superviser utilisent encore ce système !

Génération des certificats:

1. Télécharger l’archive zip de l’outil et la décompresser.

2. Lancer CertGenWizard.exe et cliquer sur Next.

3. Indiquer si l’Autorité de Certification est présente sur le serveur qui exécute l’outil (Search this computer) ou si elle se trouve sur un autre serveur (Search the network). Dans ce second cas, indiquer son nom et son domaine dans les champs CA name et CA host name.
Cliquer sur Next.

4. Indiquer la liste des serveurs à superviser hors-domaine (un seul par ligne) dans la liste Computers ainsi que le dossier où stocker les certificats dans Certificate Destination Folder.
Cliquer sur Create.

5. Après quelques secondes, l’outil confirme la création des demandes de certificat auprès de l’Autorité de Certification et demande de les y approuver :

6. Ouvrir la console « Autorité de Certification », dossier « Pending Requests ». Sélectionner les demandes de certificat en attente et faire Clic-droit > Issue :

7. Revenir à l’outil CertGenWizard et cliquer sur Retrieve. Les certificats sont copiés dans le dossier préalablement indiqué. Une fenêtre de résumé s’affiche, indiquant les certificats générés et copiés. Cocher Open folder to view certificates puis cliquer sur Close.

8. LE dossier contenant les certificats pour chacun des serveurs à monitorer s’ouvre. Il contient également le certificat racine Root Certificate, qui servira aussi sur chacun des serveurs à monitorer.

Import des certificats sur les serveurs cible:

Réaliser cette étape à la main (import du certificat racine et du certificat machine puis exécution de MOMCertImport) peut s’avérer tout aussi fastidieux que de créer les certificats à la main.

L’outil CertInstaller, fourni dans le package, permet heureusement de simplifier également ce processus.

Attention : l’agent SCOM doit être installé avant de réaliser cette opération !

1. Sur chaque serveur à monitorer, copier dans le même dossier le certificat machine généré à l’étape précédente correspondant ainsi que le certificat racine RootCertificate. Copier également l’outil CertInstaller.exe présent dans le package et l’exécutable MOMCertImport disponible sur le media d’installation de SCOM correspondant à la plateforme à monitorer (x86 ou x64).

2. Sur le serveur à monitorer, lancer CertInstaller. Sélectionner le certificat machine dans le champ Machine Certificate et le certificat racine dans le champ Root CA Certificate. Cliquer sur Install.

Voilà, c’est terminé. Vous pouvez vérifier que les certificats sont bien importés en ouvrant le magasin de certificat du serveur à monitorer.

S’il n’y a pas d’autre problème, le serveur doit remonter dans SCOM au bout de quelques minutes.

Nous allons voir comment effectuer une recherche sur un objet utilisateur dans Active Directory à l’aide du SamAccountName. Et ainsi avoir accès aux propriétés du compte.

Tout d’abord on initialise une variable contenant la connexion à un contrôleur de domaine avec les éléments d’identification.

$dc= New-Object system.directoryservices.directoryEntry(‘LDAP://192.168.1.1′,’login’,’mdp’)

Ensuite on initialise notre variable de recherche.

$Search_DC=New-Object system.directoryservices.directorysearcher($dc)

Nous allons maintenant rechercher l’utilisateur ayant pour SamAccountName “alphonse.dupuit”

$Search_DC.filter="(&(objectClass=user)(samaccountname=alphonse.dupuit))"

On affiche le résultat.

$search.findone()

On peut maintenant afficher et donc récupérer les différentes propriétés de l’objet utilisateur.

($search.findone()).properties

Nous pouvons également accéder a ces informations en utilisant d’autres méthodes :ajout de module tel que Active-Directory, Quest, etc..

Exemple avec les cmdlets Quest

Ajout des cmdlets Quest au shell :

Add-PSSnapin Quest.ActiveRoles.ADManagement

initialisation de variables pour identification

$U="login"
$PU="mdp"
$D=convertto-securestring -string $pu -AsPlainText –force (mot de passe crypté)

Connexion au contrôleur de domaine

Connect-QADService 192.168.1.1 –ConnectionAccount $U -ConnectionPassword $D

Recherche de l’utilisateur cedrick.vaccard

Get-qaduser cedrick.vaccard

On peut désormais accéder et récupérer les propriétés de l’utilisateur

Get-qaduser cedrick.vaccard |fl

Introduction

Si l’on pouvait autrefois dire qu’il n’était pas possible de cloner un contrôleur de domaine a moins de vouloir voir son infrastructure Active Directory comprise, on ne peut plus dire la même la chose aujourd’hui.

En effet, avec la génération 2012 de Windows Server apporte le support des contrôleurs de domaine virtualisé (on parlera alors de vDC). Ce support donc comprend la tolérance aux snapshots ainsi qu’au clone de contrôleur de domaine.

Dans ce billet, nous attarderons donc sur la procédure à suivre pour cloner un contrôleur de domaine.

Fonctionnement

Il faut tout d’abord savoir que cette opération nécessite un niveau de forêt en Windows Server 2012 ainsi qu’une préparation au préalable.

Lors de cette préparation, un fichier de configuration au format XML, sera généré dans C:\Windows\NTDS.

Au redémarrage du contrôleur de domaine va donc lire le contenu du fichier de configuration et s’adaptera pour s’ajouter en tant que contrôleur de domaine supplémentaire.

Dans les informations de configuration, il est possible de changer le nom de la machine, de modifier sa configuration IP ou encore de spécifier un site Active Directory.

En cas d’incohérence, le contrôleur de domaine démarrera en mode de restauration.

Enfin, il faut savoir que le clone de contrôleur virtuel ne supporte pas tous les services et fonctionnalité pouvant être ajouté à Windows Server (par exemple la fonctionnalité SNMP). Si des applications non supportées sont présentes, la génération du fichier de configuration ne sera pas permise à moins qu’une exclusion définie.

Mise en place

Le clonage d’un contrôleur doit être effectué dans l’ordre suivant :

Ajout des permissions Active Directory

Ajouter le contrôleur de domaine qui servira de base pour le clonage dans le groupe « Cloneable Domain Controllers »

Contrôle de conformité

Puis, sur ce contrôleur de domaine, réalisez la commande Get-ADDCCloningExcludeApplicationList pour obtenir la liste des services et application non supportée par le clonage.

Les résultats affichés doivent être désinstallé ou placé dans un fichier d’exception pouvant être généré automatiquement grave à l’argument –GenerateXML de la commande précédente.

Le fichier d’exclusion sera alors généré dans le répertoire NTDS.

Génération du fichier de configuration

Puis générez le fichier de configuration de clonage à l’aide de la commande New-ADDCCloningConfigFile.

Il est possible de définir de nouveaux paramètres grâce à l’argument –Static et des configurations configurations éditables :

· Pour un nouveau nom de machine, employez l’argument –CloneComputerName

· Pour une nouvelle configuration IP, employez les arguments –Ipv4Address, -IPv4DNSResolver, -IPv4DefaultGateway.

· Pour que le nouveau contrôleur de domaine intègre un autre site Active Directory, utilisez l’argument –Site.

Clonage de la machine virtuelle

Pour finir l’opération, clonez votre machine virtuelle par l’intermédiaire de vos outils de gestion d’hyperviseurs, déplacez là si nécessaire et enfin allumez là. Votre contrôleur de domaine adaptera alors sa configuration pour ne pas causer de conflit dans votre forêt Active Directory.