Informations de préinstallation pour AD RMS (Active Directory Rights Management Services)

Avant d'installer Active Directory Rights Management Services (AD RMS) sur Windows Server® 2008 R2 pour la première fois, certaines conditions doivent être respectées :

• Installez le serveur AD RMS en tant que membre du même domaine des services de domaine Active Directory (AD DS) que les comptes d'utilisateur qui utiliseront un contenu protégé par des droits.
  
  
• Créez un compte d'utilisateur de domaine sans autorisation supplémentaire, qui servira de compte de service AD RMS.
  
  
• Sélectionnez le compte d'utilisateur pour installer AD RMS et tenez compte des points suivants :
  
  
  • Le compte d'utilisateur qui installe AD RMS doit être différent du compte de service AD RMS.
    
    
  • Si vous enregistrez le point de connexion de service AD RMS au cours de l'installation, le compte d'utilisateur qui installe AD RMS doit être membre du groupe Administrateurs de l'entreprise dans les services AD DS ou d'un groupe équivalent.
    
    
  • Si vous utilisez un serveur de base de données externe pour les bases de données AD RMS, le compte d'utilisateur qui installe AD RMS doit être autorisé à créer des bases de données. Si Microsoft SQL Server 2005 ou Microsoft SQL Server 2008 est utilisé, le compte d'utilisateur doit être membre du rôle de base de données Administrateurs système ou d'un rôle équivalent.
    
    
  • Le compte d'utilisateur qui installe AD RMS doit pouvoir interroger le domaine AD DS.
    
    
• Réservez une URL pour le cluster AD RMS qui sera disponible durant toute l'existence de l'installation AD RMS. L'URL réservée doit cependant être différente du nom de l'ordinateur.
  
  

Outre les conditions de préinstallation de AD RMS, nous vous conseillons vivement de tenir compte des points suivants :

• Installez le serveur de base de données devant héberger les bases de données AD RMS sur un autre ordinateur. Voir Configuration requise pour plus d'informations sur les serveurs de bases de données pris en charge par Windows Server 2008 R2.
  
  
• Installez le cluster AD RMS en utilisant un certificat SSL (Secure Sockets Layer). Ce certificat doit être délivré par une autorité racine de certification approuvée.
  
  
• Créez un enregistrement (CNAME) d'alias DNS pour l'URL du cluster AD RMS et un autre enregistrement CNAME pour l'ordinateur hébergeant la base de données de configuration AD RMS. S'il arrive que des serveurs AD RMS soient retirés à cause d'une panne ou si le nom de l'ordinateur change, l'enregistrement CNAME approprié peut être mis à jour pour refléter ces changements sans qu'il soit nécessaire de publier de nouveau les fichiers protégés par des droits.
  
  
• Si vous utilisez une instance nommée pour la base de données de configuration AD RMS, le service SQL Server Browser doit être démarré sur le serveur de base de données avant d'installer AD RMS. Sinon, l'installation de AD RMS ne pourra pas localiser la base de données de configuration et elle échouera.
  
  

Si vous procédez à la mise à niveau d'une version de RMS (Rights Management Services) vers AD RMS, effectuez la procédure suivante :

• Sauvegardez les bases de données RMS et stockez-les dans un emplacement sécurisé.
  
  
• Si votre cluster RMS a été configuré pour utiliser le compte local SYSTEM comme compte de service pour le cluster, vous devez remplacer le compte de service compte SYSTEM local par un compte d'utilisateur de domaine avant de mettre à niveau RMS vers AD RMS.
  
  
• Si vous avez utilisé l'option d'inscription hors connexion pour déployer RMS, assurez-vous que l'inscription est terminée avant de procéder à la mise à niveau vers AD RMS.
  
  
• Si vous utilisez MSDE pour héberger les bases de données RMS, vous devez procéder à la mise à niveau des bases de données vers Microsoft SQL Server 2005 ou une version ultérieure avant de mettre à niveau le cluster RMS vers AD RMS. La mise à niveau de versions de RMS à l'aide de la base de données MSDE n'est pas prise en charge.
  
  
• Si vous utilisez Microsoft SQL Server 2000 pour héberger les bases de données RMS, vous devez procéder à la mise à niveau des bases de données vers Microsoft SQL Server 2005 ou une version ultérieure avant de mettre à niveau le cluster RMS vers AD RMS.
  
  
• Videz la file d'attente Message Queuing de RMS pour que tous les messages soient enregistrés dans la base de données de journalisation de RMS.
  
  

Voici une liste des points dont vous devez tenir compte avant d'installer AD RMS :

• Les certificats auto-signés doivent être uniquement utilisés dans un environnement de test. Dans le cas d'environnements pilotes et de production, nous vous conseillons d'utiliser un certificat SSL délivré par une autorité de certification approuvée.
  
  
• La base de données interne de Windows avec AD RMS ne doit être utilisée que dans les environnements de test. Étant donné que la base de données interne de Windows ne prend pas en charge les connexions à distance, il n'est pas possible d'ajouter un autre serveur au cluster AD RMS dans ce scénario.
  
  
• Si un point de connexion de service existe déjà dans la forêt Active Directory pour laquelle vous installez AD RMS, assurez-vous que l'URL du cluster dans le point de connexion de service est la même que l'URL du cluster de la nouvelle installation. Si ces URL sont différentes, vous ne devez pas enregistrer le point de connexion de service au cours de l'installation de AD RMS.
  
  
• localhost n'est pas une URL de cluster prise en charge pour l'installation de AD RMS.
  
  
• Pendant l'installation, au moment de spécifier le compte de service AD RMS, vérifiez qu'aucune carte à puce n'a été insérée dans l'ordinateur. Si une carte à puce est insérée dans l'ordinateur, vous obtiendrez un message d'erreur vous indiquant que le compte d'utilisateur qui installe AD RMS n'est pas autorisé à interroger AD DS.
  
  
• Pour joindre un nouveau serveur à un cluster AD RMS existant, le certificat SSL doit exister sur ce nouveau serveur avant que commence l'installation de AD RMS.
  
  
• Par défaut, AD RMS ne prend pas en charge l'authentification Kerberos. Pour plus d'informations sur les étapes à suivre pour configurer le serveur afin qu'il prenne en charge l'authentification Kerberos, voir Activer la prise en charge de l'authentification Kerberos.
  
  
• Windows Server 2008 R2 ne prend pas en charge Windows Rights Management Services (RMS) Client version 1. La prise en charge de cette version du client s'est terminée avec le tout dernier Service Pack pour RMS Client version 1. Pour continuer à créer du contenu protégé par AD RMS et y accéder, les clients qui exécutent RMS Client version 1 doivent installer le tout dernier Service Pack à partir du site Web TechCenter des services RMS Microsoft Windows sur TechNet (https://go.microsoft.com/fwlink/?LinkId=140054).
  
  

Voici une liste des points dont vous devez tenir compte avant d'installer AD RMS avec la prise en charge de la fédération d'identités :

• Une relation d'approbation fédérée doit être configurée avant d'installer la prise en charge de la fédération d'identités. Au cours de l'installation du service de rôle de la prise en charge de la fédération d'identités, vous devez spécifier l'URL du service de fédération.
  
  
• Les services de fédération Active Directory (ADFS, Active Directory Federation Services) exigent que les communications entre AD RMS et le serveur de ressource AD FS soient sécurisées. Pour que la prise en charge de la fédération d'identités fonctionne avec AD RMS, AD RMS doit être installé avec une adresse de cluster sécurisée.
  
  
• Le service de compte AD RMS doit disposer du droit Générer des audits de sécurité. Ce droit est accordé à l'aide de la console Stratégie de sécurité locale.
  
  
• Le partenaire du compte fédéré doit avoir accès aux URL des clusters extranet AD RMS.
  
  

Voici une liste des points dont vous devez tenir compte avant d'installer AD RMS avec Microsoft Federation Gateway :

• Le cluster AD RMS doit être configuré pour utiliser une connexion SSL chiffrée qui utilise un certificat approuvé par Microsoft Federation Gateway. Pour prouver que vous êtes propriétaire du domaine que vous voulez fédérer avec Microsoft Federation Gateway, vous devez détenir le certificat SSL X.509 de ce domaine. Il doit être émis par l'une des autorités de certification (AC) racines de confiance configurées dans Microsoft Federation Gateway. Le tableau suivant répertorie ces autorités de certification.
  
  

  Nom convivial du certificat de l'autorité de certification	Délivré à	Rôles prévus
  Entrust (https://go.microsoft.com/fwlink/?LinkId=162663)	Autorité de certification de serveur sécurisé Entrust.net	Authentification de serveur, authentification client, signature de code, messagerie sécurisée, fin du tunnel de sécurité IP, utilisateur IPsec (Internet Protocol security), intermédiaire IPsec (Internet Protocol security) IKE (Internet Key Exchange), enregistrement des informations de date, chiffrement de système de fichier
  Autorité de certification de classe 2 Go Daddy (https://go.microsoft.com/fwlink/?LinkId=162664)	Autorité de Certification de classe 2 Go Daddy	Authentification serveur, authentification client, messagerie sécurisée, signature de code
  Network Solutions (https://go.microsoft.com/fwlink/?LinkId=162665)	Autorité de certification Network Solutions	Authentification serveur, authentification client, messagerie sécurisée, signature de code, enregistrement des informations de date
  Autorité de certification primaire publique de classe 3 VeriSign (https://go.microsoft.com/fwlink/?LinkId=162667)	Autorité de certification publique primaire de classe 3	Messagerie sécurisée, authentification client, signature de code, authentification serveur
  VeriSign	Autorité de certification publique primaire de classe 3	Messagerie sécurisée, authentification client, signature de code, authentification serveur
  VeriSign	VeriSign Trust Network	Messagerie sécurisée, authentification client, signature de code, authentification serveur
  VeriSign	Autorité de certification publique primaire de classe 3 VeriSign - G5	Authentification serveur, authentification client, messagerie sécurisée, signature de code

  Le certificat SSL utilisé pour l'inscription sur Microsoft Federation Gateway doit prouver la propriété de l'URL extranet du cluster AD RMS. Si le cluster AD RMS est configuré avec une URL intranet différente de l'URL extranet et si l'URL intranet n'est pas un nom de domaine accessible depuis Internet, vous devez installer le certificat SSL associé à l'URL extranet sur ce serveur AD RMS, puis sélectionner ce certificat lors de l'inscription sur Microsoft Federation Gateway.
  
  Si le certificat SSL contient un autre nom d'objet (subject alternate name, SAN), la dernière entrée dans la liste SAN doit être le nom de domaine complet du domaine que vous souhaitez inscrire sur Microsoft Federation Gateway.
  
  
• Les répertoires virtuels créés pour être utilisés par la Support pour Microsoft Federation Gateway utilisent http://. De ce fait, votre pare-feu doit être configuré de sorte à autoriser le transit des données http://. Notez cependant que les transactions http:// pour la Support pour Microsoft Federation Gateway utilisent la sécurité de niveau message.
  
  
• Pour plus d'informations, voir Présentation de Microsoft Federation Gateway
  
  

Attention
Avant de désinstaller le Service Pack 1 pour Windows Server® 2008 R2, supprimez la Support pour Microsoft Federation Gateway du cluster AD RMS. Si vous ne procédez pas ainsi, la configuration du cluster AD RMS risque d'être incorrecte. Pour plus d'informations, voir Supprimer la prise en charge de Microsoft Federation Gateway.

Le tableau suivant indique la configuration matérielle minimale requise et contient des recommandations pour exécuter des serveurs Windows Server® 2008 R2 avec le rôle serveur AD RMS.

Le tableau suivant indique la configuration logicielle nécessaire pour exécuter des serveurs Windows Server 2008 R2 avec le rôle serveur AD RMS. Installer le rôle serveur AD RMS permet d'activer des fonctionnalités requises sur le système d'exploitation et de les configurer comme il convient si ce n'est pas déjà fait.