test

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

Versions de patchs Access Manager 7 2005Q4

Les dernières versions des patchs d'Access Manager 7 2005Q4 peuvent être téléchargées sur SunSolve Online à l'adresse suivante : http://sunsolve.sun.com. Les derniers ID de patch sont les suivants :

Remarque –

Les patchs d'Access Manager 7 2005Q4 peuvent être cumulés. Vous pouvez installer le patch 7 sans installer d'abord le patch 1, 2, 3, 4, 5 ou 6. Cependant, si vous n'avez pas installé un patch antérieur, vérifiez les nouvelles fonctions et problèmes dans les sections relatives aux patchs précédents pour déterminer si l'un d'eux s'appliquent à votre déploiement.

Les informations sur les patchs d'Access Manager 7 2005Q4 sont notamment :

Access Manager 7 2005Q4 Patch 7

Le patch 7 (révision 7) d'Access Manager 7 résout de nombreux problèmes, répertoriés dans le fichier LISEZMOI accompagnant le patch.

Le patch 7 inclut les modifications suivantes :

CR# 6637806 : au redémarrage, Access Manager envoyait un jeton SSO d'application incorrect à un agent

Après un redémarrage du serveur Access Manager, le SDK du client Access Manager envoie maintenant une exception significative à un agent afin que ce dernier puisse s'authentifier de nouveau pour obtenir une nouvelle session d'application. Auparavant, après l'application du patch 5 d'Access Manager 7 2005Q4, le SDK du client Access Manager envoyait un jeton SSO d'application incorrect au redémarrage du serveur Access Manager.

Ce problème a été résolu par le doublon CR 6496155. Le patch 7 inclut également une option (propriété comp.iplanet.dpro.session.dnRestrictionOnly) permettant d'envoyer le jeton SSO d'application dans un contexte restrictif. Par défaut, les agents envoient l'adresse IP du serveur où ils sont installés. Toutefois, si une vérification stricte du DN s'avère nécessaire, définissez cette propriété dans le fichier AMConfig.properties comme suit :

com.iplanet.dpro.session.dnRestrictionOnly=true

CR# 6612609 : le basculement de session fonctionne si le câble réseau est débranché du serveur Message Queue

Lors du déploiement d'un basculement de session, si chaque instance d'Access Manager et courtier Message Queue sont installés sur le même serveur, le basculement de session fonctionne si un câble réseau est débranché d'un des serveurs. Par défaut, l'attribut de fabrique de connexion imqAddressListBehavior de Message Queue est défini sur PRIORITY, ce qui amène Message Queue à essayer les adresses par ordre d'apparition dans la liste d'adresses du courtier (par exemple : localhost:7777,server2:7777,server3:7777). Si l'attribut est défini sur RANDOM, les adresses sont essayées dans le désordre.

Pour définir cet attribut sur RANDOM, définissez le paramètre suivant dans le script amsessiondb :

-DimqAddressListBehavior=RANDOM

Pour plus d'informations sur les attributs PRIORITY et RANDOM de Message Queue, reportez-vous à la section Broker Address List du Sun Java System Message Queue 3.7 UR1 Administration Guide.

CR# 6570409 : le service Interaction derrière l'équilibreur de charge fonctionne correctement en tant que fournisseur d'identités

Lors d'un déploiement impliquant deux serveurs connectés à un équilibreur de charge et fonctionnant en tant que fournisseur d'identités, vous devez définir les propriétés suivantes dans le fichier AMConfig.properties :

com.sun.identity.liberty.interaction.lbWspRedirectHandler
com.sun.identity.liberty.interaction.trustedWspRedirectHandlers

La classe com.sun.identity.liberty.interaction.interactionConfigClass est actuellement la seule prise en charge. Ainsi, par défaut, la classe de configuration de l'interaction intégrée à Federation Liberty est utilisée pour accéder aux paramètres de configuration de l'interaction.

CR# 6545176 : les URL de redirection peuvent être définis de façon dynamique dans le plug-in de la SPI de traitement de la post-authentification

Les URL de redirection peuvent être définis de façon dynamique dans les plug-ins de la SPI de traitement de la post-authentification pour la réussite et l'échec de connexion, ainsi que pour la déconnexion. Si un plug-in de post-traitement n'est pas exécuté, l'URL de redirection défini dans la SPI de post-traitement n'est pas utilisé et les URL de redirection définis par tout autre moyen seront exécutés comme auparavant.

Pour plus d'informations, reportez-vous à l'exemple com.iplanet.am.samples.authentication.spi.postprocess.ISAuthPostProcessSample.java.

Remarques relatives à la pré-installation

Sauvegarde de fichiers

Important Si vous avez personnalisé des fichiers de votre installation, sauvegardez-les avant d'installer le patch. Une fois le patch installé, comparez les fichiers sauvegardés avec les nouveaux fichiers installés par ce patch afin de repérer vos personnalisations. Fusionnez les fichiers personnalisés avec les nouveaux et enregistrez-les. Pour plus d'informations sur la gestion de fichiers personnalisés, lisez les informations suivantes.

Sauvegardez également les fichiers suivants avant d'installer un patch :

Systèmes Solaris

  • AccessManager-base/SUNWam/bin/amsfo

  • AccessManager-base/SUNWam/lib/amsfo.conf

  • Fichiers inclus dans le répertoire /etc/opt/SUNWam/config/xml/template/ :

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml, amAuth.xml , amSession.xml

  • Fichiers inclus dans le répertoire AccessManager-base/SUNWam/locale/  :

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

Systèmes Linux et HP-UX

  • AccessManager-base/identity/bin/amsfo

  • AccessManager-base/identity/lib/amsfo.conf

  • Fichiers inclus dans le répertoire /etc/opt/sun/identity/config/xml/template/  :

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml , amAuth.xml, amSession.xml

  • Fichiers inclus dans le répertoire AccessManager-base/identity/locale/  :

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

Systèmes Windows

  • AccessManager-base\identity\setup\AMConfigurator.properties

  • AccessManager-base\identity\bin\amsfo

  • AccessManager-base\identity\lib\amsfo.conf

  • Fichiers inclus dans le répertoire AccessManager-base\identity\config\xml\template  :

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml , amAuth.xml, amSession.xml

  • Fichiers inclus dans le répertoire AccessManager-base\identity\locale  :

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

AccessManager-base correspond au répertoire d'installation de base. Le répertoire d'installation de base par défaut dépend de la plate-forme :

  • Systèmes Solaris : /opt

  • Systèmes Linux et HP-UX : /opt/sun

  • Systèmes Windows : javaes-install-directory\AccessManager . Exemple : C:\Program Files\Sun\AccessManager

Installation et configuration d'Access Manager

Les patchs d'Access Manager décrits dans ce document n'installent pas Access Manager. Avant d'installer le patch, vous devez installer Access Manager 7 2005Q4 sur le serveur. Pour plus d'informations sur l'installation, reportez-vous au manuel Guide d’installation de Sun Java Enterprise System 2005Q4 pour UNIX.

Si vous installez le patch sous Windows, consultez le Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows .

Vous devez savoir exécuter le script amconfig pour déployer, redéployer et configurer Access Manager, comme décrit dans le Chapitre 1, Access Manager 7 2005Q4 Configuration Scripts du Sun Java System Access Manager 7 2005Q4 Administration Guide.

Pour obtenir une liste des patchs d'Access Manager rendus obsolètes par ce patch et tout autre patch à installer avant celui-ci, consultez le fichier LISEZMOI fourni avec ce patch.

Attention – Attention –

Les patchs d'Access Manager (ainsi que tout autre patch) doivent être testés sur un système intermédiaire ou de pré-déploiement avant de les installer dans un environnement de production. De plus, le programme d'installation du patch peut ne pas mettre à jour correctement vos fichiers JSP personnalisés. Vous devrez donc peut-être les modifier manuellement pour qu'Access Manager fonctionne correctement.

Instructions d'installation du patch

Instructions d'installation du patch pour les systèmes Solaris

Avant d'installer le patch pour Solaris, n'oubliez pas de sauvegarder les fichiers répertoriés sous Remarques relatives à la pré-installation.

Pour ajouter ou supprimer des patchs sur des systèmes Solaris, utilisez les commandes patchadd et patchrm fournies avec le système d'exploitation.

Commande patchadd

Utilisez la commande patchadd pour installer un patch sur un système autonome. Exemple :

# patchadd /var/spool/patch/120954-07
Remarque –

Si vous installez le patch pour Solaris dans la zone globale de Solaris 10, appelez la commande patchadd avec l'argument -G. Exemple :

patchadd -G /var/spool/patch/120954-07

Le script postpatch affiche un message relatif au redéploiement des applications Access Manager, sauf sur un système sur lequel seul le composant SDK d'Access Manager est installé.

Le script postpatch crée le fichier amsilent dans le répertoire suivant :

AccessManager-base correspond au répertoire d'installation de base. Le répertoire d'installation de base par défaut est /opt sous Solaris et /opt/sun sous Linux.

Le fichier amsilent est basé sur le fichier amsamplesilent, mais certains paramètres requis sont définis en fonction des fichiers de configuration d'Access Manager sur le système. Les paramètres de mot de passe contiennent cependant des valeurs par défaut. Supprimez le commentaire et modifiez la valeur de chaque paramètre de mot de passe et vérifiez les autres paramètres du fichier en fonction de votre déploiement.

Le paramètre COMMON_DEPLOY_URI, le préfixe URI des applications Web de domaine communes, contient également une valeur par défaut. Si vous avez sélectionné une autre valeur que la valeur par défaut pour cette URI, n'oubliez pas de la mettre à jour. Dans le cas contraire, le redéploiement des applications Web avec amconfig et le fichier amsilent généré par le patch échouent.

Exécutez ensuite la commande suivante (Access Manager installé dans le répertoire par défaut) :

# cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent
Attention – Attention –

Comme le fichier amsilent contient des données sensibles (mots de passe administrateur en clair, etc.), veillez à le protéger de manière appropriée en fonction de votre déploiement.

Après avoir exécuté le script amconfig, exécutez le script updateschema.sh pour charger les fichiers XML et LDIF. Le script updateschema.sh est disponible une fois le patch 7 installé dans le répertoire suivant :

Redémarrez les processus d'Access Manager une fois le script updateschema exécuté. Exemple :

# cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

Redémarrez ensuite le conteneur Web d'Access Manager.

Commande patchrm

Utilisez la commande patchrm pour supprimer un patch d'un système autonome. Exemple :

# patchrm 120954-03

Le script backout affiche un message identique à la commande patchadd, sauf sur un système sur lequel seul le composant SDK d'Access Manager est installé.

Une fois le patch supprimé, redéployez les applications Access Manager à l'aide du fichier amsilent dans le répertoire AccessManager-base /SUNWam, où AccessManager-base correspond au répertoire d'installation de base. Le répertoire d'installation de base est /opt sous Solaris.

Définissez les paramètres du fichier amsilent en fonction de votre déploiement.

Exécutez ensuite la commande suivante, accessible dans le répertoire par défaut sous Solaris une fois Access Manager installé :

# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent

Pour plus d'informations et d'exemples sur les commandes patchadd et patchrm, reportez-vous aux pages de manuel man Solaris correspondantes.

Voir aussi Remarques relatives à la post-installation pour plus d'informations.

Zones Solaris 10

Le système d'exploitation Solaris 10 a introduit le nouveau concept de 'zones'. La commande patchadd inclut donc la nouvelle option -G qui permet d'ajouter un patch à la zone globale uniquement. Par défaut, la commande patchadd recherche la variable SUNW_PKG_ALLZONES dans le pkginfo des packages à fournir en patch. Pour tous les packages Access Manager, la variable SUNW_PKG_ALLZONES n'est cependant pas définie et l'option -G est nécessaire si Access Manager 7 2005Q4 est installé dans la zone globale. L'option patchadd -G ne s'applique pas si Access Manager est installé dans une zone locale.

Si vous installez les patchs Access Manager 7 2005Q4 sur un système Solaris, il est recommandé d'utiliser l'option -G. Exemple :

 # patchadd -G AM7_patch_dir

De même, si Access Manager est installé dans la zone globale, l'option -G est nécessaire pour exécuter la commande patchrm. Exemple :

# patchrm -G 120954-07

Instructions d'installation du patch pour les systèmes Linux

Avant d'installer le patch pour Linux, n'oubliez pas de sauvegarder les fichiers répertoriés sous Remarques relatives à la pré-installation.

La commande installpatch installe un patch sur un système Linux autonome. Exemple :

# ./installpatch

Le script postpatch affiche des messages identiques à ceux d'un système Solaris. La procédure de sortie d'un patch sur un système Linux est cependant différente de celle sur un système Solaris. Il n'existe pas de script générique de sortie d'un patch Linux. Si une version antérieure du patch a été préalablement installée, vous pouvez réinstaller cette version puis suivre les instructions de postpatch afin de redéployer les applications Access Manager en exécutant le script amconfig.

Après avoir exécuté le script amconfig, exécutez le script updateschema.sh (patchs 5 et ultérieurs) pour charger les fichiers XML et LDIF. Le script updateschema.sh est disponible une fois le patch 7 installé dans le répertoire patch-home-directory/120956-07/scripts .

Redémarrez le conteneur Web d'Access Manager après avoir exécuté les scripts amconfig et updateschema.sh .

Si le patch est installé sur la version Access Manager 7 2005Q4 RTM et que vous souhaitez le supprimer et restaurer le système à l'état RTM, vous devez reinstaller Access Manager RTM à l'aide du script reinstallRTM. Ce script utilise le chemin d'accès au stockage des RPM Access Manager RTM et installe les RPM RTM sur les RPM du patch. Exemple :

# ./scripts/reinstallRTM path_of_AM7_RTM_RPM_directory

Après avoir exécuté le script reinstallRTM, redéployez les applications Access Manager en exécutant le script amconfig et redémarrez le conteneur Web.

Voir aussi Remarques relatives à la post-installation pour plus d'informations.

Instructions d'installation du patch pour les systèmes Windows

Conditions requises pour installer le patch pour Windows :

Installation du patch pour Windows

Avant d'installer le patch pour Windows, n'oubliez pas de sauvegarder les fichiers répertoriés sous Remarques relatives à la pré-installation.

Utilisez une barre oblique (/) dans le chemin d'accès au répertoire de base de saisie des scripts de patchs. Exemple : c:/sun

Pour installer le patch pour Windows :

  1. Connectez-vous à Windows en tant qu'administrateur.

  2. Créez un répertoire où télécharger et décompresser le fichier de patch pour Windows. Par exemple : AM7p7

  3. Téléchargez et décompressez le fichier 124296-07.zip dans le répertoire créé lors de l'étape précédente.

  4. Arrêtez tous les services Java ES 2005Q4.

  5. Exécutez le script AM7p7\scripts\prepatch.pl.

  6. Exécutez le fichier AM7p7\124296-07.exe pour installer le patch.

  7. Exécutez le script AM7p7\scripts\postpatch.pl.

  8. Redémarrez les services Java ES 2005Q4.

  9. Redéployez les applications Access Manager. Voir Remarques relatives à la post-installation pour plus d'informations.

  10. Exécutez le script AM7p7\scripts\updateschema.pl pour mettre à jour le schéma de service de Directory Server. Le script valide vos entrées et charge les fichiers. Le script écrit aussi le fichier journal suivant :

    javaes-install-directory\AccessManager\AM70Patch-upgrade-schema- timestamp

  11. Redémarrez les services Java ES 2005Q4.

Suppression du patch pour Windows

Pour supprimer le patch pour Windows :

  1. Connectez-vous à Windows en tant qu'administrateur.

  2. Exécutez le fichier Uninstall_124296-07.bat.

  3. Exécutez le script AM7p7\scripts\postbackout.pl.

  4. Redéployez les applications Access Manager.

  5. Redémarrez les services Java ES 2005Q4.

Remarque : Si vous retirez le patch, les modifications du schéma ajoutées par le script AM7p7\scripts\updateschema.pl 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é.

Instructions d'installation du patch pour les systèmes HP-UX

Pour installer ou supprimer le patch HP-UX, utilisez les commandes swinstall et swremove. Par exemple, pour installer le patch sur un système autonome :

# swinstall /var/spool/patch/126371-07

Ou, pour supprimer le patch d'un système autonome :

# swremove 126371-07

Pour plus d'informations sur les commandes swinstall et swremove , consultez l'aide en ligne de swinstall et swremove .

Après avoir installé ou supprimé le patch, vous devez redéployer les applications Access Manager comme décrit dans la section Remarques relatives à la post-installation.

Après avoir redéployé les applications Access Manager, exécutez le script updateschema.sh (patch 5 et versions ultérieures) pour charger les fichiers XML et LDIF. Le script updateschema.sh est disponible après avoir installé le patch 7 dans le répertoire patch-home-directory/120956-07/scripts . Redémarrez le conteneur Web d'Access Manager après avoir exécuté les scripts amconfig et updateschema.sh .

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

Pour plus d'informations sur le déploiement d'Access Manager sous HP-UX, reportez-vous aux Sun Java System Access Manager 7 2005Q4 Release Notes for HP-UX.

Remarques relatives à la post-installation

Ces remarques après l'installation du patch Access Manager 7 2005Q4 sont :

CR# 6254355 : Les patchs d'Access Manager ne déploient pas les applications Access Manager dans des scripts postpatch.

Le programme d'installation du patch peut ne pas conserver certains fichiers personnalisés et les remplace par des versions standard. Pour vous aider à identifier, puis à mettre à jour le contenu personnalisé d'un fichier WAR, suivez la procédure suivante.

Dans les exemples suivants, AccessManager-base correspond au répertoire d'installation de base. Le répertoire d'installation de base par défaut est /opt sous Solaris et /opt/sun sous Linux.

Sous Windows, AccessManager-base est javaes-install-directory\AccessManager. Exemple : C:\Program Files\Sun\AccessManager

Les fichiers WAR mis en patch sont :

Ces fichiers sont situés dans AccessManager-base/SUNWam sous Solaris et AccessManager-base/identity sous Linux.

Sur les systèmes Windows : les fichiers WAR appartenant au patch figurent dans AccessManager-base\.

Le contenu modifiable d'un fichier WAR inclut :

Pour conserver toutes les personnalisations, suivez les étapes ci-dessous. Sauvegardez toujours un fichier avant d'y apporter des modifications.

  1. Installez le patch.

  2. Ouvrez les fichiers WAR dans un répertoire temporaire. Par exemple, lorsque Access Manager est installé dans le répertoire par défaut sous Solaris :

    # cd temporary-directory 
# jar -xvf /opt/SUNWam/console.war
# jar -xvf /opt/SUNWam/services.war
# jar -xvf /opt/SUNWam/password.war

  3. Consultez les fichiers ouverts pour savoir si le programme d'installation a apporté des modifications à vos fichiers personnalisés et ajoutez vos personnalisations manuellement dans les fichiers modifiés du répertoire temporaire. Vous ne devez pas répéter les modifications des fichiers du répertoire AccessManager-base/web-src/ mais non reproduites dans les fichiers WAR du patch.

  4. Mettez à jour les fichiers WAR en fonction des fichiers modifiés : Par exemple, lorsque Access Manager est installé dans le répertoire par défaut sous Solaris :

    # cd temporary-directory
# jar -uvf /opt/SUNWam/console.war $path/$modified file
# jar -uvf /opt/SUNWam/services.war $path/$modified file
# jar -uvf /opt/SUNWam/password.war $path/$modified file

    Par exemple, pour les étapes 2 à 4 :

    # mkdir /tmp/war.tmp 
# cd /tmp/war.tmp
# jar -xvf /opt/SUNWam/services.war
# vi index.html
# jar -uvf /opt/SUNWam/services.war index.html

  5. Réutilisez le fichier de configuration (amsilent) généré par le patch ou créez-en un nouveau basé sur le modèle amsamplesilent, puis définissez les variables de configuration appropriées du fichier, notamment :

    • DEPLOY_LEVEL=21

    • DIRECTORY_MODE=5

    • Les mots de passe pour DS_DIRMGRPASSWD, ADMINPASSWD et AMLDAPUSERPASSWD

    • Variables du conteneur Web d'Access Manager

    Sous Windows, réutilisez le fichier silencieux de configuration (amsilent ) généré par le script postpatch.pl et assurez-vous que AccessManager-base\setup\AMConfigurator.properties-tmp possède des valeurs valides. Renommez ensuite ce fichier en AccessManager-base \setup\AMConfigurator.properties.

    Pour plus d'informations sur les variables du conteneur Web, consultez le fichier amsamplesilent du répertoire /opt/SUNWam/bin sur les systèmes Solaris ou du répertoire /opt/sun/identity/bin sur les systèmes Linux.

    Sous Windows, le fichier de configuration est AccessManager-base\setup\AMConfigurator.properties.

  6. Exécutez le script amconfig comme illustré ci-dessous. Directory Server et le conteneur Web d'Access Manager doivent être en cours d'exécution avant d'exécuter amconfig. Par exemple, pour exécuter amconfig sur un système Solaris sur lequel Access Manager est installé dans le répertoire d'installation de base par défaut : 

    # cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent

  7. Redémarrez les processus d'Access Manager une fois le script amconfig exécuté. Exemple :

    # cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

  8. Assurez-vous que tous les fichiers JSP personnalisés résident dans les sous-répertoires appropriés du répertoire AccessManager-base/SUNWam/web-src/ sous Solaris ou AccessManager-base /identity/web-src/ sous Linux et que vous les avez tous sauvegardés.

    Sous Windows, les fichiers figurent dans AccessManager-base\web-src\ .

  9. Redémarrez le conteneur Web d'Access Manager.

Pour plus d'informations sur l'exécution du script amconfig, reportez-vous à : Chapitre 1, Access Manager 7 2005Q4 Configuration Scripts du Sun Java System Access Manager 7 2005Q4 Administration Guide.

CR# 6436409 : Redéploiement des fichiers WAR d'authentification distribuée et de SDK client

Si vous utilisez l'authentification distribuée ou le SDK client, recréez ou redéployez le fichier WAR d'authentification distribuée et/ou le fichier WAR de SDK client après avoir installé le patch. Pour plus d'informations, reportez-vous aux documents suivants :

Access Manager 7 2005Q4 Patch 6

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

Nouvelles fonctions du patch 6

Problèmes et restrictions connus du patch 6

Remarque –

Avant d'installer le patch 6, nous vous recommandons de mettre à niveau ou d'appliquer un patch aux composants suivants :

Access Manager prend en charge la méthode setReadTimeout HttpURLConnection de JDK 1.5

Pour prendre en charge la méthode setReadTimeout, le fichier AMConfig.properties inclut la nouvelle propriété suivante qui vous permet de définir la valeur du délai d'attente de lecture : 

com.sun.identity.url.readTimeout

Si le conteneur Web utilise JDK 1.5, définissez cette propriété sur une valeur appropriée qui provoque le dépassement du délai des connexions, afin d'éviter qu'un trop grand nombre de HttpURLConnections ouvertes n'entraîne une suspension du serveur. La valeur par défaut est 30 000 millisecondes (30 secondes).

La méthode setReadTimeout est ignorée si com.sun.identity.url.readTimeout ne figure pas dans le fichier AMConfig.properties ou s'il est défini sur une chaîne vide.

Access Manager SDK rétablit le serveur d'annuaire principal après une remise en service du noeud principal

Si Sun Java System Directory Server est configuré pour une réplication multimaître (MMR), le SDK d'Access Manager rétablit le serveur d'annuaire principal après une panne et une remise en service immédiate du serveur principal. Auparavant, le SDK d'Access Manager continuait d'accéder au serveur d'annuaire secondaire, même après la remise en service du serveur principal.

Pour prendre en charge ce nouveau comportement, Access Manager inclut la nouvelle propriété suivante dans le fichier AMConfig.properties :

com.sun.am.ldap.fallback.sleep.minutes

Cette propriété définit la période en minutes pendant laquelle une instance de serveur d'annuaire secondaire est mise en veille avant de revenir au serveur principal une fois le serveur principal remis en service. La valeur par défaut est 15 minutes.

La propriété com.sun.am.ldap.fallback.sleep.minutes est masquée. Pour définir cette propriété sur une valeur différente de la valeur par défaut (15 minutes), ajoutez-la explicitement au fichier AMConfig.properties. Par exemple, pour définir la valeur sur 7 minutes :

com.sun.am.ldap.fallback.sleep.minutes=7

Pour que la nouvelle valeur soit validée, redémarrez le conteneur Web d'Access Manager.

Les instances multiples d'Access Manager sont consignées dans des fichiers journaux distincts

Les instances multiples d'Access Manager exécutées sur le même serveur hôte peuvent désormais être consignées dans des fichiers journaux distincts résidant dans différentes sous-répertoires de journalisation en définissant la nouvelle propriété suivante dans le fichier AMConfig.properties :

com.sun.identity.log.logSubdir

Si vous ne modifiez pas le répertoire de journalisation par défaut dans la console d'administration, les répertoires de journalisation par défaut sont les suivants :

La première instance d'Access Manager est toujours consignée dans le répertoire de journalisation par défaut. Pour spécifier d'autres sous-répertoires de journalisation pour des instances d'Access Manager supplémentaires, définissez la propriété com.sun.identity.log.logSubdir dans le fichier AMConfig.properties pour chaque nouvelle instance d'Access Manager.

Par exemple, si vous disposez de trois instances, am-instance-1, am-instance-2, et am-instance-3, toutes exécutées sur le même serveur hôte Solaris, définissez la propriété comme suit :

com.sun.identity.log.logSubdir=am-instance-2
com.sun.identity.log.logSubdir=am-instance-3

La propriété com.sun.identity.log.logSubdir est masquée. Vous devez ajouter explicitement cette propriété au fichier AMConfig.properties approprié et redémarrer le conteneur Web d'Access Manager pour que les valeurs de sous-répertoires soient validées.

Les instances d'Access Manager sont ensuite consignées dans les répertoires suivants :

/var/opt/SUNWam/logs/log-files-for-am-instance-1
/var/opt/SUNWam/logs/am-instance-2/log-files-for-am-instance-2
/var/opt/SUNWam/logs/am-instance-3/log-files-for-am-instance-3

Access Manager 7 autorise plusieurs domaines de cookie

Pour prendre en charge plusieurs domaines de cookie, Access Manager inclut la nouvelle propriété suivante :

com.sun.identity.authentication.setCookieToAllDomains

La valeur par défaut est true. Cette nouvelle propriété est masquée. Pour définir la valeur sur false, ajoutez explicitement la propriété au fichier AMConfig.properties et redémarrez le conteneur Web d'Access Manager.

Le plug-in de post-authentification de Microsoft IIS 6.0 prend en charge SharePoint Server

Le plug-in d'authentification de Microsoft Internet Information Services (IIS) 6.0 prend en charge Microsoft Office SharePoint Server. Un utilisateur peut se connecter à Access Manager à l'aide d'un ID utilisateur ou d'un nom de connexion. SharePoint Server accepte néanmoins un nom de connexion, ce qui pose problème lorsque l'utilisateur spécifie un ID utilisateur.

Pour permettre la connexion à SharePoint Server, le plug-in de post-authentification (ReplayPasswd.java) utilise maintenant la nouvelle propriété suivante :

com.sun.am.sharepoint_login_attr_name

Cette nouvelle propriété indique l'attribut utilisateur employé par SharePoint Server pour l'authentification. Par exemple, la propriété suivante spécifie le nom commun (cn) pour l'authentification : 

com.sun.am.sharepoint_login_attr_name=cn

Le plug-in de post-authentification lit la propriété com.sun.am.sharepoint_login_attr_name et obtient la valeur d'attribut correspondante pour l'utilisateur de Directory Server. Le plug-in définit ensuite les en-têtes d'autorisation qui permettent à l'utilisateur d'accéder à SharePoint Server.

Cette propriété est masquée. Pour définir la propriété, ajoutez-la explicitement au fichier AMConfig.properties, puis redémarrez le conteneur Web d'Access Manager pour que la valeur soit validée.

Access Manager prend en charge Internet Explorer 7

Le patch 6 d'Access Manager 7 2005Q4 prend maintenant en charge Microsoft Windows Internet Explorer 7.

CR# 6379325 Accéder à la console pendant le basculement de session renvoie une exception de pointeur null

Dans ce scénario, plusieurs serveurs Access Manager sont déployés en mode basculement de session derrière un équilibreur de charge configuré pour le routage des demandes d'association basé sur des cookies. L'administrateur d'Access Manager accède à la console Access Manager via l'équilibreur de charge. Lorsque l'administrateur se connecte à la console, la session est créée sur l'un des serveurs Access Manager. Si ce serveur tombe en panne, la session de la console bascule comme prévu vers un autre serveur Access Manager. Cependant, l'administrateur rencontre parfois des exceptions de pointeur null intermittentes sur le navigateur et dans le journal d'erreurs du conteneur Web.

Ce problème ne concerne que la session active de la console Access Manager au moment du basculement et n'affecte pas le fonctionnement des serveurs Access Manager.

Solution : pour empêcher ces exceptions de pointeur null intermittentes de se produire :

CR# 6508103 : sous Windows, cliquer sur Aide dans la console d'administration renvoie une erreur d'application

Sous Windows 2003 Édition Entreprise avec Access Manager déployé sur Sun Java System Application Server dans un environnement linguistique autre que l'anglais, cliquer sur Aide dans la console en mode Domaine d'administration renvoie une erreur d'application.

Solution :

  1. Copiez le fichier javaes-install-dir\share\lib\jhall.jar dans le répertoire %JAVA_HOME%\jre\lib\ext.

    où javaes-install-dir correspond au répertoire d'installation de Windows

  2. Redémarrez l'instance du serveur d'application.

CR# 6564877 : l'installation du patch 7 d'Access Manager entraîne l'écrasement des fichiers SAML v2

Si le plug-in SAML v2 est installé, l'installation du patch entraîne l'écrasement des fichiers associés à SAML v2 et le scriptpostpatch affiche le message suivant :

Le script postpatch a détecté que le plug-in SAML v2 est installé dans votre environnement. Lorsque vous exécutez le script amconfig pour redéployer les applications Access Manager, le script recrée le fichier amserver.war et les fichiers associés à SAML v2 sont perdus. Par conséquent, une fois le script amconfig exécuté, recréez et redéployez le fichier amserver.war, comme décrit dans le Guide de l'utilisateur du plug-in Sun Java System SAML v2 pour les services de fédération.

Solution : après avoir installé le patch et exécuté le script amconfig, recréez et redéployez le fichier amserver.war pour les déploiements de Federation Manager ou d'Access Manager qui utilisent le plug-in SAML v2.

Pour les étapes spécifiques, reportez-vous au Chapitre 2, Installing the SAML v2 Plug-in for Federation Services du Sun Java System SAML v2 Plug-in for Federation Services User’s Guide.

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.

Access Manager 7 2005Q4 Patch 4

Access Manager 7 2005Q4 patch 4 (révision 04) résout les problèmes suivants :

Problèmes et restrictions connus du patch 4

CR# 6470055 : amélioration des performances du serveur d'interface utilisateur d'authentification distribuée

Pour améliorer les performances de lecture, de recherche et de comparaison des attributs utilisateur d'un utilisateur du serveur d'interface utilisateur d'authentification distribuée, procédez comme suit :

  1. Dans le fichier Makefile.distAuthUI, remplacez le nom d'utilisateur de l'application anonymous par un autre utilisateur. Exemple : 

    APPLICATION_USERNAME=user1

  2. Dans Directory Server, ajoutez le nouveau nom (user1 dans l'exemple) et l'ACI pour pouvoir lire, rechercher et comparer les attributs utilisateur. Le nouvel ACI est ajouté dans l'exemple suivant :

    dn:ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com 
changetype:modify add:aci 
aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com")
(targetattr = *")(version 3.0; 
acl "SunAM client data access to a Distributed Auth App User"; 
allow (read, search, compare) 
userdn =  "ldap:///uid=user1,ou=people,dc=example,dc=com";)

CR# 6455079 : le service de réinitialisation des mots de passe signale des erreurs de notification lors de la modification d'un mot de passe

Lors de la modification d'un mot de passe, Access Manager envoie la notification par e-mail en utilisant un nom d'expéditeur non qualifié Identity-Server, ce qui provoque des entrées d'erreur dans les journaux amPasswordReset. Exemple :

07/19/2006 10:26:04:010 AM PDT: Thread[service-j2ee,5,main]
ERROR: Could not send email to user [Ljava.lang.String;@999262
com.sun.mail.smtp.SMTPSendFailedException: 553 5.5.4 <Identity-Server>...
Domain name required for sender address Identity-Server

Solution : Modifiez l'adresse de l'expéditeur pour ajouter le nom de domaine complet du serveur hôte dans le fichier amPasswordResetModuleMsgs.properties :

  1. Modifiez l'étiquette de l'adresse de l'expéditeur. Exemple :

    fromAddress.label=<Identity-Server@amhost.example.com>

  2. Modifiez la propriété lockOutEmailFrom pour assurer que les notifications de verrouillage utilisent l'adresse correcte de l'expéditeur. Exemple :

    lockOutEmailFrom=<Identity-Server@amhost.example.com>

    Le fichier amPasswordResetModuleMsgs.properties réside dans le répertoire AccessManager-base/SUNWam/locale sous Solaris et dans le répertoire AccessManager-base/identity/locale sous Linux.

    AccessManager-base correspond au répertoire d'installation de base. Le répertoire d'installation de base par défaut est /opt sous Solaris et /opt/sun sous Linux.

Access Manager 7 2005Q4 Patch 3

Le patch 3 (révision 3) d'Access Manager 7 résout de nombreux problèmes, répertoriés dans le fichier LISEZMOI accompagnant le patch. Le patch 3 inclut également les nouvelles fonctions et problèmes connus suivants :

Nouvelles fonctions du patch 3

Problèmes et restrictions connus du patch 3

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

La fonction de contrôle de site d'Access Manager inclut les nouvelles propriétés suivantes :

Propriété 

Description 

com.sun.identity.sitemonitor.interval

Intervalle de contrôle de site exprimé en millisecondes. La fonction de contrôle de site vérifie la disponibilité de chaque site dans l'intervalle de temps spécifié. Par défaut : 6 0000 millisecondes (1 minute). 

com.sun.identity.sitemonitor.timeout

Délai de vérification de la disponibilité du site exprimé en millisecondes. La fonction de contrôle de site attend une réponse du site pendant le délai spécifié. Par défaut : 5 000 millisecondes (5 secondes).  

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 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

    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.

Mise en œuvre personnalisée. La classe com.sun.identity.sitemonitor.SiteStatusCheck vous permet en outre de personnaliser votre mise en œuvre de vérification de la disponibilité du site à l'aide de l'interface suivante :

package com.iplanet.services.naming.WebtopNaming$SiteStatusCheck

Chaque classe de mise en œuvre doit utiliser la méthode doCheckSiteStatus.

public interface SiteStatusCheck { 
public boolean doCheckSiteStatus(URL siteurl);
}

Prise en charge de Liberty Identity Web Services Framework (ID-WSF) 1.1

La version par défaut de ID-WSF dans le patch 3 d'Access Manager 7 est WSF1.1. Aucune autre configuration n'est nécessaire pour déclencher ID-WSF, à l'exception des exemples, qui doivent doivent utiliser les nouveaux mécanismes de sécurité. Les nouveaux mécanismes de sécurité pour ID-WSF1.1 sont :

urn:liberty:security:2005-02:null:X509
urn:liberty:security:2005-02:TLS:X509
urn:liberty:security:2005-02:ClientTLS:X509
urn:liberty:security:2005-02:null:SAML
urn:liberty:security:2005-02:TLS:SAML
urn:liberty:security:2005-02:ClientTLS:SAML
urn:liberty:security:2005-02:null:Bearer
urn:liberty:security:2005-02:TLS:Bearer
urn:liberty:security:2005-02:ClientTLS:Bearer

Nouvelle propriété pour la prise en charge de Liberty ID-WSF

La propriété com.sun.identity.liberty.wsf.version détermine la structure de Liberty ID-WSF lorsque celle-ci n'est pas en mesure de déterminer à partir du message entrant ou des ressources disponibles si Access Manager fait office de WSC. Les valeurs peuvent être 1.0 ou 1.1. La valeur par défaut est 1.1.

Remarque : l'installation du patch n'ajoute pas la propriété com.sun.identity.liberty.wsf.version au fichier AMConfig.properties (CR# 6458184). Pour utiliser cette nouvelle propriété, ajoutez-la au fichier AMConfig.properties avec la valeur appropriée après l'installation du patch, puis redémarrez le conteneur Web d'Access Manager.

Une fois Access Manager 7 patch 3 installé, exécutez la commande suivante, pour charger les modifications apportées au schéma. Cette commande est illustrée avec Access Manager installé dans le répertoire par défaut sous Solaris :

# /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password 
-t /etc/opt/SUNWam/wsf1.1_upgrade.xml

L'enregistrement de découverte ID-WSF peut utiliser ces nouveaux mécanismes de sécurité lors de l'enregistrement. Les WSC détecteront également automatiquement la version à utiliser lors d'une communication avec des WSP. Pour configurer pour ID-WSF1.1, consultez les fichiers LisezMoi de Liberty ID-FF sample1 et les exemples ID-WSF fournis avec le produit.

CR# 6463779 : Le journal amProfile_Client d'authentification distribuée et le journal amProfile_Server du serveur Access Manager répertorient les exceptions inoffensives.

Les demandes faites au serveur Access Manager via une interface utilisateur d'authentification distribuée entraîne la consignation d'exceptions dans le journal distAuth/amProfile_Client et dans le journal debug/amProfile_Server du serveur Access Manager. Après plusieurs sessions, le journal amProfile_Client peut atteindre plusieurs gigaoctets et le journal amProfile_Server du serveur Access Manager peut atteindre plusieurs mégaoctets. Ces exceptions n'entraînent aucune perte de fonctionnalité dans les journaux, mais peuvent provoquer une fausse alarme pour les utilisateurs et les journaux peuvent éventuellement saturer le disque dur.

Solution. Exécutez des tâches cron qui annuleront le contenu des fichiers journaux. Exemple :

CR# 6460974 : L'utilisateur de l'application d'authentification distribuée par défaut ne doit pas être amadmin

Si vous déployez un serveur d'interface utilisateur d'authentification distribuée, l'administrateur correspondant ne doit pas être amadmin. L'utilisateur de l'application d'authentification distribuée par défaut indiqué dans le fichier Makefile.distAuthUI est amadmin, et donc dans le fichier AMConfig.properties, une fois que le fichier distAuth.war est déployé côté client. L'utilisateur amadmin dispose d'un AppSSOToken expirant à la fin de la session amadmin, pouvant ainsi entraîner la consignation d'une ERREUR FATALE dans le fichier journal amSecurity (situé, par défaut, dans le répertoire /tmp/distAuth).

Solution. Spécifiez UrlAccessAgent comme utilisateur de l'application d'authentification distribuée. Exemple :

Avant de déployer le fichier distAuth.war du conteneur Web client, modifiez les paramètres suivants du fichier Makefile.distAuthUI :

APPLICATION_USERNAME=UrlAccessAgent
APPLICATION_PASSWORD=shared-secret-password or amldapuser-password

eur

Après avoir déployé le fichier distAuth.war du conteneur Web client, modifiez les propriétés suivantes du fichier AMConfig.properties pour chaque serveur Access Manager :

com.sun.identity.agents.app.username=UrlAccessAgent
com.iplanet.am.service.password=shared-secret-password or amldapuser-password

Voir aussi CR# 6440697 : L'authentification distribuée doit être exécutée en tant qu'utilisateur non administratif..

CR# 6460576 : Aucun lien vers le service utilisateur dans Rôle filtré dans l'aide en ligne de la console

L'aide en ligne de la console Access Manager ne comprend pas de lien vers le service utilisateur dans Rôle filtré. Dans l'aide en ligne, accédez au sommaire, à Rôle filtré, puis à la procédure de création d'un rôle filtré. Faites défiler la page vers le bas puis, en fonction du type d'identité sélectionné, une liste de services s'affiche mais aucun lien de service utilisateur n'est disponible.

Solution. aucune

CR# 6460085 : Le serveur sur WebSphere est inaccessible après l'exécution de reinstallRTM et le redéploiement d'applications Web.

Après l'application du patch 3 d'Access Manager 7 pour un déploiement DEPLOY_LEVEL=1 sur IBM WebSphere Application Server 5.1.1.6 sur Red Hat Linux AS 3.0 Update 4, le script reinstallRTM a été exécuté pour restaurer les RPM RTM. Les applications Web ont alors été redéployées après modification du fichier amsilent généré par le script reinstallRTM. WebSphere a été redémarré à l'aide des scripts stopServer.sh et startServer.sh. Toutefois, lors de l'accès à la page de connexion, WebSphere a affiché une erreur 500 liée au filtre amlcontroller.

Ce problème est survenu car le nouveau fichier server.xml généré par le script reinstallRTM était corrompu.

Solution. Le fichier server.xml sauvegardé à l'aide du script amconfig est toujours valide. Utilisez cette copie précédente, comme suit :

  1. Arrêtez le serveur.

  2. Remplacez le fichier server.xml corrompu par la copie sauvegardée à l'aide du script amconfig.

    Le fichier server.xml sauvegardé à l'aide du script amconfig sera nommé server.xml-orig- pid, où pid correspond à l'ID de processus du script amwas51config. Le fichier se trouve dans le répertoire suivant :

    WebSphere-home-directory/config/cells/WebSphere-cell
/nodes/WebSphere-node/servers/server-name

  3. Redémarrez le serveur.

CR# 6455757 : La classe de marqueurs sunISManagerOrganization doit être ajoutée à une organisation avant une mise à niveau.

Une organisation dans une arborescence d'informations d'annuaire (DIT) Access Manager créée avant Access Manager version 7 risque de ne pas disposer de la classe d'objet sunISManagerOrganization. La définition d'une organisation créée par un produit autre qu'Access Manager ne comprendra pas non plus la classe d'objet sunISManagerOrganization.

Solution. Avant de mettre à niveau en Access Manager 7 2005Q4, vérifiez que la définition de toutes les organisations de l'arborescence d'informations d'annuaire (DIT) comprend la classe d'objet sunISManagerOrganization. Si nécessaire, ajoutez manuellement cette classe d'objet avant la mise à niveau.

CR# 6454489 : La mise à niveau en Access Manager 7 2005Q4 Patch 2 entraîne une erreur dans l'onglet des sessions en cours de la console

Une mise à niveau a entraîné l'erreur suivante dans l'onglet des sessions en cours de la console Access Manager :

Failed to get valid Sessions from the Specified server

Ce problème s'applique aux déploiements mis à niveau des versions Access Manager 6 ne disposant pas de suffixe racine sous la forme o=orgname.

Solution. Après l'installation d'Access Manager 7 2005Q4, appliquez le patch 3 d'Access Manager 7 puis exécutez le script amupgrade pour migrer les données comme suit :

  1. Sauvegardez votre arborescence d'informations d'annuaire (DIT) Access Manager 6.

  2. Exécutez le script ampre70upgrade.

  3. Installez Access Manager 7 2005Q4 avec l'option de configuration ultérieure.

  4. Annulez le déploiement des applications Web d'Access Manager.

  5. Déployez les applications Web d'Access Manager.

  6. Appliquez le patch 3 d'Access Manager 7, mais pas les changements XML/LDIF. Les changements XML/LDIF doivent être appliqués après l'exécution du script amupgrade à l'étape suivante.

  7. Exécutez le script amupgrade.

  8. Redéployez les applications Web d'Access Manager en raison des changements du patch 3 d'Access Manager 7.

  9. Accédez à la console Access Manager.

CR# 6452320 : Les exceptions sont rejetées en cas d'interrogation avec SDK client.

Lorsque vous déployez le SDK client d'Access Manager (amclientsdk.jar) et que vous activez l'interrogation, des erreurs comme la suivante peuvent se produire :

ERROR: Send Polling Error:
com.iplanet.am.util.ThreadPoolException: 
amSessionPoller thread pool's task queue is full.

De telles erreurs peuvent se produire après avoir déployé un serveur d'interface utilisateur d'authentification distribuée, des agents J2EE ou dans toute autre situation de déploiement du SDK client d'Access Manager sur une machine client.

Solution. Si vous disposez de quelques centaines de sessions simultanées uniquement, ajoutez les propriétés et valeurs suivantes au fichier AMConfig.properties ou au fichier AMAgents.properties :

com.sun.identity.session.polling.threadpool.size=10
com.sun.identity.session.polling.threadpool.threshold=10000

Pour des centaines ou des milliers de sessions, les valeurs doivent être identiques à celles données à titre d'exemple dans le fichier AMConfig.properties d'Access Manager après exécution du script amtune-identity. Par exemple, pour une machine disposant de 4 Go de RAM, le script amtune-identity d'Access Manager définit les valeurs suivantes :

com.sun.identity.session.notification.threadpool.size=28
com.sun.identity.session.notification.threadpool.threshold=76288

Définissez des valeurs identiques côté client dans le fichier AMAgent.properties ou AMConfig.properties lors du déploiement du serveur d'interface utilisateur d'authentification distribuée ou du SDK client d'Access Manager sur une machine client avec 4 Go de RAM.

CR# 6442905 : Le SSOToken de l'utilisateur authentifié doit être indiqué pour les sites malveillants.

Un utilisateur Access Manager authentifié peut révéler sans le vouloir le SSOToken d'un site malveillant en cliquant sur une URL du site.

Solution. Créez toujours un profil d'utilisateur d'agent unique dans Access Manager pour tous les agents de stratégie participant afin de s'assurer que le site n'est pas erroné. Vérifiez également qu'aucun de ces utilisateurs d'agent n'utilise un mot de passe identique au mot de passe secret partagé ou au mot de passe amldapuser . Par défaut, les agents de stratégie sont authentifiés dans le module d'authentification d'Access Manager comme l'utilisateur UrlAccessAgent.

Pour plus d'informations sur la création d'un agent à l'aide la console d'administration d'Access Manager, reportez-vous à Agents du Sun Java System Access Manager 7 2005Q4 Administration Guide.

CR# 6441918 : Intervalle de contrôle de site et propriétés du délai d'expiration

Le basculement de site Access Manager inclut les nouvelles propriétés suivantes :

com.sun.identity.sitemonitor.interval
com.sun.identity.sitemonitor.timeout

Pour plus d'informations, reportez-vous à Nouvelles propriétés de configuration pour le contrôle de site.

CR# 6440697 : L'authentification distribuée doit être exécutée en tant qu'utilisateur non administratif.

Pour créer un administrateur d'authentification distribuée autre que l'utilisateur administratif par défaut (amadmin) pour l'authentification d'application, suivez la procédure ci-dessous :

  1. Créez un utilisateur LDAP comme administrateur de l'authentification distribuée. Exemple :

    uid=DistAuthAdmin,ou=people,o=am

  2. Ajoutez l'administrateur de l'authentification distribuée à la liste d'utilisateurs spéciaux. Exemple :

    com.sun.identity.authentication.special.users=cn=dsameuser,
ou=DSAME Users,o=am|cn=amService-UrlAccessAgent,ou=DSAME Users,
o=am|uid=DistAuthAdmin,ou=People,o=am

    Ajoutez cette propriété au fichier AMConfig.properties de tous les serveurs Access Manager afin que le AppSSOToken de l'administrateur de l'authentification distribuée n'expire pas à la fin de la session.

CR# 6440695 : Serveurs d'interface utilisateur d'authentification distribuée avec équilibreur de charge

Si votre déploiement comprend un équilibreur de charge et plusieurs serveurs d'interface utilisateur d'authentification distribuée, définissez les propriétés suivantes dans le fichier AMConfig.properties après avoir déployé le fichier WAR.

com.iplanet.am.lbcookie.name=DistAuthLBCookieName
com.iplanet.am.lbcookie.value=DistAuthLBCookieValue

CR# 6440651 : la rediffusion de cookie requiert la propriété com.sun.identity.session.resetLBCookie .

Pour que la rediffusion de cookie fonctionne correctement dans le basculement de session d'Access Manager, ajoutez la propriété com.sun.identity.session.resetLBCookie définie sur true pour l'agent de stratégie et le serveur Access Manager. Exemple :

com.sun.identity.session.resetLBCookie='true'

Remarque : Cette propriété n'est requise que si vous avez implémenté le basculement de session d'Access Manager.

CR# 6440648 : La propriété com.iplanet.am.lbcookie.name implique une valeur par défaut de amlbcookie

Par défaut, un agent de stratégie et des serveurs Access Manager impliquent le nom de cookie d'équilibreur de charge amlbcookie. Si vous renommez le cookie du serveur d'arrière-plan, utilisez le même nom dans le fichier AMAgent.properties de l'agent de stratégie. De même, si vous utilisez le SDK client Access Manager, utilisez également le même nom de cookie que celui utilisé par le serveur d'arrière-plan.

CR# 6440641 : La propriété com.iplanet.am.lbcookie.value est désapprouvée.

Access Manager ne prend plus en charge la propriété com.iplanet.am.lbcookie.value sur les serveurs afin de personnaliser le cookie d'équilibreur de charge. Access Manager utilise désormais, pour la valeur de cookie et le nom donné par l'agent, l'ID du serveur défini dans la configuration de la session.

CR# 6429610 : Impossible de créer le jeton SSO en cas d'utilisation d'ID-FF SSO.

Après la définition de l'exemple 1 du Liberty Identity Federation Framework (ID-FF), la fédération réussit mais SSO échoue.

Solution. Ajoutez uuid de dsameuser à la propriété com.sun.identity.authentication.special.users dans le fichier AMConfig.properties. Pour l'authentification d'applications, dsameuser requiert un jeton SSO sans date d'expiration pour le serveur Access Manager.

CR# 6389564 : Plusieurs requêtes successives sur les membres du rôle d'un magasin de données LDAP v3 lors de la connexion à Access Manager

Lorsqu'un utilisateur se connecte à Access Manager, plusieurs recherches LDAP se produisent sur l'attribut nsRoleDN de l'utilisateur.

Solution. Une fois Access Manager 7 patch 3 installé, exécutez la commande suivante, illustrée avec Access Manager installé dans le répertoire par défaut sous Solaris :

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/idRepoServiceAddAttrSchemaRequest_Cache.xml

CR# 6385185 : Le module d'authentification ne peut pas remplacer l'URL 'aller à' et en spécifier une autre

Un module d'authentification peut remplacer l'URL 'aller à' et demander la redirection vers une autre URL d'un site Web externe afin de valider le statut de l'utilisateur.

Pour remplacer l'URL 'aller à' une fois l'authentification terminée, définissez la propriété de l'exemple suivant du SSOToken. Pour cela, utilisez la méthode onLoginSuccess de la classe PostProcess mettant en œuvre AMPostAuthProcessInterface. Par exemple, OverridingURL représente l'URL remplaçant l'URL 'aller à' :

public class <..> implements AMPostAuthProcessInterface {  
...
    public void onLoginSuccess(...) {
        try {
            ssoToken.setProperty("PostProcessSuccessURL", OverridingURL);
         } catch (Exception ...) {
         ...         }
...
}

CR# 6385184 : La redirection depuis un module d'authentification personnalisé lorsque le jeton SSO est toujours à l'état non valide.

La nouvelle propriété RedirectCallback pour module d'authentification personnalisé permet de rediriger vers un site Web externe via l'interface utilisateur d'authentification afin de valider un utilisateur. Si l'authentification réussit, l'utilisateur est alors redirigé vers l'URL du serveur Access Manager d'origine. Les fichiers d'exemple incluent :

Pour mettre en œuvre cette fonction :

  1. Créez un module d'authentification personnalisé basé sur l'exemple LoginModuleSample.java.

  2. Chargez le module sur un serveur Access Manager.

  3. Définissez RedirectCallback dans le fichier XML à l'aide de l'exemple LoginModuleSample.xml.

  4. Pour tester le module, utilisez le fichier d'exemple testExtWebSite.jsp pour le site Web externe.

  5. Connectez-vous via l'URL suivante :

    http://example.com/amserver/UI/Login?module=LoginModuleSample

Le nom d'utilisateur et le mot de passe sont redirigés vers le site Web externe pour validation. Si le nom et le mot de passe sont valides, l'authentification réussit et l'utilisateur est redirigé vers l'URL du serveur Access Manager d'origine.

Prenons un exemple dans lequel le déploiement utilise un module d'authentification personnalisé pour accéder à un site d'approvisionnement/carte bancaire :

  1. Un utilisateur ouvre la page de traitement d'authentification/de connexion du module d'authentification personnalisé.

  2. L'utilisateur entre les informations d'authentification (nom d'utilisateur et mot de passe) et envoie une requête au module d'authentification personnalisé.

  3. Le module d'authentification personnalisé redirige l'utilisateur vers un site d'approvisionnement/carte bancaire externe ainsi que les informations utilisateur nécessaires fournies avec la requête.

  4. Le site d'approvisionnement/carte de crédit externe vérifie le statut de l'utilisateur et renvoie la requête comme étant réussie ou en échec.

  5. Le module d'authentification personnalisé valide l'utilisateur en fonction du statut renvoyé à l'étape 4 et le renvoie au service d'authentification.

  6. L'authentification utilisateur se termine et est soit réussie, soit en échec.

CR# 6324056 : La fédération échoue en cas d'utilisation d'un profil d'artefact.

Solution : Pour résoudre ce problème, appliquez la dernière version du patch 'Core Mobile Access', en fonction de votre plate-forme :

Redémarrez le conteneur Web après application du patch.

Access Manager 7 2005Q4 Patch 2

Le patch 2 (révision 02) d'Access Manager 7 2005Q4 a résolu de nombreux problèmes, répertoriés dans le fichier LISEZMOI accompagnant le patch. Le patch 2 inclut également les nouvelles fonctions et problèmes connus suivants :

Nouvelles fonctions du patch 2

Problèmes et restrictions connus du patch 2

Nouvelles propriétés des caches User Management, Identity Repository et Service Management

Le patch 2 inclut également les nouvelles propriétés suivantes pour les caches User Management (Access Manager SDK), Identity Repository (IdRepo) et Service Management. Ces propriétés vous permettent d'activer et de désactiver les différents caches indépendamment, en fonction de vos besoins de déploiement et de définir la durée de vie des entrées de cache.

Tableau 3 Nouvelles propriétés des caches User Management, Identity Repository et Service Management

Propriété 

Description 

Nouvelles propriétés d'activation/désactivation de caches

com.iplanet.am.sdk.caching.enabled

Propriété globale activant (vrai) ou désactivant (faux) les caches Identity Repository (IdRepo), User Management et Service Management. Si cette propriété est réglée sur vrai ou absente du fichier AMConfig.properties , les trois caches sont activés.

Remarque Les trois propriétés suivantes pour activer ou désactiver les caches spécifiques ne s'appliquent que si la propriété globale ci-dessus est réglée sur faux.

com.sun.identity.amsdk.cache.enabled

Active (vrai) ou désactive (faux) le cache User Management (Access Manager SDK) uniquement. 

com.sun.identity.idm.cache.enabled

Active (vrai) ou désactive (faux) le cache Identity Repository (IdRepo) uniquement. 

com.sun.identity.sm.cache.enabled

Active (vrai) ou désactive (faux) le cache Service Management uniquement. 

Nouvelles propriétés du cache User Management de durée de vie

com.iplanet.am.sdk.cache.entry.expire.enabled

Active (vrai) ou désactive (faux) le délai d'expiration (défini par les deux propriétés suivantes) du cache User Management. 

com.iplanet.am.sdk.cache.entry.user.expire.time

Définit la durée de validité en minutes des entrées utilisateur du cache User Management après leur dernière modification. A savoir, après la durée spécifiée écoulée (après la dernière modification ou lecture dans le répertoire), les données de l'entrée mise en cache expirent. De nouvelles demandes de données pour ces entrées doivent alors être lues depuis le répertoire. 

com.iplanet.am.sdk.cache.entry.default.expire.time

Définit la durée de validité en minutes des entrées non-utilisateur du cache User Management après leur dernière modification. A savoir, après la durée spécifiée écoulée (après la dernière modification ou lecture dans le répertoire), les données de l'entrée mise en cache expirent. De nouvelles demandes de données pour ces entrées doivent alors être lues depuis le répertoire. Nouvelles propriétés de durée de vie du cache Identity Repository  

com.sun.identity.idm.cache.entry.expire.enabled

Active (vrai) ou désactive (faux) le délai d'expiration (défini par les deux propriétés suivantes) du cache IdRepo.  

com.sun.identity.idm.cache.entry.default.expire.time

Définit la durée de validité en minutes des entrées non-utilisateur du cache IdRepo après leur dernière modification. A savoir, après la durée spécifiée écoulée (après la dernière modification ou lecture dans le référentiel), les données de l'entrée mise en cache expirent. De nouvelles demandes de données pour ces entrées doivent alors être lues depuis le référentiel. 

Utilisation des nouvelles propriétés de cache

Les patchs Access Manager 7 2005Q4 n'ajoutent pas automatiquement les nouvelles propriétés de cache au fichier AMConfig.properties.

Pour utiliser les nouvelles propriétés de cache :

  1. A l'aide d'un éditeur de texte, ajoutez les propriétés et leurs valeurs au fichier AMConfig.properties 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

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

Nouvelle propriété pour le fournisseur de services de fédération

La nouvelle propriété com.sun.identity.federation.spadapter définit la classe de mise en œuvre de com.sun.identity.federation.plugins.FederationSPAdapter qui permet d'ajouter le traitement spécifique à l'application pendant le traitement de fédération côté fournisseur de services.

Voir aussi CR# 6385696 : Les IDP et SP existants et nouveaux n'apparaissent pas..

Prise en charge de la condition de filtre LDAP

La prise en charge de la condition de filtre LDAP est ajoutée dans le patch 2. Un administrateur de stratégies peut désormais spécifier un filtre LDAP dans la condition lors de la définition d'une stratégie. La stratégie ne s'applique à l'utilisateur que si l'entrée LDAP de l'utilisateur est conforme au filtre LDAP spécifié dans la condition. L'entrée LDAP de l'utilisateur est recherchée dans le répertoire indiqué dans le service de configuration de la stratégie.

Pour enregistrer et utiliser la condition de filtre LDAP, exécutez les commandes suivantes une fois Access Manager 7 patch 2 installé. Elles sont illustrées avec Access Manager installé dans le répertoire par défaut sous Solaris :

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-s /etc/opt/SUNWam/AddLDAPFilterCondition.xml
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/amPolicyConfig_mod_ldfc.xml

Remarque sur le patch 5 Si vous avez ajouté Access Manager 7 2005Q4 Patch 5 et exécuté le script updateschema.sh, vous n'avez pas besoin de charger ces fichiers à l'aide de amadmin. Pour plus d'informations, consultez la section Nouveau script updateschema.sh de chargement des fichiers LDIF et XML.

CR# 6283582 : Le nombre d'échecs de connexion n'est pas réparti entre les instances d'Access Manager.

Une fois Access Manager 7 patch 2 installé, exécutez les commandes suivantes, illustrées avec Access Manager installé dans le répertoire par défaut sous Solaris :

# cd DirectoryServer-base/shared/bin
# ./ldapmodify -h DirectoryServerHost -p DirectoryServerPort 
-D "cn=Directory Manager" -w DirectoryMangerPassword 
-a -f /etc/opt/SUNWam/accountLockout.ldif
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/accountLockoutData.xml

La valeur par défaut de DirectoryServer-base est /var/opt/mps/serverroot sous Solaris et /var/opt/sun/directory-server sous Linux.

Remarque sur le patch 5 Si vous avez ajouté Access Manager 7 2005Q4 Patch 5 et exécuté le script updateschema.sh, vous n'avez pas besoin de charger ces fichiers à l'aide de amadmin. Pour plus d'informations, consultez la section Nouveau script updateschema.sh de chargement des fichiers LDIF et XML.

CR# 6293673 : Les informations de session d'origine doivent être conservées pendant l'envoi de la notification du délai d'expiration de session.

La nouvelle propriété com.sun.identity.session.property.doNotTrimList du fichier AMConfig.properties peut contenir une liste des noms de propriétés de session séparés par une virgule. Une fois qu'une session a expiré, les propriétés définies dans cette liste ne seront pas supprimées afin de pouvoir y accéder avant la purge de la session. Exemple :

com.sun.identity.session.property.doNotTrimList=UserId,HostName

CR# 6244578 : Access Manager doit avertir l'utilisateur que la prise en charge de cookie/l'activation des cookies de navigateur est désactivée/indisponible.

La nouvelle propriété com.sun.identity.am.cookie.check du fichier AMConfig.properties indique si le serveur doit vérifier la prise en charge de cookie/l'activation des cookies dans le navigateur. La valeur true amène le serveur à vérifier la prise en charge de cookie/l'activation des cookies dans le navigateur et à renvoyer une page d'erreur si le navigateur ne prend pas en charge les cookies ou s'ils ne sont pas activés. Cette valeur doit être paramétrée sur false (valeur par défaut) si le serveur doit prendre en charge un mode sans cookies pour l'authentification.

CR# 6236892 : Substituant d'image/texte pendant que CDCServlet traite AuthNResponse après la connexion

Les nouvelles propriétés suivantes sont ajoutées au fichier AMConfig.properties et lues par CDCServlet :

CR# 6363157 : la nouvelle propriété désactive les recherches persistantes si cela est absolument nécessaire

La nouvelle propriété com.sun.am.event.connection.disable.list du fichier AMConfig.properties indique la connexion d'événement pouvant être désactivée. Les valeurs (sensibles à la casse) peuvent être :

aci - Modifications de l'attribut aci, la recherche utilisant le filtre LDAP (aci=*)

sm - Modifications de l'arborescence d'informations d'Access Manager (ou du nœud de gestion du service) qui comprend les objets appartenant à la classe d'objet marqueur sunService ou sunServiceComponent. Vous pouvez, par exemple, créer une stratégie visant à définir les privilèges d'accès à une ressource protégée ou modifier les règles, objets, conditions ou fournisseurs de réponse d'une stratégie existante.

um - Modifications dans le répertoire utilisateur (ou nœud de gestion des utilisateurs). Vous pouvez, par exemple, modifier le nom ou l'adresse de l'utilisateur.

Par exemple, pour désactiver des recherches persistantes de modifications de l'arborescence d'informations d'Access Manager (ou du nœud de gestion du service) :

com.sun.am.event.connection.disable.list=sm

Pour spécifier plusieurs valeurs, séparez chaque valeur par une virgule.

Attention – Attention –

Les recherches persistantes provoquent quelques dépassements de performances sur Directory Server. Si vous déterminez que la suppression d'une partie de ce dépassement de performances est absolument indispensable dans un environnement de production, vous pouvez désactiver une ou plusieurs recherches persistantes à l'aide de la propriété com.sun.am.event.connection.disable.list.

Cependant, avant de désactiver une recherche persistante, vous devez comprendre les restrictions présentées ci-après. Nous vous recommandons fortement de ne pas modifier cette propriété à moins que cela ne soit absolument nécessaire. Cette propriété a été initialement introduite pour éviter tout dépassement sur Directory Server lorsque plusieurs agents 2.1 J2EE sont utilisés car chacun de ces agents crée ces recherches persistantes. Les agents 2.2 J2EE ne créant plus ces recherches persistantes, il n'est pas nécessaire d'utiliser cette propriété.

Pour plus d'informations, consultez la section Obtention de davantage d'informations sur la désactivation des recherches persistantes (6486927).

CR# 6385696 : Les IDP et SP existants et nouveaux n'apparaissent pas.

La nouvelle propriété com.sun.identity.federation.spadapter du fichier AMConfig.properties spécifie la mise en œuvre par défaut de l'adaptateur de fournisseur de services de fédération dans laquelle l'application peut obtenir des assertions et des informations de réponse. Exemple :

com.sun.identity.federation.spadapter=com.sun.identity.federation.plugins.FSDefaultSPAdapter

Access Manager 7 2005Q4 Patch 1

Le patch 1 (révision 1) d'Access Manager 7 2005Q4 a résolu de nombreux problèmes, répertoriés dans le fichier LISEZMOI accompagnant le patch. Le patch 1 inclut également les nouvelles fonctions et problèmes connus suivants :

Création de fichiers de débogage

Par défaut, les fichiers de débogage d'Access Manager sont créés dans le répertoire de débogage, même si la propriété com.iplanet.services.debug.level du fichier AMConfig.properties est paramétrée sur error. Avant la sortie du patch 1 d'Access Manager 7, un fichier de débogage n'était créé que lors de la première consignation d'un message de débogage dans le fichier.

Prise en charge des rôles et des rôles filtrés dans le plug-in LDAPv3

Le patch 1 d'Access Manager 7 ajoute la prise en charge des rôles et des rôles filtrés dans le plug-in LDAPv3, si les données sont stockées dans Sun Java System Directory Server. Pour plus d'informations, reportez-vous à la section Documentation de la prise en charge des rôles et des rôles filtrés pour le plug-in LDAPv3 (6365196).

CR# 6320475 : La propriété com.iplanet.am.session.client.polling.enable côté serveur ne doit pas être paramétrée sur true.

La propriété com.iplanet.am.session.client.polling.enable du fichier AMConfig.properties côté serveur est paramétrée sur false par défaut et ne doit jamais être reparamétrée sur true.

CR# 6358751 : L'application du patch 1 d'Access Manager 7 échoue si des espaces sont insérés dans la clé de chiffrement.

L'application du patch échoue si la clé de chiffrement du mot de passe contient des espaces.

Solution. Utilisez une nouvelle clé de chiffrement sans espaces. Pour connaître les étapes de changement de clé de chiffrement, reportez-vous à : Annexe B, Changing the Password Encryption Key du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.