Restrictions de Directory Server

Cette section énumère les restrictions du produit. Les restrictions ne sont pas toujours associées à un numéro de demande de modification.

Ne modifiez pas manuellement les droits d'accès au fichier.

Des modifications apportées aux droits d'accès aux fichiers Directory Server Enterprise Edition installés peuvent parfois entraîner un dysfonctionnement du logiciel. Ne modifiez les droits d'accès au fichier que conformément aux instructions de la documentation ou aux instructions du support Sun.

Pour contourner cette restriction, installez les produits en tant qu'utilisateur disposant des droits d'accès utilisateur et groupe appropriés.

Ne répliquez pas le suffixe cn=changelog.

Même si rien ne vous empêche de configurer la réplication du suffixe cn=changelog, cette action peut interférer avec la réplication. Ne répliquez pas le suffixe cn=changelog.

Sous Windows 2003, n'utilisez pas de logiciel installé avec la commande dsee_deploy de la distribution zip dans la version allemande.

Lorsque vous utilisez la version allemande sous Windows 2003, procédez à l'installation depuis les packages natifs à l'aide de la distribution Java ES.

Il est possible de mettre à jour le cache de la base de données après le basculement sur Sun Cluster.

Lorsque Directory Server est exécuté sur Sun Cluster et que nsslapd-db-home-directory est configuré pour utiliser un répertoire non partagé, plusieurs instances partagent les fichiers cache de base de données. Après un basculement, l'instance Directory Server sur le nouveau nœud utilise des fichiers cache de base de données potentiellement dépassés.

Pour contourner cette restriction, utilisez un répertoire partagé pour nsslapd-db-home-directory ou supprimez systématiquement les fichiers figurant sous nsslapd-db-home-directory au démarrage de Directory Server.

Une bibliothèque SASL incorrecte est chargée lorsque LD_LIBRARY_PATH contient /usr/lib.

Lorsque LD_LIBRARY_PATH contient /usr/lib, une bibliothèque SASL incorrecte est utilisée de sorte que la commande dsadm échoue après l'installation.

Utilisez l'opération de remplacement LDAP pour modifier les attributs cn=config.

Une opération de modification LDAP sur cn=config ne peut qu'utiliser la sous-opération de remplacement. Toute tentative d'ajout ou de suppression d'un attribut sera refusée avec l'erreur 53, DSA refuse de s'exécuter. Alors que Directory Server 5 acceptait l'ajout ou la suppression d'un attribut ou d'une valeur d'attribut, la mise à jour était appliquée au fichier dse.ldif sans aucune validation de valeur et l'état interne du DSA n'était pas mis à jour tant que le DSA n'était pas arrêté, puis redémarré.

---

Remarque –

L'interface de configuration cn=config est désapprouvée. Lorsque cela est possible, utilisez plutôt la commande dsconf.

---

Pour contourner cette restriction, il est possible de remplacer la sous-opération LDAP de remplacement de la modification par la sous-opération d'ajout ou de suppression. Il n'en résulte aucune perte de fonctionnalité. Par ailleurs, l'état de la configuration du DSA est plus prévisible après la modification.

Sous Windows, Directory Server ne permet pas d'utiliser Start TLS par défaut.

Ce problème affecte les instances de serveur sous Windows uniquement. Ce problème est dû aux performances des systèmes fonctionnant sous Windows lors de l'utilisation de Start TLS.

Pour résoudre ce problème, veillez à utiliser l'option -P avec la commande dsconf pour vous connecter en utilisant directement le port SSL. Si votre connexion réseau est déjà sécurisée, vous pouvez également envisager d'utiliser l'option -e avec la commande dsconf. Cette option vous permet de vous connecter au port standard sans demander de connexion sécurisée.

Les vecteurs de mise à jour de la réplication peuvent référencer les serveurs supprimés.

Il est possible qu'après la suppression d'une instance Directory Server répliquée d'une topologie de réplication, les vecteurs de mise à jour de la réplication continuent de référencer cette instance. Vous pouvez ainsi rencontrer des références à des instances qui n'existent plus.

Le conteneur d'agent commun ne démarre pas à l'amorçage.

Pour résoudre ce problème lors de l'installation à partir de packages natifs, utilisez la commande cacaoadm enable en tant que root.

L'activation de l'expiration des mots de passe peut provoquer une expiration de masse.

Directory Server met désormais à jour l'attribut de fonctionnement pwdChangedTime à chaque modification d'un mot de passe. Comme cet attribut est déjà mis à jour avant l'expiration des mots de passe, les anciens mots de passe expirent immédiatement lorsque vous activez cette fonction.

Une autre condition peut provoquer l'expiration immédiate lorsque vous exécutez Directory Server en mode de stratégie de mots de passe version 5. Si vous avez précédemment activé, puis désactivé l'expiration des mots de passe, Directory Server possède encore des horodatages sur les attributs opérationnels passwordExpirationTime. Par conséquent, lorsque vous réactivez l'expiration des mots de passe, les mots de passe possédant d'anciens attributs opérationnels passwordExpirationTime peuvent expirer immédiatement.

Vous pouvez autoriser les utilisateurs de grace logins à modifier leur mot de passe avec pwdGraceAuthNLimit. Lors de l'exécution de Directory Server en mode de stratégie de mots de passe compatible avec la version 5, vous pouvez également configurer Directory Server pour avertir les utilisateurs avant l'expiration de leurs mots de passe. Définissez passwordExpireWithoutWarning sur off. Définissez également passwordWarning correctement.

max-thread-per-connection-count n'est pas utile sous Windows.

La propriété de configuration de Directory Server, max-thread-per-connection-count ne s'applique pas aux systèmes Windows.

Un bogue de Microsoft Windows indique le type de démarrage du service comme étant désactivé.

Un bogue de Microsoft Windows 2000 Standard Edition fait apparaître le service Directory Server comme étant désactivé après sa suppression de la console d'administration de Microsoft.