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
Nouveau script updateschema.sh de chargement des fichiers LDIF et XML
Prise en charge des valeurs de délai d'attente de session inactive d'une application spécifique
Prise en charge d'une nouvelle interface SPI d'identificateur de nom par SAML
Nouvelles propriétés de configuration pour le contrôle de site
L'utilisateur n'a plus à s'authentifier deux fois dans la chaîne d'authentification
Modifications apportées aux scripts de réglage des performances
Problèmes et restrictions connus du patch 5
CR # 6523499 : fichier amsilent du patch 5 lisible par tous les utilisateurs sous Linux
CR# 6402167 : LDAP JDK 4.18 provoque des problèmes au niveau du client LDAP/Directory Server
Problèmes liés à la globalisation (g11n)
Mises à jour de la documentation
Access Manager ne peut pas rebasculer en mode Hérité à partir du mode Domaine (6508473)
Obtention de davantage d'informations sur la désactivation des recherches persistantes (6486927)
Documentation des privilèges d'Access Manager pris et non pris en charge (2143066)
Documentation du routage des demandes d'association basé sur des cookies (6476922)
Documentation de la configuration de Windows Desktop SSO pour Windows 2003 (6487361)
L'aide en ligne sur la création d'un nouveau nom de site demande plus d'informations (2144543)
Le paramètre de configuration du mot de passe administrateur estADMIN_PASSWD sous Windows (6470793)
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.
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 .
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 :
AddLDAPFilterCondition.xml
amPolicyConfig_mod_ldfc.xml
accountLockoutData.xml
accountLockout.ldif
idRepoServiceAddAttrSchemaRequest_Cache.xml
wsf1.1_upgrade.xml
amAuth_mod.xml
amAuthCert_mod.xml
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 :
Connectez-vous en tant que superutilisateur (root).
Accédez au répertoire des patchs.
Exécutez le script. Par exemple, sur les systèmes Solaris :
# cd /120954-07 # ./updateschema.sh
Sous Windows, le script est updateschema.pl.
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
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
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é.
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é :
Les agents protégeant l'application doivent être configurés pour appliquer les décisions concernant la stratégie relative aux URL depuis Access Manager.
Les agents doivent être configurés pour s'exécuter en mode cache de décision de stratégie automatique. Consultez les propriétés suivantes :
Pour les agents Web : com.sun.am.policy.am.fetch_from_root_resource
Pour les agents J2EE : com.sun.identity.policy.client.cacheMode
Le fichier AMConfig.properties d'Access Manager doit spécifier un ordre d'évaluation du composant de stratégie de sorte que la Condition soit évaluée en dernier. Consultez la propriété suivante :
com.sun.identity.policy.Policy.policy_evaluation_weights
La Condition sur Access Manager ne connaîtra pas l'accès à l'application autorisé par l'agent en fonction de la décision stockée en mémoire cache localement. Par conséquent, le délai d'attente réel d'inactivité de l'application se situera entre le délai d'attente d'inactivité de l'application et le délai d'attente d'inactivité de l'application moins la durée de stockage en mémoire cache de l'agent.
Pour utiliser cette fonctionnalité :
Ajoutez la condition du plan d'authentification aux stratégies de protection de l'application nécessitant le délai d'attente d'inactivité de la session propre à l'application.
Spécifiez le nom de l'application et la valeur du délai d'attente dans la condition du plan d'authentification.
Utilisez le même nom d'application et la même valeur de délai d'attente dans toutes les stratégies applicables aux ressources de l'application.
Spécifiez la valeur du délai d'attente en minutes. Si la valeur est égale à 0 ou supérieure à la valeur de délai d'attente d'inactivité de la session spécifié dans le service de la session, la valeur est ignorée et le délai d'attente du service de la session est appliqué.
Par exemple, imaginez une stratégie http://host.sample.com/hr/* avec la condition de plan d'authentification suivante :
Schéma d'authentification : LDAP
Nom de l'application : HR
Valeur du délai d'attente : 10
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.
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 :
Modifiez le fichier AMAgent.properties pour pointer le servlet CDC sur le serveur d'authentification distribuée côté client. Par exemple, pour les agents Web, modifiez la propriété suivante :
com.sun.am.policy.agents.config.cdcservlet.url= http://DAhost.DAdomain:DAport/DISTAUTH_DEPLOY_URI/cdcservlet
Définissez les stratégies requises dans Access Manager pour les ressources que l'agent doit protéger. Par exemple, si l'agent se situe à l'emplacement host.example.com:80 , définissez une stratégie pour la ressource comme suit : http://host.example.com:80/* .
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
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.
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é.
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.
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 :
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 .
Redémarrez le conteneur Web d'Access Manager pour appliquer les valeurs.
É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.
Dans le patch 5 les modifications suivantes ont été apportées aux scripts de réglage des performances :
Prise en charge d'un fichier de mots de passe par les scripts de réglage
Le script de réglage supprime les ACI inutiles de Directory Server
Réglage des systèmes d'exploitation Solaris et Linux au moyen d'un script amtune-os unique
Exécution complète des scripts de réglages dans une zone locale de Solaris 10
Réglages à prendre en compte pour les serveurs Sun Fire T1000 et T2000
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.
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 .
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 :
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.
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 .
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.
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.
Pour modifier les réglages, configurez le fichier AMTUNE_MODE=CHANGE dans amtune-env.
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.
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.
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.
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 :
Les scripts pour Windows sont écrits en Perl et ne peuvent être exécutés sans Active Perl 5.8.
Si vous réglez Directory Server, vous devez copier les fichiers amtune-utils.pl, amtune-directory.pl, remacis.ldif et amtune-samplepassordfile sur Directory Server après avoir exécuté le script amtune-prepareDSTuner.pl car ce dernier ne peut pas compresser ces fichiers.
Aucun script de réglage de Windows n'est disponible.
Aucune prise en charge des zones n'est fournie.
Avant d'exécuter un script, vous devez configurer le paramètre $BASEDIR pour accéder au répertoire d'installation d'Access Manager dans le fichier amtune-env.pl.
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.
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 :
DESGenKey.java génère une touche unique utilisée pour chiffrer et déchiffrer le mot de passe de l'utilisateur.
ReplayPasswd.java lit la valeur de chiffrement à partir de la propriété com.sun.am.replaypasswd.key dans le fichier AMConfig.properties, chiffre le mot de passe et l'affecte à la propriété de session sunIdentityUserPassword.
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 :
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
Attribuez la valeur de clé de chiffrement de l'étape 1 à la propriété com.sun.am.replaypasswd.key dans le fichier AMConfig.properties.
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 :
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.
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 .
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.
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.
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 :
Systèmes Solaris : /etc/opt/SUNWam/config/xml
Systèmes Linux et HP-UX : /etc/opt/sun/identity/config/xml
Solution : Modifiez les fichiers amAuthLDAP.xml et amPolicyConfig.xml, puis supprimez le mot de passe en clair.
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 :
Connectez-vous au serveur Access Manager en tant que superutilisateur(root).
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.
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
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 :
Appliquez le patch 5.
Modifiez le fichier amsilent et redéployez la première instance d'Access Manager.
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 :
Systèmes Solaris : /etc/opt/SUNWam/config
Systèmes Linux : /etc/opt/sun/identity/config
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é.
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 :
Exécutez le script amconfig avec DEPLOY_LEVEL=14 pour désinstaller le SDK et annuler la configuration du conteneur Web.
Exécutez le script amconfig avec DEPLOY_LEVEL=4 pour réinstaller le SDK et reconfigurer le conteneur Web.
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
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.
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.
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 :
L'URL est relatif et aucune page correspondante n'est disponible sur le serveur d'interface utilisateur d'authentification distribuée.
L'URL est absolu et le navigateur ne peut pas y accéder.
Solution : spécifiez toujours un paramètre d'URL goto explicite pour un serveur d'interface utilisateur d'authentification distribuée.
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 :
Plates-formes SE Solaris, SPARC et x86 : 119725-04
SE Linux 120834-02
Ces patchs sont accessibles sur le site Web de SunSolve : http://sunsolve.sun.com.
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.
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.
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.
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
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 :
Dans le fichier AMConfig.properties, configurez la propriété sur la nouvelle valeur. Exemple :
com.iplanet.am.session.purgedelay=5
Redémarrez le conteneur Web d'Access Manager pour appliquer la nouvelle valeur.