| Author |
Message
|
| ivanachukapawn |
 Posted: Thu Feb 12, 2015 12:34 pm Post subject: MQ8 CHLAUTH problems |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Kicking MQ8 tires, I tried to get client SVRCONN connection to a queue manager with CHLAUTH enabled. These are the steps I took.
# Using MQExplorer followed by runmqsc ( MQ8 on Centos ) I created the TEST3 Queue Manager.
DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('nobody') REPLACE
DEFINE CHANNEL (SYSTEM.AUTO.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('nobody') REPLACE
DEFINE CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('nobody') REPLACE
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN) ACTION(REMOVE)
DEFINE CHANNEL(TEST3.ADMIN) CHLTYPE(SVRCONN) TRPTYPE(TCP) MAXMSGL(104857600) MCAUSER('nobody') DESCR('WebSphere MQ Admin Support Channel') REPLACE
SET CHLAUTH (TEST3.ADMIN) TYPE(USERMAP) CLNTUSER ('jdavis') USERSRC (MAP) MCAUSER ('mqm') ACTION (ADD)
channel authentication records: Enabled (by default)
Queue Manager Connection Authentication: SYSTEM.DEFAULT.AUTHINFO.IDPWOS (by default)
id jdavis = uid=500(jdavis) gid=502(mqm) groups=502(mqm), 503(mqbrkrs)
seemed to me that these steps ought to be sufficient to get a client connection using TEST3.ADMIN - so I set MQSERVER
echo $MQSERVER - TEST3.ADMIN/TCP/localhost(3414)
ok - going to try dmpmqmsg in client mode (this should use TEST3.ADMIN port(3414) via MQSERVER variable
dmpmqmsg -c -m TEST3 -iTESTQUEUE3 -oTESTQUEUE4
yielding error message MQCONNX on object 'TEST3' returned 2035 not authorized.
Looking at the error log for TEST3, I find that the error was caused by CONNAUTH CHCKCLNT (REQDADM ) - where TEST3 checked the user ID mqm and its password (which wasn't supplied by dspmqmsg)
I believe that this CHLAUTH configuration works in 7.1.0.5 and 7.5.0.4 - was CHLAUTH feature changed in MQ8 so that mapping a client ID to 'mqm' (via CHLAUTH records)
doesn't work anymore because 'mqm' is privileged? If so, man, this is weird - it doesn't work because the client ID is privileged. Ideas for what to do next to get this to work? |
|
| Back to top |
|
 |
| tczielke |
| Posted: Thu Feb 12, 2015 1:43 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
If you do a
| Code: |
dis AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) all
|
you will probably see CHCKCLNT(REQDADM).
You will want to research what that attribute means for CONNAUTH in MQ v8, as it should explain the error you are getting. Basically, it is enforcing that a user id in the admin group is required to pass a valid password for a client connection. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Feb 12, 2015 2:09 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
TCZ,
I created a new AUTHINFO object for CONNAUTH and set both CHCKLOCL and CHCKCLNT to NONE. Now it works. However, the error log message says: "but you should generally not allow unauthenticated remote access" - I don't quite understand why this is. The way its configured now, I think the client ID is "mapped" (i.e. changed to MCAUSER ('mqm") - why is this considered "unauthenticated"? After all, via CHLAUTH records, only a user logged in as "client ID" can get access via mqm - no one else can get access via MCAUSER('mqm') - sounds like its "authenticated" despite the CHCKCLNT(NONE) setting. |
|
| Back to top |
|
|
| tczielke |
| Posted: Thu Feb 12, 2015 3:27 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
I think IBM considers running a SVRCONN channel with mqadmin access as a potential security risk, so that is why they set the CONNAUTH default that way to enforce that the user really is who they say they are (with password authentication). Maybe I am stating it too strongly, so someone from IBM (or others) can disagree.
This all starts to get into security requirements, which drives the logical part of me crazy, so I won't comment further.  |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Feb 13, 2015 3:30 am Post subject: Re: MQ8 CHLAUTH problems |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| ivanachukapawn wrote: |
| SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN) ACTION(REMOVE) |
There's a blog out there (by Morag Hughson) on how to configure an admin-only bypass to this rule...
_________________
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 |
|
|
| fjb_saper |
| Posted: Fri Feb 13, 2015 6:34 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| ivanachukapawn wrote: |
| However, the error log message says: "but you should generally not allow unauthenticated remote access" - I don't quite understand why this is. The way its configured now, I think the client ID is "mapped" (i.e. changed to MCAUSER ('mqm") - why is this considered "unauthenticated"? After all, via CHLAUTH records, only a user logged in as "client ID" can get access via mqm - no one else can get access via MCAUSER('mqm') - sounds like its "authenticated" despite the CHCKCLNT(NONE) setting. |
No it's not and this is why you get this message. Using java anybody can pretend to be 'jdavies' and as such get mqm access !!!
Having the authinfo rule forces jdavies to submit his password for authentication before he/she/it is authorized...
Haven't tried dmpmqcfg in client mode on V8, but trying runmqsc in client mode requires you to put in a password with standard authinfo...
Also make sure you're at 8.0.0.1. MQExplorer at 8.0.0.0 had some problems with password length.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Feb 13, 2015 7:06 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Feb 16, 2015 10:41 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Exerk
Thanks for your reply. I am most interested in the bypass blog by Morag you referred to. Do you have a link? I looked over the Morag Hughson blogs and could not find one on that subject.
FJB_Saper - thanks for pointing out the Java weakness in the scheme I am currently using in 7.5 to get MQ Admin access to a SVRCONN. I am hoping exerk/morag can get me a way to strengthen this to avoid the vulnerability. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Feb 16, 2015 1:19 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| ivanachukapawn wrote: |
Exerk
Thanks for your reply. I am most interested in the bypass blog by Morag you referred to. Do you have a link? I looked over the Morag Hughson blogs and could not find one on that subject. |
Try clicking on the link in Morag's post, the one just above yours 
_________________
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 |
|
|
| ivanachukapawn |
| Posted: Thu Feb 19, 2015 1:42 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
fjb_saper,
I tried looking further at the Java "pretender" vulnerability - I saw in another post about "pretending be someone else's ID) that I could test using MQMON MQI Exercizer, but this doesn't work because MQMON won't let you test any API until you get a connection and it will do that apparently using the preconfigured MQMON SVRCONN and the user's ID. Do you have a Java sample of ID-pretense? I mean, short of using a security exit, I don't see any way of providing an ID for the channel connection attempt. Note: I don't really want to do this - just want to demonstrate to management the advantage of moving to MQ8 and using Connection Authentication / CHLAUTH. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Feb 19, 2015 1:50 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Create a user of the name you want on the machine running the client, and run the application under that user ID. Simplest way to demonstrate it.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Thu Feb 19, 2015 2:06 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Please forgive me - Maybe I am just too dense to comprehend this. I thought that the Java-pretense procedure was for a user of ID = usersNonPrivilegedID to pretend to be mqAdminID. For this test I assume that "the application" you refer to can not be MQMON - (because MQMON assumes that a privileged admin connection is required because MQMON is a remote MQ admin tool) - so I guess a simple Java program would suffice. I could develop a simple Java client app and ask a non-privileged colleague to run it to pretend to be myMQadminID. How could a Java client being run by my non-privileged colleague ID be designed to try a connection as myMQadminID? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 19, 2015 2:16 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A Java app can present any credentials.
_________________
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 |
|
|
| ivanachukapawn |
| Posted: Thu Feb 19, 2015 3:16 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| OK. Thanks. I see it now. Just supply the userID you want in MQEnvironment prior to instantiating an MQQueueManager object. I am coming to realize that with MQ 8.0.0.2 with CHLAUTH and Connection Authentication enabled with default settings, remote MQ admin via SVRCONN will not be possible. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Feb 20, 2015 6:16 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Did you know you can tell MQ Explorer to present any ID you wish?
Look at the "Connection details" of a Qmgr... This feature has been around for quite some time. |
|
| Back to top |
|
|
|
|
