| Author |
Message
|
| NomadAU |
 Posted: Sun Aug 13, 2017 7:18 pm Post subject: MQ Explorer auth failure when passing valid userid/password |
 |
|
Novice
Joined: 06 Feb 2017
Posts: 15
|
Hi,
I've encountered a security failure that is beyond my understanding...hoping someone might be able to shed some light.
MQ Version: 8.0.0.6
O/S: Linux 3.10.0-514.6.1.el7.x86_64
I am trying to set up security for MQ Explorer access. I have 2 local OS userids, one for an admin role, and the other for a ReadOnly role.
Both userids exist, and have correct passwords - I have tested this by issuing command su - <OS userid> and specifying the matching password at the promt - both userid/password pairs passed login checks.
On the MQ side, I have also defined 2 client channels, one for 'admin' activities, the other for RO activities.
However, when MQ Explorer tries to connect using for example, the 'admin' channel and the privileged userid/password combination, it is rejected with 2035.
What strikes me as odd is that I have traced the authentication activity on the MQ side, and can clearly see the userid and password being used (the latter I can figure out because the trace shows the length of the password, which corresponds to the length of the value being passed from MQ Explorer).
From MQ trace I can see amqrmppa has the correct userid (I've masked this) and password length
| Code: |
| 14:02:29.568987 12400.6 RSESS:000002 Constructing MQCSP from rfpTST_USERID_DATA...'xxxxxx' password length=5 |
MQ then makes an OS call (I think, just guessing) which fails with auth error thus.
| Code: |
12:23:50.384304 17012.117 RSESS:000062 -----------{ ziiSPIKernel
12:23:50.384304 17012.117 RSESS:000062 ------------{ ziiCreateIPCCMessage
12:23:50.384306 17012.117 RSESS:000062 -------------{ zcpCreateMessage
12:23:50.384307 17012.117 RSESS:000062 -------------} zcpCreateMessage rc=OK FunctionTime=1
12:23:50.384308 17012.117 RSESS:000062 ------------} ziiCreateIPCCMessage rc=OK FunctionTime=4
12:23:50.384309 17012.117 RSESS:000062 ------------{ ziiSendReceiveAgent
12:23:50.384311 17012.117 RSESS:000062 Corresponding QMGR_AGENT pid.tid (16890.173)
12:23:50.384312 17012.117 RSESS:000062 -------------{ zcpSendOnPipe
12:23:50.384314 17012.117 RSESS:000062 --------------{ xlsResetEvent
12:23:50.384315 17012.117 RSESS:000062 EventId:148 Flags:0x80000000
12:23:50.384316 17012.117 RSESS:000062 --------------} xlsResetEvent rc=OK FunctionTime=2
12:23:50.384317 17012.117 RSESS:000062 --------------{ xlsPostEvent
12:23:50.384318 17012.117 RSESS:000062 EventId:149 Flags:0x1
12:23:50.384320 17012.117 RSESS:000062 Data: 0x000041fa 0x000000ad
12:23:50.384332 17012.117 RSESS:000062 --------------} xlsPostEvent rc=OK FunctionTime=15
12:23:50.384333 17012.117 RSESS:000062 -------------} zcpSendOnPipe rc=OK FunctionTime=21
12:23:50.384334 17012.117 RSESS:000062 -------------{ zcpReceiveOnPipe
12:23:50.384335 17012.117 RSESS:000062 --------------{ xlsWaitEvent
12:23:50.384337 17012.117 RSESS:000062 EventId:148 Timeout:10000 Flags:0
12:23:50.384338 17012.117 RSESS:000062 Data: 0x00000000
*12:23:51.387850 17012.117 RSESS:000062 Data: 0x00000000
12:23:51.387865 17012.117 RSESS:000062 Data: 0x00000001
12:23:51.387868 17012.117 RSESS:000062 Data: 0x00000000
12:23:51.387870 17012.117 RSESS:000062 Data: 0x80000000 0x00000001
12:23:51.387872 17012.117 RSESS:000062 --------------} xlsWaitEvent rc=OK FunctionTime=1003537
12:23:51.387874 17012.117 RSESS:000062 Data: 0x00000000 0x00000000
12:23:51.387877 17012.117 RSESS:000062 -------------} zcpReceiveOnPipe rc=OK FunctionTime=1003543
12:23:51.387879 17012.117 RSESS:000062 ------------}! ziiSendReceiveAgent rc=MQRC_NOT_AUTHORIZED FunctionTime=1003570
12:23:51.387881 17012.117 RSESS:000062 ------------{ zcpDeleteMessage
12:23:51.387882 17012.117 RSESS:000062 ------------} zcpDeleteMessage rc=OK FunctionTime=1
12:23:51.387883 17012.117 RSESS:000062 -----------}! ziiSPIKernel rc=MQRC_NOT_AUTHORIZED FunctionTime=1003579
12:23:51.387884 17012.117 RSESS:000062 ----------}! lpiSPIKernel rc=MQRC_NOT_AUTHORIZED FunctionTime=1003855 |
What is even more odd to me is that I have the exact same configuration running successfully in a Docker environment - same MQ version, same OS version, same userid/password and same setup scripts.
Tracing the Docker implementation I can see it returns successfully from the OS call.
The only difference I have managed to find, which may (not) be relevant is that the real OS has SELinux enabled, whereas the Docker instances do not. I don't know enough about SELinux to say whether or not this is implicated.
Any ideas on how to progress this issue, short of raising a PMR?
Edit: I should also have added that I am not using LDAP and SYSTEM.DEFAULT.AUTHINFO.IDPWOS has the following settings
| Code: |
4 : DISPLAY AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) all
AMQ8566: Display authentication information details.
AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
AUTHTYPE(IDPWOS) ADOPTCTX(NO)
DESCR( ) CHCKCLNT(REQDADM)
CHCKLOCL(OPTIONAL) FAILDLAY(1)
ALTDATE(2017-08-14) ALTTIME(13.23.24)
|
The following configuration commands might also be useful to know
| Code: |
alter qmgr chlauth(ENABLED)
refresh security type(CONNAUTH)
* disable all incoming system channels
alter channel('SYSTEM.AUTO.RECEIVER') chltype(rcvr) +
mcauser('*NOACCESS') maxmsgl(1)
alter channel('SYSTEM.AUTO.SVRCONN') chltype(svrconn) +
mcauser('*NOACCESS') maxmsgl(1)
alter channel('SYSTEM.DEF.CLUSRCVR') chltype(clusrcvr) +
mcauser('*NOACCESS') maxmsgl(4194304)
alter channel('SYSTEM.DEF.RECEIVER') chltype(rcvr) +
mcauser('*NOACCESS') maxmsgl(1)
alter channel('SYSTEM.DEF.REQUESTER') chltype(rqstr) +
mcauser('*NOACCESS') maxmsgl(1)
alter channel('SYSTEM.DEF.SERVER') chltype(svr) +
mcauser('*NOACCESS') maxmsgl(1)
alter channel('SYSTEM.DEF.SVRCONN') chltype(svrconn) +
mcauser('*NOACCESS') maxmsgl(1)
|
|
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Aug 14, 2017 4:12 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Did you create a chlauth profile allowing privileged access to your admin channel? By default privileged access is denied with a 2035.
Read the blogs from Morag on the subject on the developerworks site.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| NomadAU |
| Posted: Tue Aug 15, 2017 4:40 pm Post subject: |
|
|
Novice
Joined: 06 Feb 2017
Posts: 15
|
| fjb_saper wrote: |
Did you create a chlauth profile allowing privileged access to your admin channel? By default privileged access is denied with a 2035.
Read the blogs from Morag on the subject on the developerworks site.
Have fun |
Yes, the following is defined
| Code: |
set chlauth('ADMIN.xxxxxx') +
type(blockuser) +
descr('Rule to allow MQ admin userids on this channel') +
userlist('nobody') +
action(REPLACE) |
The key point I made in my original post is that the exact same MQ configuration works perfectly well in my Docker environment.
That is why I tend to think this is something specific to the OS, rather than MQ. And the only difference I can find so far, is that SELinux is enabled in the real (i.e. non Docker) RHEL environment. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Aug 15, 2017 7:52 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
A blockuser rule does now allow.
_________________
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 |
|
|
| fjb_saper |
| Posted: Wed Aug 16, 2017 4:27 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
It could well be that the SELinux rules do not allow the specific user in the relevant context...
You'd have to investigate that.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Sat Aug 19, 2017 8:38 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
What error is written to your AMQERR01.LOG to go with the 2035 to the application?
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| NomadAU |
| Posted: Wed Aug 23, 2017 10:36 pm Post subject: |
|
|
Novice
Joined: 06 Feb 2017
Posts: 15
|
| hughson wrote: |
| What error is written to your AMQERR01.LOG to go with the 2035 to the application? |
Sorry for the delay, this got distracted by other issues.
Morag - a number of messages are written to the log, all consistent with a userid/password mismatch, e.g.
| Code: |
AMQ5534: User ID 'xxxx' authentication failed
EXPLANATION:
The user ID and password supplied by the 'MQ Explorer 9.0.0' program could not
be authenticated.
Additional information: 'N/A'.
ACTION:
Ensure that the correct user ID and password are provided by the application.
Ensure that the authentication repository is correctly configured. Look at
previous error messages for any additional information. |
| Code: |
AMQ5542: The failed authentication check was caused by the queue manager
CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
The user ID 'xxxx' and its password were checked because the queue
manager connection authority (CONNAUTH) configuration refers to an
authentication information (AUTHINFO) object named
'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with CHCKCLNT(REQDADM). |
| Code: |
AMQ9557: Queue Manager User ID initialization failed for 'xxxxx'.
EXPLANATION:
The call to initialize the User ID 'xxxx' failed with CompCode 2 and
Reason 2035. If an MQCSP block was used, the User ID in the MQCSP block was
'xx'. |
and finally
| Code: |
AMQ9790: The failed authentication check was caused by a CHLAUTH record with
CHCKCLNT(REQUIRED).
EXPLANATION:
The user ID 'xxxx' and its password were checked because the inbound
connection matched a channel authentication record with CHCKCLNT(REQUIRED).
The active values of the channel were 'CLNTUSER(xxxx)
ADDRESS(ws4001412)'. The MATCH(RUNCHECK) mode of the DISPLAY CHLAUTH MQSC
command can be used to identify the relevant CHLAUTH record.
|
Since my last post, I have created a minimal queue manager configuration, no queues, just one SVRCONN channel and associated security configs. I have successfully tested this in a non SELinux environment (not a Docker container) and also shown that it fails in a SELinux enabled environment.
FWIW, apart from the recommended commands to disable all incoming SYSTEM.* channels (shown in earlier post), here are the only other security commands I am running
| Code: |
SET CHLAUTH('ADMIN.xxxx') TYPE(BLOCKUSER) USERLIST('nobody') DESCR('Allow privileged users on this channel')
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('BackStop rule')
SET CHLAUTH('ADMIN.xxxx') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL) CHCKCLNT(REQUIRED) |
| fjb_saper wrote: |
It could well be that the SELinux rules do not allow the specific user in the relevant context...
You'd have to investigate that.
Have fun |
This is getting some way from my comfort zone, but I do take your point. I just don't have bandwidth right now to 'learn' SELinux, if in fact that is the cause of the problem. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 24, 2017 4:08 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You need to create a chlauth rule that maps the userid to one that is valid on the selinux side.
The rules you current have block everyone.
If the userids you're sending from MQExplorer exactly match the userids on the selinux box (not the ones on the MQExplorer side), then you just need to specify a chlauth rule that will pass the id through.
a usermap rule.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Aug 24, 2017 6:25 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| bruce2359 wrote: |
| A blockuser rule does now allow. |
@bruce
He is blocking just the ID "nobody" and thus allowing all other IDs. The ID/password MQ Explorer is passing to the Qmgr is being checked by the OS hosting the Qmgr at the Qmgr's request. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 24, 2017 6:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| JosephGramig wrote: |
| bruce2359 wrote: |
| A blockuser rule does now allow. |
@bruce
He is blocking just the ID "nobody" and thus allowing all other IDs. The ID/password MQ Explorer is passing to the Qmgr is being checked by the OS hosting the Qmgr at the Qmgr's request. |
No. The backstop rule
| Code: |
| SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('BackStop rule') |
will block all users that aren't 'nobody'.
There probably also needs to be a rule that allows admin access - I forget... Something that overrides the default rule that disallows admin groups.
Again, either the user set in MQExplorer needs to *exactly* match the userid on the MQ server side, or a CHLAUTH usermap must be supplied that changes it.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Aug 24, 2017 6:42 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
@OP,
Your comment about SELinux caused me to think twice about a current build I'm doing now. A team member mentioned vaguely that it should be turned off. I wondered why (as I've never hit this before) and Googled it and got this.
Have fun. Now I need to check what I have... |
|
| Back to top |
|
|
| NomadAU |
| Posted: Thu Aug 24, 2017 4:29 pm Post subject: |
|
|
Novice
Joined: 06 Feb 2017
Posts: 15
|
The range of views and solutions expressed here just confirms to me that MQ security is neither readily understood nor easy to implement.
I have taken my guidance from a couple of key sources, namely
- "Secure Messaging Scenarios with WebSphere MQ" Redbook, and
- Developer Works articles, particulary by Morag Hughson
Based on my reading of both, here's my understanding of what should be happening in my environment.
The OOTB MQ security configuration pretty much locks down all system and client channels with the following CHLAUTH rules:
| Code: |
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN) WARN(NO)
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER( ) USERSRC(NOACCESS) WARN(NO)
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER( ) USERSRC(CHANNEL) WARN(NO) |
I define my SVRCONN channel thus - the intent is to use this for administrative access from MQExplorer.
| Code: |
| DEFINE CHANNEL('ADMIN.MJBTEST') CHLTYPE(SVRCONN) |
And now I need to allow a privileged user to connect on this, currently prevented by the earlier OOTB CHLAUTH rules.
| Code: |
| SET CHLAUTH('ADMIN.MJBTEST') TYPE(BLOCKUSER) USERLIST('nobody') DESCR('Allow privileged users on this channel') |
This rule seems to be the cause of confusion...although it may appear to be counter-intuitive, this rule is actually overriding (removing) the earlier OOTB rule 'SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN) WARN(NO)', but just for my 'ADMIN.MJBTEST' channel. Once applied, the queue manager will now allow a privileged user to connect on this channel.
The so-called 'back stop rule' simply disallows access on all channels that are not matched by more specific rules,
| Code: |
| SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) DESCR('Back-stop rule') |
And now I grant access to my 'ADMIN.MJBTEST' channel on the proviso that a userid/password is supplied.
| Code: |
| SET CHLAUTH('ADMIN.MJBTEST') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL) CHCKCLNT(REQUIRED) |
And that folks, should be all that's required.
It's also relevant that I have got this working on an earlier RHEL, also with SELinux enabled. I've shown the details of SELinux sestatus commands below.
So it's working on a RHEL v6 (2.6.32-696.6.3.el6.x86_64) with SELinux enabled. Output from sestatus...
| Code: |
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: permissive
Mode from config file: permissive
Policy version: 24
Policy from config file: targeted |
But not working on RHEL v7 (3.10.0-514.16.1.el7.x86_64) also with SELinux enabled but somewhat different output from sestatus...
| Code: |
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28 |
My money is on something being amiss with SELinux, but so far as I can tell, all of the SELinux settings recommended in the IBM doco http://www-01.ibm.com/support/docview.wss?uid=swg21714191 are in place.
Next step is a PMR I guess, but thanks to all the suggestions on this forum. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Aug 24, 2017 9:31 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Are there any pertinent messages in /var/log/audit.log and /var/log/messages? Looking at various other SELinux password related questions on the web, that seems to be a good place to look.
I assume your SELinux is in "Enforcing" mode rather than "Permissive" mode or you probably wouldn't be having these problems. As I understand it "Permissive" mode just tells you about things that would be problems if you were in "Enforcing" mode.
DISCLAIMER: I'm not an SELinux expert!
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| NomadAU |
| Posted: Sun Aug 27, 2017 3:44 am Post subject: |
|
|
Novice
Joined: 06 Feb 2017
Posts: 15
|
| hughson wrote: |
Are there any pertinent messages in /var/log/audit.log and /var/log/messages? Looking at various other SELinux password related questions on the web, that seems to be a good place to look.
I assume your SELinux is in "Enforcing" mode rather than "Permissive" mode or you probably wouldn't be having these problems. As I understand it "Permissive" mode just tells you about things that would be problems if you were in "Enforcing" mode.
DISCLAIMER: I'm not an SELinux expert! |
No, both working and non-working RHEL are running in Permissive mode.
Anyhow, I will have a bit more of a dig and see if there's any useful nuggets in either of the log files my mention. |
|
| Back to top |
|
|
| tczielke |
| Posted: Sun Aug 27, 2017 5:07 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
Since you are running MQ traces, you may also want to try strace. Sometimes, there is a valuable clue in the strace to the underlying issue. Make sure to run strace with the -f option to follow any child processes that are created with the strace.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
