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
- Indicates that the queue manager uses the local operating system to authenticate the user ID and password.
- Indicates that the queue manager uses an LDAP server to authenticate the user ID and password.
IDPWOS and IDPWLDAP are similar in a number of their attributes, which are described here. Other attributes are considered later.
ALTER QMGR CONNAUTH(USE.PW) DEFINE AUTHINFO(USE.PW) + AUTHTYPE(IDPWOS) + FAILDLAY(10) + CHCKLOCL(OPTIONAL) + CHCKCLNT(REQUIRED) REFRESH SECURITY TYPE(CONNAUTH)
USE.PWin the CONNAUTH is a string that matches the AUTHINFO definition.
- Switches off checking.
- 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.
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.
- Requires that all applications provide a valid user ID and password. See also the following note.
- 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. (This setting is not allowed on z/OS systems.)
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 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.
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.
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)
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 application is returned the standard IBM MQ security error, RC2035 - MQRC_NOT_AUTHORIZED.
- 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:
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.
ALTER QMGR AUTHOREV(ENABLED)
Relationship to authorization
ALTER QMGR CONNAUTH(USE.PWD) DEFINE AUTHINFO(USE.PWD) + AUTHTYPE(xxxxxx) + CHCKLOCL(OPTIONAL) + CHCKCLNT(REQUIRED) + 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.
- 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. You might also find it useful to continue using this option, perhaps with client connections, because authorization checks are done by using an assigned message channel agent user identifier (MCAUSER) based on an IP address.
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.
fredis logged in. The following two CHLAUTH rules are configured:
The following command is issued, with the intention of authenticating the command as the adopted security context of the user
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)
In fact, the queue manager uses the security context of
runmqsc -c -u bob QMGR
bob, and the connection fails.
For more information about ChlauthEarlyAdopt, see Attributes of the channels stanza.