Question & Answer
Question
MQ V8.0 Connection Authentication and MQ Explorer
Answer
On Demand Consulting
Author: Phil Bareham
Introduction
Prior to MQ V8.0, MQ did not authenticate user ids and/or passwords out-of-box, MQ 'assumed' that if the operating system was OK with the user-id connecting to the queue manager then all was well, the only way to implement user-id/password authentication was by writing exits.
MQ V8.0 introduced Connection authentication (CONNAUTH) which allows user id/password authentication when an application or user connects to a queue manager and for connection requests to be rejected when the user cannot be authenticated.This article provides and overview of MQ Connection Authentication.
MQ Connection authentication should not be confused with MQ Channel Authentication which was introduced in MQ 7.1 and will be the the subject of a future Knowledge Article.
A new MQ object type has been introduced - the Authentication Information or AUTHINFO object - to configure the user-id/password requirements and to determine the type of user repository that is to be used for authentication. There is also a queue manager attribute 'Connection Authentication' or CONNAUTH that defines the type of AUTHINFO to be used by a queue manager.
MQ V8.0 introduces two new Authentication Objects for use with Connection Authentication system default objects for both of these new types can be seen in MQ Explorer for a queue manager in the 'Authentication Information' folder:
The two new AUTHINFO objects type are defined on a new queue manager as 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' and 'SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP' the other two - 'SYSTEM.DEFAULT.AUTHINFO.CRLLDAP' and 'SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP' were introduced in an earlier version of MQ and for use with SSL certificate revocation checking.
When a new V8.0 or later queue manager is created it will be configured by default to use the 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' AUTHINFO object as can be seen via the queue managers extended properties in MQ Explorer:
Or by mqsc:
If we look at the SYSTEM.DEFAULT.AUTHINFO.IDPWOS we can see that has the AUTHTYPE set to IDPWOS:
MQ V8.0 introduced Connection authentication (CONNAUTH) which allows user id/password authentication when an application or user connects to a queue manager and for connection requests to be rejected when the user cannot be authenticated.This article provides and overview of MQ Connection Authentication.
MQ Connection authentication should not be confused with MQ Channel Authentication which was introduced in MQ 7.1 and will be the the subject of a future Knowledge Article.
What is connection authentication
MQ Connection authentication provides the ability for an MQ application to provide a user and password for both MQ Local Bindings (cross memory - same host) and MQ Client Connection Channel connections. MQ Connection Authentication does not apply to MQ distributed queuing Channels (Sender/Receiver Server/Requestor & Cluster Sender and Receiver) - these are inter-queue manager connections and MQ applications do not connect directly to these channels.A new MQ object type has been introduced - the Authentication Information or AUTHINFO object - to configure the user-id/password requirements and to determine the type of user repository that is to be used for authentication. There is also a queue manager attribute 'Connection Authentication' or CONNAUTH that defines the type of AUTHINFO to be used by a queue manager.
The new Authentication Information objects
MQ V8.0 introduces two new Authentication Objects for use with Connection Authentication system default objects for both of these new types can be seen in MQ Explorer for a queue manager in the 'Authentication Information' folder:The two new AUTHINFO objects type are defined on a new queue manager as 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' and 'SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP' the other two - 'SYSTEM.DEFAULT.AUTHINFO.CRLLDAP' and 'SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP' were introduced in an earlier version of MQ and for use with SSL certificate revocation checking.
When a new V8.0 or later queue manager is created it will be configured by default to use the 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' AUTHINFO object as can be seen via the queue managers extended properties in MQ Explorer:
Or by mqsc:
C:\PJB>runmqsc MQ9QMGR
5724-H72 (C) Copyright IBM Corp. 1994 2016.
Starting MQSC for queue manager MQ9QMGR.
dis qmgr connauth
1 : dis qmgr connauth
AMQ8408: Display Queue Manager details.
QMNAME(MQ9QMGR)
CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
5724-H72 (C) Copyright IBM Corp. 1994 2016.
Starting MQSC for queue manager MQ9QMGR.
dis qmgr connauth
1 : dis qmgr connauth
AMQ8408: Display Queue Manager details.
QMNAME(MQ9QMGR)
CONNAUTH(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
If a queue manager has been migrated to V8.0 or later from an earlier version of MQ then the CONNAUTH property on the queue manager will not be set this is done to maintain the behaviour of the earlier version of MQ meaning no user-id/password checking.
Authentication object parameters
If we look at the SYSTEM.DEFAULT.AUTHINFO.IDPWOS we can see that has the AUTHTYPE set to IDPWOS: dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
2 : dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
AMQ8566: Display authentication information details.
AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
AUTHTYPE(IDPWOS) ADOPTCTX(NO)
DESCR( ) CHCKCLNT(REQDADM)
CHCKLOCL(OPTIONAL) FAILDLAY(1)
AUTHENMD(OS) ALTDATE(2017-05-22)
ALTTIME(11.53.22)
2 : dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
AMQ8566: Display authentication information details.
AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS)
AUTHTYPE(IDPWOS) ADOPTCTX(NO)
DESCR( ) CHCKCLNT(REQDADM)
CHCKLOCL(OPTIONAL) FAILDLAY(1)
AUTHENMD(OS) ALTDATE(2017-05-22)
ALTTIME(11.53.22)
IDPWOS means that the queue manager uses the operating system to authenticate the user id passed to the queue manager on a connection attempt the alternative to IDPWOS is IDPWLDAP which would use an LDAP Server to check the user-id ad password.
The CHCKCLNT and CHCKLOCL properties are of the most interest here - they also apply to the IDPWLDAP AUTHINFO type discussed in the following section.
The CHCKCLNT and CHCKLOCL parameter determines if user-id/password checks are required for locally bound connections. The possible values are:
Setting the ADOPTCTX parameter to YES means that user-id and password checked by Connection Authentication will also be used to authorize access to MQ Queues etc. on this queue manager (the same queue manager). A value of NO means that the id that the application is running under will be checked for Authorisation to access queue and other MQ objects.
FAILDLAY determines the delay - in seconds - after a failure to authenticate before sending a response back to the application. For example FAILDELAY(3) means that after 3 seconds there is not response from the authentication mechanism then then an authentication failure is returned. There is no parameter to limit the maximum number of authentication attempts.
If we look at the details SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP AUTHINFO object:
We can see that there are some extra parameters above those that we found on the SYSTEM.DEFAULT.AUTHINFO.IDPWOS AUTHINFO object. The CONNAME LDAPUSER and LDAPPWD parameters determine the LDAP hostname/IP Address and user-id and password used to access to the LDAP server. The remainder of the parameters here determine how the LDAP is to be searched see the MQ knowledge centre here:
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.ref.adm.doc/q085490_.htm
If we use runmqsc or MQ Explorer as we have prior to V8.0 on the same machine as the queue manager MQ9QMGR - using local bindings - then both MQ Explorer and runmqsc will start and run without an issue as they have in previous versions of MQ because CHCKLOCL is set to OPTIONAL no user-id and password is sent when starting runmqsc or MQ Explorer so no authentication check is done.
From V8.0 onwards runmqsc provides the ability to send a user-id and password to the queue manager. If we start runmqsc with the user-id ab123456 we will be prompted for the password:
If the password is entered incorrectly then we will get mqrc 2035 (user not authorized)
In MQ Explorer for V8.0 onwards we can now specify a user-id and password to be used to connect to a queue manager. To set the user id and password settings for a queue manager right-click and select 'Connection Details' -> 'Properties' then select 'Userid':
In this example we have selected 'Enable user identification' specified the user id 'ab123456' and have chosen 'prompt for password' to make MQ Explorer ask for a password and we attempt to connect to the queue manager. We could save the password for this userid and queue manager by selecting the 'Use saved password' option.
When a queue manager is added to MQ Explorer the dialog defaults to 'Enable user identification' being unchecked the 'User id' field is blank and 'No password' is selected.
The 'User identification compatibility mode' allows user ids and passwords to be sent to pre MQ V8.0 queue managers so that they can be passed to security exits.
The CHCKCLNT and CHCKLOCL properties are of the most interest here - they also apply to the IDPWLDAP AUTHINFO type discussed in the following section.
The CHCKCLNT and CHCKLOCL parameter determines if user-id/password checks are required for locally bound connections. The possible values are:
- None - no user-id/password checks are done all connection attempts are allowed.
- Optional - if a user-id and password are supplied they will be checked and rejected if they fail authentication if no user-id/password is supplied. no check is done and the connection attempt is allowed. This may seem an odd option but it could prove useful during migration to using CONNAUTH
- Required for administrators - Any privilegeduser-id must provide a user-id and password any non-privileged user-id is not require to authenticate.
- Required for all - all connection attempts require user-id and password
Setting the ADOPTCTX parameter to YES means that user-id and password checked by Connection Authentication will also be used to authorize access to MQ Queues etc. on this queue manager (the same queue manager). A value of NO means that the id that the application is running under will be checked for Authorisation to access queue and other MQ objects.
FAILDLAY determines the delay - in seconds - after a failure to authenticate before sending a response back to the application. For example FAILDELAY(3) means that after 3 seconds there is not response from the authentication mechanism then then an authentication failure is returned. There is no parameter to limit the maximum number of authentication attempts.
If we look at the details SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP AUTHINFO object:
dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP)
1 : dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP)
AMQ8566: Display authentication information details.
AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP)
AUTHTYPE(IDPWLDAP) ADOPTCTX(NO)
DESCR( ) CONNAME( )
CHCKCLNT(REQUIRED) CHCKLOCL(OPTIONAL)
CLASSGRP( ) CLASSUSR( )
FAILDLAY(1) FINDGRP( )
BASEDNG( ) BASEDNU( )
LDAPUSER( ) LDAPPWD( )
SHORTUSR( ) GRPFIELD( )
USRFIELD( ) AUTHORMD(OS)
NESTGRP(NO) SECCOMM(NO)
ALTDATE(2017-05-22) ALTTIME(11.53.22)
1 : dis authinfo(SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP)
AMQ8566: Display authentication information details.
AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWLDAP)
AUTHTYPE(IDPWLDAP) ADOPTCTX(NO)
DESCR( ) CONNAME( )
CHCKCLNT(REQUIRED) CHCKLOCL(OPTIONAL)
CLASSGRP( ) CLASSUSR( )
FAILDLAY(1) FINDGRP( )
BASEDNG( ) BASEDNU( )
LDAPUSER( ) LDAPPWD( )
SHORTUSR( ) GRPFIELD( )
USRFIELD( ) AUTHORMD(OS)
NESTGRP(NO) SECCOMM(NO)
ALTDATE(2017-05-22) ALTTIME(11.53.22)
We can see that there are some extra parameters above those that we found on the SYSTEM.DEFAULT.AUTHINFO.IDPWOS AUTHINFO object. The CONNAME LDAPUSER and LDAPPWD parameters determine the LDAP hostname/IP Address and user-id and password used to access to the LDAP server. The remainder of the parameters here determine how the LDAP is to be searched see the MQ knowledge centre here:
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.ref.adm.doc/q085490_.htm
Default configuration on a newly created queue manager
As shown above the default configuration for a new queue manager created with MQ V8.0 or later is for the CONNAUTH parameter to be set to SYSTEM.DEFAULT.AUTHINFO.IDPWOS which has CHCKLOCL set to OPTIONAL and CHCKCLNT set to REQDADM.If we use runmqsc or MQ Explorer as we have prior to V8.0 on the same machine as the queue manager MQ9QMGR - using local bindings - then both MQ Explorer and runmqsc will start and run without an issue as they have in previous versions of MQ because CHCKLOCL is set to OPTIONAL no user-id and password is sent when starting runmqsc or MQ Explorer so no authentication check is done.
From V8.0 onwards runmqsc provides the ability to send a user-id and password to the queue manager. If we start runmqsc with the user-id ab123456 we will be prompted for the password:
C:\PJB>runmqsc -u ab123456 MQ9QMGR
5724-H72 (C) Copyright IBM Corp. 1994 2016.
Enter password:
************
Starting MQSC for queue manager MQ9QMGR.
end
1 : end
No MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.
C:\PJB>
5724-H72 (C) Copyright IBM Corp. 1994 2016.
Enter password:
************
Starting MQSC for queue manager MQ9QMGR.
end
1 : end
No MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.
C:\PJB>
If the password is entered incorrectly then we will get mqrc 2035 (user not authorized)
C:\PJB>runmqsc -u ab123456 MQ9QMGR
5724-H72 (C) Copyright IBM Corp. 1994 2016.
Enter password:
************
Starting MQSC for queue manager MQ9QMGR.
AMQ8135: Not authorized.
No MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.
C:\PJB>
5724-H72 (C) Copyright IBM Corp. 1994 2016.
Enter password:
************
Starting MQSC for queue manager MQ9QMGR.
AMQ8135: Not authorized.
No MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.
C:\PJB>
Using connection authentication in MQ Explorer
In MQ Explorer for V8.0 onwards we can now specify a user-id and password to be used to connect to a queue manager. To set the user id and password settings for a queue manager right-click and select 'Connection Details' -> 'Properties' then select 'Userid':In this example we have selected 'Enable user identification' specified the user id 'ab123456' and have chosen 'prompt for password' to make MQ Explorer ask for a password and we attempt to connect to the queue manager. We could save the password for this userid and queue manager by selecting the 'Use saved password' option.
When a queue manager is added to MQ Explorer the dialog defaults to 'Enable user identification' being unchecked the 'User id' field is blank and 'No password' is selected.
The 'User identification compatibility mode' allows user ids and passwords to be sent to pre MQ V8.0 queue managers so that they can be passed to security exits.
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSQTW3","label":"IBM On Demand Consulting for Hybrid Cloud"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"","label":""}}]
Was this topic helpful?
Document Information
Modified date:
16 March 2019
UID
ibm10771821