| Author |
Message
|
| naxtell |
 Posted: Tue Feb 22, 2011 12:58 pm Post subject: MCA UserId needed? |
 |
|
Novice
Joined: 30 Sep 2003
Posts: 17
|
I am working with a newly upgraded configuration with v7.0.1.4 (Windows) on my end and v.7.0.1.4 (AIX) on another company's end. They are using an MCA UserId, but I am not. When I send them a message, it is successfully placed on their receiving queue. When they send me a message, it is placed on my Dead Letter queue with reason MQRC_Not_Authorized. Do I also need to use an MCA UserId or setup any special security, or does their use of a user id have no affect on me receiving messages from them?
Thanks,
Nate |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Feb 22, 2011 1:06 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Clearly it their use of a userid does have some affect on you. If it did not, then the message wouldn't be going to the DLQ.
Regardless of anything else, is it the policy of your company to trust this other company with full access to all of your internal systems?
If it is NOT the policy of your company to trust that other company to that extent, then you need an MCAUSER. |
|
| Back to top |
|
|
| naxtell |
| Posted: Tue Feb 22, 2011 1:19 pm Post subject: |
|
|
Novice
Joined: 30 Sep 2003
Posts: 17
|
Yes, we trust this company and we have taken the appropriate network precautions to only allow communication between our two servers. We have tried specifying a UserId but still see the Not Authorized result. Do the names of our userid settings have to match on both end? Do they have to be set on both the sending and receiving channels on both ends? I have nothing against setting up the MCA UserId if it is needed to get this to work.
Thanks for the help. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 22, 2011 1:26 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Without an MCAUSER on the channel I'm talking to, I can build and send mq messages to JUST THE QUEUE MANAGER I'M CONNECTED to, and potentially access random data on every computer in your company that has a queue manager running on it.
How this can be done is left as an exercise.
The fact that the messages that they are currently sending are failing with an authorization error does not in any way imply that they will keep sending messages with the userid that is failing. The only reasonable way to protect your company is to set an MCAUSER.
Otherwise, yes, the userid that is passed in on the message has to match the name of an existing userid on the system hosting the queue manager, and it has to be as case-sensitive as the platform that the queue manager is running on expects.
Set an MCAUSER. |
|
| Back to top |
|
|
| naxtell |
| Posted: Tue Feb 22, 2011 1:57 pm Post subject: |
|
|
Novice
Joined: 30 Sep 2003
Posts: 17
|
We only have the one Server and production-level Queue Manager and don't intend to expand from that. Your warnings on security still pertain (especially if we ever decided to expand), so it looks like we will be using an MCAUSER. I will have to follow up to find whether there is an MCAUSER set on the other side's sending channel as well as receiving channel. I'll test with the same user account set on both ends and let you know what happens.
Thanks again! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 22, 2011 2:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| naxtell wrote: |
We only have the one Server and production-level Queue Manager and don't intend to expand from that. Your warnings on security still pertain (especially if we ever decided to expand), so it looks like we will be using an MCAUSER. I will have to follow up to find whether there is an MCAUSER set on the other side's sending channel as well as receiving channel. I'll test with the same user account set on both ends and let you know what happens.
Thanks again! |
What Jeff was trying to convey as well, was that you should not bother with the mcauser of the sending party if you are setting it at the receiving end of the channel. All you need to set up on your end are
- a user group for authorization to the 3rd party
- a user member of the group defined in 1
- permissions to access the necessary MQ Objects for users in the group defined in 1 (hint: setup the permissions at group level: -g)
- the SSL trust for the channel
- the SSL peer values for the channel
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 22, 2011 2:51 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
With no mcauser specified on the receiving end of a channel, the mca operates with mqm privileges. This means that the MCA can open and mqput any message it received to any queue.
Any queue includes your internal application queues (payroll, a/p, a/r), SYSTEM.COMMAND.INPUT queue (to do administrative tasks on your qmgr), and to any xmit queues that are used (in the future) to other qmgrs in the network.
Whether or not your organization trusts other organization (today), best-practice is to create an mcauser with only sufficient authority to open the queues that you want the other organization to put messages to.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| naxtell |
| Posted: Wed Feb 23, 2011 9:11 am Post subject: |
|
|
Novice
Joined: 30 Sep 2003
Posts: 17
|
| bruce2359 wrote: |
| With no mcauser specified on the receiving end of a channel, the mca operates with mqm privileges. |
Alright, so back to my original problem then. If I don't have an MCAUSER set, why am I seeing messages placed onto the dead letter queue with reason Not Authorized? I have tried using no MCAUSER, a local account in MQM, and a domain account in MQM. In all cases I still see Not Authorized. I also verified that there is No MCAUSER set on the Sending channel. If the process is running with MQM priviledges, I shouldn't be seeing Not Authorized, right?
Thank you. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 23, 2011 9:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
It's never as simple as one might think...
It is the listener that (usually) starts the RCVR channel.
What or who started the listener at the receiving end? Is that userid in the mqm group?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| naxtell |
| Posted: Wed Feb 23, 2011 9:47 am Post subject: |
|
|
Novice
Joined: 30 Sep 2003
Posts: 17
|
| My listener (receiving end) is set with Control: Queue Manager (as shown in WS Explorer). So I believe it gets started when the Queue Manager is started. Would this mean that it's running under the mqm context and therefore not a specific user context? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 23, 2011 10:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Yes, with a null (blank) MCAUSER specified in the RCVR channel definition, the MCA will operate with the qmgr authority - mqm. This gives the MCA access (open, put) to all queues.
Your external organization could put msgs anywhere on your qmgr, and do admin tasks on your qmgr. You should not allow this.
Keep in mind that the external organization may have weaker security than you. Anyone with a laptop and a free-to-download instance of WMQ could connect to their qmgr, and subsequently put messages to your queues. In this sense, trusting the other organization is not a best-practice.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| naxtell |
| Posted: Wed Feb 23, 2011 10:14 am Post subject: |
|
|
Novice
Joined: 30 Sep 2003
Posts: 17
|
Alright, so I will plan to use an MCAUSER. But I still get "Not Authorized" no matter what I try for an MCAUSER value on my receiving queue (leaving it blank or setting it a user that I've added to the MQM group). I would like to get this to work first without an MCAUSER (to verify basic functionality), then with an MCAUSER to address the security concerns.
So what I have now is a sending channel on the other end with a blank MCAUSER and a receiving channel on my end with a blank MCAUSER, but I get "Not Authorized". I'd like to clear this up before moving onto using an MCAUSER on my receiving channel (since I can't get either to work). From what you're saying, it looks like I shouldn't be seeing messages placed onto the dead letter queue with "Not Authorized" as it's running with mqm privileges. Any ideas on why this basic setup doesn't work?
Thank you. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 23, 2011 10:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| naxtell wrote: |
Any ideas on why this basic setup doesn't work?
|
Looking at it square on, the user id that's putting the message at the sending end (or the MCAUser in your receiver channel) isn't authorised to put to the queue where the messages are destined to go.
Enabling security events will prove what user id the queue manager has found to use and is failing. Remembering that on AIX both users and groups are case sensitive so adding someone to the MQM group will not give a user admin rights to the queue manager in the way adding him to the mqm group will.
You might also want to look at what the user's primary group is. Also if the MCAUser value has been folded (deliberately or otherwise) to upper case.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Feb 23, 2011 10:46 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If the RCVR channel's Put Authority parameter is set to Context, you are telling the channel to use the User ID in the MQMD of the message for authority checking.
If you are using Put Authority set to Context, don't. Its trivial for the sender to send a message with mqm in the MQMD header and do whatever they want to your QM.
Turn on Authority Events at the QM level. This will show you exactly what ID is failing on what MQ API call against what MQ object.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 23, 2011 10:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
Please display your RCVR channel (using runmqsc); then post the results here.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
