1. Inicio
  2. Pregunta y respuesta
  3. MQJMS2013 autenticación de seguridad no válida

MQJMS2013 autenticación de seguridad no válida

2010-12-15 11 views
6

Estoy tratando de conectarme al servidor IBM Websphere MQ desde el servidor de aplicaciones IBM Websphere.MQJMS2013 autenticación de seguridad no válida

estoy consiguiendo el error siguiente:

MQJMS2013: invalid security authentication supplied for MQQueueManager

Lo que entiendo es, esto es debido a las credenciales de seguridad no válidos por ERA mientras se conecta al Administrador MQ.

He intentado con una combinación diferente de proporcionar la contraseña de administrador de MQ, p.

  1. Proporcione la autenticación J2C a MQ Connection Factory.
  2. Proporcione el nombre de usuario y la contraseña de administrador de MQ a las colas.
  3. Proporcionando nombre de usuario en blanco.
  4. Combinación de los tres anteriores.

Además, como se menciona en algunos de los puestos, he probado el Tipo de Transporte como 'Encuadernación', así como 'Cliente' para QueueConnectionFactory.

Sugerido.

Fuente

2010-12-15 Sandeep Jindal

Respuesta

1

Finalmente funcionó, después de 2 días de aplicar combinaciones.

para ayudar a otros (y probablemente también a mí mismo en el futuro), después fue el tema:

Estábamos configuración de IBM Websphere Application Server con el servidor IBM Websphere MQ. Creamos la fábrica de conexiones de cola, las colas y los puertos de escucha a la derecha. Estábamos recibiendo la excepción en cuestión en varias ocasiones.

Cómo funcionó es: Cuando inicia su servidor de aplicaciones, el usuario que está iniciando el servidor debería tener acceso para MQ. es decir, el usuario debe ser parte del grupo MQM. Solo para agregar, después de agregar el grupo al usuario, recuerde reiniciar el servidor MQ porque el servidor MQ actualiza los derechos solo después del reinicio.

Espero que esto ayude.

Fuente

2010-12-16 11:20:52

+1

Vinculaciones o modo cliente? En el mejor de los casos (modo de enlaces), acaba de otorgar la autorización del servidor de aplicaciones para administrar WMQ y ejecutar comandos del sistema operativo como la identificación de usuario mqm. Esto está bien en aplicaciones triviales, pero es equivalente a otorgar a una aplicación derechos de administrador de DBA completos que la mayoría de las tiendas nunca realizarían. Por qué lo hacen con WMQ es un misterio para mí. En el peor de los casos (enlaces de cliente), acaba de otorgar ese privilegio administrativo a usuarios remotos anónimos. Básicamente * cualquier persona * con una ruta IP al QMgr puede administrarlo y ejecutar comandos del sistema operativo. ¿Era eso lo que pretendías? Ver http://bit.ly/17oKEc –

+1

Por cierto, con cualquiera de las herramientas a las que me he vinculado en mi respuesta habrías solucionado esto en dos minutos en lugar de dos días. Entonces, para ayudar a otros (y probablemente a usted mismo también en el futuro), instale una o ambas herramientas ahora para no hacer girar sus ruedas la próxima vez. Y si tiene * cualquier * interés en proteger WMQ, use IDs de bajo privilegio y comandos setmqaut en lugar de pegar la aplicación en el grupo mqm y bloquear todos los canales entrantes con MCAUSER de bajo privilegio. Lo que hizo "funciona" en el sentido de que la aplicación ahora puede enviar mensajes, pero casi nunca es la respuesta correcta. –

+0

+1 ¡Te tengo! Lamentablemente, no soy el experto en la configuración y el servidor de MQ. Trabajando en la industria de servicios, donde todo es CRÍTICO, solo necesitamos que las cosas funcionen. En general, comprende el aspecto de Seguridad que mencionaste, pero como dijiste, ¡no es muy importante para mi entorno desde ahora! ¡Gracias de nuevo! –

2

Un problema es que el MQJMS2013 puede no tener nada que ver con el QMgr. Podría ser un problema de configuración de archivos de configuración, credenciales LDAP haciendo búsquedas JNDI, problemas con un almacén de claves, etc.

Una forma de determinar si esta es realmente una excepción de autorización WMQ es habilitar eventos de autorización en el QMgr y volver a crear el error. Si se trata de un problema de autenticación de WMQ, el mensaje de evento aterrizará en la cola SYSTEM.ADMIN.QMGR.EVENT. Contendrá el ID del usuario, el objeto en el que falló la llamada, la llamada API que falló y todas las opciones utilizadas en la llamada. Si usa SupportPac MO71, formateará el mensaje de evento por usted. Si usa WMQ Explorer, puede instalar SupportPac MS0P para formatear los mensajes de eventos.

¡Si no recibe un mensaje de evento, entonces la conexión no llega a WMQ! En ese caso, nada de lo que haga con cuentas, grupos, setmqaut y otra configuración específica de WMQ ayudará y sugeriría enabling tracing.

En el modo de enlaces, el ID presentado debe coincidir con con el ID con el que se ejecuta JVM. En el modo cliente, otra manera de diagnosticar es establecer el MCAUSER del canal a un valor bueno conocido. El MCAUSER del canal anula cualquier identificación ingresada por el servidor de la aplicación y siempre debe establecerse en una cuenta con privilegios bajos. Para el diagnóstico, configúrelo TEMPORARIAMENTE en 'mqm' y si la conexión funciona que aísla el problema para que sea un problema de autenticación de WMQ.

Fuente

2010-12-15 20:10:03

+0

Parece que esta información es bastante útil. He encontrado un mensaje en la cola SYSTEM.ADMIN.QMGR.EVENT. Pero los detalles del mensaje son "MQGET terminó con el código de razón 2080". ¡Intentando eliminar el mensaje y hacerlo de nuevo! –

+1

El 2080 es MQRC_TRUNCATED_MSG_FAILED, lo que significa que probablemente esté utilizando amqsget. Si usa las herramientas mencionadas anteriormente, obtendrán el mensaje completo * y * formateándolo en texto legible para las personas (los mensajes de eventos son PCF). Si desea obtener una forma rápida y sucia de recibir el mensaje, use amqsbcg, que le dará un volcado hexadecimal y luego podrá usar los archivos de encabezado C y una calculadora hexadecimal para decodificarlo. –

Cuestiones relacionadas

 Cuestiones relacionadas