Cette section énumère les restrictions du produit.
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.
Il est possible de résoudre cette limitation en installant les produits et créant des instances de serveur en tant qu'utilisateur disposant des droits d'accès utilisateur et groupe appropriés.
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.
Lorsque vous utilisez la version allemande sous Windows 2003, procédez à l'installation depuis les packages natifs à l'aide de la distribution Java ES.
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.
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.
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é.
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.
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.
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.
Pour résoudre ce problème lors de l'installation à partir de packages natifs, utilisez la commande cacaoadm enable en tant que root.
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 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.
La console n'autorise pas l'administrateur à se connecter au serveur sous Windows XP.
Pour résoudre ce problème, le compte invité doit être désactivé et la clé de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\ForceGuest doit être définie sur 0.