ChlauthEarlyAdopt and AdoptContext rules behavior in MQ v9.1+

August 8, 2019.

Due to a security vulnerability, IBM changed the order of operations when authenticating users in v9.1. This is important if you setup your security on a prior version and then migrate to v9.1. Your security rules might stop working as you intended. In this post, we will talk about “channel early adoption” setting and how it changes MQ’s authentication mechanism in v9.1.

Current order of operations when MQ authenticates a client connection

The following picture shows a very good high level view of what MQ does when a client attempts a connection.

There are two settings that affect the order of operations and the users MQ will apply them to: ChlauthEarlyAdopt and AdoptContext. I talked about AdoptContext at length in my previous post. ChlauthEarlyAdopt parameter means “whether or not to adopt channel authentication records early”, that is before adopting context of the MQCSP user.

Let’s use an example to illustrate the behavior. Let’s assume an application was started on a Windows box under user id: WindowsServiceAccount and application passed in the MQCSP: app345 / password. Let’s further assume your queue manager is running on RHEL v7.something.

Before v9.1

ChlauthEarlyAdopt = N is the default setting. It means “do not apply channel authentication rules before adopting MQCSP user context”.

If your queue manager is setup with the following:

ChlauthEarlyAdopt = N
AdoptContext = N

Then MQ will perform operations in the following order:

1. The channel authentication rules will be applied to user app345
2. The connection authentication rules will be applied to app345 (sent to LDAP or OS for password check)
3. Lastly, authorization rules will be checked on WindowsServi user, because you instructed the queue manager not to adopt context and only 12 first characters are meaningful to RHEL.

If you set the following:

ChlauthEarlyAdopt = N
AdoptContext = Y

VP of IT’s Guide to Transforming Your Business

This guide provides solutions for a VP of IT in four major areas: Cloud Strategy, Data, DevOps, and Product Development.

Download the Guide

Order of operations:

1. Channel authentication rules will be applied to app345
2. Then connection authentications rules will be applied to app345 (sent to LDAP or OS for password check)
3. Authorization rules will be checked on app345

The following settings:

ChlauthEarlyAdopt = Y
AdoptContext = N

Will produce the following result:

1. Connection authentication rules will be applied to app345 (sent to LDAP or OS for password check)
2. Next, channel authentication rules will be applied to app345.
3. Last, authorization rules will be checked on WindowsServi account.

Last combination:

ChlauthEarlyAdopt = Y
AdoptContext = Y

Will result in the following:

1. Connection authentication rules will be applied to app345 (sent to LDAP or OS for password check)
2. Channel authentication rules will be applied to app345
3. Authorization rules will be checked on app345

Now, let’s look at the same settings in MQ v9.1.

After v9.1

ChlauthEarlyAdopt = Y is the default for NEW queue managers, migrated queue managers keep their original setting.

Let’s look at the first combination of settings:

ChlauthEarlyAdopt = N
AdoptContext = N

Results:

1. Channel authentication rules will be applied to WindowsServi
2. Connection authentication rules will be applied to WindowsServi (sent to LDAP or OS for password check)
3. Authorization rules will be checked on WindowsServi

The order of operations does not change, but the users, MQ is working with, do. Post v9.1, if you don’t adopt the context and don’t apply early adoption of channel authentication rules, MQ will not work with the MQCSP structure at all.

Second set of settings:

ChlauthEarlyAdopt = N
AdoptContext = Y

Will result in:

1. Channel authentication rules will be applied to WindowsServi
2. Connection authentication rules will be applied to WindowsServi (sent to LDAP or OS for password check)
3. Authorization rules will be checked on app345

You’re instructing MQ not to adopt channel authentication rules early, so it will not apply them to the user ID in the MQCSP structure, but to the user ID the application is running under. You’re instructing MQ to do adopt the context of the MQCSP structure user ID for authorization checks; that’s why it will use it for OAM rules.

Next combination of settings:

ChlauthEarlyAdopt = Y
AdoptContext = N

Will produce the following order of operations:

1. Connection authentication rules will be applied to app345 (sent to LDAP or OS for password check)
2. Channel authentication rules will be applied to app345
3. Authorization rules will be checked on WindowsServi

Because of your instruction to adopt channel authentication rules early, MQ will work with user ID in MQCSP structure for channel and connection authentication. Because you’re not adopting context, authorization rules will not be applied to the MQCSP structure user ID.

Last combination of parameters:

ChlauthEarlyAdopt = Y
AdoptContext = Y

Will result in:

1. Connection authentication rules will be applied to app345 (sent to LDAP or OS for password check)
2. Channel authentication rules will be applied to app345
3. Authorization rules will be checked on app345

If we compare pre- and post-v9.1 order of operations and the users MQ is working with, we can clearly see the differences in some of the combinations of the settings.

Be mindful of this when you migrate to MQ v9.1 and have fun!