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)
Les notes de version ne résolvent pas un problème connu (6422907)
Document com.iplanet.am.session.protectedPropertiesList dans AMConfig.properties (6351192)
Documentation de la prise en charge des rôles et des rôles filtrés pour le plug-in LDAPv3 (6365196)
Documentation des propriétés non utilisées dans le fichier AMConfig.properties (6344530)
L'URL par défaut de connexion réussie est incorrecte dans l'aide en ligne de la console (6296751)
Documentation sur la façon d'activer le chiffrement XML (6275563)
Si vous installez Access Manager 7 2005Q4 en mode Domaine, vous ne pouvez pas rebasculer en mode Hérité.
Si vous installez Access Manager 7 2005Q4 en mode Hérité, vous pouvez basculer en mode Domaine à l'aide de la commande amadmin associée à l'option -M. Exemple :
amadmin -u cn=amAdmin,ou=People,dc=example,dc=com -w amadmin-password -M dc=example,dc=com
Access Manager utilise les recherches persistantes pour recevoir des informations sur la modification des entrées de Sun Java System Directory Server. Access Manager crée par défaut les connexions de recherche persistante suivantes pendant le démarrage du serveur :
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.
Il n'est pas recommandé de désactiver les recherches persistantes de l'un de ces composants. De fait, lorsqu'une recherche persistante d'un composant est désactivée, ce dernier ne reçoit pas de notification de Directory Server. Par conséquent, les modifications apportées dans Directory Server pour ce composant particulier ne seront pas notifiées au cache du composant et le cache du composant sera bloqué.
Par exemple, si vous désactivez les recherches persistantes des modifications dans le répertoire utilisateur (um), le serveur Access Manager ne recevra plus les notifications de Directory Server. Par conséquent, un agent ne recevra pas les notifications d'Access Manager l'avertissant de mettre à jour son cache utilisateur local vers les nouvelles valeurs de l'attribut utilisateur. Si ensuite une application demande à l'agent de lui fournir les attributs utilisateur, elle recevra les anciennes valeurs.
N'utilisez cette propriété que dans des circonstances spéciales et lorsque cela est absolument nécessaire. Par exemple, si vous savez que les modifications de la configuration du service (en rapport avec la modification des valeurs de n'importe quel service comme le service de session ou les services d'authentification) ne seront pas mises en œuvre dans l'environnement de production, vous pouvez désactiver la recherche persistante sur le composant Service Management (sm). Cependant, en cas de modification d'un service quelconque, vous devrez redémarrer le serveur. La même condition s'applique aux recherches persistantes spécifiées par les valeurs aci et um.
Pour plus d'informations, consultez la section CR# 6363157 : la nouvelle propriété désactive les recherches persistantes si cela est absolument nécessaire.
Les privilèges définissent les droits d'accès dont bénéficient les administrateurs appartenant aux rôles ou groupes existant dans un domaine. Access Manager vous autorise à configurer les autorisations des types d'administrateurs suivants :
Les administrateurs de domaine peuvent exécuter toutes les tâches liées au domaine, y compris la définition des référentiels d'identité (magasins de données), la configuration de l'authentification et la définition des stratégies.
Les administrateurs de stratégie peuvent configurer des stratégies dans les domaines existants.
Les privilèges suivants sont pris en charge :
Accès en lecture et écriture à toutes les propriétés de stratégie et de domaine Définit les privilèges d'accès en lecture et écriture des administrateurs de domaine.
Accès en lecture et écriture aux propriétés de stratégie uniquement Définit les privilèges d'accès en lecture et écriture des administrateurs de stratégie.
Combinaison de privilèges pris en charge : Accès en lecture et écriture uniquement pour les propriétés de stratégie et accès en lecture seule aux magasins de données. Les autres combinaisons de privilèges ne sont pas prises en charge.
Lorsque les serveurs Access Manager sont déployés derrière un équilibreur de charge, le routage des demandes d'association basé sur les cookies empêche une requête cliente d'être acheminée vers un serveur Access Manager incorrect (c'est-à-dire vers un serveur n'hébergeant pas la session). Cette fonctionnalité a été implémentée dans Access Manager 7 2005Q4 patch 3.
Auparavant, en l'absence d'un tel routage, les requêtes des clients non basés sur un navigateur (comme les agents de stratégie et les clients utilisant le SDL client distant d'Access Manager) étaient souvent acheminées vers un serveur Access Manager sur lequel la session n'était pas hébergée. Pour envoyer la requête au serveur approprié, le serveur Access Manager devait alors valider la session au moyen d'une communication par canal retour, ce qui engendrait une dégradation des performances. Le routage des demandes d'association basé sur des cookies permet de ne pas recourir aux communications par canal retour et contribue donc à améliorer les performances d'Access Manager.
Pour mettre en œuvre le routage des demandes d'association basé sur des cookies, le déploiement d'Access Manager doit être configuré comme un site. Pour obtenir plus d'informations, reportez-vous à la section Configuring an Access Manager Deployment as a Site du Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.
Pour configurer le routage des demandes d'association basé sur des cookies :
Pour spécifier un nom de cookie, configurez la propriété com.iplanet.am.lbcookie.name dans le fichier AMConfig.properties. Access Manager génère ensuite le cookie d'équilibreur de charge à l'aide d'un ID de serveur à 2 octets (comme 01, 02 et 03). Si vous ne spécifiez pas de nom de cookie, Access Manager génère la valeur du cookie d'équilibreur de charge à l'aide du nom par défaut amlbcookie plus l'ID de serveur à 2 octets.
Si vous configurez le nom du cookie du serveur Access Manager, 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 Access Manager.
Remarque : Ne configurez pas la propriété com.iplanet.am.lbcookie.value car Access Manager définit la valeur du cookie à l'aide de l'ID de serveur à 2 octets.
Configurez l'équilibreur de charge avec le nom de cookie de l'étape 1. Vous pouvez utiliser un équilibreur de charge matériel ou logiciel avec votre déploiement Access Manager.
Si un basculement de session est implémenté, activez la propriété com.sun.identity.session.resetLBCookie pour l'agent de stratégie et le serveur Access Manager.
Pour un agent de stratégie, ajoutez la propriété au fichier AMAgent.properties et activez-la.
Pour un serveur Access Manager, ajoutez la propriété au fichier AMConfig.properties et activez-la.
Exemple :
com.sun.identity.session.resetLBCookie='true'
En cas de basculement, la session est acheminée vers un serveur Access Manager secondaire et la valeur du cookie d'équilibreur de charge est configurée sur l'ID de serveur du serveur Access Manager secondaire. Toute requête ultérieure de la session est acheminée vers le serveur Access Manager secondaire.
Pour configurer Windows Desktop SSO sous Windows 2003, comme indiqué dans la section Configuring Windows Desktop SSO du Sun Java System Access Manager 7 2005Q4 Administration Guide, utilisez la commande ktpass suivante :
ktpass /out filename /mapuser username /princ HTTP/hostname.domainname /crypto encryptiontype /rndpass /ptype principaltype /target domainname
Exemple :
ktpass /out demo.HTTP.keytab /mapuser http /princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM /crypto RC4-HMAC-NT /rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM
La syntaxe est décrite sur le site suivant :
La procédure suivante décrit comment configurer les mots de passe chiffrés d'un serveur d'interface utilisateur d'authentification distribuée communiquant avec un serveur Access Manager.
Pour configurer les mots de passe d'un serveur d'interface utilisateur d'authentification distribuée :
Sur le serveur Access Manager :
Chiffrez le mot de passe amadmin à l'aide de l'utilitaire ampassword -e. Par exemple, sur les systèmes Solaris :
# cd /opt/SUNWam/bin # ./ampassword -e amadmin-password AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX
Enregistrez la valeur chiffrée.
Copiez et enregistrez la valeur de la propriété am.encryption.pwd à partir du fichier AMConfig.properties du serveur Access Manager. Exemple :
am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y
Sur le serveur d'interface utilisateur d'authentification distribuée, apportez les modifications suivantes au fichier AMConfig.properties :
Commentez la propriété com.iplanet.am.service.password.
Configurez la propriété com.iplanet.am.service.secret sur le mot de passe chiffré amadmin à l'étape 1a.
Ajoutez am.encryption.pwd et la valeur chiffrée que vous avez copiés à l'étape 1b. Exemple :
com.sun.identity.agents.app.username=username #com.iplanet.am.service.password=password com.iplanet.am.service.secret=AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y
Redémarrez le serveur d'interface utilisateur d'authentification distribuée.
Dans l'aide en ligne d'Access Manager Console, il manque l'état de sauvegarde de la procédure de création d'un nouveau nom de site sous Configuration>Propriétés du système>Plate-forme. Si vous ne cliquez pas sur Enregistrer après avoir ajouté un nouveau nom de site et que vous essayez ensuite d'ajouter un nom d'instance, la procédure échoue. Par conséquent, vous devez toujours cliquer sur Enregistrer après avoir ajouté le nom du site, puis ajouter le nom de l'instance.
Sous Solaris et Linux, le paramètre de configuration du mot de passe (amadmin ) administrateur d'Access Manager dans le fichier amsamplesilent est ADMINPASSWD. Sous Windows, le paramètre dans le fichier AMConfigurator.properties est ADMIN_PASSWD .
Si vous exécutez amconfig.bat sous Windows, définissez le mot de passe amadmin dans le fichier AMConfigurator.properties à l'aide du paramètre ADMIN_PASSWORD et non du paramètre ADMINPASSWD.
L'étape 3 de la procédure L'exécution de l'exemple de services Web renvoie le message Resource offering not found (6359900) n'est pas corrigée.
Le paramètre com.iplanet.am.session.protectedPropertiesList ne vous permet pas de protéger certaines propriétés essentielles ou de session interne contre des mises à jour à distance via la méthode SetProperty de Session Service. Le réglage de ce paramètre de sécurité clé “ masqué ” vous permet de personnaliser des attributs de session en vue d'une autorisation et dans le cadre d'autres fonctionnalités d'Access Manager. Pour utiliser ce paramètre :
À l'aide d'un éditeur de texte, ajoutez le paramètre au fichier AMConfig.properties .
Réglez le paramètre pour les propriétés de session que vous souhaitez protéger. Exemple :
com.iplanet.am.session.protectedPropertiesList = PropertyName1,PropertyName2,PropertyName3
Redémarrez le conteneur Web d'Access Manager pour appliquer les valeurs.
Après avoir appliqué le patch respectif, vous pouvez configurer les rôles et les rôles filtrés pour le plug-in LDAPv3, si les données sont stockées dans Sun Java System Directory Server (résout CR 6349959). Au niveau de la console d'administration Access Manager 7 2005Q4, dans la configuration LDAPv3, saisissez les valeurs suivantes pour le champ Types et opérations pris en charge du plug-in LDAPv3 :
role: read,edit,create,delete filteredrole: read,edit,create,delete
Vous pouvez saisir une ou plusieurs des entrées ci-dessus, en fonction des rôles et des rôles filtrés que vous prévoyez d'utiliser dans votre configuration LDAPv3.
Les propriétés suivantes du fichier AMConfig.properties ne sont pas utilisées :
com.iplanet.am.directory.host com.iplanet.am.directory.port
La propriété com.iplanet.am.session.client.polling.enable dans le fichier AMConfig.properties ne doit jamais être paramétrée sur true côté serveur.
Solution : Par défaut, cette propriété est paramétrée sur false. Elle ne doit jamais être paramétrée sur true.
L'URL par défaut de connexion réussie est incorrecte dans le fichier service.scserviceprofile.iplanetamauthservice.html de l'aide en ligne. Le champ URL par défaut de connexion réussie accepte une liste de valeurs multiples indiquant l'URL vers lequel les utilisateurs sont redirigés à l'issue d'une authentification réussie. Le format de cet attribut est clientType|URL, bien que vous puissiez ne spécifier que la valeur de l'URL, qui suppose un type HTML par défaut.
La valeur par défaut /amconsole est incorrecte.
Solution : La valeur par défaut appropriée est /amserver/console.
Pour activer le chiffrement XML pour Access Manager ou Federation Manager à l'aide du fichier JAR Bouncy Castle afin de générer une clé de transport, appliquez les étapes suivantes :
Si vous utilisez une version de JDK antérieure à la version 1.5, téléchargez le fournisseur JCE Bouncy Castle depuis le site Web de Bouncy Castle (http://www.bouncycastle.org/). Par exemple, pour JDK 1.4, téléchargez le fichier bcprov-jdk14-131.jar .
Si vous avez téléchargé un fichier JAR lors de l'étape précédente, copiez le fichier dans le répertoire jdk_root/jre/lib/ext.
Pour la version domestique de JDK, téléchargez les fichiers JCE Unlimited Strength Jurisdiction Policy correspondant à votre version de JDK depuis le site Web de Sun (http://java.sun.com). Pour IBM WebSphere, rendez-vous sur le site IBM correspondant pour télécharger les fichiers requis.
Copiez les fichiers US_export_policy.jar et local_policy.jar téléchargés dans le répertoire jdk_root/jre/lib/security .
Si vous utilisez une version de JDK inférieure à JDK 1.5, modifiez le fichier jdk_root/jre/lib/security/java.security et ajoutez Bouncy Castle en tant que fournisseur. Exemple :
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
Définissez la propriété suivante du fichier AMConfig.properties sur true :
com.sun.identity.jss.donotInstallAtHighestPriority=true
Redémarrez le conteneur Web d'Access Manager.
Pour de plus amples informations, reportez-vous au problème ayant pour ID 5110285 (le chiffrement XML requiert un fichier JAR Bouncy Castle).