Configuración de seguridad y errores de habilitación

Utilice esta información para la resolución de problemas de configuración o de habilitación de la seguridad.

Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM® i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL para resolver problemas de aplicaciones para obtener más información sobre la utilización de HPEL.

[AIX Solaris HP-UX Linux Windows][IBM i]Para obtener información general sobre cómo diagnosticar y resolver los problemas relacionados con la seguridad, consulte el tema Resolución de problemas del componente de seguridad.

"Contraseña LTPA no establecida. Mensaje de error de validación anómala"

"Contraseña LTPA no establecida. Error de validación", como un error en la consola administrativa después de guardar los valores de seguridad administrativos o de la aplicación.

Este error puede producirse si al configurar la seguridad de WebSphere Application Server se selecciona LTPA como el mecanismo de autenticación y el campo de contraseña de LTPA no se ha establecido. Para solucionar este problema:
  • Seleccione Seguridad > Seguridad global > Mecanismos de autenticación y caducidad > LTPA.
  • Cumplimente el campo de contraseña y confirme la contraseña.
  • Pulse Aceptar.
  • Intente volver a configurar la seguridad administrativa o de la aplicación.
[AIX Solaris HP-UX Linux Windows][z/OS]

El archivo setupClient.bat o setupClient.sh no funciona correctamente

El archivo setupClient.bat en las plataformas Windows y el archivo setupClient.sh en las plataformas Linux basadas en UNIX especifican incorrectamente la ubicación del archivo de propiedades de seguridad SOAP.
[Windows]En el archivo setupClient.bat, la ubicación correcta es:
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%WAS_HOME%/properties/soap.client.props
[AIX][Linux][AIX HP-UX Solaris][z/OS]En el archivo setupClient.sh, la variable CLIENTSOAP es:
CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:$WAS_HOME/properties/soap.client.props
En los archivos setupClient.bat y setupClient.sh, siga estos pasos:
  1. Elimine la primera barra inclinada / después de file:.
  2. Cambie sas por soap.
[HP-UX]

Aviso de Java HotSpot Server VM

Después de habilitar la seguridad en las plataformas HP-UX 11i, se produce el siguiente error en el archivo native_stdout.log, un volcado del núcleo y WebSphere Application Server no se inicia:
Aviso de Java HotSpot(TM) Server VM: 
Se ha producido una señal 11 inesperada con el manejador de señales definido por el
usuario 0x7895710a
Para solucionar este error, aplique los arreglos recomendados por Hewlett Packard para Java™ desde el sitio de soporte de Hewlett Packard en el siguiente URL: http://www.hp.com.

WebSphere Application Server Versión 6 no funciona correctamente con EWLM (Enterprise Workload Manager)

Para utilizar WebSphere Application Server Versión 6 con EWLM (Enterprise Workload Manager), debe actualizar manualmente los archivos server.policy de WebSphere Application Server. Por ejemplo:
grant codeBase "file:/<EWLM_Install_Home>/classes/ARM/arm4.jar" {
 permission java.security.AllPermission; 
};
De lo contrario, es posible que se genere una excepción de la seguridad de Java 2 por violar el permiso de la seguridad de Java 2.

Consulte Permisos del archivo server.policy para obtener más información sobre la configuración de archivos server.policy.

Para obtener información actual disponible del servicio de soporte de IBM acerca de problemas conocidos y su resolución, consulte la página IBM Support.

El servicio de soporte de IBM tiene documentos que pueden ahorrarle tiempo a la hora de reunir la información necesaria para solucionar este problema. Antes de abrir un PMR, consulte la página IBM Support.

NMSV0610I: Se está generando una excepción NamingException desde una implementación javax.naming.Context.

Si utiliza la autenticación de entrada CSIv2, se necesita una autenticación básica, y los clientes Java que se ejecuten con com.ibm.CORBA.validateBasicAuth=true pueden fallar con la siguiente excepción:
Si utiliza la autenticación de entrada CSIv2, se necesita una autenticación básica, y los
clientes Java™ que se ejecuten con com.ibm.CORBA.validateBasicAuth=true pueden
fallar con la 
siguiente excepción:

NMSV0610I: Se está generando una excepción NamingException desde una implementación javax.naming.Context 
           . A continuación se facilitan más detalles:

Implementación de contexto: com.ibm.ws.naming.jndicos.CNContextImpl
Método de contexto: lookupExt
Nombre de contexto: TestaburgerNode01Cell/nodes/TestaburgerNode01/servers/server1
Nombre de destino: SecurityServer
Otros datos: "" ""
Rastreo de pila de la excepción: javax.naming.NoPermissionException: Se ha capturado la
excepción NO_PERMISSION. La excepción raíz es org.omg.CORBA.NO_PERMISSION: vmcid:
0x49421000 Código menor: 92 Finalizado: No
...
SECJ0395E: No se ha podido localizar el SecurityServer en el host/puerto:9.42.72.27/9100  para validar el ID
de usuario y la contraseña especificados. Puede que tenga que
especificar un securityServerHost/Port válido en el archivo
(RAÍZ_INSTALACIÓN_WAS)/properties/sas.client.props.

Para solucionar este problema, modifique la propiedad com.ibm.CORBA.validateBasicAuth=false del archivo sas.clients.props del cliente, que se encuentra en WAS_HOME/profiles/<nombre-perfil>/properties y a continuación ejecute el cliente.

El servlet de rendimiento muestra errores de autorización y no puede proporcionar estadísticas

En WebSphere Application Server Versión 6.1, cuando está habilitada la seguridad administrativa, el servicio administrativo está bloqueado. No obstante, si la seguridad de las aplicaciones no está habilitada, no se genera un aviso de autenticación para las solicitudes de entrada y, por lo tanto, no existen credenciales para que el servlet de rendimiento pueda acceder al servicio de administración.

si se ha habilitado la seguridad administrativa, también debe habilitar la seguridad de las aplicaciones para que el servlet de rendimiento pueda procesar las solicitudes de entrada.

Se muestra "El valor del nombre no es válido" cuando se migran los usuarios y grupos después de configurar el proveedor JACC para Tivoli

[AIX Solaris HP-UX Linux Windows][IBM i]Cuando utiliza el programa de utilidad migrateEAR para migrar los cambios realizados en los usuarios y grupos de la consola después de configurar el proveedor JACC para Tivoli Access Manager, se muestra el siguiente error de configuración en el archivo systemOut.log.

[z/OS]Cuando utiliza el programa de utilidad migrateEAR para migrar los cambios realizados en los usuarios y grupos de la consola después de configurar el proveedor JACC para Tivoli Access Manager, se muestra el siguiente error de configuración en la salida correspondiente del archivo de anotaciones de trabajo.

<specialSubjects> name value is invalid
[z/OS]Nota: Dado que el archivo de registro cronológico SystemOut no existe en el sistema operativo z/OS, compruebe la salida de los registros cronológicos del trabajo adecuados en el sistema operativo z/OS.

El programa de utilidad migrateEAR migra los datos del usuario y del grupo contenidos en el archivo admin-authz.xml. No obstante, el programa de utilidad migrateEAR no convierte los códigos XML que figuran en el archivo admin-authz.xml si antes de la migración se ha añadido el grupo pdwas-admin a la lista de control de acceso (ACL) del administrador en Tivoli Access Manager.

Para solucionar este error, escriba el mandato siguiente en padadmin para comprobar si el grupo pdwas-admin está en la lista ACL del administrador antes de realizar la migración:

acl show
_WebAppServer_deployedResources_Roles_administrator_admin-authz_ACL

Se muestra el resultado siguiente:

Nombre ACL:
_WebAppServer_deployedResources_Roles_administrator_admin-authz_ACL
Descripción: Creado por la herramienta de migración Tivoli Access Manager
para Websphere Application Server.
Entradas:
User sec_master TcmdbsvaBR1
Group pdwas-admin T[WebAppServer]i

Si el grupo pdwas-admin no figura en la lista, escriba el mandato siguiente en pdadmin para modificar la ACL y añadir el grupo pdwas-admin:

acl modify 
_WebAppServer_deployedResources_Roles_administrator_admin
-authz_ACL set gruop pdwas-admin T [WebAppServer]i

El JDK de Sun no puede leer un almacén de claves PKCS12 creado por el servidor de aplicaciones

Un JDK de Sun no puede leer un almacén de claves PKCS12 creado por el servidor de aplicaciones. El motivo es que la implementación de PKCS12 utilizada por IBM SDK y el servidor de aplicaciones es distinta a la implementación utilizada por Sun JDK. La diferencia ocasiona problemas cuando se utiliza Sun JDK para leer el almacén de confianza por omisión, trust.p12, o el almacén de claves key.P12 creado por el servidor de aplicaciones.

Dado que JDK de Sun no puede leer el almacén de confianza, en primer lugar debe extraer los certificados del almacén de confianza utilizando un SDK de IBM. A continuación, puede importar estos certificados a un almacén de claves que JDK de Sun puede leer correctamente como, por ejemplo, un almacén de claves JKS.

No se puede llamar a un recurso seguro desde un recurso no seguro

Si tiene un recurso no seguro (por ejemplo, un JSP o un servlet) que llama a un recurso seguro, la aplicación puede fallar si el recurso no seguro recopila datos de usuarios y, a continuación, envía esta datos para a archivos de JSP o servlet seguros para su proceso.

Para evitar esta situación, estructure la aplicación web para que los usuarios se vean obligados a iniciar de sesión antes de que la aplicación realice cualquier acción HTTP POST a los archivos de JSP o servlet seguros. Para llevar esto a cabo, proteja el primer recurso mediante el mecanismo de seguridad que elija (por ejemplo, la autenticación básica, el inicio de sesión con formulario o certificado).

Esta restricción se debe a que la autenticación básica y el inicio de sesión de formulario utiliza el método de servlet sendRedirect, que tiene varias implicaciones para el usuario. El método sendRedirect se utiliza dos veces durante la autenticación básica y el inicio de sesión de formulario.

El método sendRedirect muestra inicialmente la autenticación básica o la página de inicio de sesión de formulario en el navegador web. Posteriormente redirige el navegador web de nuevo a la página protegida solicitada inicialmente. El método sendRedirect(String URL) insta al navegador web para que utilice la petición GET de HTTP para acceder a la página especificada en la dirección web. Si HTTP POST es la primera petición dirigida a un archivo de JSP o servlet y no se ha producido anteriormente una autenticación o inicio de sesión, HTTP POST no se envía a la página solicitada. Sin embargo, HTTP GET se envía porque la autenticación básica y el inicio de sesión de formulario utilizan el método sendRedirect, que se comporta como una petición HTTP GET que intenta mostrar una página solicitada después de que tenga lugar el inicio de sesión.


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_secconfigprobs
File name: rtrb_secconfigprobs.html