| Author |
Message
|
| KIT_INC |
 Posted: Thu Jun 13, 2013 8:12 pm Post subject: MQ explorer user Id |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I installed the new MQ explorer supportpac on my laptop and use it to connect to a V7.1 MQ server on Windows. On the Explore, I did an add QMGR by specifying the IP address and port number of the MQ server and using the SYSTEM.ADMIN.SVRCONN. I got auhtorisation failure which is expected because I log on to my laptop as user1 which has no authroty on the MQ server at all.
I go the the explorer Winodws/preference/Websphere MQ Explorer/client connection/user identification and put 'mqadmin' in the userId field. I know that mqadmin has mqm authority. I then do the add qmgr again. Now I am able to get connected and create a queue on the server.
This doesn't look right to me. It seems a big security issue. All I need is knowing the userId of my MQ administrator. Is this already a known problem and fixed by IBM ? |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu Jun 13, 2013 11:59 pm Post subject: Re: MQ explorer user Id |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| KIT_INC wrote: |
| ...This doesn't look right to me. It seems a big security issue. All I need is knowing the userId of my MQ administrator... |
Well done for not just shrugging your shoulders because it's worked and then adopting a don't-care attitude, which a surprising number of people do. 
| KIT_INC wrote: |
| ...Is this already a known problem and fixed by IBM ? |
There is a fantastic resource, the WebSphere MQ Security in an Enterprise Environment, which clearly explains how to lock down queue managers.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 14, 2013 5:37 am Post subject: Re: MQ explorer user Id |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| KIT_INC wrote: |
| Is this already a known problem and fixed by IBM ? |
The "problem" is if you leave the MCAUSER of a SVRCONN channel blank you are saying you are willing to accept any ID from the client. Forget that MQExplorer makes it easy for you to provide an ID in the GUI. You could just as easily have created a local user on your PC called 'mqadmin', logged in as that ID, started Explorer and made it in that way.
Unless one accepts that a SVRCONN channel might be used for 100% control of your queue manager, you must somehow dictate what the potential IDs are that are allowed over that channel. Hard coding an ID into the MCAUSER of the channel is one way. A Security Exit on the channel can set the MCAUSER to any value the exit is coded to do, or block any ID the exit is coded to block. The CHLAUTH rules in MQ 7.1 and newer also have some capabilities for setting and/or blocking IDs based on how you set up the mapping rules.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 14, 2013 7:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
You can also add SSL to the channel ends to enhance security.
_________________
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 |
|
|
| KIT_INC |
| Posted: Fri Jun 14, 2013 8:44 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| I understand what all of you are saying. We have not done our home work. But in real world there are still small shops out there that only have a few QMGRs and part time MQ administrators. All we need is basic security. We have done the basic work of not letting any non company PC to plug into our network. Lock down company PC that user cannot create local IDs. Set up QAM securities to check any user ID accessing MQ resources. Any user iD coming in through the SVRCONN is checked. This satisfied our current requirement. (no plan for ssl).We only notice this User Identification option when we start our study for V7 migration work estimation. We were hoping that it will be just migrate exsiting configuration from V6 to V7 and it will be at least as good as before. Now it looks like that we have some additional work on the security side because it makes it so easy to clone another userid. I was hoping that it will at least ask for password just like when you try to do a run as in Windows. But there is no password required. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 14, 2013 9:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
v6 had the same problem.
If you didn't notice it, you didn't notice it, but it was still there. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jun 15, 2013 4:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@Kit_inc
As an experiment, create a little stand alone JMS program (java).
Connect without passing a user id and see what priviledges you will get...
This is why you want to use SSL on any admin channel.
To secure the qmgr, you should be using SSL with SSL PEER check on every svrconn channel. V7.1 and 7.5 relax this some as you can block on an ip / host basis on the channel and also disallow admin access.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jun 15, 2013 5:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| To secure the qmgr, you should be using SSL with SSL PEER check on every svrconn channel. V7.1 and 7.5 relax this some as you can block on an ip / host basis on the channel and also disallow admin access. |
Or a Security Exit.
But not every SVRCONN channel needs this to deem the QM secure. Channels with MCAUSERs filled in with an ID that has no access don't need SSL or an Exit or CHLAUTH rules. Channels tagged with a low privileged ID (i.e. display only to a subset of queues) might be OK without SSL / Exit / CHLAUTH.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
