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
Nueva secuencia de comandos updateschema.sh para cargar archivos LDIF y XML
Compatibilidad con valores de tiempo de espera inactivo de sesión de aplicaciones específicas
CDC Servlet puede implementarse en un servidor de la IU de autenticación distribuida
El certificado de autenticación puede utilizar un valor UPN para asignar un perfil de usuario.
SAML es compatible con una nueva SPI de identificador de nombres.
Nuevas propiedades de configuración para la supervisión de sitios
El usuario ya no tiene que autenticarse dos veces en la cadena de autenticación.
Cambios en las secuencias de comandos de ajuste del rendimiento
Problemas conocidos y limitaciones de la revisión 5
CR# 6520016: la instalación sólo de SDK de la revisión 5 sobrescribe los archivos MAKE de ejemplos
CR# 6515383: la autenticación distribuida y el agente J2EE no funcionan en el mismo contenedor web
CR# 6402167: LDAP JDK 4.18 causa problemas en el cliente LDAP/Directory Server
CR# 6513653: problema con la configuración de la propiedad com.iplanet.am.session.purgedelay
Problemas de internacionalización (g11n)
Actualizaciones de la documentación
Access Manager no puede pasar del modo tradicional al modo de dominio (6508473)
Información acerca de la deshabilitación de búsquedas persistentes (6486927)
Información sobre privilegios admitidos y no admitidos de Access Manager (2143066)
Información sobre encaminamiento de solicitudes persistentes basadas en cookies (6476922)
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.
La revisión 124296 proporciona compatibilidad con los sistemas Windows. Para obtener más información, consulte:
Instrucciones de instalación de revisiones para los sistemas Windows
Las secuencias de comandos de ajuste están disponibles para sistemas Windows
Para obtener información sobre la instalación en sistemas Windows, consulte la Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows .
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:
AddLDAPFilterCondition.xml
amPolicyConfig_mod_ldfc.xml
accountLockoutData.xml
accountLockout.ldif
idRepoServiceAddAttrSchemaRequest_Cache.xml
wsf1.1_upgrade.xml
amAuth_mod.xml
amAuthCert_mod.xml
En versiones de revisiones anteriores de Access Manager, se le solicitó que cargara estos archivos manualmente.
Para ejecutar la secuencia de comandos updateschema.sh:
Inicie una sesión como superusuario o conviértase en uno (root).
Cambie al directorio de la revisión.
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.
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
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
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.
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:
Los agentes que protegen la aplicación deben configurarse de tal manera que cumplan las decisiones de la directiva URL de Access Manager.
Deben configurarse los agentes para ejecutarse en modo de caché de decisiones de directiva automática. Consulte las siguientes propiedades:
Para agentes web: com.sun.am.policy.am.fetch_from_root_resource
Para agentes de J2EE: com.sun.identity.policy.client.cacheMode
El archivo AMConfig.properties de Access Manager debe especificar un orden de evaluación de componentes de directiva tal que esa condición se evalúe al final. Consulte la siguiente propiedad:
com.sun.identity.policy.Policy.policy_evaluation_weights
El acceso a la aplicación permitido por el agente basado en una decisión almacenada en caché local será desconocido para la condición sobre Access Manager. Por tanto, el tiempo de espera inactivo de la aplicación actual estará entre el tiempo de espera inactivo de la aplicación y el tiempo de espera inactivo de la aplicación menos la duración de la caché del agente.
Para usar esta función:
Agregue una condición de esquema de autenticación a las directivas que protegen la aplicación que necesita el tiempo de espera inactivo de sesión específico de la aplicación.
Especifique el nombre de la aplicación y el valor de tiempo de espera en la condición de esquema de autenticación.
Utilice el mismo nombre de la aplicación y valor de tiempo de espera en todas las directivas aplicables a los recursos de la aplicación.
Especifique el valor de tiempo de espera en minutos. Si el valor es 0 o superior al valor de tiempo de espera inactivo de la sesión especificado en el servicio de sesión, se ignorará el valor y se aplicará el tiempo de espera del servicio de sesión.
Por ejemplo, considere una directiva http://host.sample.com/hr/*, con esta condición de esquema de autenticación:
Esquema de autenticación: LDAP
Nombre de aplicación: RR.HH.
Valor de tiempo de espera: 10
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 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:
Modifique el archivo AMAgent.properties del agente para que señale a CDC Servlet en la autenticación distribuida (cliente). Por ejemplo, para agentes web, cambie la siguiente propiedad:
com.sun.am.policy.agents.config.cdcservlet.url= http://DAhost.DAdomain:DAport/DISTAUTH_DEPLOY_URI/cdcservlet
Defina las directivas como le convenga en Access Manager para los recursos que el agente deba proteger. Por ejemplo, si el agente está en host.example.com:80 , defina una directiva para el recurso como http://host.example.com:80/* .
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
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.
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 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.
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:
Agregue las propiedades y sus valores al archivo AMConfig.properties . Si utiliza agentes de directivas, agregue estas propiedades al archivo AMAgents.properties.
Reinicie el contenedor web de Access Manager para que se apliquen los valores.
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.
La revisión 5 incluye estos cambios en las secuencias de comandos de ajuste del rendimiento:
Las secuencias de comandos de ajuste son compatibles con un archivo de contraseñas
La secuencia de comandos de ajuste elimina los ACI innecesarios de Directory Server
La secuencia de comandos única amtune-os ajusta los SO Solaris y Linux
Las secuencias de comandos de ajuste están disponibles para sistemas Windows
Consideraciones de ajuste para servidores Sun Fire T1000 y T2000
Consulte también CR# 6527663: el valor predeterminado de la propiedad com.sun.identity.log.resolveHostName debe ser false en lugar de true.
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.
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 .
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:
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.
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 .
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.
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.
Para hacer cambios de ajuste, defina AMTUNE_MODE=CHANGE en el archivo amtune-env.
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 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.
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.
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:
Las secuencias de comandos de Windows se escriben en Perl y necesitan Active Perl 5.8 para ejecutarse.
Si desea ajustar Directory Server, tras ejecutar la secuencia de comandos amtune-prepareDSTuner.pl , debe copiar los archivos amtune-utils.pl, amtune-directory.pl, remacis.ldif y amtune-samplepassordfile en el sistema de Directory Server, ya que la secuencia de comandos no puede comprimir estos archivos.
No se encuentra disponible ninguna secuencia de comandos para ajustar el sistema operativo Windows.
No se proporciona compatibilidad para zonas.
Antes de ejecutar una secuencia de comandos, debe definir el parámetro $BASEDIR en el directorio de instalación de Access Manager en el archivo amtune-env.pl.
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.
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.
DESGenKey.java genera una clave exclusiva utilizada para cifrar y descifrar la contraseña del usuario.
ReplayPasswd.java lee el valor de clave de cifrado de la propiedad com.sun.am.replaypasswd.key en el archivo AMConfig.properties, cifra la contraseña y la asigna a la propiedad de la sesión sunIdentityUserPassword.
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:
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
Asigne un valor de clave de cifrado del Paso 1 a la propiedad com.sun.am.replaypasswd.key del archivo AMConfig.properties.
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:
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.
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 .
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.
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.
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:
Sistemas Solaris: /etc/opt/SUNWam/config/xml
Sistemas Linux y HP-UX: /etc/opt/sun/identity/config/xml
Solución: Edite los archivos amAuthLDAP.xml y amPolicyConfig.xml y elimine la contraseña de texto sin formato.
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:
En el servidor de Access Manager, inicie una sesión como superusuario o conviértase en uno (root).
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.
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
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:
Aplique la revisión 5.
Modifique el archivo amsilent y vuelva a implementar la primera instancia de Access Manager.
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:
Sistemas Solaris: /etc/opt/SUNWam/config
Sistemas Linux: /etc/opt/sun/identity/config
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.
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:
Ejecute la secuencia de comandos amconfig con DEPLOY_LEVEL=14 para desinstalar SDK y desconfigurar el contenedor web.
Ejecute la secuencia de comandos amconfig con DEPLOY_LEVEL=4 para reinstalar SDK y volver a configurar el contenedor web.
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
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.
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.
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:
La URL es relativa y no se encuentra disponible ninguna página correspondiente en el servidor de la IU de autenticación distribuida
La URL es absoluta y el navegador no puede alcanzar la URL.
Solución: Especifique siempre un parámetro de URL goto explícito para un servidor de la IU de autenticación distribuida.
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:
SO Solaris, SPARC y plataformas x86: 119725-04
SO Linux: 120834-02
Las revisiones están disponibles en SunSolve Online: http://sunsolve.sun.com.
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.
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.
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.
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
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:
En el archivo AMConfig.properties, defina la propiedad en el nuevo valor. Por ejemplo:
com.iplanet.am.session.purgedelay=5
Reinicie el contenedor web de Access Manager para que se aplique el nuevo valor.