Connection authentication: Configuration

A queue manager can be configured to use a supplied user ID and password to check whether a user has authority to access resources.

Turning on connection authentication on a queue manager

On a queue manager object, the CONNAUTH attribute can be set to the name of an authentication information (AUTHINFO) object. This object can be one of two types (AUTHTYPE attribute):
IDPWOS
Indicates that the queue manager uses the local operating system to authenticate the user ID and password.
IDPWLDAP
Indicates that the queue manager uses an LDAP server to authenticate the user ID and password.
Note: You cannot use any other type of authentication information object in the CONNAUTH field.

IDPWOS and IDPWLDAP are similar in a number of their attributes, which are described here. Other attributes are considered later.

To check local connections, use the AUTHINFO attribute CHCKLOCL (check local connections). To check client connections, use the AUTHINFO attribute CHCKCLNT (check client connections). The configuration must be refreshed before the queue manager recognizes the changes. 
ALTER QMGR CONNAUTH(USE.PW)
DEFINE AUTHINFO(USE.PW) +
AUTHTYPE(IDPWOS) +
FAILDLAY(10) +
CHCKLOCL(OPTIONAL) +
CHCKCLNT(REQUIRED)
REFRESH SECURITY TYPE(CONNAUTH)
Where USE.PW in the CONNAUTH is a string that matches the AUTHINFO definition.
CHCKLOCL accepts the values of NONE and OPTIONAL, and CHCKCLNT allows the value of NONE for the authentication requirements to be configured:
NONE
Switches off checking.
OPTIONAL
Ensures that if a user ID and password are provided by an application, they are a valid pair, but that it is not mandatory to provide them. This option might be useful during migration, for example.
If you:
  • Provide the username and password, they are authenticated.
  • Do not provide the username and password, connection is allowed.
  • Provide the username, but not the password you receive an error.
Important: OPTIONAL is the minimum value you can set, in order to use more stringent CHLAUTH rules.

If you select NONE and the client connection matches a CHLAUTH record with CHCKCLNT REQUIRED (or REQDADM on platforms other than z/OS®), the connection fails. You receive message AMQ9793 on platforms other than z/OS, and message CSQX793E on z/OS.

REQUIRED
Requires that all applications provide a valid user ID and password. See also the following note.
REQDADM
Privileged users must supply a valid user ID and password, but non-privileged users are treated as with the OPTIONAL setting. See also the following note. [z/OS](This setting is not allowed on z/OS systems.)
Note:

Setting CHCKLOCL to REQUIRED or REQDADM means that you cannot locally administer the queue manager by using runmqsc (error AMQ8135: Not authorized) unless the user specifies the -u UserId parameter on the runmqsc command line. With that set, runmqsc prompts for the user's password at the console.

Similarly, a user running IBM® MQ Explorer on the local system will see error AMQ4036 when attempting to connect to the queue manager. To specify a user name and password, right-click the local queue manager object and select Connection Details > Properties... from the menu. In the Userid section, enter the user name and password to be used, then click OK.

Similar considerations apply to remote connections with CHCKCLNT.

CONNAUTH is blank for migrated queue managers but set to SYSTEM.DEFAULT.AUTHINFO.IDPWOS for new queue managers. The preceding AUTHINFO definition has CHCKCLNT set to REQDADM by default.

Therefore, you need to provide the correct operating system password for any existing clients using a privileged user ID to connect.

Warning: In some cases, the password in an MQCSP structure for a client application will be sent across a network in plain text. To ensure that client application passwords are protected appropriately, see MQCSP password protection.

Configuration granularity

In addition to CHCKLOCL and CHCKCLNT that are used to turn on user ID and password checking, there are enhancements to the CHLAUTH rules so that more specific configuration can be made using CHCKCLNT.

You can set the overall CHCKCLNT value to OPTIONAL, for example, and then upgrade it to be more stringent for certain channels by setting CHCKCLNT to REQUIRED or REQDADM on the CHLAUTH rule. By default, CHLAUTH rules will run with CHCKCLNT(ASQMGR) so this granularity does not have to be used. For example: 
DEFINE AUTHINFO(USE.PW) AUTHTYPE(xxxxxx) +
CHCKCLNT(OPTIONAL)
SET CHLAUTH('*') TYPE(ADDRESSMAP) +
ADDRESS('*') USERSRC(CHANNEL) +
CHCKCLNT(REQUIRED)
SET CHLAUTH('*') TYPE(SSLPEERMAP) +
SSLPEER('CN=*') USERSRC(CHANNEL)

Error notification

A diagrammatic representation of failed connection authentication. See text for further details.
An error is recorded if an application does not supply a user ID and password when required to, or supplies an incorrect combination even when it is optional.
Note: When password checking is turned off, by using the NONE option on either CHCKLOCL or CHCKCLNT, invalid passwords are not detected.

Failed authentications are held for the number of seconds specified by the FAILDLAY attribute before the error is returned to the application. This provides some protection from an application repeatedly trying to connect.

The error is recorded in a number of ways:
Application
The application is returned the standard IBM MQ security error, RC2035 - MQRC_NOT_AUTHORIZED.
Administrator
An IBM MQ administrator sees the event reported in the error log and can therefore see that the application was rejected because the user ID and password failed the check, rather than because, for example, there was no connection authority .
Monitoring tool
A monitoring tool can also be notified of the failure, if you turn on authority events by sending an event message to the SYSTEM.ADMIN.QMGR.EVENT queue: 
ALTER QMGR AUTHOREV(ENABLED)
This "Not Authorized" event is a Type 1 connect event, and provides the same fields as other Type 1 events, with an additional field, the MQCSP user ID that was provided. The password is not given in the event message. This means that there are two user IDs in the event message: the ID that the application is running under and the ID that the application presented for user ID and password checking.

Relationship to authorization

See text for details.
You can configure a queue manager to mandate that user IDs and passwords are provided by certain applications as the user ID that the application is running under might not be the same user ID that was presented by the application along with a password when the application opens a queue for output, for example: 
ALTER QMGR CONNAUTH(USE.PWD)
DEFINE AUTHINFO(USE.PWD) +
AUTHTYPE(xxxxxx) +
CHCKLOCL(OPTIONAL) +
CHCKCLNT(REQUIRED) +
ADOPTCTX(YES)
How user IDs and passwords are handled is controlled by the ADOPTCTX attribute on the authentication information object.
ADOPTCTX(YES)
All authorization checks for an application are made with the same user ID that you authenticated by password, by selecting to adopt the context as the application context for the rest of the life of the connection.
Attention: When using ADOPTCTX(YES) and OS user Ids you must ensure that the user Id being adopted does not exceed the maximum length of user IDs. See User IDs for more information.
ADOPTCTX(NO)
An application provides a user ID and password for the purposes of authenticating them at connection time, but then continues by using the user ID that the application is running under for future authorization checks. You might find this option useful when migrating, or if you plan to use other mechanisms, such as channel authentication records, to assign the message channel agent user identifier (MCAUSER).
Attention:

When you use the ADOPTCTX(YES) parameter on an authentication information object, another security context cannot be adopted unless you set the ChlauthEarlyAdopt parameter in the channels stanza of the qm.ini file.

For example, the default authentication information object is set to ADOPTCTX(YES), and the user fred is logged in. The following two CHLAUTH rules are configured:
SET CHLAUTH('MY.CHLAUTH') TYPE(ADDRESSMAP) DESCR('Block all access by
default') ADDRESS('*') USERSRC(NOACCESS) ACTION(REPLACE)
SET CHLAUTH('MY.CHLAUTH') TYPE(USERMAP) DESCR('Allow user bob and force
CONNAUTH') CLNTUSER('bob') CHCKCLNT(REQUIRED) USERSRC(CHANNEL)
The following command is issued, with the intention of authenticating the command as the adopted security context of the user bob:
runmqsc -c -u bob QMGR
In fact, the queue manager uses the security context of fred, not bob, and the connection fails.

For more information about ChlauthEarlyAdopt, see Attributes of the channels stanza.