test

Notes de version de Sun Java System Access Manager 7 2005Q4

Access Manager 7 2005Q4 Patch 5

Le patch 5 (révision 5) d'Access Manager 7 résout de nombreux problèmes, répertoriés dans le fichier LISEZMOI accompagnant le patch. Le patch 5 comprend également les nouvelles fonctionnalités, les problèmes et les mises à jour de la documentation ci-après.

Nouvelles fonctions du patch 5

Problèmes et restrictions connus du patch 5

Problèmes liés à la globalisation (g11n)

Mises à jour de la documentation

Prise en charge des systèmes HP-UX

Le patch 126371 prend en charge les systèmes HP-UX. Pour davantage d'informations, consultez les rubriques:

Pour plus d'informations sur l'installation sous HP-UX, consultez le Guide d’installation de Sun Java Enterprise System 2005Q4 pour UNIX.

Prise en charge des systèmes Microsoft Windows

Le patch 124296 prend en charge les systèmes Windows. Pour davantage d'informations, consultez les rubriques:

Pour plus d'informations sur l'installation sous Windows, consultez le Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows .

Nouveau script updateschema.sh de chargement des fichiers LDIF et XML

Le patch 5 (et version ultérieure) inclut le script updateschema.sh qui permet de charger les fichiers suivants pour mettre à jour le schéma du service Directory Server :

Dans les précédentes versions de patch pour Access Manager, il était nécessaire de charger ces fichiers manuellement.

Pour exécuter le script updateschema.sh :

  1. Connectez-vous en tant que superutilisateur (root).

  2. Accédez au répertoire des patchs.

  3. Exécutez le script. Par exemple, sur les systèmes Solaris :

    # cd /120954-07 
# ./updateschema.sh

    Sous Windows, le script est updateschema.pl.

  4. Lorsque le script vous y invite, entrez les éléments suivants :

    • Nom d'hôte et numéro de port de Directory Server

    • DN utilisateur admin et mot de passe de Directory Server

    • DN amadmin et mot de passe

  5. Le script valide vos entrées et charge les fichiers. Le script écrit aussi le fichier journal suivant :

    • Systèmes Solaris : /var/opt/SUMWam/logs/AM70Patch.upgrade.schema. timestamp

    • Systèmes Linux : /var/opt/sun/identity/logs/AM70Patch.upgrade.schema. timestamp

  6. Une fois le script terminé, redémarrez le conteneur Web d'Access Manager.

Remarque Si vous supprimez le patch 5, les modifications apportées au schéma ajoutées au script updateschema.sh ne sont pas supprimées de Directory Server. Vous n'avez, cependant, pas besoin de supprimer les modifications apportées manuellement au schéma car ces dernières n'affectent pas les fonctionnalités d'Access Manager ni son utilisation une fois le patch supprimé.

Prise en charge des valeurs de délai d'attente de session inactive d'une application spécifique

Le patch 5 permet à différentes applications d'avoir différentes valeurs de délai d'attente de session inactive. Dans une entreprise, certaines applications peuvent nécessiter des valeurs de délai d'attente de session inférieures aux valeurs de délai d'attente de session spécifiées dans le service de la session. Vous avez, par exemple, spécifié une valeur de délai d'attente de session de 30 minutes dans le service de la session mais une application HR doit se déconnecter dès qu'un utilisateur est inactif pendant plus de 10 minutes.

Conditions requises pour utiliser cette fonctionnalité :

Pour utiliser cette fonctionnalité :

Par exemple, imaginez une stratégie http://host.sample.com/hr/* avec la condition de plan d'authentification suivante :

Si plusieurs stratégies sont définies pour protéger les ressources de l'application HR, vous devez ajouter la condition à toutes les stratégies.

Lorsqu'un utilisateur d'une session distincte tente d'accéder à l'application HR protégée par l'agent d'Access Manager, il est invité à s'authentifier pour le plan LDAP (si ce n'est pas déjà fait).

Si l'utilisateur s'est déjà authentifié sur le plan LDAP, il dispose d'une autorisation d'accès à condition qu'il se soit écoulé moins de 10 minutes depuis sa dernière authentification ou depuis son dernier accès à l'application HR. Dans le cas contraire, il est invité à s'authentifier à nouveau sur le plan LDAP pour accéder à l'application.

Déploiement possible du servlet CDC sur un serveur d'interface utilisateur d'authentification distribuée

Le servlet CDC peut coexister avec un serveur d'interface utilisateur d'authentification distribuée dans la DMZ pour activer la connexion unique interdomaine (CDSSO). Il est possible de déployer le serveur Access Manager derrière un pare-feu. Par ailleurs, tous les accès à Access Manager dédiés à l'exécution d'une connexion unique interdomaine sont gérés par le servlet CDC dans le serveur d'interface utilisateur d'authentification distribuée. Pour activer la connexion unique interdomaine, consultez la documentation de l'agent de stratégie spécifique et exécutez la procédure complémentaire suivante :

Spécification possible du domaine lors de la redirection vers l'URL de connexion d'Access Manager par le servlet CDC

Vous pouvez à présent spécifier un nom de domaine sur le servlet CDC, de sorte à inclure le nom du domaine lors de la redirection vers l'URL de connexion d'Access Manager et à permettre à l'utilisateur de se connecter au domaine spécifique. Exemple :

com.sun.am.policy.agents.config.cdcservlet.url=
    http://lb.example.com/amserver/cdcservlet?org=realm1

Utilisation possible de la valeur UPN par l'authentification des certificats pour mapper le profil utilisateur

Auparavant, l'authentification des certificats n'utilisait que le composant dn dans le subjectDN pour mapper un profil utilisateur. Access Manager prend désormais en charge la valeur UPN (nom principal de l'utilisateur) dans SubjectAltNameExt pour mapper le profil.

Exécution du traitement post-authentification de la déconnexion dans un environnement de serveur multiple

Le traitement post-authentification est désormais exécuté lorsqu'un utilisateur se déconnecte d'un autre serveur que celui auquel il était initialement connecté dans un environnement de serveur multiple, qu'un basculement de session soit ou non configuré.

Prise en charge d'une nouvelle interface SPI d'identificateur de nom par SAML

SAML prend désormais en charge une nouvelle interface SPI d'identificateur de nom permettant à un site de personnaliser l'identificateur de nom dans l'assertion SAML. Un site peut mettre en œuvre la nouvelle interface NameIdentifierMapper pour mapper un compte utilisateur sur un identificateur de nom dans le cadre d'une assertion SAML.

Nouvelles propriétés de configuration pour le contrôle de site

La fonctionnalité de surveillance de site d'Access Manager intègre les nouvelles propriétés suivantes, afin que vous puissiez spécifier le comportement du contrôle d'état du site.

Propriété 

Description 

com.sun.identity.urlchecker.invalidate.interval

Intervalle de détection d'un site hors service ou qui ne répond pas exprimé en millisecondes. 

Par défaut : 70 000 millisecondes (70 secondes). 

com.sun.identity.urlchecker.sleep.interval

Intervalle de temps en millisecondes pendant lequel le contrôle d'état du site est en sommeil. 

Par défaut : 30 000 millisecondes (30 secondes). 

com.sun.identity.urlchecker.targeturl

Autre URL cible pour le contrôle de l'état du processus d'Access Manager. 

Par défaut : "/amserver/namingservice".

Le patch n'ajoute pas ces propriétés au fichier AMConfig.properties . Pour utiliser ces nouvelles propriétés avec des valeurs autres que celles par défaut :

  1. Ajoutez les propriétés et leurs valeurs au fichier AMConfig.properties . Pour les agents de stratégie, ajoutez ces propriétés au fichier AMAgents.properties .

  2. Redémarrez le conteneur Web d'Access Manager pour appliquer les valeurs.

L'utilisateur n'a plus à s'authentifier deux fois dans la chaîne d'authentification

Étudiez le scénario suivant. Un site configure une chaîne d'authentification avec trois modules LDAP. Tous les modules sont configurés sur SUFFICIENT et les options iplanet-am-auth-shared-state-enabled et iplanet-am-auth-store-shared-state-enabled sont configurées sur true. Exemple :

<AttributeValuePair>
   <Value>A-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>B-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>C-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
</AttributeValuePair>

Le patch 5 ajoute la nouvelle option iplanet-am-auth-shared-state-behavior-pattern aux options du module. Cette option peut prendre deux valeurs : tryFirstPass (par défaut) et useFirstPass.

Pour empêcher un utilisateur d'avoir à saisir deux fois son identifiant et son mot de passe pour s'authentifier (comme indiqué dans le scénario précédent), configurez cette nouvelle option sur useFirstPass pour tous les modules de la chaîne. Auparavant, un utilisateur qui n'existait que dans la troisième instance LDAP devait saisir son identifiant et son mot de passe deux fois pour s'authentifier.

Modifications apportées aux scripts de réglage des performances

Dans le patch 5 les modifications suivantes ont été apportées aux scripts de réglage des performances :

Voir aussi CR# 6527663 : la valeur par défaut de la propriété com.sun.identity.log.resolveHostName doit être false au lieu de true.

Prise en charge d'un fichier de mots de passe par les scripts de réglage

Le patch 5 vous permet de spécifier des mots de passe dans un fichier texte pour les scripts de réglage. Auparavant, vous ne pouviez saisir de mots de passe que sous la forme d'un argument de ligne de commande, ce qui pouvait engendrer des problèmes de sécurité. Pour utiliser un fichier de mots de passe, configurez les variables suivantes dans le fichier, au besoin :

DS_ADMIN_PASSWORD=DirectoryServer-admin-password
AS_ADMIN_PASSWORD=ApplicationServer8-admin-password

Par exemple, pour régler Application Server 8 :

# ./amtune-as8 password-file

password-file contenant AS_ADMIN_PASSWORD, cette valeur étant définie sur le mot de passe administrateur d'Application Server 8.

Les scripts de réglage utilisent l'option -j password-file lorsqu'ils appellent les utilitaires ldapmodify, ldapsearch, db2index et dsconf de Directory Server.

Le script de réglage supprime les ACI inutiles de Directory Server

Si Access Manager 7 2005Q4 est installé en mode Domaine, les privilèges de délégation servent à déterminer les droits d'accès ; par conséquent, certains ACI de Directory Server ne sont pas requis. Le patch 5 d'Access Manager 7 2005Q4 vous permet de supprimer les ACI inutiles en exécutant le script amtune-prepareDSTuner. Ce script lit une liste d'ACI dans le fichier remacis.ldif, puis appelle l'utilitaire ldapmodify pour les supprimer.

Vous pouvez exécuter le script amtune-prepareDSTuner pour supprimer les ACI inutiles sous Solaris, Linux, HP-UX et Windows. Pour plus d'informations, y compris sur la manière d'exécuter le script, consultez le Technical Note: Sun Java System Access Manager ACI Guide .

Réglage possible du conteneur Web du serveur d'interface utilisateur d'authentification distribuée par les scripts de réglage

Une fois le serveur d'interface utilisateur d'authentification distribuée déployé sur un serveur Web, vous pouvez régler le conteneur Web en exécutant les scripts de réglage d'Access Manager. Les scripts de réglage suivants définissent la JVM, ainsi que d'autres options de réglage du conteneur Web concerné :

Tableau 2 Scripts de réglage du conteneur Web d'Access Manager

Conteneur Web 

Script de réglage 

amtune-ws61

Web Server6.1 

amtune-as7

Application Server 7 

amtune-as8

Application Server Enterprise Edition 8.1 

Pour régler un conteneur Web pour un serveur d'interface utilisateur d'authentification distribuée :

  1. Le serveur Access Manager n'étant pas installé sur le système sur lequel le serveur d'interface utilisateur d'authentification distribuée est déployé, copiez le script de réglage de conteneur Web approprié (indiqué dans le tableau précédent), le fichier de configuration amtune-env et le script amtune-utils depuis une installation du serveur Access Manager. Si vous souhaitez régler le système d'exploitation Solaris ou Linux, copiez également le script amtune-os.

  2. Modifiez les paramètres dans le fichier de configuration amtune-env pour spécifier le conteneur Web et les options de réglage. Pour exécuter le script en mode REVIEW (de révision), configurez AMTUNE_MODE=REVIEW dans le fichier amtune-env .

  3. Exécutez le script de réglage du conteneur Web en mode REVIEW. En mode REVIEW, le script suggère des modifications de réglage basées sur les valeurs contenues dans le fichier amtune-env mais n'apporte aucune modification réelle au déploiement.

  4. Consultez les recommandations en matière de réglage dans le fichier journal de débogage. Modifiez le fichier amtune-env en fonction de cette exécution, au besoin.

  5. Pour modifier les réglages, configurez le fichier AMTUNE_MODE=CHANGE dans amtune-env.

  6. Exécutez le script de réglage en mode CHANGE (de modification) pour modifier les réglages du déploiement.

Pour plus d'informations sur l'exécution du script de réglage pour régler le conteneur Web d'Access Manager, consultez le Chapitre 2, Access Manager Tuning Scripts du Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide.

Réglage des systèmes d'exploitation Solaris et Linux au moyen d'un script amtune-os unique

Le patch 5 intègre un script amtune-os unique pour régler les systèmes d'exploitation Solaris et Linux. Le script détermine le type de système d'exploitation au moyen de la commande uname -s. Auparavant, Access Manager fournissait des scripts amtune-os distincts pour régler chaque système d'exploitation.

Exécution complète des scripts de réglages dans une zone locale de Solaris 10

Si Access Manager est installé dans une zone locale de Solaris 10, tous les scripts de réglage à l'exception du script amtune-os peuvent être exécutés dans la zone locale. Dans une zone locale, le script amtune-os affiche un message d'avertissement mais ne règle pas le système d'exploitation. Le script continue d'exécuter les autres scripts de réglage que vous avez demandés. Auparavant, dans une zone locale, l'exécution du script amtune-os était interrompue et aucun des scripts de réglage ultérieurs demandés ne s'exécutaient.

Dans une zone globale de Solaris 10, le script amtune appelle amtune-os pour régler le système d'exploitation, ainsi que les autres scripts que vous voulez exécuter.

Disponibilité des scripts de réglage pour Windows

Le patch 5 comprend des scripts de réglage de Windows. L'exécution des scripts de réglage sous Windows est similaire à l'exécution des scripts de réglage sous Solaris ou Linux, aux exceptions suivantes près :

Réglages à prendre en compte pour les serveurs Sun Fire T1000 et T2000

Si Access Manager est installé sur un serveur Sun Fire T1000 ou T2000, les scripts de réglage pour Web Server 6.1 et Application Server 8 fournis avec le patch 5 configurent le paramètre JVM GC ParallelGCThreads sur 8 :

-XX:ParallelGCThreads=8

Ce paramètre réduit le nombre de threads de libération de la mémoire qui pourrait être inutilement élevé sur un système prenant en charge 32 threads. Vous pouvez toutefois augmenter la valeur à 16, voire à 20, pour une machine CPU virtuelle 32 bits comme un serveur Sun Fire T1000 ou T2000, si cela permet de réduire les activités complètes de libération de la mémoire.

Par ailleurs, pour les systèmes Solaris SPARC intégrant un processeur CMT doté de la technologie CoolThreads, nous vous recommandons d'ajouter la propriété suivante à la fin du fichier /etc/opt/SUNWam/config/AMConfig.properties :

com.sun.am.concurrencyRate=value

La value par défaut est de 16, mais vous pouvez attribuer une valeur inférieure à cette propriété en fonction du nombre de composants de base que contient le serveur Sun Fire T1000 ou T2000.

Authentification de base dans l'agent de stratégie IIS 6.0

Pour activer l'authentification de base dans Microsoft Internet Information Services (IIS) 6.0, l'agent de stratégie doit obtenir le nom et le mot de passe de l'utilisateur. Le patch 5 intègre les nouvelles classes suivantes pour activer cette fonctionnalité à l'aide du chiffrement DES du mot de passe de l'utilisateur :

Pour utiliser l'authentification de base dans IIS 6.0, vous devez exécuter la procédure suivante sur le serveur Access Manager et l'agent de stratégie IIS 6.0.

Sur le serveur Access Manager :

  1. Exécutez DESGenKey.java pour générer une clé de chiffrement unique pour le chiffrement et le déchiffrement du mot de passe. Sous Solaris, le fichier DESGenKey.java figure dans le répertoire com/sun/identity/common présent dans am_sdk.jar dans le répertoire /opt/SUNWam/lib. Par exemple, la commande suivante génère une clé de chiffrement :

    # cd /opt/SUNWam/lib
# java -cp am_sdk.jar com.sun.identity.common.DESGenKey

  2. Attribuez la valeur de clé de chiffrement de l'étape 1 à la propriété com.sun.am.replaypasswd.key dans le fichier AMConfig.properties.

  3. Déployez ReplayPasswd.java comme plug-in de post-authentification. Utilisez le nom de classe complet lors de la configuration du plug-in : com.sun.identity.authentication.spi.ReplayPasswd .

Sur l'agent de stratégie IIS 6.0 :

  1. Attribuez la valeur de clé de chiffrement du côté serveur à la propriété com.sun.am.replaypasswd.key dans le fichier AMAgent.properties . Le serveur Access Manager et l'agent de stratégie IIS 6.0 doivent utiliser la même clé de chiffrement.

  2. Activez l'authentification de base dans le gestionnaire d'IIS 6.0.

L'agent de stratégie IIS 6.0 lit le mot de passe chiffré de la réponse de session, déchiffre le mot de passe à partir de la propriétécom.sun.am.replaypasswd.key et configure les en-têtes d'authentification pour permettre le fonctionnement de l'authentification de base.

Pour plus d'informations sur l'agent de stratégie IIS 6.0, consultez le Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0 .

CR# 6567746 : sous HP-UX, le patch 5 d'Access Manager renvoie une valeur errorCode incorrecte si le nombre de nouvelles tentatives de saisie du mot de passe est dépassé

Lorsqu'un compte d'utilisateur est bloqué, le patch 5 d'Access Manager 7 2005Q4 sous HP-UX renvoie errorCode = null au lieu de errorCode = 107 si le nombre de tentatives de saisie du mot de passe est dépassé.

Solution. aucune.

CR# 6527663 : la valeur par défaut de la propriété com.sun.identity.log.resolveHostName doit être false au lieu de true

Avant d'exécuter le script de réglage amtune-identity, nous vous recommandons d'ajouter la propriété suivante, configurée sur false, dans le fichier AMConfig.properties :

com.sun.identity.log.resolveHostName=false

La valeur false réduit l'incidence de la résolution des noms d'hôte et peut, en conséquence, améliorer les performances. Cependant, si vous souhaitez imprimer le nom d'hôte de la machine cliente dans le journal amAuthentication.access, configurez cette valeur sur true.

CR# 6527528 : la suppression du patch conserve le mot de passe amldapuser en clair dans les fichiers XML

Si vous supprimez le patch 5 d'une installation complète du serveur Access Manager, les fichiers amAuthLDAP.xml et amPolicyConfig.xml contiennent le mot de passe amldapuser en clair. Ces fichiers figurent dans le répertoire suivant, en fonction de votre plate-forme :

Solution : Modifiez les fichiers amAuthLDAP.xml et amPolicyConfig.xml, puis supprimez le mot de passe en clair.

CR# 6527516 : le serveur plein sur WebLogic exige que les fichiers JAR de JAX-RPC 1.0 communiquent avec le SDK client

Dans les patchs d'Access Manager 7 2005Q4, le script de configuration d'Access Manager pour BEA WebLogic Server (amwl81config) ajoute les fichiers JAR de JAX-RPC 1.1 au classpath de l'instance WebLogic. Alors que cette modification est intéressante pour les produits comme Sun Java System Portal Server, une installation de serveur complète (DEPLOY_LEVEL=1) déployée sur WebLogic Server ne peut pas communiquer avec une installation de SDK client. Le cas échéant, des exceptions se produiront ultérieurement.

Si le serveur Access Manager 7 2005Q4 est installé sur BEA WebLogic Server, le CLASSPATH dans le script startWebLogic.sh doit être configuré à l'emplacement des fichiers JAR de JAX-RPC 1.0 pour communiquer avec le SDK client d'Access Manager.

Solution : avant d'appliquer le patch d'Access Manager, configurez le CLASSPATH dans le script startWebLogic.sh de l'instance de WebLogic Server pour utiliser les fichiers JAR de JAX-RPC 1.0 plutôt que les fichiers JAR de JAX-RPC 1.1 :

  1. Connectez-vous au serveur Access Manager en tant que superutilisateur(root).

  2. Modifiez le script startWebLogic.sh et remplacez le CLASSPATH pour utiliser les fichiers JAR de JAX-RPC 1.0. Exemple :

Valeur actuelle :

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-spi.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-impl.jar:

Nouvelle valeur :

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc_1.0/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-ri.jar:

où AccessManager-base correspond au répertoire d'installation de base. La valeur par défaut est /opt sous Solaris et /opt/sun sous Linux et HP-UX. AccessManager-package-dir correspond au répertoire du package d'Access Manager.

5. Redémarrez l'instance de WebLogic Server.

CR # 6523499 : fichier amsilent du patch 5 lisible par tous les utilisateurs sous Linux

Sous Linux. Le script postpatch crée le fichier /opt/sun/identity/amsilent avec des permissions de 644, qui offrent un accès en lecture à tous les utilisateurs.

Solution : Une fois le script installpatch exécuté, modifiez les permissions dans le fichier amsilent pour accorder un accès en lecture et en écriture au propriétaire uniquement. Exemple :

# chmod 600 /opt/sun/identity/amsilent

CR# 6520326 : l'application du patch 5 sur une deuxième instance d'Access Manager sur un serveur écrase le fichier serverconfig.xml de la première instance

Dans ce scénario de déploiement, deux instances d'Access Manager sont déployées sur le même serveur hôte, chaque instance figurant sur une instance de conteneur Web différente. Procédez ensuite comme suit :

  1. Appliquez le patch 5.

  2. Modifiez le fichier amsilent et redéployez la première instance d'Access Manager.

  3. Modifiez à nouveau amsilent pour la seconde instance d'Access Manager, puis redéployez cette instance.

Si NEW_INSTANCE=false dans le fichier amsilent, le fichier serverconfig.xml de la première instance d'Access Manager est écrasé par les données de la seconde instance d'Access Manager. Un redémarrage ultérieur de la première instance d'Access Manager échoue. Le fichier serverconfig.xml figure dans le répertoire suivant en fonction de votre plate-forme :

Solution : lorsque vous déployez la seconde instance d'Access Manager, configurez NEW_INSTANCE=true dans le fichier amsilent. Le fichier serverconfig.xml de la seconde instance d'Access Manager est ensuite mis à jour avec les données correctes et le fichier serverconfig.xml de la première instance d'Access Manager n'est pas écrasé.

CR# 6520016 : l'installation du patch 5 sur une machine SDK uniquement écrase les fichiers makefile échantillon

L'application du patch 5 sur une machine SDK uniquement écrase les fichiers makefile échantillon.

Solution : L'application du patch 5 sur une machine SDK uniquement ne nécessite pas de reconfiguration ; cependant, si vous souhaitez utiliser les fichiers makefile échantillon, observez la procédure suivante pour mettre à jour les fichiers LDIF et de propriétés (effectuez le remplacement des balises) des fichiers makefile échantillon :

  1. Exécutez le script amconfig avec DEPLOY_LEVEL=14 pour désinstaller le SDK et annuler la configuration du conteneur Web.

  2. Exécutez le script amconfig avec DEPLOY_LEVEL=4 pour réinstaller le SDK et reconfigurer le conteneur Web.

CR#6515502 : le plug-in de référentiel LDAPv3 ne gère pas toujours correctement l'attribut de recherche d'alias

Ce problème a été résolu pour la plupart des recherches. Faites toutefois attention lors de la configuration de l'attribut de recherche d'alias. La valeur des attributs de recherche d'alias doit être unique au sein d'une organisation. Si plus d'un attribut de recherche d'alias est configuré, il est possible qu'une entrée du magasin de données corresponde à un attribut et qu'une autre entrée corresponde à l'autre attribut. Le cas échéant, le serveur Access Manager renvoie l'erreur suivante :

An internal authentication error has occurred. Contact your system administrator.

Solution : aucune

CR# 6515383 : l'authentification distribuée et l'agent J2EE ne fonctionnent pas dans le même conteneur Web

Un serveur d'interface utilisateur d'authentification distribuée et un agent de stratégie J2EE ne fonctionnent pas s'ils sont installés dans le même conteneur Web.

Solution : créez une seconde instance pour le conteneur Web et déployez le serveur d'interface utilisateur d'authentification distribuée et l'agent de stratégie sur une instance différente du conteneur.

CR# 6508103 : l'aide en ligne renvoie une erreur d'application si le serveur d'application fonctionne sous Windows

Si vous déployez Access Manager sur un serveur d'application Sun Java System sous Windows, cliquer sur Aide dans le panneau gauche de l'écran d'aide de la console en mode Domaine renvoie une erreur d'application.

Solution : copiez le fichier javaes-install-dir\share\lib\jhall.jar dans le répertoire JAVA_HOME\jre\lib\ext, puis redémarrez Application Server.

CR# 6507383 et CR# 6507377 : l'authentification distribuée nécessite un paramètre d'URL goto explicite

Si aucun paramètre d'URL goto explicite n'est spécifié, un serveur d'interface utilisateur d'authentification distribuée tente de rediriger le paramètre goto sur un URL opérationnel spécifié dans Access Manager. Cette redirection peut échouer pour les motifs suivants :

Solution : spécifiez toujours un paramètre d'URL goto explicite pour un serveur d'interface utilisateur d'authentification distribuée.

CR# 6402167 : LDAP JDK 4.18 provoque des problèmes au niveau du client LDAP/Directory Server

Dans Access Manager 7 2005Q4, LDAP JDK 4.18 est intégré à Java ES 2005Q4, d'où l'apparition de plusieurs problèmes de connexions avec Access Manager et Directory Server.

Solution : Appliquez l'un des patchs Sun Java System LDAP Java Development Kit suivants :

Ces patchs sont accessibles sur le site Web de SunSolve : http://sunsolve.sun.com.

CR# 6352135 : les fichiers du serveur d'interface utilisateur d'authentification distribuée ne sont pas installés au bon emplacement

Sous Solaris, le programme d'installation de Java ES n'installe pas les fichiers du serveur d'interface utilisateur d'authentification distribuée Makefile.distAuthUI, README.distAuthUI et amauthdistui.war au bon emplacement : /opt/SUNComm/SUNWam.

Solution : copiez ces fichiers au bon emplacement : /opt/SUNWam.

Remarque : tout problème relatif au serveur d'interface utilisateur d'authentification distribuée qui a été résolu dans un patch est inséré dans le fichier /opt/SUNComm/SUNWam/amauthdistui.war . En conséquence, chaque fois que vous appliquez un patch sur le serveur Access Manager, puis que vous reconstruisez et déployez le fichier WAR, vous devez également copier ces fichiers dans le répertoire /opt/SUNWam.

CR# 6522720 : il est impossible d'effectuer une recherche de caractères multioctets dans l'aide en ligne de la console sous Windows et HP-UX

Si Access Manager est installé dans un environnement linguistique utilisant des caractères multioctets (comme le japonais) sous Windows ou HP-UX, il est impossible d'effectuer une recherche par saisie de mots-clés utilisant des caractères multioctets dans l'aide en ligne de la console.

Solution : aucune

Mise à jour du patch 6 : le patch 6 d'Access Manager 7 2005Q4 résout ce problème sous Windows. Cependant, il persiste sur les systèmes HP-UX.

CR# 6524251 : les caractères multioctets des messages sortants sont tronqués pendant la configuration d'Access Manager sous Windows

Si Access Manager est installé dans un environnement linguistique utilisant des caractères multioctets (comme le japonais ou le chinois) sous Windows, les mots sont tronqués dans les messages sortants apparaissant dans la fenêtre de terminal pendant sa configuration.

Solution : aucune, mais ce problème n'affecte pas la configuration en elle-même.

CR# 6526940 : les touches de propriété apparaissent à la place du texte pendant l'installation du patch 5 dans une autre langue que l'anglais sous Windows

Si vous installez le patch 5 (124296-05) dans une autre langue que l'anglais sous Windows, certaines chaînes apparaissent dans les panneaux d'installation sous la forme de touches de propriété au lieu de s'afficher sous forme de texte. Exemples de touches de propriété : PRODUCT_NAME, JES_Patch_FinishPanel_Text1 et JES_Patch_FinishPanel_Text2.

Solution : aucune

CR# 6513653 : la configuration de la propriété com.iplanet.am.session.purgedelay peut provoquer un problème

Le script amtune configure la propriété com.iplanet.am.session.purgedelay sur 1 pour autoriser autant de sessions Access Manager que possible. Cette propriété spécifie, en minutes, le délai pendant lequel l'opération de session de purge est repoussée. Pour les clients comme Sun Java System Portal Server, cependant, une valeur de 1 peut s'avérer trop faible.

Solution : réinitialisez la propriété com.iplanet.am.session.purgedelay après avoir exécuté le script amtune :

  1. Dans le fichier AMConfig.properties, configurez la propriété sur la nouvelle valeur. Exemple :

    com.iplanet.am.session.purgedelay=5

  2. Redémarrez le conteneur Web d'Access Manager pour appliquer la nouvelle valeur.