NetIQ eDirectory 9.0 permet de chiffrer certaines données sensibles lors de leur stockage sur le disque et lorsque le client y accède. Ce chapitre fournit des informations sur les erreurs susceptibles de se produire lors de l'utilisation des fonctions de réplication et des attributs chiffrés dans eDirectory 9.0.
Pour plus d'informations sur les autres messages d'erreur dans eDirectory, reportez-vous au site Web des codes d'erreur de NetIQ.
Le processus de synchronisation des répliques eDirectory a tenté de démarrer la réplication codée avec le serveur eDirectory cible, alors que le processus de réplication codée des répliques est désactivé sur ce serveur.
Cause possible
La réplication codée est désactivée sur le serveur eDirectory cible.
Opération
Activez la réplication codée sur le serveur eDirectory cible.
Une application (accès du client) a tenté d'accéder à un attribut codé par le biais d'un canal en texte clair.
Source
eDirectory ou NDS.
Cause possible
Les attributs codés sont configurés de manière à n'être accessibles que par le biais d'un canal sécurisé. L'application essaie toutefois d'y accéder via un canal en texte clair.
Opération
L'application doit accéder aux attributs codés par le biais d'un canal sécurisé, tel qu'un canal sécurisé LDAP ou HTTP.
Cause possible
Si cette erreur se produit lors de la réplication, cela signifie qu'un ou plusieurs serveurs de l'anneau de répliques ont des attributs marqués pour le chiffrement et sont configurés de manière à n'être accessibles que par le biais d'un canal sécurisé.
Opération
Changez la configuration de la règle d'attributs codés pour que ces derniers soient accessibles via des canaux non sécurisés. Pour plus d'informations, reportez-vous au Section 11.0, Chiffrement des données dans eDirectory.
Cause possible
Si cette erreur se produit lorsque la réplication codée est configurée au niveau de la partition ou entre les répliques de cette dernière, cela signifie que l'anneau de répliques contient des serveurs dotés d'une version d'eDirectory antérieure à 9.0.
Opération
Mettez à niveau tous les serveurs de l'anneau de répliques vers une version compatible avec eDirectory 9.0.
Texte à insérer ici
Cause possible
Si la réplication codée est activée au niveau de la partition et que vous essayez d'ajouter une réplique de cette partition à un serveur eDirectory, cela signifie que la version eDirectory de ce dernier n'est pas compatible avec celle du serveur source.
Opération
Mettez à niveau le serveur vers une version compatible d'eDirectory.
Cause possible
Si la partition parent inclut des serveurs dotés d'une version d'eDirectory antérieure à 9.0 (anneau avec différentes versions) et si la réplication codée est activée pour la partition enfant, les opérations de fusion et/ou de jonction de partitions ne sont pas autorisées et l'erreur ERR_INCOMPATIBLE_DS_VERSION est renvoyée.
Cela s'explique par le fait que, d'une part, la partition enfant contient des données sensibles pour lesquelles la réplication codée est activée au niveau de la partition et que, d'autre part, la partition parent inclut un ou plusieurs serveurs dotés d'une version d'eDirectory antérieure à 9.0. La réplication codée étant uniquement activée entre les serveurs eDirectory 9.0, lors d'opérations de fusion, les données sensibles sont exposées pendant la réplication vers les serveurs dotés de versions antérieures à eDirectory 9.0.
Opération
Mettez à niveau le serveur vers une version compatible d'eDirectory.
OU
Désactivez la réplication codée pour la partition parent ou enfant.
REMARQUE :Si vous désactivez la réplication codée, la réplication s'effectuera en texte clair.
Si vous ajoutez un attribut pour le chiffrement à l'aide de LDIF, n'associez pas deux algorithmes à un même attribut.
Par exemple, si vous désignez title comme un attribut codé avec les algorithmes de codage AES et DES, l'algorithme à considérer en fin de compte n'est pas clairement défini. À chaque exécution du contrôleur de connectivité (limber), l'attribut title bascule entre AES et DES. C'est comme si la configuration était modifiée.
Pour éviter ce type de scénario, nous vous recommandons de ne pas assigner deux algorithmes à un même attribut.
Cela ne se produit pas si vous marquez les attributs pour le chiffrement à l'aide d'iManager.
Les attributs de flux peuvent être présents sous forme de données en texte clair. Cala s'explique par le fait que eDirectory 9.0 ne code pas les attributs de flux.
Vous ne pouvez pas configurer la réplication codée via iManager si l'un des serveurs de l'anneau de répliques est arrêté.
Si un attribut d'un objet est codé, vous ne pouvez pas afficher ni modifier l'objet à l'aide d'iManager 2.5.
Pour éviter ce problème, vous pouvez afficher ou modifier l'attribut codé via un canal sécurisé grâce à l'une des méthodes suivantes :
LDAP : la requête LDAP doit être envoyée via un canal sécurisé, ce qui signifie qu'il faut utiliser le certificat de racine approuvée du serveur.
ICE : l'objet peut être modifié à l'aide de scripts LDIF. Dans ce cas, ICE doit utiliser un canal sécurisé.
Utilisez iManager 2.5 FP2, iManager 2.6 ou une version ultérieure.
REMARQUE :nous vous recommandons d'utiliser iManager 2.6 ou une version ultérieure pour afficher ou modifier les attributs codés.
Vous pouvez également désactiver l'option imposant l'utilisation d'un canal sécurisé pour afficher ou modifier les attributs codés en désactivant l'attribut requireSecure dans la règle d'attributs codés. L'objet et les attributs codés deviennent alors accessibles par tous les clients via un canal en texte clair. Une fois cette opération effectuée, iManager pourra accéder à l'objet.
Lorsque la réplication codée est activée, la fusion d'arborescences échoue. Avant d'effectuer ce type d'opération, veillez donc à désactiver la réplication codée pour chaque arborescence.
Le contrôleur de connectivité (limber) affiche l'erreur -603 si le serveur dispose uniquement d'une réplique de référence subordonnée de la partition de stratégie d'attributs codés.
Pour éviter ce problème, effectuez l'une des opérations suivantes :
Attribuez un accès en lecture à l'objet Serveur NCP. Pour ce faire, utilisez iManager pour ajouter un ayant droit à la racine de l'arborescence et accorder un accès en lecture à l'objet Serveur NCP. Dans les attributs, spécifiez attrEncryptionDefinition et attrEncryptionRequiresSecure.
Attribuez un accès public en lecture aux attributs suivants via LDAP ou ndssch :
attrEncryptionDefinition
attrEncryptionRequiresSecure