2011-05-16 5 views
6

WebSphere 6의 인스턴스와 WebSphere 7의 인스턴스가 있습니다. 각 인스턴스에는 WebSphere MQ 메시징 공급자, 대기열 연결 팩토리 및 비슷한 방식으로 구성된 대기열이 있습니다 . 모든 사용자 ID 필드는 비어 있고 인증 별명은 "none"으로 남습니다.사용자 ID가없는 JMS Q 연결 팩토리를 구성하는 WebSphere 7 : MQRC_NOT_AUTHORIZED

WAS6에서 제대로 작동합니다. WAS7에서

는 오류가 발생합니다 :

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').

에는 사용자 ID가 제공되지 않는 경우 WAS7이 WAS6에 비해 MQ에 연결하는 방법과 다를 수 있습니다 무엇입니까?

MQ (버전 7)에 대한 가시성이나 액세스 권한이 없으므로 WAS 6에서 액세스 할 때 사용자 ID가 필요하지 않으므로 WAS7을 동일하게 작동시켜야합니다.

답변

12

WAS 6에서 관리 패널의 사용자 ID를 비워두면 공백이 WMQ로 전달됩니다. WMQ는 원격 사용자를 확인할 수 없더라도 채널을 실행하며이 경우 채널은 항상 관리 채널 인 메시지 채널 에이전트 (MCA)의 권한으로 실행됩니다. 따라서 V6에서는 작동합니다.

V7에서 WMQ 클라이언트는 WAS 관리자 패널에서 비워두면 JVM ID를 얻고 CONNECT 호출에서 전달할 ID를 결정하기 위해 조금 더 노력할 것입니다. 이것이 바로 2035 년의 출처입니다.

이 문제를 해결하는 올바른 방법은 WMQ 관리자가 SVRCONN 채널의 MCAUSER 필드에 낮은 권한의 ID를 지정해야한다는 것입니다. 이 ID는 Java EE 서버에 필요한 대기열에 상관없이 명령 대기열 및 다양한 다른 관리 대기열에 권한이 부여되어야합니다. 이렇게하면 WAS 7이 인식 할 수없는 ID 을 보내는 문제가 해결되어 모든 유형의 원격 클라이언트가 해당 채널에 대한 관리 액세스 권한을 얻지 못하게됩니다.

WMQ 연결을위한 WAS 관리 패널로 이동하여 사용자 ID를 mqm으로 설정하십시오. (WMQ가 Windows가 아닌 분산 시스템에서 실행되는 경우 작동합니다 .WWQ가 Windows, z/OS 또는 다른 플랫폼에서 실행중인 경우 여기에서 플랫폼 해당 ID로 대체하십시오.) WAS가 작동하여 실행되지만, QMgr가 관리 액세스를 노출한다는 사실.

QMgr에서 기본 보안 노출을 식별하고 수정하는 방법에 대한보다 포괄적 인 설명은 WMQ 강화 프레젠테이션 및 랩 http://t-rob.net/links을 참조하십시오.

+0

매우 명확하고 유능한 대답입니다. 고마워요! –

+1

이 불타는 질문을 게시 해 주신 Maxim에게 감사 드리며 정확한 대답은 T.Rob에게도 감사드립니다. –