| Author |
Message
|
| kmidderigh |
 Posted: Wed Jun 03, 2015 1:23 am Post subject: connecting to v8 queue manager - connection blocked |
 |
|
Apprentice
Joined: 21 Apr 2009
Posts: 26
|
I've just created our first new queue manager at v8 (on Iseries) and i've got to the pulling my hair out stage trying to get an external connection to be accepted.
In v7.5 (on AIX) i'm used to disabling CHLAUTH (we use our own security exits) and then connections work as expected.
On a fresh v8 QM i've got the following configured :
DISPLAY CHLAUTH(*)
> DISPLAY CHLAUTH(*)
1 : DISPLAY CHLAUTH(*)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.AUTO.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.AUTO.SVRCONN) TYPE(BLOCKUSER)
USERLIST(ALLOWANY)
DISPLAY QMGR CHLAUTH
2 : DISPLAY QMGR CHLAUTH
AMQ8408: Display Queue Manager details.
QMNAME(MFTH1A2) CHLAUTH(DISABLED)
I then try to use explorer to connect via SYSTEM.AUTO.SVRCONN (MCA user is set to QMQMADM on SYSTEM.AUTO.SVRCONN temporarily whilst i perform initial build/config - will be removed latter)
I receive AMQ4036 trying a connection - this gives the following in the error log :
----- cmqxrsrv.c : 2282 -------------------------------------------------------
06/03/15 10:09:55 - Process(684339.14) User(QMQM) Jobname(288903/QMQM/AMQZLAA0 )
Host(MFTB40.MFTL.CO.UK)
VRMF(8.0.0.2) QMgr(MFTH1A2)
AMQ5540: Application 'MQ Explorer 8.0.0' did not supply a user ID and password
EXPLANATION:
Cause . . . . . : The queue manager is configured to require a user ID and
password, but none was supplied.
Recovery . . . : Ensure that the application provides a valid user ID and
password, or change the queue manager configuration to OPTIONAL to allow
applications to connect which have not supplied a user ID and password.
Technical Description . . . . . . . . : None.
----- amqzfuca.c : 4279 -------------------------------------------------------
06/03/15 10:09:55 - Process(684339.14) User(QMQM) Jobname(288903/QMQM/AMQZLAA0 )
Host(MFTB40.MFTL.CO.UK)
VRMF(8.0.0.2) QMgr(MFTH1A2)
AMQ5541: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.
EXPLANATION:
Cause . . . . . : The user ID 'QMQMADM' and its password were checked
because the user ID is privileged and the queue manager connection authority
(CONNAUTH) configuration refers to an authentication information (AUTHINFO)
object named 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with CHCKCLNT(REQDADM).
This message accompanies a previous error to clarify the reason for the user ID
and password check.
Recovery . . . : Refer to the previous error for more information.
Ensure that a password is specified by the client application and that the
password is correct for the user ID. The authentication configuration of the
queue manager connection determines the user ID repository. For example, the
local operating system user database or an LDAP server.
To avoid the authentication check, you can either use an unprivileged user ID
or amend the authentication configuration of the queue manager. You can amend
the CHCKCLNT attribute in the CHLAUTH record, but you should generally not
allow unauthenticated remote access.
Technical Description . . . . . . . . : None.
-------------------------------------------------------------------------------
06/03/15 10:09:56 - Process(684448.5) User(QMQM) Jobname(289029/QMQM/AMQRMPPA )
Host(MFTB40.MFTL.CO.UK)
VRMF(8.0.0.2) QMgr(MFTH1A2)
AMQ9557: Queue Manager User ID initialization failed for 'QMQMADM'.
EXPLANATION:
Cause . . . . . : The call to initialize the User ID 'QMQMADM' failed with
CompCode 2 and Reason 2035.
Recovery . . . : Correct the error and try again.
----- cmqxrsrv.c : 2282 -------------------------------------------------------
Despite having read a number of articles about the security setup in v8 I am still confused about how this works.
Please can someone point me to a clear set of commands to disable this connection checking.
(I really think an RFE for the documentation is required to make this clearer = will raise one once i sort this out)
Thanks.
Kevin. |
|
| Back to top |
|
 |
| kmidderigh |
| Posted: Wed Jun 03, 2015 1:37 am Post subject: |
|
|
Apprentice
Joined: 21 Apr 2009
Posts: 26
|
A bit more googling finally found the answer....
ALTER QMGR CONNAUTH(' ') removes this checking completely
Phew... |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 03, 2015 1:38 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Whilst you may have disabled CHLAUTH, V8.0 introduced CONNAUTH, and it's clear that the failure is there. The setting you have is REQDADM, which means that your privileged account used as the MCAUSER value will be checked for a password match with the local OS. If you are only doing this for testing purposes, temporarily alter the CHCKCLNT attribute to OPTIONAL.
EDIT: Are you planning to reinstate CONNAUTH post testing?
_________________
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 |
|
|
| kmidderigh |
| Posted: Wed Jun 03, 2015 2:01 am Post subject: |
|
|
Apprentice
Joined: 21 Apr 2009
Posts: 26
|
no - will be leaving CONNAUTH disabled.
We use Blockip on all serverconn channels to control access (added already and QMQMADM MCA user removed).
all good.  |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 03, 2015 2:21 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| kmidderigh wrote: |
| ...all good. |
I'd disagree with that - not using the inherent security mechanisms and all.
_________________
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 |
|
|
| kmidderigh |
| Posted: Wed Jun 03, 2015 2:40 am Post subject: |
|
|
Apprentice
Joined: 21 Apr 2009
Posts: 26
|
| will certainly look into the new security features in time but as this will take time to rollout across any large estate its not something to be undertaken lightly - especially when you have a working security model in place (and not when pushing through an urgent client migration project - which is what this qm has been created for). |
|
| Back to top |
|
|
|
|
