WebSphere 7, configuración de fábrica de conexión JMS sin ID de usuario: MQRC_NOT_AUTHORIZED

Question

Tengo una instancia de WebSphere 6 y una instancia de WebSphere 7. Cada una tiene un proveedor de mensajería WebSphere MQ, una fábrica de conexión de cola y una cola configuradas de forma similar . Todos los campos de ID de usuario se dejan vacíos y los alias de autenticación se dejan en "ninguno".

En WAS6 funciona bien.

En WAS7 Me aparece un error:

JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MYQMNGR' with connection mode 'Client' and host name '10.11.22.33(51001)'.; nested exception is com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'MYQMNGR' with connection mode 'Client' and host name '10.11.22.33(51001)'. Please check if the supplied username and password are correct on the QueueManager you are connecting to; nested exception is com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').

Lo que puede ser diferente en la forma WAS7 conecta a MQ en comparación con WAS6 si ningún ID de usuario se suministra?

No tengo visibilidad ni acceso a esa MQ (versión 7), no requiere identificación de usuario cuando accedo desde WAS 6, así que necesito que WAS7 funcione de la misma manera.

Answer 1

En WAS 6 si dejó el ID de usuario en el panel de administración en blanco, se pasó un espacio en blanco a WMQ. WMQ ejecutará el canal incluso si no puede determinar el usuario remoto y en ese caso el canal se ejecuta con la autoridad del agente de canal de mensajes (Message Channel Agent, MCA), que siempre es administrativo. Por lo tanto, en V6, funciona.

A partir de V7, el cliente WMQ tratará un poco más difícil de determinar qué ID pasar si lo deja en blanco en el panel de administración y ERA obtendrán la JVM Identificación y pasar que en la llamada CONNECT. Esta es la fuente del 2035.

La forma correcta de solucionar este problema es que el administrador WMQ debe colocar un documento de identidad con pocos privilegios en el campo MCAUSER del canal SVRCONN. El ID debe estar autorizado para las colas que el servidor Java EE necesite, pero no para la cola de comandos y otras colas administrativas. Esto resolverá el problema de que WAS 7 está enviando un ID y no reconocido que impide que los clientes remotos de cualquier tipo obtengan acceso de administrador en ese canal.

La alternativa es ir al panel de administración WAS para la conexión WMQ y establecer la ID de usuario en mqm. (Esto funciona si WMQ se ejecuta en un sistema distribuido que no sea de Windows. Si WMQ se ejecuta en Windows, z/OS u otra cosa, sustituya la ID equivalente de la plataforma aquí). Aunque esto pondrá a WAS en funcionamiento, no soluciona el hecho de que QMgr expone el acceso administrativo.

Consulte la presentación y laboratorio de WMQ Hardening en http://t-rob.net/links para obtener una explicación más completa de cómo identificar y remediar la exposición de seguridad subyacente en el QMgr.