test

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

Problèmes liés à la documentation

Access Manager ne peut pas rebasculer en mode Hérité à partir du mode Domaine (6508473)

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

Obtention de davantage d'informations sur la désactivation des recherches persistantes (6486927)

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.

Attention – Attention –

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.

Documentation des privilèges d'Access Manager pris et non pris en charge (2143066)

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 privilèges suivants sont pris en charge :

Documentation du routage des demandes d'association basé sur des cookies (6476922)

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 :

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

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

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

Documentation de la configuration de Windows Desktop SSO pour Windows 2003 (6487361)

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 :

http://technet2.microsoft.com/WindowsServer/en/library/64042138-9a5a-4981-84e9-d576a8db0d051033.mspx?mfr=true

Documentation des étapes de configuration des mots de passe du serveur d'interface utilisateur d'authentification distribuée (6510859)

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 :

  1. Sur le serveur Access Manager :

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

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

  2. Sur le serveur d'interface utilisateur d'authentification distribuée, apportez les modifications suivantes au fichier AMConfig.properties :

    1. Commentez la propriété com.iplanet.am.service.password.

    2. Configurez la propriété com.iplanet.am.service.secret sur le mot de passe chiffré amadmin à l'étape 1a.

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

  3. Redémarrez le serveur d'interface utilisateur d'authentification distribuée.

L'aide en ligne sur la création d'un nouveau nom de site demande plus d'informations (2144543)

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.

Le paramètre de configuration du mot de passe administrateur estADMIN_PASSWD sous Windows (6470793)

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.

Les notes de version ne résolvent pas un problème connu (6422907)

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.

Document com.iplanet.am.session.protectedPropertiesList dans AMConfig.properties (6351192)

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 :

  1. À l'aide d'un éditeur de texte, ajoutez le paramètre au fichier AMConfig.properties .

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

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

Documentation de la prise en charge des rôles et des rôles filtrés pour le plug-in LDAPv3 (6365196)

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.

Documentation des propriétés non utilisées dans le fichier AMConfig.properties (6344530)

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 côté serveur ne doit pas être paramétrée sur true (6320475)

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 l'aide en ligne de la console (6296751)

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.

Documentation sur la façon d'activer le chiffrement XML (6275563)

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 :

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

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

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

  4. Copiez les fichiers US_export_policy.jar et local_policy.jar téléchargés dans le répertoire jdk_root/jre/lib/security .

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

  6. Définissez la propriété suivante du fichier AMConfig.properties sur true :

    com.sun.identity.jss.donotInstallAtHighestPriority=true

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