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 :
Systèmes d'exploitation SolarisTM (Solaris OS) sur SPARC® : 120954-07
Solaris OS sur les plates-formes x86 : 120955-07
Systèmes Linux : 120956-07
Systèmes Microsoft Windows : 124296-07
Systèmes HP-UX : 126371-07
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 :
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 :
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
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.
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.
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.
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 :
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.
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 pour les systèmes Solaris
Instructions d'installation du patch pour les systèmes Linux
Instructions d'installation du patch pour les systèmes Windows
Instructions d'installation du patch pour les systèmes HP-UX
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
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 :
Systèmes Solaris : AccessManager-base/SUNWam
Systèmes Linux : AccessManager-base/identity
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
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 :
Systèmes Solaris SPARC : patch-home-directory /120954-07
Systèmes Solaris x86 : patch-home-directory/120955-07
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.
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
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.
Conditions requises pour installer le patch pour Windows :
Access Manager 7 2005Q4 doit être installé sous Windows. Pour plus d'informations sur l'installation, consultez le Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows .
Pour exécuter les scripts du patch, ActivePerl 5.8 (ou version ultérieure) doit être installé sous 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 :
Connectez-vous à Windows en tant qu'administrateur.
Créez un répertoire où télécharger et décompresser le fichier de patch pour Windows. Par exemple : AM7p7
Téléchargez et décompressez le fichier 124296-07.zip dans le répertoire créé lors de l'étape précédente.
Arrêtez tous les services Java ES 2005Q4.
Exécutez le script AM7p7\scripts\prepatch.pl.
Exécutez le fichier AM7p7\124296-07.exe pour installer le patch.
Exécutez le script AM7p7\scripts\postpatch.pl.
Redémarrez les services Java ES 2005Q4.
Redéployez les applications Access Manager. Voir Remarques relatives à la post-installation pour plus d'informations.
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
Redémarrez les services Java ES 2005Q4.
Pour supprimer le patch pour Windows :
Connectez-vous à Windows en tant qu'administrateur.
Exécutez le fichier Uninstall_124296-07.bat.
Exécutez le script AM7p7\scripts\postbackout.pl.
Redéployez les applications Access Manager.
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é.
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.
Ces remarques après l'installation du patch Access Manager 7 2005Q4 sont :
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 :
console.war
password.war
services.war
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 :
Fichiers de propriétés :
Systèmes Solaris : AccessManager-base/SUNWam/locale/*.properties
Systèmes Linux : AccessManager-base/identity/locale/*.properties
Systèmes Windows : AccessManager-base\locale\*.properties
Descripteurs de bibliothèque de balises :
Systèmes Solaris : AccessManager-base/SUNWam/web-src/applications/WEB-INF/*.tld
Systèmes Linux : AccessManager-base/identity/web-src/applications/WEB-INF/*.tld
Systèmes Windows : AccessManager-base\web-src\applications\WEB-INF\*.tld
Le fichier web.xml et les fichiers utilisés pour le créer (WEB-INF/web.xml et WEB-INF/*.xml)
Les fichiers spécifiques à l'application : Fichiers JSP (*.jsp), image (*.gif) et feuilles de styles (couleurs d'arrière-plan, tailles de police, etc.) (*.css)
Pour conserver toutes les personnalisations, suivez les étapes ci-dessous. Sauvegardez toujours un fichier avant d'y apporter des modifications.
Installez le patch.
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
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.
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
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.
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
Redémarrez les processus d'Access Manager une fois le script amconfig exécuté. Exemple :
# cd /opt/SUNWam/bin # ./amserver stop # ./amserver start
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\ .
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.
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 :
Création du fichier WAR d'authentification distribuée : Technical Note: Using Access Manager Distributed Authentication
Création du fichier WAR de SDK client : Installing the Client SDK du Sun Java System Access Manager 7 2005Q4 Developer’s Guide
Déploiement du fichier WAR de SDK client : To Deploy amclientwebapps.war du Sun Java System Access Manager 7 2005Q4 Developer’s Guide
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
Access Manager prend en charge la méthode setReadTimeout HttpURLConnection de JDK 1.5
Les instances multiples d'Access Manager sont consignées dans des fichiers journaux distincts
Le plug-in de post-authentification de Microsoft IIS 6.0 prend en charge SharePoint Server
Problèmes et restrictions connus du patch 6
Avant d'installer le patch 6, nous vous recommandons de mettre à niveau ou d'appliquer un patch aux composants suivants :
Si vous utilisez Sun Java System Web Server 6.1 SP5 ou une version ultérieure, procédez à une mise à niveau vers Web Server 6.1 SP7, cette version étant disponible sur le site :
http://www.sun.com/download/products.xml?id=45c90ca9
Suivez la procédure de mise à niveau comme indiqué dans la section Mise à niveau du Notes de version de Sun Java System Web Server 6.1 SP8.
Téléchargez et installez le dernier patch sur la sécurité pour NSS, JSS et NSPR depuis SunSolve Online :http://sunsolve.sun.com
Plates-formes Solaris 8 SPARC : 119209
Plates-formes Solaris 8 x86 : 119210
Plates-formes Solaris 9 SPARC : 119211
Plates-formes Solaris 9 x86 : 119212
Plates-formes Solaris 10 SPARC : 119213
Plates-formes Solaris 10 x86 et AMD64 : 119214
Systèmes Windows : 124392
Systèmes HP-UX : 124379
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.
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 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 :
Systèmes Solaris : /var/opt/SUNWam/logs
Systèmes Linux et HP-UX : /var/opt/sun/identity/logs
Systèmes Windows : C:\Sun\JavaES5\identity\logs
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
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 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.
Le patch 6 d'Access Manager 7 2005Q4 prend maintenant en charge Microsoft Windows Internet Explorer 7.
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 :
Pour une solution temporaire, actualisez le navigateur ou bien déconnectez-vous, puis reconnectez-vous à la console.
Pour une solution permanente, déployez la console Access Manager sur une instance d'Access Manager distincte ne participant pas au basculement de session.
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 :
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
Redémarrez l'instance du serveur d'application.
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.
Le patch 5 (révision 5) d'Access Manager 7 résout de nombreux problèmes, répertoriés dans le fichier LISEZMOI accompagnant le patch. Le patch 5 comprend également les nouvelles fonctionnalités, les problèmes et les mises à jour de la documentation ci-après.
Nouvelles fonctions du patch 5
Nouveau script updateschema.sh de chargement des fichiers LDIF et XML
Prise en charge des valeurs de délai d'attente de session inactive d'une application spécifique
Prise en charge d'une nouvelle interface SPI d'identificateur de nom par SAML
Nouvelles propriétés de configuration pour le contrôle de site
L'utilisateur n'a plus à s'authentifier deux fois dans la chaîne d'authentification
Modifications apportées aux scripts de réglage des performances
Problèmes et restrictions connus du patch 5
CR # 6523499 : fichier amsilent du patch 5 lisible par tous les utilisateurs sous Linux
CR# 6402167 : LDAP JDK 4.18 provoque des problèmes au niveau du client LDAP/Directory Server
Problèmes liés à la globalisation (g11n)
Mises à jour de la documentation
Access Manager ne peut pas rebasculer en mode Hérité à partir du mode Domaine (6508473)
Obtention de davantage d'informations sur la désactivation des recherches persistantes (6486927)
Documentation des privilèges d'Access Manager pris et non pris en charge (2143066)
Documentation du routage des demandes d'association basé sur des cookies (6476922)
Documentation de la configuration de Windows Desktop SSO pour Windows 2003 (6487361)
L'aide en ligne sur la création d'un nouveau nom de site demande plus d'informations (2144543)
Le paramètre de configuration du mot de passe administrateur estADMIN_PASSWD sous Windows (6470793)
Le patch 126371 prend en charge les systèmes HP-UX. Pour davantage d'informations, consultez les rubriques:
Pour plus d'informations sur l'installation sous HP-UX, consultez le Guide d’installation de Sun Java Enterprise System 2005Q4 pour UNIX.
Le patch 124296 prend en charge les systèmes Windows. Pour davantage d'informations, consultez les rubriques:
Pour plus d'informations sur l'installation sous Windows, consultez le Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows .
Le patch 5 (et version ultérieure) inclut le script updateschema.sh qui permet de charger les fichiers suivants pour mettre à jour le schéma du service Directory Server :
AddLDAPFilterCondition.xml
amPolicyConfig_mod_ldfc.xml
accountLockoutData.xml
accountLockout.ldif
idRepoServiceAddAttrSchemaRequest_Cache.xml
wsf1.1_upgrade.xml
amAuth_mod.xml
amAuthCert_mod.xml
Dans les précédentes versions de patch pour Access Manager, il était nécessaire de charger ces fichiers manuellement.
Pour exécuter le script updateschema.sh :
Connectez-vous en tant que superutilisateur (root).
Accédez au répertoire des patchs.
Exécutez le script. Par exemple, sur les systèmes Solaris :
# cd /120954-07 # ./updateschema.sh
Sous Windows, le script est updateschema.pl.
Lorsque le script vous y invite, entrez les éléments suivants :
Nom d'hôte et numéro de port de Directory Server
DN utilisateur admin et mot de passe de Directory Server
DN amadmin et mot de passe
Le script valide vos entrées et charge les fichiers. Le script écrit aussi le fichier journal suivant :
Systèmes Solaris : /var/opt/SUMWam/logs/AM70Patch.upgrade.schema. timestamp
Systèmes Linux : /var/opt/sun/identity/logs/AM70Patch.upgrade.schema. timestamp
Une fois le script terminé, redémarrez le conteneur Web d'Access Manager.
Remarque Si vous supprimez le patch 5, les modifications apportées au schéma ajoutées au script updateschema.sh ne sont pas supprimées de Directory Server. Vous n'avez, cependant, pas besoin de supprimer les modifications apportées manuellement au schéma car ces dernières n'affectent pas les fonctionnalités d'Access Manager ni son utilisation une fois le patch supprimé.
Le patch 5 permet à différentes applications d'avoir différentes valeurs de délai d'attente de session inactive. Dans une entreprise, certaines applications peuvent nécessiter des valeurs de délai d'attente de session inférieures aux valeurs de délai d'attente de session spécifiées dans le service de la session. Vous avez, par exemple, spécifié une valeur de délai d'attente de session de 30 minutes dans le service de la session mais une application HR doit se déconnecter dès qu'un utilisateur est inactif pendant plus de 10 minutes.
Conditions requises pour utiliser cette fonctionnalité :
Les agents protégeant l'application doivent être configurés pour appliquer les décisions concernant la stratégie relative aux URL depuis Access Manager.
Les agents doivent être configurés pour s'exécuter en mode cache de décision de stratégie automatique. Consultez les propriétés suivantes :
Pour les agents Web : com.sun.am.policy.am.fetch_from_root_resource
Pour les agents J2EE : com.sun.identity.policy.client.cacheMode
Le fichier AMConfig.properties d'Access Manager doit spécifier un ordre d'évaluation du composant de stratégie de sorte que la Condition soit évaluée en dernier. Consultez la propriété suivante :
com.sun.identity.policy.Policy.policy_evaluation_weights
La Condition sur Access Manager ne connaîtra pas l'accès à l'application autorisé par l'agent en fonction de la décision stockée en mémoire cache localement. Par conséquent, le délai d'attente réel d'inactivité de l'application se situera entre le délai d'attente d'inactivité de l'application et le délai d'attente d'inactivité de l'application moins la durée de stockage en mémoire cache de l'agent.
Pour utiliser cette fonctionnalité :
Ajoutez la condition du plan d'authentification aux stratégies de protection de l'application nécessitant le délai d'attente d'inactivité de la session propre à l'application.
Spécifiez le nom de l'application et la valeur du délai d'attente dans la condition du plan d'authentification.
Utilisez le même nom d'application et la même valeur de délai d'attente dans toutes les stratégies applicables aux ressources de l'application.
Spécifiez la valeur du délai d'attente en minutes. Si la valeur est égale à 0 ou supérieure à la valeur de délai d'attente d'inactivité de la session spécifié dans le service de la session, la valeur est ignorée et le délai d'attente du service de la session est appliqué.
Par exemple, imaginez une stratégie http://host.sample.com/hr/* avec la condition de plan d'authentification suivante :
Schéma d'authentification : LDAP
Nom de l'application : HR
Valeur du délai d'attente : 10
Si plusieurs stratégies sont définies pour protéger les ressources de l'application HR, vous devez ajouter la condition à toutes les stratégies.
Lorsqu'un utilisateur d'une session distincte tente d'accéder à l'application HR protégée par l'agent d'Access Manager, il est invité à s'authentifier pour le plan LDAP (si ce n'est pas déjà fait).
Si l'utilisateur s'est déjà authentifié sur le plan LDAP, il dispose d'une autorisation d'accès à condition qu'il se soit écoulé moins de 10 minutes depuis sa dernière authentification ou depuis son dernier accès à l'application HR. Dans le cas contraire, il est invité à s'authentifier à nouveau sur le plan LDAP pour accéder à l'application.
Le servlet CDC peut coexister avec un serveur d'interface utilisateur d'authentification distribuée dans la DMZ pour activer la connexion unique interdomaine (CDSSO). Il est possible de déployer le serveur Access Manager derrière un pare-feu. Par ailleurs, tous les accès à Access Manager dédiés à l'exécution d'une connexion unique interdomaine sont gérés par le servlet CDC dans le serveur d'interface utilisateur d'authentification distribuée. Pour activer la connexion unique interdomaine, consultez la documentation de l'agent de stratégie spécifique et exécutez la procédure complémentaire suivante :
Modifiez le fichier AMAgent.properties pour pointer le servlet CDC sur le serveur d'authentification distribuée côté client. Par exemple, pour les agents Web, modifiez la propriété suivante :
com.sun.am.policy.agents.config.cdcservlet.url= http://DAhost.DAdomain:DAport/DISTAUTH_DEPLOY_URI/cdcservlet
Définissez les stratégies requises dans Access Manager pour les ressources que l'agent doit protéger. Par exemple, si l'agent se situe à l'emplacement host.example.com:80 , définissez une stratégie pour la ressource comme suit : http://host.example.com:80/* .
Vous pouvez à présent spécifier un nom de domaine sur le servlet CDC, de sorte à inclure le nom du domaine lors de la redirection vers l'URL de connexion d'Access Manager et à permettre à l'utilisateur de se connecter au domaine spécifique. Exemple :
com.sun.am.policy.agents.config.cdcservlet.url= http://lb.example.com/amserver/cdcservlet?org=realm1
Auparavant, l'authentification des certificats n'utilisait que le composant dn dans le subjectDN pour mapper un profil utilisateur. Access Manager prend désormais en charge la valeur UPN (nom principal de l'utilisateur) dans SubjectAltNameExt pour mapper le profil.
Le traitement post-authentification est désormais exécuté lorsqu'un utilisateur se déconnecte d'un autre serveur que celui auquel il était initialement connecté dans un environnement de serveur multiple, qu'un basculement de session soit ou non configuré.
SAML prend désormais en charge une nouvelle interface SPI d'identificateur de nom permettant à un site de personnaliser l'identificateur de nom dans l'assertion SAML. Un site peut mettre en œuvre la nouvelle interface NameIdentifierMapper pour mapper un compte utilisateur sur un identificateur de nom dans le cadre d'une assertion SAML.
La fonctionnalité de surveillance de site d'Access Manager intègre les nouvelles propriétés suivantes, afin que vous puissiez spécifier le comportement du contrôle d'état du site.
Propriété |
Description |
com.sun.identity.urlchecker.invalidate.interval |
Intervalle de détection d'un site hors service ou qui ne répond pas exprimé en millisecondes. Par défaut : 70 000 millisecondes (70 secondes). |
com.sun.identity.urlchecker.sleep.interval |
Intervalle de temps en millisecondes pendant lequel le contrôle d'état du site est en sommeil. Par défaut : 30 000 millisecondes (30 secondes). |
com.sun.identity.urlchecker.targeturl |
Autre URL cible pour le contrôle de l'état du processus d'Access Manager. Par défaut : "/amserver/namingservice". |
Le patch n'ajoute pas ces propriétés au fichier AMConfig.properties . Pour utiliser ces nouvelles propriétés avec des valeurs autres que celles par défaut :
Ajoutez les propriétés et leurs valeurs au fichier AMConfig.properties . Pour les agents de stratégie, ajoutez ces propriétés au fichier AMAgents.properties .
Redémarrez le conteneur Web d'Access Manager pour appliquer les valeurs.
Étudiez le scénario suivant. Un site configure une chaîne d'authentification avec trois modules LDAP. Tous les modules sont configurés sur SUFFICIENT et les options iplanet-am-auth-shared-state-enabled et iplanet-am-auth-store-shared-state-enabled sont configurées sur true. Exemple :
<AttributeValuePair> <Value>A-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true iplanet-am-auth-store-shared-state-enabled=true</Value> <Value>B-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true iplanet-am-auth-store-shared-state-enabled=true</Value> <Value>C-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true iplanet-am-auth-store-shared-state-enabled=true</Value> </AttributeValuePair>
Le patch 5 ajoute la nouvelle option iplanet-am-auth-shared-state-behavior-pattern aux options du module. Cette option peut prendre deux valeurs : tryFirstPass (par défaut) et useFirstPass.
Pour empêcher un utilisateur d'avoir à saisir deux fois son identifiant et son mot de passe pour s'authentifier (comme indiqué dans le scénario précédent), configurez cette nouvelle option sur useFirstPass pour tous les modules de la chaîne. Auparavant, un utilisateur qui n'existait que dans la troisième instance LDAP devait saisir son identifiant et son mot de passe deux fois pour s'authentifier.
Dans le patch 5 les modifications suivantes ont été apportées aux scripts de réglage des performances :
Prise en charge d'un fichier de mots de passe par les scripts de réglage
Le script de réglage supprime les ACI inutiles de Directory Server
Réglage des systèmes d'exploitation Solaris et Linux au moyen d'un script amtune-os unique
Exécution complète des scripts de réglages dans une zone locale de Solaris 10
Réglages à prendre en compte pour les serveurs Sun Fire T1000 et T2000
Le patch 5 vous permet de spécifier des mots de passe dans un fichier texte pour les scripts de réglage. Auparavant, vous ne pouviez saisir de mots de passe que sous la forme d'un argument de ligne de commande, ce qui pouvait engendrer des problèmes de sécurité. Pour utiliser un fichier de mots de passe, configurez les variables suivantes dans le fichier, au besoin :
DS_ADMIN_PASSWORD=DirectoryServer-admin-password AS_ADMIN_PASSWORD=ApplicationServer8-admin-password
Par exemple, pour régler Application Server 8 :
# ./amtune-as8 password-file
password-file contenant AS_ADMIN_PASSWORD, cette valeur étant définie sur le mot de passe administrateur d'Application Server 8.
Les scripts de réglage utilisent l'option -j password-file lorsqu'ils appellent les utilitaires ldapmodify, ldapsearch, db2index et dsconf de Directory Server.
Si Access Manager 7 2005Q4 est installé en mode Domaine, les privilèges de délégation servent à déterminer les droits d'accès ; par conséquent, certains ACI de Directory Server ne sont pas requis. Le patch 5 d'Access Manager 7 2005Q4 vous permet de supprimer les ACI inutiles en exécutant le script amtune-prepareDSTuner. Ce script lit une liste d'ACI dans le fichier remacis.ldif, puis appelle l'utilitaire ldapmodify pour les supprimer.
Vous pouvez exécuter le script amtune-prepareDSTuner pour supprimer les ACI inutiles sous Solaris, Linux, HP-UX et Windows. Pour plus d'informations, y compris sur la manière d'exécuter le script, consultez le Technical Note: Sun Java System Access Manager ACI Guide .
Une fois le serveur d'interface utilisateur d'authentification distribuée déployé sur un serveur Web, vous pouvez régler le conteneur Web en exécutant les scripts de réglage d'Access Manager. Les scripts de réglage suivants définissent la JVM, ainsi que d'autres options de réglage du conteneur Web concerné :
Tableau 2 Scripts de réglage du conteneur Web d'Access Manager
Conteneur Web |
Script de réglage |
---|---|
amtune-ws61 |
Web Server6.1 |
amtune-as7 |
Application Server 7 |
amtune-as8 |
Application Server Enterprise Edition 8.1 |
Pour régler un conteneur Web pour un serveur d'interface utilisateur d'authentification distribuée :
Le serveur Access Manager n'étant pas installé sur le système sur lequel le serveur d'interface utilisateur d'authentification distribuée est déployé, copiez le script de réglage de conteneur Web approprié (indiqué dans le tableau précédent), le fichier de configuration amtune-env et le script amtune-utils depuis une installation du serveur Access Manager. Si vous souhaitez régler le système d'exploitation Solaris ou Linux, copiez également le script amtune-os.
Modifiez les paramètres dans le fichier de configuration amtune-env pour spécifier le conteneur Web et les options de réglage. Pour exécuter le script en mode REVIEW (de révision), configurez AMTUNE_MODE=REVIEW dans le fichier amtune-env .
Exécutez le script de réglage du conteneur Web en mode REVIEW. En mode REVIEW, le script suggère des modifications de réglage basées sur les valeurs contenues dans le fichier amtune-env mais n'apporte aucune modification réelle au déploiement.
Consultez les recommandations en matière de réglage dans le fichier journal de débogage. Modifiez le fichier amtune-env en fonction de cette exécution, au besoin.
Pour modifier les réglages, configurez le fichier AMTUNE_MODE=CHANGE dans amtune-env.
Exécutez le script de réglage en mode CHANGE (de modification) pour modifier les réglages du déploiement.
Pour plus d'informations sur l'exécution du script de réglage pour régler le conteneur Web d'Access Manager, consultez le Chapitre 2, Access Manager Tuning Scripts du Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide.
Le patch 5 intègre un script amtune-os unique pour régler les systèmes d'exploitation Solaris et Linux. Le script détermine le type de système d'exploitation au moyen de la commande uname -s. Auparavant, Access Manager fournissait des scripts amtune-os distincts pour régler chaque système d'exploitation.
Si Access Manager est installé dans une zone locale de Solaris 10, tous les scripts de réglage à l'exception du script amtune-os peuvent être exécutés dans la zone locale. Dans une zone locale, le script amtune-os affiche un message d'avertissement mais ne règle pas le système d'exploitation. Le script continue d'exécuter les autres scripts de réglage que vous avez demandés. Auparavant, dans une zone locale, l'exécution du script amtune-os était interrompue et aucun des scripts de réglage ultérieurs demandés ne s'exécutaient.
Dans une zone globale de Solaris 10, le script amtune appelle amtune-os pour régler le système d'exploitation, ainsi que les autres scripts que vous voulez exécuter.
Le patch 5 comprend des scripts de réglage de Windows. L'exécution des scripts de réglage sous Windows est similaire à l'exécution des scripts de réglage sous Solaris ou Linux, aux exceptions suivantes près :
Les scripts pour Windows sont écrits en Perl et ne peuvent être exécutés sans Active Perl 5.8.
Si vous réglez Directory Server, vous devez copier les fichiers amtune-utils.pl, amtune-directory.pl, remacis.ldif et amtune-samplepassordfile sur Directory Server après avoir exécuté le script amtune-prepareDSTuner.pl car ce dernier ne peut pas compresser ces fichiers.
Aucun script de réglage de Windows n'est disponible.
Aucune prise en charge des zones n'est fournie.
Avant d'exécuter un script, vous devez configurer le paramètre $BASEDIR pour accéder au répertoire d'installation d'Access Manager dans le fichier amtune-env.pl.
Si Access Manager est installé sur un serveur Sun Fire T1000 ou T2000, les scripts de réglage pour Web Server 6.1 et Application Server 8 fournis avec le patch 5 configurent le paramètre JVM GC ParallelGCThreads sur 8 :
-XX:ParallelGCThreads=8
Ce paramètre réduit le nombre de threads de libération de la mémoire qui pourrait être inutilement élevé sur un système prenant en charge 32 threads. Vous pouvez toutefois augmenter la valeur à 16, voire à 20, pour une machine CPU virtuelle 32 bits comme un serveur Sun Fire T1000 ou T2000, si cela permet de réduire les activités complètes de libération de la mémoire.
Par ailleurs, pour les systèmes Solaris SPARC intégrant un processeur CMT doté de la technologie CoolThreads, nous vous recommandons d'ajouter la propriété suivante à la fin du fichier /etc/opt/SUNWam/config/AMConfig.properties :
com.sun.am.concurrencyRate=value
La value par défaut est de 16, mais vous pouvez attribuer une valeur inférieure à cette propriété en fonction du nombre de composants de base que contient le serveur Sun Fire T1000 ou T2000.
Pour activer l'authentification de base dans Microsoft Internet Information Services (IIS) 6.0, l'agent de stratégie doit obtenir le nom et le mot de passe de l'utilisateur. Le patch 5 intègre les nouvelles classes suivantes pour activer cette fonctionnalité à l'aide du chiffrement DES du mot de passe de l'utilisateur :
DESGenKey.java génère une touche unique utilisée pour chiffrer et déchiffrer le mot de passe de l'utilisateur.
ReplayPasswd.java lit la valeur de chiffrement à partir de la propriété com.sun.am.replaypasswd.key dans le fichier AMConfig.properties, chiffre le mot de passe et l'affecte à la propriété de session sunIdentityUserPassword.
Pour utiliser l'authentification de base dans IIS 6.0, vous devez exécuter la procédure suivante sur le serveur Access Manager et l'agent de stratégie IIS 6.0.
Sur le serveur Access Manager :
Exécutez DESGenKey.java pour générer une clé de chiffrement unique pour le chiffrement et le déchiffrement du mot de passe. Sous Solaris, le fichier DESGenKey.java figure dans le répertoire com/sun/identity/common présent dans am_sdk.jar dans le répertoire /opt/SUNWam/lib. Par exemple, la commande suivante génère une clé de chiffrement :
# cd /opt/SUNWam/lib # java -cp am_sdk.jar com.sun.identity.common.DESGenKey
Attribuez la valeur de clé de chiffrement de l'étape 1 à la propriété com.sun.am.replaypasswd.key dans le fichier AMConfig.properties.
Déployez ReplayPasswd.java comme plug-in de post-authentification. Utilisez le nom de classe complet lors de la configuration du plug-in : com.sun.identity.authentication.spi.ReplayPasswd .
Sur l'agent de stratégie IIS 6.0 :
Attribuez la valeur de clé de chiffrement du côté serveur à la propriété com.sun.am.replaypasswd.key dans le fichier AMAgent.properties . Le serveur Access Manager et l'agent de stratégie IIS 6.0 doivent utiliser la même clé de chiffrement.
Activez l'authentification de base dans le gestionnaire d'IIS 6.0.
L'agent de stratégie IIS 6.0 lit le mot de passe chiffré de la réponse de session, déchiffre le mot de passe à partir de la propriétécom.sun.am.replaypasswd.key et configure les en-têtes d'authentification pour permettre le fonctionnement de l'authentification de base.
Pour plus d'informations sur l'agent de stratégie IIS 6.0, consultez le Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0 .
Lorsqu'un compte d'utilisateur est bloqué, le patch 5 d'Access Manager 7 2005Q4 sous HP-UX renvoie errorCode = null au lieu de errorCode = 107 si le nombre de tentatives de saisie du mot de passe est dépassé.
Solution. aucune.
Avant d'exécuter le script de réglage amtune-identity, nous vous recommandons d'ajouter la propriété suivante, configurée sur false, dans le fichier AMConfig.properties :
com.sun.identity.log.resolveHostName=false
La valeur false réduit l'incidence de la résolution des noms d'hôte et peut, en conséquence, améliorer les performances. Cependant, si vous souhaitez imprimer le nom d'hôte de la machine cliente dans le journal amAuthentication.access, configurez cette valeur sur true.
Si vous supprimez le patch 5 d'une installation complète du serveur Access Manager, les fichiers amAuthLDAP.xml et amPolicyConfig.xml contiennent le mot de passe amldapuser en clair. Ces fichiers figurent dans le répertoire suivant, en fonction de votre plate-forme :
Systèmes Solaris : /etc/opt/SUNWam/config/xml
Systèmes Linux et HP-UX : /etc/opt/sun/identity/config/xml
Solution : Modifiez les fichiers amAuthLDAP.xml et amPolicyConfig.xml, puis supprimez le mot de passe en clair.
Dans les patchs d'Access Manager 7 2005Q4, le script de configuration d'Access Manager pour BEA WebLogic Server (amwl81config) ajoute les fichiers JAR de JAX-RPC 1.1 au classpath de l'instance WebLogic. Alors que cette modification est intéressante pour les produits comme Sun Java System Portal Server, une installation de serveur complète (DEPLOY_LEVEL=1) déployée sur WebLogic Server ne peut pas communiquer avec une installation de SDK client. Le cas échéant, des exceptions se produiront ultérieurement.
Si le serveur Access Manager 7 2005Q4 est installé sur BEA WebLogic Server, le CLASSPATH dans le script startWebLogic.sh doit être configuré à l'emplacement des fichiers JAR de JAX-RPC 1.0 pour communiquer avec le SDK client d'Access Manager.
Solution : avant d'appliquer le patch d'Access Manager, configurez le CLASSPATH dans le script startWebLogic.sh de l'instance de WebLogic Server pour utiliser les fichiers JAR de JAX-RPC 1.0 plutôt que les fichiers JAR de JAX-RPC 1.1 :
Connectez-vous au serveur Access Manager en tant que superutilisateur(root).
Modifiez le script startWebLogic.sh et remplacez le CLASSPATH pour utiliser les fichiers JAR de JAX-RPC 1.0. Exemple :
Valeur actuelle :
CLASSPATH=/etc/opt/SUNWam/config: AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar: AccessManager-base/AccessManager-package-dir/lib/namespace.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-api.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-spi.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-impl.jar:
Nouvelle valeur :
CLASSPATH=/etc/opt/SUNWam/config: AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar: AccessManager-base/AccessManager-package-dir/lib/namespace.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc_1.0/jaxrpc-api.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-ri.jar:
où AccessManager-base correspond au répertoire d'installation de base. La valeur par défaut est /opt sous Solaris et /opt/sun sous Linux et HP-UX. AccessManager-package-dir correspond au répertoire du package d'Access Manager.
5. Redémarrez l'instance de WebLogic Server.
Sous Linux. Le script postpatch crée le fichier /opt/sun/identity/amsilent avec des permissions de 644, qui offrent un accès en lecture à tous les utilisateurs.
Solution : Une fois le script installpatch exécuté, modifiez les permissions dans le fichier amsilent pour accorder un accès en lecture et en écriture au propriétaire uniquement. Exemple :
# chmod 600 /opt/sun/identity/amsilent
Dans ce scénario de déploiement, deux instances d'Access Manager sont déployées sur le même serveur hôte, chaque instance figurant sur une instance de conteneur Web différente. Procédez ensuite comme suit :
Appliquez le patch 5.
Modifiez le fichier amsilent et redéployez la première instance d'Access Manager.
Modifiez à nouveau amsilent pour la seconde instance d'Access Manager, puis redéployez cette instance.
Si NEW_INSTANCE=false dans le fichier amsilent, le fichier serverconfig.xml de la première instance d'Access Manager est écrasé par les données de la seconde instance d'Access Manager. Un redémarrage ultérieur de la première instance d'Access Manager échoue. Le fichier serverconfig.xml figure dans le répertoire suivant en fonction de votre plate-forme :
Systèmes Solaris : /etc/opt/SUNWam/config
Systèmes Linux : /etc/opt/sun/identity/config
Solution : lorsque vous déployez la seconde instance d'Access Manager, configurez NEW_INSTANCE=true dans le fichier amsilent. Le fichier serverconfig.xml de la seconde instance d'Access Manager est ensuite mis à jour avec les données correctes et le fichier serverconfig.xml de la première instance d'Access Manager n'est pas écrasé.
L'application du patch 5 sur une machine SDK uniquement écrase les fichiers makefile échantillon.
Solution : L'application du patch 5 sur une machine SDK uniquement ne nécessite pas de reconfiguration ; cependant, si vous souhaitez utiliser les fichiers makefile échantillon, observez la procédure suivante pour mettre à jour les fichiers LDIF et de propriétés (effectuez le remplacement des balises) des fichiers makefile échantillon :
Exécutez le script amconfig avec DEPLOY_LEVEL=14 pour désinstaller le SDK et annuler la configuration du conteneur Web.
Exécutez le script amconfig avec DEPLOY_LEVEL=4 pour réinstaller le SDK et reconfigurer le conteneur Web.
Ce problème a été résolu pour la plupart des recherches. Faites toutefois attention lors de la configuration de l'attribut de recherche d'alias. La valeur des attributs de recherche d'alias doit être unique au sein d'une organisation. Si plus d'un attribut de recherche d'alias est configuré, il est possible qu'une entrée du magasin de données corresponde à un attribut et qu'une autre entrée corresponde à l'autre attribut. Le cas échéant, le serveur Access Manager renvoie l'erreur suivante :
An internal authentication error has occurred. Contact your system administrator.
Solution : aucune
Un serveur d'interface utilisateur d'authentification distribuée et un agent de stratégie J2EE ne fonctionnent pas s'ils sont installés dans le même conteneur Web.
Solution : créez une seconde instance pour le conteneur Web et déployez le serveur d'interface utilisateur d'authentification distribuée et l'agent de stratégie sur une instance différente du conteneur.
Si vous déployez Access Manager sur un serveur d'application Sun Java System sous Windows, cliquer sur Aide dans le panneau gauche de l'écran d'aide de la console en mode Domaine renvoie une erreur d'application.
Solution : copiez le fichier javaes-install-dir\share\lib\jhall.jar dans le répertoire JAVA_HOME\jre\lib\ext, puis redémarrez Application Server.
Si aucun paramètre d'URL goto explicite n'est spécifié, un serveur d'interface utilisateur d'authentification distribuée tente de rediriger le paramètre goto sur un URL opérationnel spécifié dans Access Manager. Cette redirection peut échouer pour les motifs suivants :
L'URL est relatif et aucune page correspondante n'est disponible sur le serveur d'interface utilisateur d'authentification distribuée.
L'URL est absolu et le navigateur ne peut pas y accéder.
Solution : spécifiez toujours un paramètre d'URL goto explicite pour un serveur d'interface utilisateur d'authentification distribuée.
Dans Access Manager 7 2005Q4, LDAP JDK 4.18 est intégré à Java ES 2005Q4, d'où l'apparition de plusieurs problèmes de connexions avec Access Manager et Directory Server.
Solution : Appliquez l'un des patchs Sun Java System LDAP Java Development Kit suivants :
Plates-formes SE Solaris, SPARC et x86 : 119725-04
SE Linux 120834-02
Ces patchs sont accessibles sur le site Web de SunSolve : http://sunsolve.sun.com.
Sous Solaris, le programme d'installation de Java ES n'installe pas les fichiers du serveur d'interface utilisateur d'authentification distribuée Makefile.distAuthUI, README.distAuthUI et amauthdistui.war au bon emplacement : /opt/SUNComm/SUNWam.
Solution : copiez ces fichiers au bon emplacement : /opt/SUNWam.
Remarque : tout problème relatif au serveur d'interface utilisateur d'authentification distribuée qui a été résolu dans un patch est inséré dans le fichier /opt/SUNComm/SUNWam/amauthdistui.war . En conséquence, chaque fois que vous appliquez un patch sur le serveur Access Manager, puis que vous reconstruisez et déployez le fichier WAR, vous devez également copier ces fichiers dans le répertoire /opt/SUNWam.
Si Access Manager est installé dans un environnement linguistique utilisant des caractères multioctets (comme le japonais) sous Windows ou HP-UX, il est impossible d'effectuer une recherche par saisie de mots-clés utilisant des caractères multioctets dans l'aide en ligne de la console.
Solution : aucune
Mise à jour du patch 6 : le patch 6 d'Access Manager 7 2005Q4 résout ce problème sous Windows. Cependant, il persiste sur les systèmes HP-UX.
Si Access Manager est installé dans un environnement linguistique utilisant des caractères multioctets (comme le japonais ou le chinois) sous Windows, les mots sont tronqués dans les messages sortants apparaissant dans la fenêtre de terminal pendant sa configuration.
Solution : aucune, mais ce problème n'affecte pas la configuration en elle-même.
Si vous installez le patch 5 (124296-05) dans une autre langue que l'anglais sous Windows, certaines chaînes apparaissent dans les panneaux d'installation sous la forme de touches de propriété au lieu de s'afficher sous forme de texte. Exemples de touches de propriété : PRODUCT_NAME, JES_Patch_FinishPanel_Text1 et JES_Patch_FinishPanel_Text2.
Solution : aucune
Le script amtune configure la propriété com.iplanet.am.session.purgedelay sur 1 pour autoriser autant de sessions Access Manager que possible. Cette propriété spécifie, en minutes, le délai pendant lequel l'opération de session de purge est repoussée. Pour les clients comme Sun Java System Portal Server, cependant, une valeur de 1 peut s'avérer trop faible.
Solution : réinitialisez la propriété com.iplanet.am.session.purgedelay après avoir exécuté le script amtune :
Dans le fichier AMConfig.properties, configurez la propriété sur la nouvelle valeur. Exemple :
com.iplanet.am.session.purgedelay=5
Redémarrez le conteneur Web d'Access Manager pour appliquer la nouvelle valeur.
Access Manager 7 2005Q4 patch 4 (révision 04) résout les problèmes suivants :
CR# 6463796 : la désactivation du service iPlanetAMClientDetection pour genericHTML bloque l'accès à toutes les pages HTML d'Access Manager
CR# 6463779 : l'authentification distribuée amProfile_Client et le serveur Access Manager Server amProfile_Server répertorient les exceptions inoffensives
CR# 6463730 : les paramètres goto et gx-charset présentent une vulnérabilité de script de site croisé (XSS)
CR# 6435889 : la méthode Session.getSession échoue car RestrictedTokenContext n'est pas configuré
Problèmes et restrictions connus du patch 4
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 :
Dans le fichier Makefile.distAuthUI, remplacez le nom d'utilisateur de l'application anonymous par un autre utilisateur. Exemple :
APPLICATION_USERNAME=user1
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";)
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 :
Modifiez l'étiquette de l'adresse de l'expéditeur. Exemple :
fromAddress.label=<Identity-Server@amhost.example.com>
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.
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
Nouvelles propriétés de configuration pour le contrôle de site
Prise en charge de Liberty Identity Web Services Framework (ID-WSF) 1.1
Problèmes et restrictions connus du patch 3
CR# 6452320 : Les exceptions sont rejetées en cas d'interrogation avec SDK client.
CR# 6441918 : Intervalle de contrôle de site et propriétés du délai d'expiration
CR# 6440648 : La propriété com.iplanet.am.lbcookie.name implique une valeur par défaut de amlbcookie
CR# 6440641 : La propriété com.iplanet.am.lbcookie.value est désapprouvée.
CR# 6429610 : Impossible de créer le jeton SSO en cas d'utilisation d'ID-FF SSO.
CR# 6324056 : La fédération échoue en cas d'utilisation d'un profil d'artefact.
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 :
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 .
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); }
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.
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 :
Sur la machine client de l'interface utilisateur d'authentification distribuée, exécutez "cat /dev/null > distAuth/amProfile_Client" à des intervalles de quelques heures en fonction du trafic.
Sur le serveur Access Manager, exécutez "cat /dev/null > /var/opt/SUNWam/debug/amProfile_Server" à des intervalles de quelques jours plutôt que quelques heures.
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..
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
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 :
Arrêtez le serveur.
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
Redémarrez le serveur.
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.
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 :
Sauvegardez votre arborescence d'informations d'annuaire (DIT) Access Manager 6.
Exécutez le script ampre70upgrade.
Installez Access Manager 7 2005Q4 avec l'option de configuration ultérieure.
Annulez le déploiement des applications Web d'Access Manager.
Déployez les applications Web d'Access Manager.
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.
Exécutez le script amupgrade.
Redéployez les applications Web d'Access Manager en raison des changements du patch 3 d'Access Manager 7.
Accédez à la console Access Manager.
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.
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.
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.
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 :
Créez un utilisateur LDAP comme administrateur de l'authentification distribuée. Exemple :
uid=DistAuthAdmin,ou=people,o=am
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.
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
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'
Pour l'agent de stratégie, ajoutez la propriété au fichier AMAgent.properties .
Pour le serveur Access Manager, ajoutez la propriété au fichier AMConfig.properties.
Remarque : Cette propriété n'est requise que si vous avez implémenté le basculement de session d'Access Manager.
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.
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.
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.
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
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 ...) { ... } ... }
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 :
LoginModuleSample.java
LoginModuleSample.xml
testExtWebSite.jsp
Pour mettre en œuvre cette fonction :
Créez un module d'authentification personnalisé basé sur l'exemple LoginModuleSample.java.
Chargez le module sur un serveur Access Manager.
Définissez RedirectCallback dans le fichier XML à l'aide de l'exemple LoginModuleSample.xml.
Pour tester le module, utilisez le fichier d'exemple testExtWebSite.jsp pour le site Web externe.
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 :
Un utilisateur ouvre la page de traitement d'authentification/de connexion du module d'authentification personnalisé.
L'utilisateur entre les informations d'authentification (nom d'utilisateur et mot de passe) et envoie une requête au module d'authentification personnalisé.
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.
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.
Le module d'authentification personnalisé valide l'utilisateur en fonction du statut renvoyé à l'étape 4 et le renvoie au service d'authentification.
L'authentification utilisateur se termine et est soit réussie, soit en échec.
Solution : Pour résoudre ce problème, appliquez la dernière version du patch 'Core Mobile Access', en fonction de votre plate-forme :
Solaris OS sur les systèmes SPARC : 119527
Solaris OS sur les plates-formes x86 : 119528
Systèmes Linux : 119529
Redémarrez le conteneur Web après application du patch.
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
Nouvelles propriétés des caches User Management, Identity Repository et Service Management
Nouvelle propriété pour le fournisseur de services de fédération
Problèmes et restrictions connus du patch 2
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 :
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
Redémarrez le conteneur Web d'Access Manager pour appliquer les valeurs.
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..
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.
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.
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
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.
Les nouvelles propriétés suivantes sont ajoutées au fichier AMConfig.properties et lues par CDCServlet :
com.iplanet.services.cdc.WaitImage.display entraîne l'affichage d'une image dans le navigateur pendant que l'utilisateur attend la page sécurisée d'un scénario, si cette propriété est paramétrée sur true. La valeur par défaut est faux.
com.iplanet.services.cdc.WaitImage.name indique le nom de l'image. La valeur par défaut est waitImage.gif. Cette image peut être copiée du répertoire login_images.
com.iplanet.services.cdc.WaitImage.width indique la largeur de l'image. La valeur par défaut est 420.
com.iplanet.services.cdc.WaitImage.height indique la hauteur de l'image. La valeur par défaut est 120.
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.
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).
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
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 :
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.
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).
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.
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.