Authentification et chiffrement des données dans Operations Manager

System Center Operations Manager se compose de fonctionnalités telles que le serveur d’administration, le serveur de passerelle, le serveur de rapports, le serveur de rapports, la base de données opérationnelle, l’entrepôt de données de création de rapports, l’agent, la console web et la console Opérateur. Cet article explique comment l’authentification est effectuée et identifie les canaux de connexion où les données sont chiffrées.

Authentification basée sur un certificat

Lorsqu’un agent Operations Manager et un serveur d’administration sont séparés par une forêt non approuvée ou une limite de groupe de travail, l’authentification basée sur un certificat doit être implémentée. 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.

Configurer la communication entre les agents et les serveurs d’administration dans la même limite 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.

Configurer la communication entre les agents et les serveurs d’administration entre 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’existe aucune 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 au sein de chaque domaine se produit toujours.

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.

Configurer la communication entre un domaine – Limite de 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 à l’aide du 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.

Remarque

Dans ce scénario, l'agent doit être installé manuellement.

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 :

1. Demandez les certificats à l'autorité de certification.
2. Approuvez les demandes de certificat au niveau de l'autorité de certification.
3. Installez les certificats approuvés dans les magasins de certificats de l'ordinateur.
4. Utilisez l’outil MOMCertImport pour configurer Operations Manager.

Remarque

Les certificats avec KEYSPEC autre que 1 ne sont pas pris en charge.

Il s’agit des mêmes étapes pour installer des certificats sur un serveur de passerelle, sauf que vous n’installez pas ou exécutez l’outil d’approbation de passerelle

Confirmer l’installation du certificat

Si vous avez correctement installé le certificat, l’événement suivant est écrit dans le journal des événements Operations Manager.

Type	Source	ID événement	Général
Information	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.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings

Attention

Une modification incorrecte du Registre peut sérieusement endommager votre système. Avant toute modification du registre, il est conseillé de sauvegarder toutes les données importantes de votre ordinateur.

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. Le serveur de passerelle envoie le message chiffré au serveur d’administration où le serveur d’administration 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 nécessaire.

Serveur d’administration et console Opérateur, serveur de console web et serveur de création 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 s’effectue à l’aide de la technologie Windows Communication Foundation (WCF). 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 à l’aide de 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é en fonction du 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 SQL Server Reporting 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ôt de données reporting

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 reporting et le serveur d’administration sont séparés par une limite d’approbation (par exemple, chacun réside dans des domaines différents sans approbation), l’authentification intégrée Windows 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

1. Profil d'identification : compte d'entrepôt de données

   • Compte d’identification : Action d’entrepôt de données
   • Informations d’identification du compte : compte d’enregistreur de données (spécifié lors de l’installation)

2. Profil d'identification : compte d'authentification SQL Server de l'entrepôt de données

   • Compte d’identification : Authentification SQL Server data Warehouse
   • Informations d’identification du compte : compte spécial créé par Operations Manager (ne changez pas)

Facultatif : authentification SQL Server

1. Profil d’identification : compte d’authentification SQL Server Data Warehouse
   • Compte d’identification : compte d’identification que vous avez spécifié lors de l’installation.
   • Informations d’identification du compte : compte que vous avez spécifié lors de l’installation.

Le service System Center Data Access et l’entrepôt de données Reporting

Par défaut, le service System Center Data Access, qui est chargé de lire des données à partir de l’entrepôt de données de création de rapports et de le rendre disponible dans la zone paramètres de rapport, obtient l’authentification intégrée Windows en s’exécutant en tant que service d’accès aux données et compte de service de configuration qui a été défini lors de l’installation d’Operations Manager.

Si l’entrepôt de données reporting et le serveur d’administration sont séparés par une limite d’approbation (par exemple, chacun réside dans des domaines différents sans approbation), l’authentification intégrée Windows ne fonctionne 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. N’apportez jamais de modifications au compte associé au profil d’identification, au compte d’authentification SQL Server du Kit de développement logiciel (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

1. 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 du compte : compte spécial créé par Operations Manager (ne changez pas)

2. Facultatif : authentification SQL Server

   • Profil d'identification : compte d'authentification SQL Server de l'entrepôt de données
   • Compte d’identification : compte d’identification que vous avez spécifié lors de l’installation.
   • Informations d’identification du compte : compte que vous avez spécifié lors de l’installation.

Console Opérateur et serveur de création de rapports

La console Opérateur se connecte au serveur de rapports sur le port 80 en utilisant HTTP. L’authentification est effectuée à l’aide de l’authentification Windows. Les données peuvent être chiffrées par l'utilisation du canal SSL.

Serveur de rapports et entrepôt de données de création 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 devez apporter la même modification de mot de passe à l’aide du Gestionnaire de configuration de Reporting Services dans SQL Server. Les données entre le serveur de rapports et l’entrepôt de données reporting ne sont pas chiffrées.