Authentification et chiffrement des données pour les ordinateurs Windows
S'applique à: System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager
System Center 2012 – Operations Manager comprend des fonctionnalités telles que le serveur d'administration, le serveur de passerelle, le serveur de rapports, la base de données opérationnelle, l'entrepôt de données de rapports, l'agent, la console Web et la console Opérateur. Cette section explique comment se fait l'authentification et identifie les canaux de connexion dans lesquels les données sont chiffrées.
Authentification basée sur un certificat
Lorsqu'un agent Operations Manager et le serveur d'administration sont séparés par une forêt non approuvée ou une limite de groupe de travail, il est nécessaire d'implémenter une authentification basée sur un certificat. Les sections suivantes donnent des informations sur ces situations ainsi que les procédures spécifiques pour l'obtention et l'installation de certificats à partir d'autorités de certification Windows.
Établissement de la communication entre les agents et les serveurs d'administration dans les mêmes limites d'approbation
Un agent et le serveur d'administration utilisent l'authentification Windows pour s'authentifier mutuellement avant que le serveur d'administration n'accepte des données de l'agent. Le protocole Kerberos version 5 constitue la méthode par défaut pour fournir l'authentification. Pour que l'authentification mutuelle Kerberos fonctionne, il est nécessaire d'installer les agents et le serveur d'administration dans un domaine Active Directory. Si un agent et un serveur d'administration sont dans des domaines séparés, une approbation totale doit exister entre les domaines. Dans ce scénario, lorsque l'authentification mutuelle a eu lieu, le canal de données entre l'agent et le serveur d'administration est chiffré. Aucune intervention de l'utilisateur n'est requise pour réaliser l'authentification et le chiffrage.
Établissement de la communication entre les agents et les serveurs d'administration en franchissant les limites d'approbation
Un ou plusieurs agents pourraient être déployés dans un domaine (domaine B) séparé du serveur d'administration (domaine A), et il n'existerait pas d'approbation bidirectionnelle entre les domaines. Étant donné qu'il n'y a pas d'approbation entre les deux domaines, les agents d'un domaine ne peuvent pas s'authentifier auprès du serveur d'administration dans l'autre domaine à l'aide du protocole Kerberos. L'authentification mutuelle entre les fonctionnalités Operations Manager se produit toujours au sein de chaque domaine.
Une solution à cette situation consiste à installer un serveur de passerelle dans le domaine dans lequel résident les agents, puis à installer des certificats sur le serveur de passerelle et sur le serveur d'administration pour obtenir une authentification mutuelle et un chiffrement des données. L'utilisation du serveur de passerelle signifie que vous avez besoin d'un seul certificat dans le domaine B et d'un seul port à travers le pare-feu, comme représenté dans l'illustration suivante.
.jpeg "Approbation inter-domaines")
Établissement de la communication à travers un domaine – Limite du groupe de travail
Dans votre environnement, vous pouvez avoir un ou deux agents déployés dans un groupe de travail à l'intérieur de votre pare-feu. L'agent du groupe de travail ne peut pas s'authentifier auprès du serveur d'administration dans le domaine utilisant le protocole Kerberos. Une solution à cette situation consiste à installer des certificats sur l'ordinateur qui héberge l'agent et sur le serveur d'administration auquel celui-ci se connecte, comme représenté dans l'illustration suivante.
Notes
Dans ce scénario, l'agent doit être installé manuellement.
.jpeg "Approbation entre domaine et groupe de travail")
Procédez comme suit sur l'ordinateur qui héberge l'agent et le serveur d'administration en utilisant la même autorité de certification (CA) pour chacun :
Demandez les certificats à l'autorité de certification.
Approuvez les demandes de certificat au niveau de l'autorité de certification.
Installez les certificats approuvés dans les magasins de certificats de l'ordinateur.
Utilisez l'outil MOMCertImport pour configurer Operations Manager.
Il s'agit de la même procédure que pour installer des certificats sur un serveur de passerelle, à l'exception du fait que vous n'installez pas ou n'exécutez pas l'outil d'approbation de la passerelle.
Confirmer l'installation du certificat
Si vous avez correctement installé le certificat, l'événement suivant est consigné dans le journal des événements d'Operations Manager.
Type |
Source |
ID de l'événement |
Général |
|---|---|---|---|
Informations |
Connecteur OpsMgr |
20053 |
Le connecteur OpsMgr a chargé avec succès le certificat d'authentification spécifié. |
Pendant l'installation d'un certificat, vous exécutez l'outil MOMCertImport. Lorsque l'outil MOMCertImport a terminé, le numéro de série du certificat que vous avez importé est consigné dans la sous-clé de Registre suivante.
.jpeg "System_CAPS_caution"){kind=icon} Attention |
|---|
Une modification incorrecte du Registre peut endommager gravement votre système. Avant de modifier le registre, vous devez sauvegarder toutes les données importantes sur l'ordinateur. |
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings
Authentification et chiffrement des données entre le serveur d'administration, le serveur de passerelle et les agents
La communication entre ces fonctionnalités d'Operations Manager commence avec l'authentification mutuelle. Si des certificats sont présents des deux côtés du canal de communications, ils seront utilisés pour l'authentification mutuelle ; sinon, le protocole Kerberos version 5 est utilisé. Si deux fonctionnalités sont séparées à travers un domaine non approuvé, l'authentification mutuelle doit être effectuée à l'aide de certificats.
Les communications normales, comme les événements, les alertes et le déploiement d'un pack d'administration, s'effectuent sur ce canal. L'illustration précédente présente un exemple d'une alerte générée sur l'un des agents qui est acheminée vers le serveur d'administration. Entre l'agent et le serveur de passerelle, le package de sécurité Kerberos est utilisé pour chiffrer les données car le serveur de passerelle et l'agent se trouvent dans le même domaine. L'alerte est déchiffrée par le serveur de passerelle puis de nouveau chiffrée en utilisant les certificats du serveur d'administration. Une fois l'alerte reçue par le serveur d'administration, celui-ci déchiffre le message, le rechiffre en utilisant le protocole Kerberos puis l'envoie au serveur d'administration où ce dernier déchiffre l'alerte.
Une partie de la communication entre le serveur d'administration et l'agent peut comprendre des informations d'identification, par exemple des données et des tâches de configuration. Le canal de données entre l'agent et le serveur d'administration ajoute une autre couche de chiffrage en plus du chiffrage normal du canal. Aucune intervention de l'utilisateur n'est requise.
Serveur d'administration et console Opérateur, serveur de console Web et serveur de rapports
L'authentification et le chiffrement des données entre le serveur d'administration et la console Opérateur, le serveur de console Web ou le serveur de rapports sont effectués à l'aide de la technologie WCF (Windows Communication Foundation). La tentative initiale d'authentification est effectuée en utilisant les informations d'identification de l'utilisateur. Le protocole Kerberos est essayé en premier. Si le protocole Kerberos ne fonctionne pas, une autre tentative est effectuée en utilisant NTLM. Si l'authentification échoue toujours, l'utilisateur est invité à fournir des informations d'identification. Une fois l'authentification effectuée, le flux de données est chiffré selon le protocole Kerberos, ou SSL si NTLM est utilisé.
Dans le cas d'un serveur de rapports et d'un serveur d'administration, une fois l'authentification effectuée, une connexion de données est établie entre le serveur d'administration et le serveur de rapports SQL Server. Cela est accompli en utilisant strictement le protocole Kerberos ; par conséquent, le serveur d'administration racine et le serveur de rapports doivent résider dans des domaines approuvés. Pour plus d'informations sur WCF, consultez l'article MSDN Présentation de Windows Communication Foundation.
Serveur d'administration et entrepôts de données de rapports
Deux canaux de communication existent entre un serveur d'administration et l'entrepôt de données de rapports :
Le processus hôte d'analyse généré par le service de contrôle d'intégrité (service System Center Management) dans un serveur d'administration
Les services d'accès aux données System Center dans le serveur d'administration
Processus hôte d'analyse et entrepôt de données de rapports
Par défaut, le processus hôte d'analyse généré par le service de contrôle d'intégrité, qui est chargé de consigner les événements collectés et les compteurs de performances dans le magasin de données, obtient l'authentification Windows intégrée en s'exécutant en tant que compte d'enregistreur de données, lequel a été spécifié pendant l'installation de Reporting. Les informations d'identification du compte sont stockées de façon sûre dans un compte d'identification intitulé Compte d'action d'entrepôt de données. Ce compte d'identification est membre d’un profil d'identification appelé Compte d'entrepôt de données (qui est associé aux règles de collecte réelles).
Si l'entrepôt de données de rapports et le serveur d'administration sont séparés par une limite d'approbation (par exemple s'ils résident dans des domaines différents sans approbation), l'authentification Windows intégrée ne fonctionnera pas. Pour contourner cette situation, le processus hôte d'analyse peut se connecter à l'entrepôt de données de rapports en utilisant l'authentification SQL Server. Pour cela, créez un nouveau compte d'identification (du type compte simple) avec les informations d'identification du compte SQL et faites-en un membre du profil d'identification appelé Compte d'authentification SQL Server de l'entrepôt de données, avec le serveur d'administration comme ordinateur cible.
Important
Par défaut, le profil d'identification, dénommé Compte d'authentification SQL Server de l'entrepôt de données, a reçu un compte spécial via l'utilisation du compte d'identification du même nom. Ne modifiez jamais le compte associé au profil d'identification dénommé Compte d'authentification SQL Server de l'entrepôt de données. Créez plutôt votre propre compte et votre propre compte d'identification et faites de ce dernier un membre du profil d'identification dénommé Compte d'authentification SQL Server de l'entrepôt de données lors de la configuration de l'authentification SQL Server.
Le texte qui suit décrit les relations des diverses informations d'identification de comptes, comptes d'identification et profils d'identification pour l'authentification Windows intégrée et l'authentification SQL Server.
Par défaut : authentification Windows intégrée
Profil d'identification : compte d'entrepôt de données
Compte d'identification : compte d'action d'entrepôt de données
Informations d'identification : compte d'enregistreur de données (spécifié pendant l'installation)
Profil d'identification : compte d'authentification SQL Server de l'entrepôt de données
Compte d'identification : compte d'authentification SQL Server de l'entrepôt de données
Informations d'identification : compte spécial créé par Operations Manager (ne pas modifier)
Facultatif : authentification SQL Server
Profil d'identification : compte d'authentification SQL Server de l'entrepôt de données
Compte d'identification : un compte d'identification que vous créez.
Informations d'identification : un compte que vous créez.
Le service d'accès aux données System Center et l'entrepôt de données de rapports
Par défaut, le service d'accès aux données System Center, qui est chargé de lire les données de l'entrepôt de données de rapports et de les rendre accessibles dans la zone Paramètre de rapport, obtient l'authentification Windows intégrée en s'exécutant en tant que service d'accès aux données et compte de service de configuration, lequel a été défini pendant l'installation d'Operations Manager.
Si l'entrepôt de données de rapports et le serveur d'administration sont séparés par une limite d'approbation (si, par exemple, ils résident dans des domaines différents sans approbation), l'authentification Windows intégrée ne fonctionnera pas. Pour contourner cette situation, le service d'accès aux données System Center peut se connecter à l'entrepôt de données de rapports en utilisant l'authentification SQL Server. Pour cela, créez un nouveau compte d'identification (du type compte simple) avec les informations d'identification du compte SQL et faites-en un membre du profil d'identification appelé Compte d'authentification SQL Server du SDK Reporting, avec le serveur d'administration comme ordinateur cible.
Important
Par défaut, le profil d'identification, dénommé Compte d'authentification SQL Server du SDK Reporting a reçu un compte spécial via l'utilisation du compte d'identification du même nom. Ne modifiez jamais le compte associé au profil d'identification dénommé Compte d'authentification SQL Server du SDK Reporting. Créez plutôt votre propre compte et votre propre compte d'identification et faites de ce dernier un membre du profil d'identification dénommé Compte d'authentification SQL Server du SDK Reporting lors de la configuration de l'authentification SQL Server.
Le texte qui suit décrit les relations des diverses informations d'identification de comptes, comptes d'identification et profils d'identification pour l'authentification Windows intégrée et l'authentification SQL Server.
Par défaut : authentification Windows intégrée
Service d'accès aux données et compte de service de configuration (défini pendant l'installation d'Operations Manager)
Profil d'identification : compte d'authentification SQL Server du SDK Reporting
Compte d'identification : compte d'authentification SQL Server du SDK Reporting
Informations d'identification : compte spécial créé par Operations Manager (ne pas modifier)
Facultatif : authentification SQL Server
Profil d'identification : compte d'authentification SQL Server de l'entrepôt de données
Compte d'identification : un compte d'identification que vous créez.
Informations d'identification : un compte que vous créez.
Console Opérateur et serveur de rapports
La console Opérateur se connecte au serveur de rapports sur le port 80 en utilisant HTTP. L'authentification est effectuée en utilisant l'authentification Windows. Les données peuvent être chiffrées par l'utilisation du canal SSL. Pour plus d'informations sur l'utilisation de SSL entre la console Opérateur et le serveur de rapports, consultez Comment faire pour configurer la Console d'opérations pour utiliser SSL lors de la connexion à un serveur de rapports.
Serveur de rapports et entrepôt de données de rapports
L'authentification entre le serveur de rapports et l'entrepôt de données de rapports est effectuée en utilisant l'authentification Windows. Le compte qui avait été spécifié comme compte de lecteur de données pendant l'installation de l'application de rapports devient le compte d'exécution sur le serveur de rapports. Si le mot de passe du compte doit changer, vous devrez modifier le mot de passe de la même façon à l'aide du Gestionnaire de configuration de Reporting Services dans SQL Server. Pour plus d'informations sur la réinitialisation de ce mot de passe, consultez Comment faire pour modifier le mot de passe du compte de l'exécution du serveur Reporting. Les données entre le serveur de rapports et l'entrepôt de données de rapports ne sont pas chiffrées.