none
MQSeries send adapter and MQRC_NOT_AUTHORIZED error RRS feed

  • Question

  • This is probably a long shot...

    I'm trying to send messages from BizTalk 2009 using the MQSC adapter in the host systems adapter pack.  Initially the queue I was sending to resided on a Solaris box and everything was good.  Messages were flowing, no errors and I was happy.  Last week I was given a new queue to send to that resides on an iSeries box.  I have thus far not been able to send successfully to the queue on the iSeries box.

    When I try to send, I end up with the following error in the event log:

     Error details: Failure encountered while attempting to open queue. queue = <my queue name>, queueManager = <my queue manager>, reasonCode = 6124

    From what I've found, error code 6124 basically means the connection to the queue isn't open so messages can't be sent.  This seemed a bit odd to me since obviously from a BizTalk messaging perspective, the adapter should be managing all of that.  This morning I figured out how to turn on MQ tracing and found this in my trace file:

    ImqQueueManager::connect (rc=MQRC_NOT_AUTHORIZED)

    The queue that I'm trying to send to does require credentials.  I'm sending from an orchestration using a dyanmic send port.  In my message construction, I'm setting the following context properties: 

    MQSeriesEx.Channel_Password
    MQSeriesEx.Channel_UserId

    When my messages get suspended, I am able to see these properties in the message context.

    It seems like the error I'm getting is saying that the credentials I'm passing are either no good or not present.  However I'm able to connect to the queue using the same credentials from MQExplorer.  Also, for what it's worth, I've tried using a static port rather than dynamic and got the same error.

    Any suggestions would be very much appreciated.

    Thanks!

    Chris

    Monday, June 7, 2010 3:41 PM

Answers

  • Did you create credentials on the Solaris box before? You may need to create similar credentials again for the iSeries box.

    When I worked with MQSC, I created a similar local account (same login/password) on the BizTalk box as on the remote MQSeries queue server. I think we added it to the mqm group. I then configured a dedicated host just to interact with the queue running under the local account. This way the remote queue recognized the user.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    • Marked as answer by Chris.House Thursday, June 10, 2010 5:34 PM
    Monday, June 7, 2010 8:51 PM
    Moderator

All replies

  • Did you create credentials on the Solaris box before? You may need to create similar credentials again for the iSeries box.

    When I worked with MQSC, I created a similar local account (same login/password) on the BizTalk box as on the remote MQSeries queue server. I think we added it to the mqm group. I then configured a dedicated host just to interact with the queue running under the local account. This way the remote queue recognized the user.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    • Marked as answer by Chris.House Thursday, June 10, 2010 5:34 PM
    Monday, June 7, 2010 8:51 PM
    Moderator
  • Thanks for the response Ben.

    I inherited this environment from someone who's no longer around.  That being said, I was told that no credentials should  be required, for whatever that's worth :)

    Yesterday one of our Java developers put together a quick app to send a message to the same queue.  His code works fine and doesn't pass any credentials, so I'm not so sure it's a security issue. 

    I've got cases opened with both MS and IBM.  I'll give your suggestion of creating a local account and specific host a try as well.

    Chris

    Tuesday, June 8, 2010 8:03 PM
  • There are a couple different configuration options - I think you can also authenticate using a client certificate for MQSC to work. If you do not have a certificate for accessing the queue then I would say it would probably go off a local account.

    Here is an article on the certificate approach: http://msdn.microsoft.com/en-us/library/aa754431(BTS.10).aspx

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Tuesday, June 8, 2010 8:51 PM
    Moderator
  • The word from IBM is that when sending to MQ, the identity of the user which the process is running under is sent to the queue manager.  I confirmed this by trying your suggestion of creating a new host instance.  Once I did that, we were able to send messages. 

    We weren't able to get a clear answer as to why this only happened when sending to the iSeries and not to the Solaris box.  That being said, I don't really like the solution of running a dedicated host instance, so I think we're going to look at setting up remote queues on the Solaris box that transmit to the iSeries.

    Thanks again!

    Thursday, June 10, 2010 5:34 PM
  • There are other benefits from having a dedicated host instance such as more memory and threads available. It is good from a security perspective - you can limit your attack surface by isolating the processing to a single host/Windows service.

    But it does add to the management requirements and if the password changes you have to change the password in both places.

    Thanks,


    If this answers your question, please use the "Answer" button to say so | Ben Cline
    Thursday, June 10, 2010 6:03 PM
    Moderator