ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » MQ Explorer auth failure when passing valid userid/password

Post new topic  Reply to topic
 MQ Explorer auth failure when passing valid userid/password « View previous topic :: View next topic » 
Author Message
NomadAU
PostPosted: Sun Aug 13, 2017 7:18 pm    Post subject: MQ Explorer auth failure when passing valid userid/password Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Mon Aug 14, 2017 4:12 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20695
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
View user's profile Send private message Send e-mail
NomadAU
PostPosted: Tue Aug 15, 2017 4:40 pm    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Aug 15, 2017 7:52 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9392
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
View user's profile Send private message
fjb_saper
PostPosted: Wed Aug 16, 2017 4:27 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20695
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
View user's profile Send private message Send e-mail
hughson
PostPosted: Sat Aug 19, 2017 8:38 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
NomadAU
PostPosted: Wed Aug 23, 2017 10:36 pm    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu Aug 24, 2017 4:08 am    Post subject: Reply with quote

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
View user's profile Send private message
JosephGramig
PostPosted: Thu Aug 24, 2017 6:25 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1228
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
View user's profile Send private message AIM Address
mqjeff
PostPosted: Thu Aug 24, 2017 6:36 am    Post subject: Reply with quote

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
View user's profile Send private message
JosephGramig
PostPosted: Thu Aug 24, 2017 6:42 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1228
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
View user's profile Send private message AIM Address
NomadAU
PostPosted: Thu Aug 24, 2017 4:29 pm    Post subject: Reply with quote

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
View user's profile Send private message
hughson
PostPosted: Thu Aug 24, 2017 9:31 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
NomadAU
PostPosted: Sun Aug 27, 2017 3:44 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Sun Aug 27, 2017 5:07 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Security » MQ Explorer auth failure when passing valid userid/password
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.