Vous devez veiller à ce que les transferts de données entre le chargeur distant et le moteur Identity Manager s'effectuent en toute sécurité. NetIQ recommande l'utilisation des protocoles TLS/SSL (Transport Layer Security/Secure Socket Layer) pour les communications. Les connexions TLS/SSL nécessitent un certificat auto-signé dans un fichier Keystore ou KMO. Cette section explique comment créer, exporter et stocker ce certificat.
REMARQUE :utilisez la même version de SSL sur les serveurs hébergeant le moteur Identity Manager et le chargeur distant. Si les versions de SSL sur le serveur et le chargeur distant ne correspondent pas, le serveur renvoie un message d'erreur SSL3_GET_RECORD:wrong version number. Ce message est un simple avertissement ; la communication entre le serveur et le chargeur distant n'est pas interrompue. Toutefois, l'erreur peut prêter à confusion.
Le chargeur distant ouvre un socket client et écoute les connexions à partir du module d'interface distant. Le module d'interface et le chargeur distants effectuent une reconnaissance mutuelle SSL afin d'établir un canal sécurisé. Le module d'interface distant s'authentifie ensuite auprès du chargeur distant. Si la procédure d'authentification du module d'interface distant aboutit, le chargeur distant s'authentifie auprès du module d'interface distant. Une fois que les deux bords communiquent avec une entité autorisée, le trafic de synchronisation commence.
La procédure d'établissement des connexions SSL entre un pilote et le moteur Identity Manager dépend du type de pilote :
Pour un pilote natif, tel que le pilote Active Directory, pointez vers un certificat codé en base64. Pour plus d'informations, reportez-vous à la Section 20.1.2, Gestion des certificats de serveur auto-signés.
Pour un pilote Java, vous devez créer un fichier Keystore. Pour plus d'informations, reportez-vous à la Section 20.1.3, Création d'un fichier Keystore à l'aide de connexions SSL.
Pour un pilote .NET, pointez vers un certificat codé en base64. Pour plus d'informations, reportez-vous à la Section 20.1.2, Gestion des certificats de serveur auto-signés.
REMARQUE :le chargeur distant autorise des méthodes de connexion personnalisées entre le chargeur distant et le module d'interface distant hébergé sur le serveur Identity Manager. Pour configurer un module de connexion personnalisé, reportez-vous à la documentation qui accompagne le module pour plus d'informations sur le contenu d'une chaîne de connexion et ce qui est autorisé dans ce cadre.
Vous pouvez créer et exporter un certificat de serveur auto-signé afin d'assurer une communication sécurisée entre le chargeur distant et le moteur Identity Manager. Pour plus de sécurité, vous pouvez configurer des chiffrements plus forts pour la communication SSL comme spécifié par Suite B. Cette communication requiert l'utilisation de certificats ECDSA (Elliptic Curve Digital Signature Algorithm) pour le chiffrement des données. Lorsque Suite B est activé, le chargeur distant utilise TLS 1.2 comme protocole de communication. Pour plus d'informations sur SuiteB, reportez-vous à la section relative à la technologie de chiffrement SuiteB sur le site Web de la NSA.
Vous pouvez exporter un certificat récemment créé ou utiliser un certificat existant.
REMARQUE :lorsqu'un serveur est intégré à une arborescence, eDirectory crée les certificats par défaut suivants :
SSL CertificateIP
SSL CertificateDNS
Certificats conformes à Suite B
Connectez-vous à NetIQ iManager.
Pour créer un nouveau certificat, procédez comme suit :
Cliquez sur Serveur de certificats NetIQ > Créer un certificat de serveur.
Sélectionnez le serveur devant héberger le certificat.
Spécifiez un surnom pour le certificat. Par exemple, remotecert.
REMARQUE :NetIQ vous recommande de ne pas utiliser d'espaces dans le surnom du certificat. Par exemple, utilisez remotecert plutôt que remote cert.
N'oubliez pas de noter le surnom. Ce surnom est utilisé pour le nom KMO dans les paramètres de connexion à distance du pilote.
Sélectionnez la méthode de création du certificat, puis cliquez sur Suivant.
Vous avez les options suivantes :
Standard : cette option crée un objet Certificat de serveur à l'aide de la plus grande taille de clé possible et signe le certificat de clé publique avec votre autorité de certification organisationnelle.
Personnalisé: cette option crée un objet Certificat de serveur à l'aide des paramètres que vous spécifiez. Elle vous permet de définir un certain nombre de paramètres personnalisés pour l'objet Certificat de serveur. Sélectionnez cette option pour créer des certificats ECDSA pour la communication Suite B.
Importer : cette option crée un objet Certificat de serveur à l'aide des clés et des certificats d'un fichier PKCS12 (PFX). Vous pouvez utiliser cette option en combinaison avec l'option Exporter pour sauvegarder et restaurer un certificat de serveur, ou pour déplacer un objet Certificat de serveur entre des serveurs.
Spécifiez les paramètres du certificat.
Acceptez les autres paramètres par défaut du certificat.
Passez en revue le résumé, cliquez sur Terminer, puis sur Fermer.
Pour exporter un certificat, procédez comme suit :
Dans iManager, accédez à Rôles et tâches > Accès aux certificats NetIQ > Certificats de serveur.
Recherchez et sélectionnez le certificat créé ou le certificat de serveur créé (par exemple, SSL CertificateDNS).
Cliquez sur Exporter.
Pour Certificat d'autorité de certification, sélectionnez OU=organization CA.O=TREEANAME dans le menu déroulant.
Pour Format d'exportation, sélectionnez BASE64 dans le menu déroulant.
REMARQUE :lorsque le chargeur distant est exécuté sur un serveur Windows 2012 R2 64 bits, le certificat doit être au format Base64. Si vous utilisez le format DER, le chargeur distant ne parvient pas à se connecter au moteur Identity Manager.
Cliquez sur Suivant.
Cliquez sur Enregistrer, puis sur Fermer.
Pour utiliser des connexions SSL entre un pilote Java et le moteur Identity Manager, vous devez créer un fichier Keystore. Un keystore est un fichier Java qui contient des clés de codage et, le cas échéant, des certificats. Si vous voulez utiliser SSL entre le chargeur distant et le moteur Identity Manager et si vous utilisez un module d'interface Java, vous devez créer un fichier Keystore. Les sections suivantes expliquent comment créer un fichier Keystore :
Pour créer un keystore sur n'importe quelle plate-forme, vous pouvez entrer ce qui suit à l'invite de la ligne de commande :
keytool -import -alias trustedroot -file self-signed_certificate_name -keystore filename -storepass keystorepass
Donnez au fichier le nom de votre choix. Par exemple, rdev_keystore.
Dans les environnements Linux, utilisez le fichier create_keystore qui est un script shell qui appelle l'utilitaire Keytool. Le fichier est installé avec rdxml situé par défaut dans le répertoire répertoire_installation/dirxml/bin. Le fichier create_keystore est également inclus dans le fichier dirxml_jremote.tar.gz, situé dans le répertoire \dirxml\java_remoteloader.
REMARQUE :sur les ordinateurs UNIX, lorsque le certificat auto-signé est utilisé pour créer le fichier Keystore, le certificat peut être exporté au format DER binaire ou Base64.
Entrez la commande suivante sur la ligne de commande :
create_keystore self-signed_certificate_name keystorename
Par exemple, saisissez une des commandes suivantes :
create_keystore tree-root.b64 mystore create_keystore tree-root.der mystore
Le script create_keystore spécifie un mot de passe codé en dur de « dirxml », pour le mot de passe Keystore. Cela ne pose pas de risque de sécurité ; en effet, seuls un certificat public et une clé publique sont mémorisés dans le keystore.
Sur les ordinateurs Windows, exécutez l'utilitaire Keytool situé par défaut dans le répertoire c:\novell\remoteloader\jre\bin.