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.
- "Contraseña LTPA no establecida. Mensaje de error de validación anómala"
El archivo setupClient.bat o setupClient.sh no funciona correctamente
Aviso de Java HotSpot Server VM
- WebSphere Application Server Versión 6 no funciona correctamente con EWLM (Enterprise Workload Manager)
- Si ha configurado correctamente la seguridad pero ahora tiene problemas cuando accede a los recursos web o a la consola administrativa, consulte el tema Errores o problemas de acceso después de habilitar la seguridad.
- NMSV0610I: Se está generando una excepción NamingException desde una implementación javax.naming.Context.
- El servlet de rendimiento muestra errores de autorización y no puede proporcionar estadísticas
- 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
- El JDK de Sun no puede leer un almacén de claves PKCS12 creado por el servidor de aplicaciones
- No se puede llamar a un recurso seguro desde un recurso no seguro
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.
- Seleccione .
- 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]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
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]](../images/windows.gif)
set CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:%WAS_HOME%/properties/soap.client.props
![[AIX]](../images/aixlogo.gif)
![[Linux]](../images/linux.gif)
![[AIX HP-UX Solaris]](../images/unix.gif)
![[z/OS]](../images/ngzos.gif)
CLIENTSOAP=-Dcom.ibm.SOAP.ConfigURL=file:$WAS_HOME/properties/soap.client.props
- Elimine la primera barra inclinada / después de file:.
- Cambie sas por soap.
![[HP-UX]](../images/hpux.gif)
Aviso de Java HotSpot Server VM
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)
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:
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
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.
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]](../images/ngzos.gif)
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.