| Author |
Message
|
| Studv01 |
 Posted: Mon Oct 10, 2016 4:42 pm Post subject: MQ RC 2035: queue MQCONN failed, reason: not authorized |
 |
|
Apprentice
Joined: 23 Jan 2015
Posts: 27
|
I have a Queue Manager QMGR1 running on 8005.
- I have enabled CHLAUTH at QMGR level
- I have defined a SVRCONN channel CH01
- I have setup authentication using the following commands
SET CHLAUTH(CH01) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)
SET CHLAUTH(CH01) TYPE(BLOCKUSER) USERLIST(nobody)
when I tried to connect to the queue manager using the SVRCONN channel CH01 I and getting "not authorized" error.
*** can some one help me resolve this issue.
- studv01 |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Oct 10, 2016 6:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What is the value of the connauth field on the qmgr? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Studv01 |
| Posted: Tue Oct 11, 2016 9:20 am Post subject: |
|
|
Apprentice
Joined: 23 Jan 2015
Posts: 27
|
here are the QMGR details on auth
QMNAME(QMGR1)
COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE)
CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 11, 2016 9:35 am Post subject: Re: MQ RC 2035: queue MQCONN failed, reason: not authorized |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Studv01 wrote: |
*** can some one help me resolve this issue.
|
Enable security events and channel events.
Set WARN(YES) on all the channel authority records, not just the 2 you've created.
Repeat the test and obtain the 2035.
Review the events to see what you're bouncing off.
Remediate.
Remove WARN(YES) or set WARN(NO).
Disable security and channel events.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Studv01 |
| Posted: Tue Oct 11, 2016 9:51 am Post subject: |
|
|
Apprentice
Joined: 23 Jan 2015
Posts: 27
|
thanks Vitor and fjb_saper
the issue is resolved now. thanks for the tip on CONNAUTH
here is what I did
I saw my QMGR1 was enabled with CHLAUTH and CONNAUTH was assigned with SYSTEM.DEFAULT.AUTHINFO.IDPWOS.
I looked up the parameters in AUTHINFO for IDPWOS policy and I saw the CHCKCLNT was REQDADM
I altered it to NONE and I was able to test my connection with out 2035.
thanks for your time and help
here is the IBM documentation I refered
http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q113250_.htm
***Also I refreshed the CONNAUTH security ****
REFRESH SECURITY TYPE(CONNAUTH) |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 11, 2016 9:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
No.
You should have changed your channel to use a different mcauser.
And used a program that could specify a password.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Studv01 |
| Posted: Tue Oct 11, 2016 10:15 am Post subject: |
|
|
Apprentice
Joined: 23 Jan 2015
Posts: 27
|
Some how our Engineers designed the system to have nominal restrictions on the objects. it was never meant to check the user for ID and password.
turning off the client check helps us with the requirement we have.
we have other means of client security in place though.
~studv01 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 11, 2016 11:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
... I hope these other methods of client security and the nominal restrictions on objects meet your internal security standards...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
