Question

I am trying to create a JMS connection from WebSphere App Server 7, but keep getting JMSWMQ2013 (with MQ reason code 2035). Clearly this is an authentication problem, and I can see many other similar reports so I have a rough idea of the general problem.

I'm awaiting feedback from our operations team as to the exact configuration of the channel, however, in the meantime I have one observation that is quite puzzling. If I use WebSphere's JAAS authentication to provide the userid, then I always get the JMSWMQ2013 error. , however, if explicitly pass the same userid to the JMS queue connection factory's call to createQueueConnection(), then I don't get the authentication error.

To be honest, I would have expected both techniques to behave consistently. Is there some subtlety that I am missing with using JAAS to provide the credentials for a JMS queue connection factory?

Edit: I turned on JMS tracing in WAS using *=info: JMSApi=all: JMSServer=all: Messaging=all: JMS_WASTraceAdapter=all: com.ibm.mq.*=all: jmsApi=all, and compared the output line by line.

When using JAAS I can can see that deep in the bowels of JmsXAQueueConnectionImpl it is actually calling WMQConnection.getProcessUserId() which returns the userid that my WAS instance is running under (which is definitely not the user that is defined in the channel's MCAUSER).

It is all quite odd... it doesn't seem to be picking up the JAAS authentication entry at all. My QCF definitely is using CLIENT transport with a mapping configuration alias of DefaultPrincipalMapping, but for some reason it is still using the process's userid instead of the JAAS userid.

Thanks. Craig

Was it helpful?

Solution 2

2035 is certainly authentication problem. The user id trying to connect doesn't have access to the MQ resource.

Regarding, your below comment:

If I use WebSphere's JAAS authentication to provide the userid, then I always get the JMSWMQ2013 error. , however, if explicitly pass the same userid to the JMS queue connection factory's call to createQueueConnection(), then I don't get the authentication error.

Your expectation is correct. Both techniques should behave in the same way. If user id has access then both should connect, if not then both should throw error.

Only explanation to your problem may be, that you are unknowingly sending different user ids in these apps.

Like, your user id is "User123", and it has access to the MQ resource.

However, may be WebSphere's JAAS authentication is sending Domain along with user id. Say, your user id is in "Developer" domain, then the user id being sent is "Developer\User123", which may not be having access to the resource.

OTHER TIPS

Run IBM WebSphere MQ Explorer as administrator of OS. Disable identification record of a channel at queue manager properties (menu link/connection or smth like that).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top