En esta sección, se describen los siguientes problemas conocidos y sus soluciones (si las hay) en el momento de la publicación de Access Manager 7.1.
La información acerca de los problemas de instalación de Java System Enterprise se encuentra en las Notas de la versión de JES5. Consulte la sección Access Manager Installation Issues de Sun Java Enterprise System 5 Release Notes for UNIX.
Esta sección contiene los siguientes problemas conocidos:
Existe un problema conocido con el archivo WAR único implementado en Weblogic 8.1 con la inicialización de JAX-RPC. Para que Access Manager se comunique con el SDK del cliente, deberá sustituir los archivos jar de JAX-RCP 1.1 por archivos jar de JAX-RPC 1.0.
Solución:
Existen dos formas de obtener el archivo WAR. Una es mediante el programa de instalación de Java Enterprise System 5 con Access Manager definido en la opción Configurar más tarde; la otra es desde el sitio de descargas de Sun.
Si ha generado el archivo WAR mediante el programa de instalación de JES 5 con la opción Configurar más tarde:
Elimine los siguientes archivos .jar de JAXRPC 1.1 de AccessManager-base/SUNWam/web-src/WEB-INF/lib :
jaxrpc-api.jar
jaxrpc-spi.jar
jaxrpc-impl.jar
Copie los siguientes archivos .jar desde sus ubicaciones respectivas a AccessManager-base/SUNWam/web-src/WEB-INF/lib :
jaxrpc-api.jar desde /opt/SUNWam/lib/jaxrpc 1.0
jaxrpc_ri.jar desde /opt/SUNWam/lib/jaxrpc 1.0
commons-logging.jar desde /opt/SUNWmfwk/lib
Vaya a AccessManager-base/SUNWam/bin/ y ejecute el siguiente comando:
amconfig —s samplesilent
Para obtener más información sobre cómo configurar Access Manager con la secuencia de comandos amconfig, consulte Running the Access Manager amconfig Script en la Guía de postinstalación de Access Manager.
Si ha obtenido el archivo WAR mediante el sitio de descargas de Sun (http://www.sun.com/download/index.jsp):
Obtenga el archivo ZIP_ROOT/applications/jdk14/amserver.war y ábralo en un área de ensayo, como /tmp/am-staging .
Elimine los siguientes archivos .jar de JAXRPC 1.1 de /tmp/am-staging/WEB-INF/lib:
jaxrpc-api.jar
jaxrpc-spi.jar
jaxrpc-impl.jar
Copie los siguientes archivos .jar de JAXRPC 1.0 y el archivo .jar de registros comunes, que se encuentra en el directorio ZIP_ROOT/applications/jdk14/jarFix a /tmp/am-staging/WEB-INF/lib:
jaxrpc-api.jar
jaxrpc-ri.jar
commons-logging.jar
Vuelva a crear e implementar el archivo WAR de Access Manager. Para obtener más información, consulte Deploying Access Manager as a Single WAR File en la Guía de postinstalación de Access Manager.
Si se genera el archivo WAR único de Access utilizando el programa de instalación de JES 5 con la opción Configurar más tarde, se necesitarán archivos .jar adicionales antes de que implemente Websphere 5.1.
Solución:
Copie jsr173_api.jar desde /usr/share/lib al directorio AcessManager-base/opt/SUNWam/web-src/WEB-INF/lib .
Vaya a AccessManager-base/SUNWam/bin/ y ejecute el siguiente comando:
amconfig —s samplesilent
Para obtener más información sobre cómo configurar Access Manager con la secuencia de comandos amconfig, consulte Running the Access Manager amconfig Script en la Access Manager Post Installation Guide.
Para que la implementación del archivo WAR único de Access Manager con Websphere 5.1 se comunique correctamente con el SDK del cliente deberá realizar cambios en el archivo server.xml .
Solución:
Para cambiar correctamente el archivo server.xml, lleve a cabo los siguientes pasos:
Obtenga el archivo amserver.war. Existen dos maneras de obtener el archivo WAR único; mediante el programa de instalación de JES 5 con la opción Configurar más tarde o mediante el sitio de descarga de Sun.
Si ha generado el archivo WAR mediante el programa de instalación de JES 5, asegúrese de completar los pasos definidos en el problema conocido nº 6550261.
Despliegue el archivo WAR de Access Manager en un área de ensayo, por ejemplo /tmp/am-staging.
Copie los siguientes archivos .jar compartidos de /tmp/am-staging/WEB-INF/lib a una ubicación compartida como /export/jars:
jaxrpc-api.jar jaxrpc-spi.jar jaxrpc-impl.jar saaj-api.jar saaj-impl.jar xercesImpl.jar namespace.jar xalan.jar dom.jar jax-qname.jar jaxb-api.jar jaxb-impl.jar jaxb-libs.jar jaxb-xjc.jar jaxr-api.jar jaxr-impl.jar xmlsec.jar swec.jar acmecrypt.jar iaik_ssl.jar iaik_jce_full.jar mail.jar activation.jar relaxngDatatype.jar xsdlib.jar mfwk_instrum_tk.jar FastInfoset.jar jsr173_api.jar
Elimine los mismos archivos .jar de /tmp/am-staging/WEB-INF/lib en el área de ensayo.
Actualice el archivo server.xml de la instancia de Websphere. Realice los cambios a jvmEntries en server.xml si la ubicación de instancia predeterminada es /opt/WebSphere/AppServer/config/cells/ node-name/nodes/node-name/servers/server1 , como se indica a continuación:
<classpath>/export/jars/jaxrpc-api.jar:/export/jars/jaxrpc-spi.jar: /export/jars/jaxrpc-impl.jar:/export/jars/saaj-api.jar: /export/jars/saaj-impl.jar:/export/jars/xercesImpl.jar: /export/jars/namespace.jar:/export/jars/xalan.jar:/export/jars/dom.jar: /export/jars/jax-qname.jar:/export/jars/jaxb-api.jar:/export/jars/jaxb-impl.jar: /export/jars/jaxb-libs.jar:/export/jars/jaxb-xjc.jar:/export/jars/jaxr-api.jar: /export/jars/jaxr-impl.jar:/export/jars/xmlsec.jar:/export/jars/swec.jar: /export/jars/acmecrypt.jar:/export/jars/iaik_ssl.jar: /export/jars/iaik_jce_full.jar:/export/jars/mail.jar: /export/jars/activation.jar::/export/jars/relaxngDatatype.jar: /export/jars/xsdlib.jar:/export/jars/mfwk_instrum_tk.jar: /export/jars/FastInfoset.jar:/export/jars/jsr173_api.jar</classpath>
Reinicie el contenedor.
Vuelva a crear e implementar el archivo WAR de Access Manager desde /tmp/am-staging. Para obtener más información, consulte Deploying Access Manager as a Single WAR File en la Guía de postinstalación de Access Manager.
El archivo WAR de autenticación distribuida requiere archivos jar adicionales para el análisis tanto para Weblogic 8.1 como para Websphere 5.1 porque el contenedor es de la versión JDK14. Los archivos .jar de JDK14 se encuentran en el siguiente directorio del archivo .zip:
ZIP-ROOT/applications/jdk14/jarFix
Solución:
Para Weblogic 8.1:
Configure la autenticación distribuida utilizando las secuencias de comandos de configuración. Consulte Deploying a Distributed Authentication UI Server en la Guía de postinstalación de Access Manager.
Despliegue el archivo WAR de autenticación distribuida actualizado en una ubicación temporal como /tmp/dist-auth.
Copie xercesImpl.jar, dom.jar y xalan.jar al directorio /tmp/dist_auth/WEB-INF/lib desde ZIP-ROOT/applications/jdk14/jarFix.
Vuelva a generar el archivo WAR de autenticación distribuida desde la ubicación temporal e impleméntelo. Para obtener más información, consulte Deploying a Distributed Authentication UI Server WAR File en la Guía de postinstalación de Access Manager.
Para Websphere 5.1:
Configure la autenticación distribuida utilizando las secuencias de comandos de configuración. Consulte Deploying a Distributed Authentication UI Server en la Guía de postinstalación de Access Manager.
Despliegue el archivo WAR de autenticación distribuida actualizado en una ubicación temporal como /tmp/dist-auth.
Copie xercesImpl.jar, dom.jar y xalan.jar al directorio /tmp/dist_auth/WEB-INF/lib desde ZIP-ROOT/applications/jdk14/jarFix.
Edite el archivo WEB-INF/web.xml y sustituya jar://web-app_2_3.dtd por http://java.sun.com/dtd/web-app_2_3.dtd .
Vuelva a generar el archivo WAR de autenticación distribuida desde la ubicación temporal e impleméntelo. Para obtener más información, consulte Deploying a Distributed Authentication UI Server WAR File en la Guía de postinstalación de Access Manager.
Access Manager implementado como un archivo WAR único no se configura correctamente en Directory Server 6 con un sufijo raíz de un único componente, por ejemplo. dc=example. Sin embargo, funciona con un sufijo raíz de varios componentes, como dc=example,dc=com .
Solución: Use el sufijo raíz de varios componentes, por ejemplo dc=example,dc=com.
Cuando se configura la segunda instancia del archivo WAR único de Access Manager en el mismo host con Directory Server, presenta una excepción mientras se actualiza el Alias de organización. Este problema no se produce si la segunda instancia configurada se encuentra en un host distinto.
Puede encontrar información sobre los problemas de actualización en la sección Upgrade Issues de Sun Java Enterprise System 5 Release Notes for UNIX en las Notas de la versión de Sun Java Enterprise System 5 para UNIX.
La utilidad commadmin de Delegated Administrator no crea un usuario (6294603)
La utilidad commadmin de Delegated Administrator no crea una organización (6292104)
El problema se produce después de instalar Access Manager, Messaging Server y Calendar Server, configurarlos para que trabajen juntos e instalar a continuación la revisión 120955-01 de JES5. El usuario encontrará un error de inicio de sesión. Este error se debe a una incompatibilidad entre las propiedades de Policy Agent 2.1 y AMSDK. No hay una solución para este error por el momento.
Si Access Manager se ha configurado en una instancia de Web Server 7.0 que utiliza una JVM de 64 bits, el usuario encontrará un mensaje de error de servidor al acceder a la página de inicio de sesión de la consola. El registro de errores de Web Server contiene una excepción StackOverflowError.
Solución: modifique la configuración de Web Server siguiendo estos pasos:
Inicie una sesión en la consola de administración de Web Server como administrador de Web Server.
Haga clic en "Edit Configuration".
En el campo "Plataform", seleccione 64 y haga clic en "Save".
Haga clic en la ficha "Java" y a continuación en la ficha "JVM Settings".
En "Options", busque la entrada de menor tamaño de pila (por ejemplo: -Xms). El valor de tamaño mínimo de pila debe ser, al menos, 512m. Por ejemplo, si el valor de tamaño de pila no es -Xms512m o superior, cambie el valor a, al menos, -Xms512m.
El valor de tamaño máximo de pila debe ser, al menos, 768m. Si el tamaño máximo de pila no es -Xmx768m o superior, cambie el valor a, al menos, -Xmx768m.
Defina el tamaño de pila Java en 512 k o 768 k utilizando -Xss512k o -Xss768k. Puede utilizar el tamaño predeterminado para la JVM de 64 bits en Solaris Sparc (1024k) dejándolo en blanco.
Haga clic en la ficha "Performance" y, a continuación, en el vínculo "Thread Pool Settingsâ
Cambie el valor de tamaño de pila a, al menos, 261144 y haga clic en Guardar.
Haga clic en el vínculo "Deployment Pending" en la esquina superior de la pantalla.
En la página "Configuration Deployment", haga clic en el botón "Deploy".
En la ventana "Results", haga clic en OK para reiniciar la instancia de Web Server.
Haga clic en "Close" en la ventana "Results" después de que se haya reiniciado Web Server.
El modo tradicional de Access Manager 7.1 presenta las siguientes incompatibilidades en el módulo de autenticación principal a partir de la versión Access Manager 6 2005Q1:
Los módulos de autenticación de la organización se eliminan en el modo tradicional.
Se ha modificado la presentación de la “Configuración de autenticación del administrador” y la “Configuración de autenticación de la organización”. En la consola de Access Manager 7.1, la lista desplegable tiene seleccionada de forma predeterminada la opción ldapService. En la consola de Access Manager 6 2005Q1, se mostraba el botón de edición y el módulo LDAP no aparecía seleccionado de forma predeterminada.
Solución: ninguna.
La utilidad commadmin de Delegated Administrator, junto con la opción -S mail,cal, no crea un usuario en el dominio predeterminado.
Solución: este problema se produce al actualizar Access Manager a la versión 7.1 sin actualizar Delegated Administrator.
Si no desea actualizar Delegated Administrator, siga estos pasos:
En el archivo UserCalendarService.xml, marque los atributos mail, icssubcribed e icsfirstday como opcionales en lugar de obligatorios. Este archivo se encuentra de forma predeterminada en el directorio /opt/SUNWcomm/lib/services/ de los sistemas Solaris.
En Access Manager, elimine el archivo XML existente. Para ello, ejecute el comando amadmin de la siguiente forma:
# ./amadmin -u amadmin -w password -r UserCalendarService
En Access Manager, agregue el archivo XML actualizado como se muestra a continuación:
# ./amadmin -u amadmin -w password -s /opt/SUNWcomm/lib/services/UserCalendarService.xml
Reinicie el contenedor web de Access Manager.
La utilidad commadmin de Delegated Administrator, junto con la opción -S mail,cal, no crea una organización.
Solución: consulte la solución del problema anterior.
Validación de datos para los atributos necesarios en los servicios (6308653)
Solución para la implementación en una instancia de WebLogic 8.1 segura (6295863)
Si cuenta con instancias de Access Manager implementadas detrás de un equilibrador de carga, el inicio de sesión en Access Manager Console puede redirigirse a una de las instancias de Access Manager en vez de al equilibrador de carga. La dirección URL en el explorador también cambia a la instancia de Access Manager. Por ejemplo, este problema se puede producir si inicia la sesión en Console usando esta dirección URL:
http://loadbalancer.example.com/amserver/realm
Esta redirección se puede producir tanto en la implementación de los modos Realm como Legacy.
Existen dos soluciones para este problema. Puede utilizar cualquiera de ellas:
Inicie la sesión con cualquiera de las siguientes direcciones URL:
http:// loadbalancer/amserver/UI/Login
http:// loadbalancer/amserver
En AMConfig.properties, defina la propiedad com.sun.identity.loginurl como el nombre del equilibrador de carga. Esto debe realizarse en cada instancia de Access Manager detrás del equilibrador de carga.
Si instala Access Manager SDK sin un contenedor web ejecutando el programa de instalación de Java ES 5 con la opción "Configurar ahora", la propiedad com.iplanet.am.notification.url del archivo AMConfig.properties se establece en NOTIFICATION_URL. Si no se realiza ninguna configuración adicional del contenedor web, los usuarios no recibirán ninguna notificación desde el servidor remoto de Access Manager.
Solución: restablezca esta propiedad de la siguiente forma: com.iplanet.am.notification.url=""
Cuando se modifica una contraseña, Access Manager envía una notificación por correo electrónico utilizando un nombre de remitente inadecuado Identity-Server que da lugar a entradas de errores en los registros de amPasswordReset. Ejemplo:
07/19/2006 10:26:04:010 AM PDT: Thread[service-j2ee,5,main] ERROR: Could not send email to user [Ljava.lang.String;@999262 com.sun.mail.smtp.SMTPSendFailedException: 553 5.5.4 <Identity-Server>... Domain name required for sender address Identity-Server |
Solución: Cambie la configuración en /opt/SUNWam/locale/amPasswordResetModuleMsgs.properties.
Cambie la dirección del remitente. Cambie fromAddress.label=<Identity-Server> por fromAddress.label=<IdentityServer@myhost.company.com>
Cambie la propiedad lockOutEmailFrom para garantizar que las notificaciones de bloqueo utilicen la dirección del remitente (from) correcta.
En una implementación con varios servidores, no se actualizan la lista de servidores de plataforma ni el atributo de alias FQDN cuando se instala Access Manager en el segundo servidor (y en los siguientes).
Solución: agregue manualmente los alias de dominio/DNS y las entradas de la lista de servidores de plataforma. Para obtener información sobre los pasos de este proceso, consulte Adding Additional Instances to the Platform Server List and Realm/DNS Aliases de Sun Java System Access Manager 7.1 Postinstallation Guide.
En Access Manager 7.1, los atributos necesarios para los archivos XML de los servicios deben establecerse obligatoriamente en los valores predeterminados.
Solución: si tiene servicios con atributos necesarios sin valores, agregue los valores para dichos atributos y, a continuación, vuelva a cargar el servicio.
Si se implementa Access Manager 7.1 en una instancia de BEA WebLogic 8.1 SP4 segura (con SSL habilitado), se producirá una excepción durante la implementación de cada aplicación web de Access Manager.
Solución: siga estos pasos:
Aplique el archivo JAR de la revisión de WebLogic 8.1 SP4, CR210310_81sp4.jar , disponible en BEA.
En la secuencia de comandos /opt/SUNWam/bin/amwl81config (sistemas Solaris) o /opt/sun/identity/bin/amwl81config (sistemas Linux), actualice las funciones doDeploy y undeploy_it para especificar la ruta del archivo JAR de la revisión al principio de wl8_classpath , que es la variable que contiene la ruta classpath empleada para implementar las aplicaciones Web de Access Manager y anular la implementación.
Busque la línea que contiene wl8_classpath:
wl8_classpath= ...
Justo detrás de la línea indicada en el paso 2, agregue la siguiente línea:
wl8_classpath=path-to-CR210310_81sp4.jar:$wl8_classpath
En una implementación con varios servidores, la secuencia de comandos amconfig no actualiza los alias de dominio/DNS ni las entradas de la lista de servidores de plataforma para las instancias de Access Manager adicionales.
Solución: agregue manualmente los alias de dominio/DNS y las entradas de la lista de servidores de plataforma. Para obtener información sobre los pasos de este proceso, consulte Adding Additional Instances to the Platform Server List and Realm/DNS Aliases de Sun Java System Access Manager 7.1 Postinstallation Guide.
El modo de Access Manager (variable AM_REALM) se activa de forma predeterminada en la plantilla del archivo de estado de la configuración.
Solución: para instalar o configurar Access Manager en el modo tradicional, restablezca la variable en el archivo de estado:
AM_REALM = disabled
Si Access Manager se instala en el modo Realm, siempre que se cree un grupo nuevo, Access Manager creará dinámicamente una nueva administración de grupo con las ACIs necesarias para administrar el grupo. En el modo Realm, estas ACIs de administración de grupo no se utilizan. Sin embargo, Directory Server todavía las evalúa al procesar entradas bajo el sufijo, lo que puede reducir el rendimiento de Access Manager, especialmente si la implementación crea un gran número de grupos.
Solución: La solución para este problema implica dos partes:
Evitar que Access Manager cree una administración de grupo y las ACIs correspondientes cada vez que se cree un grupo nuevo
Eliminar cualquier ACI de administración de grupo de Directory Server
Evitar que se creen ACIs de administración de grupos
El siguiente procedimiento impide que Access Manager cree una administración de grupo y las ACIs correspondientes cada vez que se cree un grupo nuevo.
Este procedimiento evita permanentemente la creación de administraciones de grupo y las ACI correspondiente siempre que se cree un grupo nuevo. Use este procedimiento únicamente si este comportamiento es adecuado para su implementación específica.
Realice una copia de seguridad del archivo amAdminConsole.xml. Este archivo se encuentra en el siguiente directorio, en función de su plataforma:
Sistemas Solaris: /etc/opt/SUNWam/config/xml
Sistemas Linux y HP-UX: /etc/opt/sun/identity/config/xml
Sistemas Windows: javaes-install-dir\identity\config\xml
javaes-install-dir representa el directorio de instalación de Java ES 5. El valor predeterminado es C:\Program Files\Sun\JavaES5.
En el archivo amAdminConsole.xml, elimine la siguiente entrada de administración de grupo que se muestra entre líneas de comentario:
<AttributeSchema name="iplanet-am-admin-console-dynamic-aci-list" type="list" syntax="string" i18nKey="g111"> <DefaultValues> ... # Beginning of entry to delete <Value>Group Admin|Group Admin Description|ORGANIZATION:aci: (target="ldap:///GROUPNAME")(targetattr = "*") (version 3.0; acl "Group and people container admin role"; allow (all) roledn = "ldap:///ROLENAME";)##ORGANIZATION:aci: (target="ldap:///ORGANIZATION") (targetfilter=(&FILTER(!(|(nsroledn=cn=Top-level Admin Role,dc=iplanet,dc=com) (nsroledn=cn=Top-level Help Desk Admin Role,dc=iplanet,dc=com) (nsroledn=cn=Top-level Policy Admin Role,dc=iplanet,dc=com) (nsroledn=cn=Organization Admin Role,ORGANIZATION) (nsroledn=cn=Container Admin Role,ORGANIZATION) (nsroledn=cn=Organization Policy Admin Role,ORGANIZATION))))) (targetattr != "iplanet-am-web-agent-access-allow-list || iplanet-am-web-agent-access-not-enforced-list|| iplanet-am-domain-url-access-allow || iplanet-am-web-agent-access-deny-list ||nsroledn") (version 3.0; acl "Group admin's right to the members"; allow (read,write,search) roledn = "ldap:///ROLENAME";)</Value> # End of entry to delete ... </DefaultValues> </AttributeSchema>
Use amadmin para eliminar el servicio de Consola de administración de Access Manager. Por ejemplo, en sistemas Solaris:
# cd /opt/SUNWam/bin # ./amadmin -u amadmin -w amadmin_password --deleteService iPlanetAMAdminConsoleService
Use amadmin para volver a cargar el servicio de Consola de administración en Access Manager del archivo amAdminConsole.xml editado en el paso 2. Por ejemplo:
# ./amadmin -u amadmin -w amadmin_password -t /etc/opt/SUNWam/config/xml/amAdminConsole.xml
Reinicie el contenedor web de Access Manager. (Si tiene previsto eliminar ACIs de Directory Server, como se describe en el siguiente procedimiento, espere y reinicie el contenedor web una vez haya finalizado dicho procedimiento.)
Eliminar las ACIs de administración de grupos existentes
El siguiente procedimiento emplea las utilidades ldapsearch y ldapmodify para buscar y eliminar las ACIs de administración de grupos. Si su implementación utiliza Directory Server 6.0, también puede utilizar Directory Server Control Center (DSCC) o el comando dsconf para realizar estas funciones. Para obtener más información, consulte la documentación de Directory Server 6.0:
http://docs.sun.com/app/docs/coll/1224.1
El siguiente procedimiento elimina las ACIs de administración de grupos que ya existen en Directory Server.
Cree un archivo LDIF para utilizarlo con ldapmodify para eliminar las ACIs de administración de grupos. Para buscar estas ACIs, use ldapsearch (o cualquier otra herramienta de búsqueda en directorios si lo prefiere).
Por ejemplo, las siguientes entradas en el archivo LDIF de muestra llamado Remove_Group_ACIs.ldif eliminarán las ACIs de un grupo que se llama Grupo nuevo:
dn: ROOT_SUFFIX changetype: modify delete: aci aci: (target="ldap:///cn=New Group,ou=Groups,o=isp")(targetattr = "*") (version 3.0; acl "Group and people container admin role"; allow (all) roledn = "ldap:///cn=cn=New Group_ou=Groups_o=isp,o=isp";) dn: ROOT_SUFFIX changetype: modify delete: aci aci: (target="ldap:///ou=People,o=isp")(targetattr="nsroledn") (targattrfilters="add=nsroledn:(!(nsroledn=*)), del=nsroledn:(!(nsroledn=*))") (version 3.0; acl "Group admin's right to add user to people container"; allow (add) roledn = "ldap:///cn=cn=New Group_ou=Groups_o=isp,o=isp";) dn: ROOT_SUFFIX changetype: modify delete: aci aci: (target="ldap:///o=isp") (targetfilter=(&(|(memberof=*cn=New Group,ou=Groups,o=isp) (iplanet-am-static-group-dn=*cn=New Group,ou=Groups,o=isp)) (!(|(nsroledn=cn=Top-level Admin Role,o=isp) (nsroledn=cn=Top-level Help Desk Admin Role,o=isp) (nsroledn=cn=Top-level Policy Admin Role,o=isp) (nsroledn=cn=Organization Admin Role,o=isp)( nsroledn=cn=Container Admin Role,o=isp) (nsroledn=cn=Organization Policy Admin Role,o=isp))))) (targetattr != "iplanet-am-web-agent-access-allow-list || iplanet-am-web-agent-access-not-enforced-list || iplanet-am-domain-url-access-allow || iplanet-am-web-agent-access-deny-list ||nsroledn") (version 3.0; acl "Group admin's right to the members"; allow (read,write,search) roledn = "ldap:///cn=cn=New Group_ou=Groups_o=isp,o=isp";) aci: (target="ldap:///o=isp")(targetattr="*") (version 3.0; acl "S1IS special dsame user rights for all under the root suffix"; allow (all) userdn = "ldap: ///cn=dsameuser,ou=DSAME Users,o=isp"; )
Use ldapmodify con el archivo LDIF del paso anterior para eliminas las ACIs de grupo de Directory Server. Por ejemplo:
# ldapmodify -h ds-host -p 389 -D "cn=Directory Manager" -w ds-bind-password -f Remove_Group_ACIs.ldif
Reinicie el contenedor web de Access Manager.
La nueva consola de Access Manager no puede establecer las prioridades de plantilla de CoS (6309262)
Aparece la antigua consola al agregar servicios relacionados con Portal Server (6293299)
Adición del atributo ContainerDefaultTemplateRole después de la migración de datos (4677779)
La nueva consola de Access Manager 7.1 no puede establecer ni modificar una prioridad de plantilla de Clase de servicio (CoS).
Solución: inicie una sesión en la consola de Access Manager 6 2005Q1 para establecer o modificar la prioridad de plantilla de CoS.
Portal Server y Access Manager se instalan en el mismo servidor. Con Access Manager instalado en el modo tradicional, inicie una sesión en la nueva consola mediante /amserver. Si se selecciona un usuario existente y se intentan agregar servicios (como NetFile o Netlet), aparecerá la antigua consola de Access Manager (/amconsle).
Solución: ninguna. La versión actual de Portal Server requiere la consola de Access Manager 6 2005Q1.
Instale Directory Server y, a continuación, Access Manager con la opción de DIT existente. Inicie una sesión en la consola de Access Manager y cree un grupo. Edite los usuarios de dicho grupo. Por ejemplo, agregue usuarios con el filtro uid=*999*. La lista resultante estará vacía y la consola no mostrará ningún mensaje de error, advertencia ni informativo.
Solución: los miembros del grupo no deben superar el límite de tamaño de búsqueda de Directory Server. En caso contrario, cambie el límite de tamaño de búsqueda proporcionalmente.
En el modo tradicional, el rol del usuario no se muestra en una organización que no se haya creado en Access Manager. En el modo de depuración, aparece el siguiente mensaje:
ERROR: DesktopServlet.handleException() com.iplanet.portalserver.desktop.DesktopException: DesktopServlet.doGetPost(): no privilige to execute desktop
Este error se muestra después de que se ejecuten las secuencias de comandos de migración del programa de instalación de Java ES. El atributo ContainerDefaultTemplateRole no se agrega automáticamente a la organización cuando ésta se migra desde un árbol de información de directorio (DIT, Directory Information Tree) o desde otro origen.
Solución: utilice la consola de Directory Server para copiar el atributo ContainerDefaultTemplateRole desde otra organización de Access Manager y agréguelo a continuación a la organización en cuestión.
Un administrador asignado al rol de administrador de organización no puede crear un nuevo usuario con la utilidad de línea de comandos debido a privilegios de registro incorrectos.
Solución: Tanto el administrador de organización como el administrador de nivel superior deben establecer los permisos. Para realizar esta tarea mediante la consola de administración:
Acceda a la organización a la que pertenece el administrador.
Haga clic en la ficha Privilegios.
Haga clic en el vínculo Rol de administrador de organización.
Seleccione Read and write access to all log files o Write access to all log files.
Haga clic en Guardar.
Los clientes no reciben notificaciones después de reiniciarse el servlet (6309161)
Los clientes de SDK deben reiniciarse después del cambio de esquema de servicio. (6292616)
Las aplicaciones escritas con el cliente SDK (amclientsdk.jar) no reciben notificaciones si se reinicia el servidor.
Solución: ninguna.
Si se modifica un esquema de servicio, ServiceSchema.getGlobalSchema devuelve el antiguo esquema en lugar del nuevo.
Solución: reinicie el cliente tras modificar un esquema de servicio.
Este problema se ha solucionado en la revisión 1.
Al implementar el servidor de la IU de autenticación distribuida utilizando el usuario predeterminado de la aplicación, el rendimiento se reduce significativamente debido a los privilegios restringidos del usuario de la aplicación predeterminado.
Solución: cree un nuevo usuario con los privilegios adecuados.
Para crear un nuevo usuario con las ACI adecuadas:
Cree un nuevo usuario en la consola de Access Manager. Por ejemplo, cree un usuario que se llame AuthUIuser.
En la consola de Directory Server, agregue la siguiente ACI.
dn:ou=1.0,ou=SunAMClientData,ou=ClientData,<ROOT_SUFFIX> changetype:modifyadd:aci aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,<ROOT_SUFFIX>") (targetattr = "*"(version 3.0; acl "SunAM client data anonymous access"; allow (read, search, compare) userdn = "ldap:///<AuthUIuser's DN>";) |
Observe que userdn se ha definido en "ldap:///<AuthUIuser's DN>".
Consulte las instrucciones incluidas en To Install and Configure a Distributed Authentication UI Server de Sun Java System Access Manager 7.1 Postinstallation Guide para editar el archivo amsilent y ejecutar el comando amadmin.
En el archivo amsilent, defina las siguientes propiedades:
Introduzca AuthUIuser.
Introduzca una contraseña para AuthUIuser.
Guarde el archivo.
Ejecute la secuencia de comandos amconfig utilizando el nuevo archivo de configuración. Por ejemplo, en un sistema Solaris con Access Manager instalado en el directorio predeterminado:
# cd /opt/SUNWam/bin
# ./amconfig -s ./DistAuth_config
Reinicie el contenedor Web en el servidor de la IU de autenticación distribuida.
Al instalar Access Manager en el modo tradicional, se modifica la configuración predeterminada del servicio de estadísticas:
El servicio se activa de forma predeterminada (com.iplanet.services.stats.state=file ). Anteriormente, estaba desactivado.
El intervalo predeterminado (com.iplanet.am.stats.interval) cambia de 3600 a 60.
El directorio de estadísticas predeterminado (com.iplanet.services.stats.directory ) cambia de /var/opt/SUNWam/debug a /var/opt/SUNWam/stats.
Solución: ninguna.
Después de instalar Access Manager, inicie una sesión como amadmin y agregue los atributos o, sunPreferredDomain, associatedDomain , sunOrganizationAlias, uid y mail a la lista de atributos exclusivos. Si crea dos nuevas organizaciones con el mismo nombre, la operación fallará, aunque Access Manager mostrará un mensaje en el que se indica que la organización ya existe y no el mensaje previsto, en el que se indica que se ha infringido la unicidad del atributo.
Solución: ninguna. No haga caso del mensaje incorrecto. Access Manager funciona correctamente.
Si Access Manager se implementa con Web Server como contenedor web mediante un equilibrador de carga con finalización SSL, los clientes no se envían a la página correcta de Web Server. Al hacer clic en la ficha Sesiones (Sessions) de la consola de Access Manager, se devuelve un error debido a que el host no es válido.
Solución: en los siguientes ejemplos, Web Server escucha en el puerto 3030, mientras que el equilibrador de carga lo hace en el puerto 80 y redirecciona las solicitudes a Web Server.
En el archivo web-server-instance-name/config/server.xml , edite el atributo servername para que señale al equilibrador de carga en función de la versión de Web Server que esté utilizando.
Para las versiones Web Server 6.1 Service Pack (SP), edite el atributo servername de la siguiente forma:
<LS id="ls1" port="3030" servername="loadbalancer.example.com:80" defaultvs="https-sample" security="false" ip="any" blocking="false" acceptorthreads="1"/>
Web Server 6.1 SP2 (o superior) permite el cambio de protocolo de http a https o de https a http. Por lo tanto, edite servername de la siguiente forma:
<LS id="ls1" port="3030" servername="https://loadbalancer.example.com:443" defaultvs="https-sample" security="false" ip="any" blocking="false" acceptorthreads="1"/>
El método predeterminado para mantener las sesiones de autenticación es âsesión internaâ en lugar de HttpSession. El valor predeterminado de tiempo máximo de sesión no válida de tres minutos es suficiente. La secuencia de comandos amtune define este valor en un minuto para Web Server o Application Server. Sin embargo, si utiliza un contenedor web de otros fabricantes (IBM WebSphere o el servidor BEA WebLogic) y el elemento opcional HttpSession, es posible que necesite limitar el tiempo máximo de HttpSession del contenedor web para evitar problemas de rendimiento.
La eliminación de atributos dinámicos en el servicio de configuración de directivas provoca problemas al editar las directivas, como se muestra a continuación:
Cree dos atributos dinámicos en el servicio de configuración de directivas.
Cree una directiva y seleccione los atributos dinámicos del paso 1 en el proveedor de respuesta.
Elimine los atributos dinámicos en el servicio de configuración de directivas y cree dos atributos adicionales.
Intente editar la directiva creada en el paso 2.
Se mostrarán los siguientes resultados: "Error, se está estableciendo una propiedad dinámica no válida" (Error Invalid Dynamic property being set).No se muestra de forma predeterminada ninguna directiva en la lista. Después de realizar la búsqueda, se mostrarán las directivas, pero no se podrán editar o eliminar las directivas existentes ni crear una nueva.
Solución: antes de eliminar los atributos dinámicos del servicio de configuración de directivas, elimine las referencias a dichos atributos en las directivas.
Al iniciar Access Manager 7.1, se devuelven los siguientes errores de depuración en los archivos amDelegation y amProfile:
amDelegation: no se puede obtener una instancia del complemento para la delegación.
amProfile: se recibió una excepción de delegación.
Solución: ninguna. Puede hacer caso omiso de estos mensajes.
Se muestra un error al realizar la operación AMIdentity.modifyService (6506448)
Los miembros del grupo no se muestran en la lista seleccionada (6459598)
No se pueden crear organizaciones secundarias desde Access Manager al utilizar amadmin (5001850)
Al utilizar AMIdentity.modifyService para establecer el atributo dinámico del servicio de escritorio en un dominio, Access Manager devuelve una excepción de puntero nulo.
Solución:agregue la siguiente propiedad a AMConfig.properties y, a continuación, reinicie el servidor:
com.sun.am.ldap.connnection.idle.seconds=7200
Este problema tiene lugar al realizar las siguientes acciones:
Defina un dominio con la siguiente configuración:
El dominio de nivel superior es amroot. El subdominio es example.com.
El subdominio example.com tiene dos almacenes de datos: exampleDB y exampledminDB.
El almacén de datos exampleDB contiene todos los usuarios a partir de dc=example,dc=com. Las operaciones LDAPv3 admitidas se definen en user=read,write,create,delete,service.
El almacén de datos exampleadminDB contiene un grupo de administración para el dominio. El grupo de administración es DN: cn=example.com Realm Administrators,ou=Groups,dc=example,dc=com. Este grupo tiene un único miembro, scarter. Las operaciones LDAPv3 admitidas se definen en group=read,write,create,delete,service.
Haga clic en la ficha "Subjects", luego en "Groups" y en la entrada de administradores de dominio de example.com.
Haga clic en la ficha "Users".
Todos los usuarios del almacén de datos exampleDB se mostrarán como disponibles, pero scarter no se mostrará en el campo Seleccionado.
Solución: agregue la operación user=read a las operaciones LDAPv3 admitidas en el almacén de datos exampleadminDB .
Es posible que el problema se deba a la utilización de mayúsculas y minúsculas en el nombre de dominio completo (FQDN).
Ejemplo: HostName.PRC.Example.COM
Solución: tras la instalación, no utilice la dirección URL predeterminada de inicio de sesión de Access Manager. En su lugar, en la URL de inicio de sesión, incluya la ubicación LDAP de la organización predeterminada. Por ejemplo:
http://HostName.PRC.Example.COM/amserver/UI/Login?org=dc=PRC,dc=Example,dc=COM
Una vez que haya iniciado la sesión correctamente en Access Manager, ya no es necesario introducir la ruta completa a la organización del usuario cada vez que inicie una sesión en Access Manager. siga estos pasos:
Vaya a la ficha Dominio en el modo de dominio o vaya a la ficha Organización en el modo tradicional.
Haga clic en el nombre de organización o dominio predeterminado.
En este ejemplo, haga clic en prc.
Cambie todos los caracteres en mayúsculas del valor de dominio/alias de DNS a caracteres en minúsculas.
En este ejemplo, agregue el valor con letras minúsculas hostname.prc.example.com a la lista y elimine el valor HostName.PRC.Example.COM en mayúsculas y minúsculas de la lista.
Haga clic en Guardar y cierre la sesión en la consola de Access Manager.
Ahora puede iniciar la sesión utilizando cualquiera de las siguientes direcciones URL:
http://hostname.PRC.Example.COM/amserver/UI/Login
http://hostname.PRC.Example.COM/amserver
http://hostname.PRC.Example.COM/amserver/console
Este problema se produce cuando se activa la repetición de varias réplicas principales entre dos servidores de Directory Server y se intenta crear una organización secundaria mediante la utilidad amadmin.
Solución: en ambos servidores de Directory Server, defina la propiedad nsslapd-lookthroughlimit en -1.
La secuencia de comandos amconfig genera un error cuando el certificado SSL está caducado. (6488777)
Si el contenedor de Access Manager se está ejecutando en modo SSL y el certificado SSL de contenedor está caducado, amconfig genera un error, que puede provocar daños en la ruta de clase.
Solución: si ya ha ejecutado amconfig con un certificado caducado y la ruta de clase está dañada, obtenga primero un certificado SSL válido. Restablezca el archivo domain.xml original o una copia del archivo domain.xml en el que la ruta de clase no esté dañada. A continuación, vuelva a ejecutar el comando amconfig :
/opt/SUNWam/bin/amconfig -s $PWD/amsamplesilent
Los archivos de muestra se incluyen en el SDK de cliente y muestran cómo escribir programas independientes y aplicaciones web. Las muestras se encuentran en el directorio en el que se haya generado el archivo Makefile.clientsdk y en los siguientes subdirectorios:
.../clientsdk-samples/
.../clientsdk-webapps/
En el directorio "clientsdk-samples", se incluyen muestras de autenticación, registro, y programas independientes SAML y de directivas. En el directorio "clientsdk-webapps", se incluyen muestras para la administración de usuarios y servicios, y programas de directivas. Cada muestra incluye un archivo Léame (Readme.html) con instrucciones sobre cómo compilar y ejecutar el programa de muestra.
Para compilar las muestras, el archivo makefile debe ejecutarse en el subdirectorio correspondiente. El archivo makefile de nivel superior no compila las muestras en los subdirectorios.
Si ejecuta Application Server 8.1 en Red Hat Linux, el tamaño de pila de los subprocesos creados por el SO Red Hat para Application Server es de 10 Mbytes, lo que puede provocar problemas en los recursos de JVM cuando el número de sesiones de usuario de Access Manager alcance las 200.
Solución: establezca el tamaño de pila del SO Red Hat con un valor inferior como, por ejemplo, 2048 o, incluso, 256 Kbytes, ejecutando el comando ulimit antes de iniciar Application Server. Ejecute el comando ulimit en la misma consola que utilizará para iniciar Application Server. Por ejemplo:
# ulimit -s 256;
Solución: Si se usan las configuraciones regionales zh_TW y es en la plataforma HP-UX, Access Manager debe configurarse únicamente en el modo "Configurar más tarde". Inicie el programa de instalación de JavaES, instale el producto Access Manager y salga del programa. A continuación, ejecute el programa de configuración de Access Manager, como se muestra a continuación:
LANG=C
export LANG
Edite accessmanager-base/bin/amsamplesilent file.
Ejecute accessmanager-base/bin/amconfig -s amsamplesilent.
Actualmente no existe ninguna solución para este problema.
En el modo de dominio, si se intenta realizar la federación de cuentas de usuario en un proveedor de identidades (IDP) y un proveedor de servicios (SP), se finaliza la federación y, a continuación, se cierra la sesión, se producirá un error: Error: no se ha encontrado ninguna suborganización (Error: No sub organization found.)
Solución: ninguna.
El valor actual y el nuevo valor se muestran incorrectamente en la consola (6476672)
La fecha de la condición de directiva debe especificarse con el formato inglés (6390856)
No se puede eliminar UTF-8 en la sección de detección de cliente. (5028779)
Al establecer la configuración regional del explorador en zh, los componentes de la consola de administración se muestran en inglés como, por ejemplo, los botones "Version" (Versión), "Help" (Ayuda) y "Logout " (Cerrar la sesión).
Solución: establezca la configuración regional en zh-cn en lugar de en zh.
En la versión traducida de la consola de administración, las etiquetas de los atributos de valor actual y nuevo valor se muestran incorrectamente como "label.current.value" y "label.new.value" respectivamente.
Las etiquetas de formato de fecha de la condición de directiva en la configuración regional china no se muestran de acuerdo con la manera habitual china. La etiquetas proponen un formato de fecha inglés. Los campos relacionados también aceptan los valores de formato de fecha inglés.
Solución: para cada campo, siga el ejemplo de formato de fecha que se indica en la etiqueta del campo.
La función de detección de cliente no funciona correctamente. Los cambios realizados en la consola de Access Manager 7.1 no se transfieren automáticamente al explorador.
Solución: existen dos soluciones:
Reinicie el contenedor web de Access Manager después de realizar un cambio en la sección de detección de cliente.
o
Siga estos pasos en la consola de Access Manager:
Haga clic en Client Detection en la ficha Configuration.
Haga clic en el vínculo Edit para genericHTML.
En la ficha HTML, haga clic en el vínculo genericHTML.
Introduzca la siguiente entrada en la lista de juegos de caracteres: UTF-8;q=0.5 (Asegúrese de que el factor q de UTF-8 sea inferior al de otros juegos de caracteres de su configuración regional.)
Guarde el cambio, cierre la sesión y vuelve a iniciarla.
Los mensajes de varios bytes de los archivos de registro del directorio /var/opt/SUNWam/logs se muestran en forma de signos de interrogación (?). Los archivos de registro suelen presentar una codificación nativa y, no siempre, UTF-8. Cuando una instancia del contenedor web se inicia con una determinada configuración regional, los archivos de registro presentarán una codificación nativa para dicha configuración regional. Si se cambia a otra configuración regional y se reinicia la instancia del contenedor web, los mensajes actuales presentarán la codificación nativa para dicha configuración regional, pero los mensajes de codificaciones anteriores se mostrarán en forma de signos de interrogación.
Solución: asegúrese de iniciar siempre las instancias del contenedor web con la misma codificación nativa.
Después de aplicar la respectiva revisión, puede configurar los roles y los roles filtrados del complemento LDAPv3, si los datos se han almacenado en Sun Java System Directory Server (soluciona el Id. de problema 6349959). En la consola de administración de Access Manager 7.1, en la configuración de LDAPv3 del campo "Operaciones y tipos admitidos del complemento LDAPv3", introduzca los valores de la siguiente forma:
role: read,edit,create,delete filteredrole: read,edit,create,delete
Puede introducir una de las entradas anteriores o ambas en función de los roles y los roles filtrados que desee utilizar en la configuración de LDAPv3.
Las siguientes propiedades del archivo AMConfig.properties no se utilizan:
com.iplanet.am.directory.host com.iplanet.am.directory.port
Para habilitar el cifrado XML para Access Manager o Federation Manager mediante el archivo JAR de Bouncy Castle con el fin de generar una clave de transporte, siga estos pasos:
Si utiliza una versión de JDK anterior a JDK 1.5, descargue el proveedor JCE de Bouncy Castle desde el sitio de Bouncy Castle (http://www.bouncycastle.org/). Por ejemplo, para JDK 1.4, descargue el archivo bcprov-jdk14-131.jar.
Si ha descargado un archivo JAR en el paso anterior, cópielo en el directorio jdk_root/jre/lib/ext.
Para la versión interna de JDK, descargue los archivos de "Unlimited Strength Jurisdiction Policy" de JCE para la versión de JDK en el sitio de Sun (http://java.sun.com). Para IBM WebSphere, acceda al sitio correspondiente de IBM para descargar los archivos necesarios.
Copie los archivos descargados US_export_policy.jar y local_policy.jar en el directorio jdk_root/jre/lib/security .
Si utiliza una versión de JDK anterior a JDK 1.5, edite el archivo jdk_root/jre/lib/security/java.security y agregue Bouncy Castle como uno de los proveedores. Por ejemplo:
security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider
Defina la siguiente propiedad en el archivo AMConfig.properties como "true" (verdadera):
com.sun.identity.jss.donotInstallAtHighestPriority=true
Reinicie el contenedor web de Access Manager.
Para obtener más información, consulte el Id. de problema 5110285 (El cifrado XML requiere el archivo JAR de Bouncy Castle).