Users Guide

Si la validation de certicat est activée, lorsqu'iDRAC établit la connexion SSL avec le serveur de répertoire, il utilise le certicat CA
téléversé pour vérier le certicat du serveur de répertoire. Les principales causes de l'échec de la validation de certication sont les
suivantes :
• La date iDRAC ne se trouve pas dans la période de validité du certicat du serveur ou du certicat CA. Vériez l'heure iDRAC et
la période de validité de votre certicat.
• Les adresses des contrôleurs de domaine dénies dans iDRAC ne correspondent pas à l'objet ou à l'autre nom d'objet du certicat
du serveur de répertoire. Si vous utilisez une adresse IP, lisez la question suivante. Si vous utilisez le nom de domaine complet
qualié (FQDN), veillez à utiliser le nom de domaine complet qualié du contrôleur de domaine et non pas du domaine. Par
exemple, nomserveur.exemple.com au lieu de exemple.com.
La validation de certicat échoue si l'adresse IP est utilisée comme adresse de contrôleur de domaine. Comment résoudre ce
problème ?
Vériez le champ Objet ou Autre nom d'objet du certicat du contrôleur de domaine. Normalement, Active Directory utilise le nom
d'hôte et non pas l'adresse IP du contrôleur de domaine dans le champ Objet ou Autre nom de l'objet du certicat du contrôleur de
domaine. Pour résoudre ce problème, procédez de l'une des manières suivantes :
• Dénissez le nom d'hôte (nom de domaine complet qualié) du contrôleur de domaine comme adresse(s) de contrôleur de
domaine dans iDRAC pour qu'il corresponde au champ Objet ou Autre nom de l'objet dans le certicat du serveur.
• Réémettez le certicat de serveur pour utiliser une adresse IP dans le champ Objet ou Autre nom de l'objet pour qu'il
corresponde à l'adresse IP dénie dans iDRAC.
• Désactivez la validation de certicat si vous choisissez de faire conance à ce contrôleur de domaine sans validation de certicat
los de l'établissement de liaisons SSL.
Comment congurer l'adresse (ou les adresses) de contrôleur de domaine en utilisant le schéma étendu dans un
environnement multi-domaine ?
Il doit s'agir du nom d'hôte (nom de domaine complet qualié) ou de l'adresse IP du (ou des) contrôleur(s) de domaine qui gère(nt) le
domaine dans lequel l'objet iDRAC réside.
Quand faut-il dénir une adresse (ou des adresses) de catalogue global ?
Si vous utilisez le schéma standard et que les utilisateurs et les groupes de rôles appartiennent à des domaines diérents, une
adresse (ou plusieurs adresses) de catalogue global est nécessaire. Dans ce cas, vous pouvez utiliser uniquement le groupe universel.
Si vous utilisez le schéma standard et que tous les utilisateurs et groupes de rôles proviennent du même domaine, une ou des
adresses du catalogue global ne sont pas requises.
Si vous utilisez le schéma étendu, l'adresse du catalogue global n'est pas utilisée.
Comment fonctionne la requête de schéma standard ?
iDRAC se connecte tout d'abord à l'adresse (ou aux adresses) de contrôleur de domaine dénie. Si l'utilisateur et les groupes de rôles
se trouvent dans ce domaine, les privilèges sont enregistrés.
Si une adresse (ou des adresses) de contrôleur global est congurée, iDRAC continue d'interroger le catalogue global. Si des
privilèges supplémentaires sont extraits du catalogue global, ces privilèges sont accumulés.
iDRAC utilise-t-il toujours LDAP sur SSL ?
Oui. Tout le transport s'eectue sur le port 636 et/ou 3 269. Au cours du test, iDRAC exécute LDAP CONNECT uniquement pour
isoler le problème, mais il n'exécute pas LDAP BIND sur une connexion non sécurisée.
Pourquoi iDRAC active-t-il par défaut la validation de certicat ?
iDRAC applique une sécurité stricte pour garantir l'identité du contrôleur de domaine auquel iDRAC se connecte. Sans la validation de
certicat un intrus peut usurper l'identité d'un contrôleur de domaine et détourner la connexion SSL. Si vous faites conance à tous
313