test

Notas de la version de Sun Java System Access Manager 7 2005Q4

Access Manager 7 2005Q4 revisión 5

Access Manager 7 revisión 5 (versión 05) soluciona diversos problemas, como se indica en el archivo README incluido con la revisión. La revisión 5 también incluye las siguientes nuevas funciones, problemas y actualizaciones de documentación.

Nuevas funciones de la revisión 5

Problemas conocidos y limitaciones de la revisión 5

Problemas de internacionalización (g11n)

Actualizaciones de la documentación

Compatibilidad con los sistemas HP-UX

La revisión 126371 cuenta con compatibilidad con los sistemas HP-UX. Para obtener más información, consulte:

Para obtener información sobre la instalación en sistemas HP-UX, consulte Guía de instalación de Sun Java Enterprise System 2005Q4 para UNIX.

Compatibilidad con sistemas de Microsoft Windows

La revisión 124296 proporciona compatibilidad con los sistemas Windows. Para obtener más información, consulte:

Para obtener información sobre la instalación en sistemas Windows, consulte la Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows .

Nueva secuencia de comandos updateschema.sh para cargar archivos LDIF y XML

La revisión 5 (y posteriores) incluye la secuencia de comandos updateschema.sh, que carga los archivos siguientes para actualizar el esquema de servicio de Directory Server:

En versiones de revisiones anteriores de Access Manager, se le solicitó que cargara estos archivos manualmente.

Para ejecutar la secuencia de comandos updateschema.sh:

  1. Inicie una sesión como superusuario o conviértase en uno (root).

  2. Cambie al directorio de la revisión.

  3. Ejecute la secuencia de comandos. Por ejemplo, en sistemas Solaris:

    # cd /120954-07 
# ./updateschema.sh

    En sistemas Windows, la secuencia de comandos es updateschema.pl.

  4. Cuando la secuencia de comandos se lo solicite, introduzca estos elementos:

    • Nombre de host y número de puerto de Directory Server

    • DN y contraseña de usuario administrativo de Directory Server

    • DN y contraseña amadmin

  5. La secuencia de comandos valida sus entradas y, a continuación, carga los archivos. La secuencia de comandos también escribe el siguiente archivo de registro:

    • Sistemas Solaris: /var/opt/SUMWam/logs/AM70Patch.upgrade.schema. timestamp

    • Sistemas Linux: /var/opt/sun/identity/logs/AM70Patch.upgrade.schema. timestamp

  6. Una vez finalizada la secuencia de comandos, reinicie el contenedor web de Access Manager.

Nota si elimina la revisión 5, los cambios realizados en el esquema agregados por la secuencia de comandos updateschema.sh no se eliminan de Directory Server. Sin embargo, no es necesario eliminar esos cambios manualmente porque no afectarán a la funcionalidad ni a la facilidad de uso de Access Manager una vez eliminada la revisión.

Compatibilidad con valores de tiempo de espera inactivo de sesión de aplicaciones específicas

La revisión 5 permite que distintas aplicaciones tengan valores de tiempo de espera inactivo de diferentes sesiones. En una empresa, puede que algunas aplicaciones necesiten valores de tiempo de espera inactivo de sesión inferiores al tiempo de espera inactivo de sesión especificado en el servicio de sesión. Por ejemplo, suponga que ha establecido el valor de tiempo de espera de inactividad de sesión en el servicio de sesión en 30 minutos, pero una aplicación de RR.HH. debe agotar el tiempo de espera si un usuario ha estado inactivo durante más de 10 minutos.

Los requisitos para utilizar esta función son:

Para usar esta función:

Por ejemplo, considere una directiva http://host.sample.com/hr/*, con esta condición de esquema de autenticación:

Si hay varias directivas definidas para proteger los recursos de la aplicación de RR.HH., debe agregar la condición a todas ellas.

Si un usuario intenta acceder, en una sesión distinta, a la aplicación de RR.HH. protegida por el agente de Access Manager, se le solicitará su autenticación para el esquema LDAP (si aún no se ha autenticado).

Si ya se ha autenticado para el esquema LDAP, podrá acceder sólo si el tiempo es inferior a 10 minutos desde la última autenticación o si el tiempo es inferior a 10 minutos desde el último acceso del usuario a la aplicación de RR.HH. De lo contrario, el usuario debe autenticarse de nuevo para el esquema LDAP para acceder a la aplicación.

CDC Servlet puede implementarse en un servidor de la IU de autenticación distribuida

CDC Servlet puede coexistir con un servidor de la IU de autenticación distribuida en DMZ para habilitar el inicio de sesión único de dominio cruzado (CDSSO). El servidor de Access Manager puede implementarse detrás de un servidor de seguridad, y CDC Servlet se encarga de todo el acceso a Access Manager para habilitar CDSSO en el servidor de la IU de autenticación distribuida. Para habilitar CDSSO, consulte la documentación del agente de directivas específica y realice los siguientes pasos adicionales:

Se puede especificar un dominio cuando el servlet de CDC redirige a la URL de inicio de sesión de Access Manager

Ahora puede especificar un nombre de dominio en el servlet de CDC para que, cuando se produzca el redireccionamiento a la URL de inicio de sesión de Access Manager, el nombre de dominio esté incluido y el usuario pueda iniciar una sesión en el dominio específico. Por ejemplo:

com.sun.am.policy.agents.config.cdcservlet.url=
    http://lb.example.com/amserver/cdcservlet?org=realm1

El certificado de autenticación puede utilizar un valor UPN para asignar un perfil de usuario.

Previamente, el certificado de autenticación utilizó sólo el componente dn en subjectDN para asignar un perfil de usuario. Access Manager ahora permite el valor de nombre principal de usuario (UPN) en SubjectAltNameExt para la asignación de perfiles.

El proceso de cierre de la sesión posterior a la autenticación se produce en un entorno de varios servidores.

Este proceso ahora se produce cuando un usuario finaliza una sesión en un servidor distinto de aquel en el que inició la sesión originalmente en un entorno de varios servidores, con o sin la opción de migración tras error de sesión configurada.

SAML es compatible con una nueva SPI de identificador de nombres.

SAML ahora es compatible con una nueva interfaz de proveedor de servicios (SPI) de identificador de nombres, para que un sitio pueda personalizar el identificador de nombres en la afirmación SAML. Un sitio puede implementar la nueva interfaz NameIdentifierMapper para asignar una cuenta de usuario a un identificador de nombres en el asunto de una afirmación SAML.

Nuevas propiedades de configuración para la supervisión de sitios

La función de supervisión de sitios de Access Manager incluye las siguientes nuevas propiedades que permiten especificar el comportamiento de la comprobación de estado del sitio.

Propiedad 

Descripción 

com.sun.identity.urlchecker.invalidate.interval

Intervalo de tiempo en milisegundos para reconocer un sitio que no responde o está inactivo.  

Valor predeterminado: 70.000 milisegundos (70 segundos). 

com.sun.identity.urlchecker.sleep.interval

Intervalo de tiempo en milisegundos que debería permanecer suspendida la comprobación de estado del sitio. 

Valor predeterminado: 30.000 milisegundos (30 segundos). 

com.sun.identity.urlchecker.targeturl

Distintas URL de destino para la comprobación del estado del proceso de Access Manager. 

Valor predeterminado: "/amserver/namingservice".

La revisión no agrega estas propiedades al archivo AMConfig.properties . Para utilizar las nuevas propiedades con valores diferentes a los predeterminados:

  1. Agregue las propiedades y sus valores al archivo AMConfig.properties . Si utiliza agentes de directivas, agregue estas propiedades al archivo AMAgents.properties.

  2. Reinicie el contenedor web de Access Manager para que se apliquen los valores.

El usuario ya no tiene que autenticarse dos veces en la cadena de autenticación.

Considere el siguiente escenario. Un sitio configura una cadena de autenticación con tres módulos LDAP. Todos los módulos se configuran en SUFFICIENT y las opciones iplanet-am-auth-shared-state-enabled y iplanet-am-auth-store-shared-state-enabled se configuran en true. Por ejemplo:

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

La revisión 5 agrega la nueva opción iplanet-am-auth-shared-state-behavior-pattern a las opciones de módulo con dos valores posibles: tryFirstPass (default) and useFirstPass.

Para evitar que un usuario tenga que introducir dos veces el Id. de usuario y la contraseña para autenticarse (tal como se describe en el escenario anterior), configure la nueva opción en useFirstPass para todos los módulos de la cadena. Anteriormente, se le solicitó a un usuario que existía sólo en la tercera instancia LDAP que introdujera un Id. de usuario y contraseña dos veces para autenticarse.

Cambios en las secuencias de comandos de ajuste del rendimiento

La revisión 5 incluye estos cambios en las secuencias de comandos de ajuste del rendimiento:

Consulte también CR# 6527663: el valor predeterminado de la propiedad com.sun.identity.log.resolveHostName debe ser false en lugar de true.

Las secuencias de comandos de ajuste son compatibles con un archivo de contraseñas

La revisión 5 permite especificar contraseñas para las secuencias de comandos de ajuste en un archivo de texto. Anteriormente, podía introducir contraseñas sólo como argumento de la línea de comandos, opción que podía producir problemas de seguridad. Para utilizar un archivo de contraseñas, configure las variables siguientes como desee en el archivo:

DS_ADMIN_PASSWORD=DirectoryServer-admin-password
AS_ADMIN_PASSWORD=ApplicationServer8-admin-password

Por ejemplo, para ajustar Application Server 8:

# ./amtune-as8 password-file

donde password-file contiene AS_ADMIN_PASSWORD definido en la contraseña de administrador de Application Server 8.

Las secuencias de comandos de ajuste utilizan la opción -j password-file cuando llaman a las utilidades ldapmodify, ldapsearch, db2index y dsconf de Directory Server.

La secuencia de comandos de ajuste elimina los ACI innecesarios de Directory Server

Si Access Manager 7 2005Q4 está instalado en modo de dominio, se utilizan privilegios de delegación para determinar los permisos de acceso y, por tanto, no son necesarios algunos ACI de Directory Server. La revisión 5 de Access Manager 7 2005Q4 permite eliminar los ACI innecesarios ejecutando la secuencia de comandos amtune-prepareDSTuner. Esta secuencia de comandos lee una lista de ACI del archivo remacis.ldif y, a continuación, llama a la utilidad ldapmodify para eliminarlos.

Puede ejecutar la secuencia de comandos amtune-prepareDSTuner para eliminar los ACI innecesarios de los sistemas Solaris, Linux, HP-UX y Windows. Para obtener más información, incluido cómo ejecutar la secuencia de comandos, consulte la Technical Note: Sun Java System Access Manager ACI Guide .

Las secuencias de comandos de ajuste pueden ajustar el contenedor web del servidor de la IU de autenticación distribuida

Después de implementar el servidor de la IU de autenticación distribuida en un contenedor web, puede ajustar el contenedor web ejecutando las secuencias de comandos de ajuste de Access Manager. Las siguientes secuencias de comandos de ajuste definen la máquina virtual de Java (Java Virtual Machine) y otras opciones de ajuste para el contenedor web correspondiente:

Tabla 2 Secuencias de comandos de ajuste del contenedor web de Access Manager

Contenedor web 

Secuencia de comandos de ajuste 

amtune-ws61

Web Server 6.1 

amtune-as7

Application Server 7 

amtune-as8

Application Server Enterprise Edition 8.1 

Para ajustar un contenedor web para un servidor de la IU de autenticación distribuida:

  1. Como el servidor de Access Manager no está instalado en el sistema en el que está implementado el servidor de la IU de autenticación distribuida, copie la secuencia de comandos de ajuste del contenedor web adecuado (mostrada en la tabla anterior), el archivo de configuración amtune-env y la secuencia de comandos amtune-utils de una instalación de servidor de Access Manager. Si desea ajustar el sistema operativo Solaris o Linux, copie también la secuencia de comandos amtune-os.

  2. Edite los parámetros en el archivo de configuración amtune-env para especificar el contenedor web y las opciones de ajuste. Para ejecutar la secuencia de comandos en modo REVIEW, defina AMTUNE_MODE=REVIEW en el archivo amtune-env .

  3. Ejecute la secuencia de comandos de ajuste del contenedor web en modo REVIEW. En modo REVIEW, la secuencia de comandos sugiere cambios de ajuste basados en los valores del archivo amtune-env pero no realiza ningún cambio en la implementación.

  4. Revise las recomendaciones de ajuste en el archivo de registro de depuración. Si es necesario, haga cambios en el archivo amtune-env basados en esta ejecución.

  5. Para hacer cambios de ajuste, defina AMTUNE_MODE=CHANGE en el archivo amtune-env.

  6. Ejecute la secuencia de comandos de ajuste en modo CHANGE para realizar los cambios de ajuste en la implementación.

Para obtener más información acerca de la ejecución de la secuencia de comandos de ajuste para ajustar un contenedor web de Access Manager, consulte el Capítulo 2, Access Manager Tuning Scripts de Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide.

La secuencia de comandos única amtune-os ajusta los SO Solaris y Linux

La revisión 5 incluye una secuencia de comandos única amtune-os para ajustar ambos SO. La secuencia de comandos determina el tipo de SO del comando uname -s. Anteriormente, Access Manager proporcionaba secuencias de comandos amtune-os individuales para ajustar cada SO.

Las secuencias de comandos de ajuste se ejecutan hasta su finalización en una zona local de Solaris 10

Si Access Manager está instalado en una zona local de Solaris 10, todas las secuencias de comandos de ajuste excepto amtune-os pueden ejecutarse en la zona local. En una zona local, la secuencia de comandos amtune-os muestra un mensaje de advertencia pero no ajusta el SO. La secuencia de comandos continúa ejecutando otras secuencias de comandos de ajuste que usted haya solicitado. Anteriormente, en una zona local, la secuencia de comandos amtune-os se cancelaría, además de no ejecutarse las posteriores secuencias de comandos de ajuste solicitadas.

En una zona global de Solaris 10, la secuencia de comandos amtune llama a amtune-os para ajustar el SO además de otras secuencias de comandos que haya solicitado.

Las secuencias de comandos de ajuste están disponibles para sistemas Windows

La revisión 5 incluye secuencias de comandos de ajuste para sistemas Windows. La ejecución de secuencias de comandos de ajuste en un sistema Windows es similar a la ejecución de las secuencias de comandos en un sistema Solaris o Linux, con estas diferencias:

Consideraciones de ajuste para servidores Sun Fire T1000 y T2000

Si Access Manager está instalado en un servidor Sun Fire T1000 o T2000, las secuencias de comandos de ajuste de la revisión 5 para Web Server 6.1 y Application Server 8 definen el parámetro JVM GC ParallelGCThreads en 8:

-XX:ParallelGCThreads=8

Este parámetro reduce el número de subprocesos de liberación de recursos, que podría ser innecesariamente elevado en un sistema compatible con 32 subprocesos. Sin embargo, puede incrementar el valor a 16 o incluso 20 para una CPU virtual de 32 como, por ejemplo, un servidor Sun Fire T1000 o T2000, si minimiza todas las actividades de liberación de recursos.

Además, para los sistemas Solaris SPARC con un procesador CMT con tecnología CoolThreads, se recomienda que agregue la siguiente propiedad al final del archivo /etc/opt/SUNWam/config/AMConfig.properties:

com.sun.am.concurrencyRate=value

El value predeterminado es 16, pero puede definir esta propiedad en un valor inferior, dependiendo del número de núcleos del servidor Sun Fire T1000 o T2000.

Autenticación básica en el agente de directivas de IIS 6.0

Para habilitar la autenticación básica en Microsoft Internet Information Services (IIS) 6.0, el agente de directivas debe obtener el nombre de usuario y la contraseña. La revisión 5 incluye las siguientes nuevas clases que habilitan esta funcionalidad utilizando cifrado DES de la contraseña del usuario.

Para utilizar la autenticación básica en IIS 6.0, debe realizar estos pasos tanto en el servidor de Access Manager como en el agente de directivas de IIS 6.0.

En el servidor de Access Manager:

  1. Ejecute DESGenKey.java para generar una clave de cifrado exclusiva para el cifrado y el descifrado de la contraseña. En los sistemas Solaris, el archivo DESGenKey.java se ubica en el directorio com/sun/identity/common , incluido en am_sdk.jar en el directorio /opt/SUNWam/lib. Por ejemplo, el siguiente comando genera una clave de cifrado:

    # cd /opt/SUNWam/lib
# java -cp am_sdk.jar com.sun.identity.common.DESGenKey

  2. Asigne un valor de clave de cifrado del Paso 1 a la propiedad com.sun.am.replaypasswd.key del archivo AMConfig.properties.

  3. Implemente ReplayPasswd.java como un complemento posterior a la autenticación. Utilice el nombre de clase completo cuando configure el complemento: com.sun.identity.authentication.spi.ReplayPasswd .

En el agente de directivas de IIS 6.0:

  1. Asigne el valor de clave de cifrado del servidor a la propiedad com.sun.am.replaypasswd.key del archivo AMAgent.properties . Tanto el servidor de Access Manager como el agente de directivas de IIS 6.0 deben utilizar la misma clave de cifrado.

  2. Habilite la autenticación básica en IIS 6.0 Manager.

El agente de directivas de IIS 6.0 lee la contraseña cifrada de la respuesta de sesión, descifra la contraseña de la propiedad com.sun.am.replaypasswd.key y configura los encabezados de autenticación para que la autenticación básica comience a funcionar.

Para obtener más información acerca del agente de directivas de IIS 6.0, consulte Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0 .

CR# 6567746: en los sistemas HP-UX, la revisión 5 de Access Manager informa de un valor incorrecto de "errorCode" si se supera el recuento de reintentos de introducción de la contraseña

Cuando se bloquea una cuenta de usuario, la revisión 5 de Access Manager 7 2005Q4 en los sistemas HP-UX informa de errorCode = null en lugar de errorCode = 107 si se supera el recuento de reintentos de introducción de la contraseña.

Solución. Ninguna.

CR# 6527663: el valor predeterminado de la propiedad com.sun.identity.log.resolveHostName debe ser false en lugar de true

Antes de ejecutar la secuencia de comandos de ajuste amtune-identity, se recomienda que agregue la siguiente propiedad definida en false al archivo AMConfig.properties:

com.sun.identity.log.resolveHostName=false

Un valor false minimiza el impacto de resolver nombres de host y, por tanto, puede mejorar el rendimiento. Sin embargo, si desea que el nombre de sistema anfitrión del equipo cliente se imprima en el registro amAuthentication.access, establezca el valor en true.

CR# 6527528: la eliminación de la revisión deja los archivos XML con la contraseña amldapuser en texto sin formato

Si elimina la revisión 5 de una instalación de servidor completo de Access Manager, los archivos amAuthLDAP.xml y amPolicyConfig.xml contienen la contraseña amldapuser en texto sin formato. Estos archivos se encuentran en el siguiente directorio, dependiendo de la plataforma:

Solución: Edite los archivos amAuthLDAP.xml y amPolicyConfig.xml y elimine la contraseña de texto sin formato.

CR# 6527516: el servidor completo en WebLogic necesita archivos JAR JAX-RPC 1.0 para comunicarse con el SDK de cliente

En las revisiones de Access Manager 7 2005Q4, la secuencia de comandos de configuración de Access Manager para BEA WebLogic Server (amwl81config) agrega los archivos JAR JAX-RPC 1.1 a la classpath de la instancia WebLogic. Aunque esta modificación es beneficiosa para productos como Sun Java System Portal Server, una instalación de servidor completo (DEPLOY_LEVEL=1) implementado en WebLogic Server no puede comunicarse con una instalación de SDK de cliente y, posteriormente, se producirán excepciones.

Si el servidor de Access Manager 7 2005Q4 está instalado en BEA WebLogic Server, la CLASSPATH de la secuencia de comandos startWebLogic.sh debe configurarse en la ubicación de los archivos JAR JAX-RPC 1.0 para comunicarse con el SDK de cliente de Access Manager.

Solución: antes de aplicar la revisión de Access Manager, establezca la ruta de clase, CLASSPATH, en la secuencia de comandos startWebLogic.sh para que la instancia de WebLogic Server utilice los archivos JAR de JAX-RPC 1.0 en lugar de los archivos JAR de JAX-RPC 1.1:

  1. En el servidor de Access Manager, inicie una sesión como superusuario o conviértase en uno (root).

  2. Edite la secuencia de comandos startWebLogic.sh y sustituya la CLASSPATH para utilizar los archivos JAR JAX-RPC 1.0. Por ejemplo:

Valor actual:

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:

Valor nuevo:

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:

donde AccessManager-base es el directorio base de instalación. El valor predeterminado es /opt en los sistemas Solaris y /opt/sun en los sistemas Linux y HP-UX. AccessManager-package-dir es el directorio de paquetes de Access Manager.

5. Reinicie la instancia de WebLogic Server.

CR # 6523499: el archivo amsilent de la revisión 5 puede ser leído por todos los usuarios en los sistemas Linux

En los sistemas Linux. la secuencia de comandos postpatch crea el archivo /opt/sun/identity/amsilent con los permisos 644, opción que permite que todos los usuarios tengan acceso de lectura.

Solución: Una vez ejecutada la secuencia de comandos installpatch, cambie los permisos del archivo amsilent para que sólo el propietario tenga acceso de lectura y escritura. Por ejemplo:

# chmod 600 /opt/sun/identity/amsilent

CR# 6520326: la aplicación de la revisión 5 a una segunda instancia de Access Manager en un servidor sobrescribe serverconfig.xml en la primera instancia

En este escenario de implementación, dos instancias de Access Manager se instalan en el mismo servidor del sistema anfitrión, con cada instancia en una instancia de contenedor web distinto. A continuación siga estos pasos:

  1. Aplique la revisión 5.

  2. Modifique el archivo amsilent y vuelva a implementar la primera instancia de Access Manager.

  3. Modifique el archivo amsilent de nuevo para la segunda instancia de Access Manager y, a continuación, vuelva a implementar esa instancia.

Si NEW_INSTANCE=false en el archivo amsilent, el archivo serverconfig.xml de la primera instancia de Access Manager se sobrescribe con la información de la segunda instancia de Access Manager. Falla un reinicio posterior de la primera instancia de Access Manager. El archivo serverconfig.xml se encuentra en el siguiente directorio dependiendo de su plataforma:

Solución: Si implementa la segunda instancia de Access Manager, establezca NEW_INSTANCE=true en el archivo amsilent. El archivo serverconfig.xml de la segunda instancia de Access Manager se actualiza con la información correcta, y el archivo serverconfig.xml de la primera instancia de Access Manager no se sobrescribe.

CR# 6520016: la instalación sólo de SDK de la revisión 5 sobrescribe los archivos MAKE de ejemplos

La aplicación de la revisión 5 a un equipo sólo de SDK sobrescribe los archivos MAKE de ejemplos.

Solución: La aplicación de la revisión 5 a un equipo sólo de SDK no necesita una reconfiguración; sin embargo, si desea utilizar los archivos MAKE de ejemplos, siga estos pasos para actualizar los archivos LDIF y de propiedades (es decir, realice un intercambio de etiquetas) de los archivos MAKE de ejemplos:

  1. Ejecute la secuencia de comandos amconfig con DEPLOY_LEVEL=14 para desinstalar SDK y desconfigurar el contenedor web.

  2. Ejecute la secuencia de comandos amconfig con DEPLOY_LEVEL=4 para reinstalar SDK y volver a configurar el contenedor web.

CR#6515502: el complemento de depósito LDAPv3 no siempre administra correctamente el atributo de búsqueda de alias

Para la mayoría de las búsquedas, este problema se ha solucionado. Sin embargo, tenga cuidado cuando configure el atributo de búsqueda de alias. El valor de los atributos de búsqueda de alias debe ser exclusivo en una organización. Si se configura más de un atributo de búsqueda de alias, es posible que una entrada del almacén de datos coincida con un atributo y que otra entrada coincida con el otro atributo. En esta situación, el servidor de Access Manager emite el siguiente error:

An internal authentication error has occurred. Contact your system administrator.

Solución: Ninguna

CR# 6515383: la autenticación distribuida y el agente J2EE no funcionan en el mismo contenedor web

Un servidor de la IU de autenticación distribuida y un agente de directivas J2EE no funcionan si están instalados en el mismo contenedor web.

Solución: Cree una instancia de un segundo contenedor web e implemente el servidor de la IU de autenticación distribuida y el agente de directivas J2EE en distintas instancias del contenedor.

CR# 6508103: la ayuda en línea devuelve un error de aplicación con Application Server en los sistemas Windows

Si implementa Access Manager en Sun Java System Application Server en un sistema Windows, al hacer clic en la Ayuda del panel izquierdo de la pantalla de ayuda de la consola en modo de dominio aparece un error de aplicación.

Solución: copie el archivo javaes-install-dir\share\lib\jhall.jar en el directorio JAVA_HOME\jre\lib\ext y, a continuación, reinicie Application Server.

CR# 6507383 and CR# 6507377: la autenticación distribuida necesita el parámetro de URL goto explícito

Si no se especifica un parámetro de URL goto específico, un servidor de la IU de autenticación distribuida intenta redirigir al parámetro goto en una URL satisfactoria especificada en Access Manager. Este redireccionamiento puede fallar por estos motivos:

Solución: Especifique siempre un parámetro de URL goto explícito para un servidor de la IU de autenticación distribuida.

CR# 6402167: LDAP JDK 4.18 causa problemas en el cliente LDAP/Directory Server

Access Manager 7 2005Q4 fue lanzado con LDAP JDK 4.18 como parte de la revisión de Java ES 2005Q4, que causó una serie de problemas de conexión de Access Manager y Directory Server.

Solución: Aplique una de las siguientes revisiones de Java Development Kit de Sun Java System LDAP:

Las revisiones están disponibles en SunSolve Online: http://sunsolve.sun.com.

CR# 6352135: los archivos del servidor de la IU de autenticación distribuida se instalan en una ubicación incorrecta

En los sistemas Solaris, el programa de instalación de Java ES instala el servidor de la IU de autenticación distribuida Makefile.distAuthUI, README.distAuthUI y los archivos amauthdistui.war en una ubicación incorrecta: /opt/SUNComm/SUNWam.

Solución: Copie estos archivos en la ubicación correcta: /opt/SUNWam.

Nota: cualquier problema de servidor de la IU de autenticación distribuida solucionado en una revisión se reflejará en el archivo /opt/SUNComm/SUNWam/amauthdistui.war , así que siempre que aplique una revisión en el servidor de Access Manager y, a continuación, genere de nuevo e implemente el archivo WAR, también debe copiar estos archivos en el directorio /opt/SUNWam.

CR# 6522720: la búsqueda en la ayuda en línea de la consola no funciona con caracteres de varios bytes en los sistemas Windows y HP-UX

Si se instala Access Manager en un idioma que utilice caracteres de varios bytes (como, por ejemplo, japonés) en un sistema Windows o HP-UX, no funcionará la búsqueda en la ayuda en línea de la consola con palabras clave introducidas utilizando caracteres de varios bytes.

Solución: Ninguna

Actualización de la revisión 6: la revisión 6 de Access Manager 7 2005Q4 soluciona este problema en los sistemas Windows. Sin embargo, el problema aún persiste en los sistemas HP-UX.

CR# 6524251: los caracteres de varios bytes en los mensajes de salida están distorsionados durante la configuración de Access Manager en los sistemas Windows

Si se instala Access Manager en un idioma que utilice caracteres de varios bytes (como, por ejemplo, japonés o chino) en un sistema Windows, durante la configuración de Access Manager, las palabras se distorsionan en los mensajes de salida en la ventana de terminal.

Solución: Ninguna, pero este problema no afecta a la configuración.

CR# 6526940: las claves de propiedad aparecen en lugar del texto del mensaje durante la instalación de la revisión 5 en idiomas diferentes del inglés en los sistemas Windows

Si instala la revisión 5 (124296-05) en un idioma distinto del inglés en un sistema Windows, algunas cadenas de los paneles de instalación aparecen como claves de propiedad en lugar del texto del mensaje. Ejemplos de claves de propiedad son PRODUCT_NAME, JES_Patch_FinishPanel_Text1 y JES_Patch_FinishPanel_Text2.

Solución: Ninguna

CR# 6513653: problema con la configuración de la propiedad com.iplanet.am.session.purgedelay

La secuencia de comandos amtune de Access Manager configura la propiedad com.iplanet.am.session.purgedelay en 1, para permitir el mayor número posible de sesiones de Access Manager. Esta propiedad especifica el número de minutos de retraso de la operación de sesión de purga. Sin embargo, para clientes como, por ejemplo, Sun Java System Portal Server, no es suficiente un valor de 1.

Solución: Restablezca la propiedad com.iplanet.am.session.purgedelay una vez ejecutada la secuencia de comandos amtune:

  1. En el archivo AMConfig.properties, defina la propiedad en el nuevo valor. Por ejemplo:

    com.iplanet.am.session.purgedelay=5

  2. Reinicie el contenedor web de Access Manager para que se aplique el nuevo valor.