There are several different ways to set the credentials used by an IBM MQ server-connection (SVRCONN) channel, and of course they could all interact with each other because you might have several of them turned on in your system. This post aims to discuss all of the different mechanisms and show how they interact.
- Flowed client-side user ID
- Fixed MCAUSER on channel definition
- User ID and password
- CHLAUTH rules setting MCAUSER
- Security exit setting MCAUSER
Morag inspects how the MCAUSER gets set
Flowed client-side user ID
When a client attached application connects to the queue manager, the user ID under which the O/S process on the client machine is running, is flowed up to the queue manager. You can choose to use this user ID if you wish, but generally, you are advised not to trust an unauthenticated client side user ID. Luckily, pretty much everything that follows will over-ride this flowed user ID, so it is not a difficult task to choose to use something else instead.
Fixed MCAUSER on channel definition
The MCAUSER for a running channel can be set with a simple definition. There is an attribute on the SVRCONN channel definition, MCAUSER, which can provide the user ID for the channel to run with. This may be appropriate when combined with something like SSL/TLS certificates and Distinguished Name matching which ensure that this statically defined MCAUSER is only being used by connections that are allowed to connect to this channel. Using a statically defined MCAUSER without some authentication to determine who is allowed to connect to your SVRCONN channel, simply means that everyone who can reach your channel gets to use that user ID and access whatever resources that user ID can work with.
This feature can also be used as a handy trick to ensure that the client flowed ID, mentioned in the first section, is never used. If you define the MCAUSER as ‘rubbish’ then any connection that does not get the MCAUSER set appropriately by one of the next methods cannot connect.
User ID and password
If you are making use of the new IBM MQ V8 feature, Connection Authentication, which checks your user ID and password, you can set up your system so that the user ID that has been authenticated can be used as the running MCAUSER for the SVRCONN channel. You do so by setting ADOPTCTX(YES) on your Authentication Information object that configures Connection Authentication to be used.
ADOPTCTX is a queue manager wide setting and applies to all channels, but you may wish only to do this for some channels. This can be done by combining Connection Authentication with CHLAUTH rules. CHLAUTH rules can be created to determine which channels must supply a user ID and password (the use of CHCKCLNT(REQUIRED) achieves this). Additionally, you must ensure that there isn’t something else over-riding the MCAUSER, by using USERSRC(CHANNEL). For those channels where you don’t want to use the Connection Authentication feature, and you don’t want any client side user ID being adopted you can also ensure this happens with a CHLAUTH rule. You do this by setting the MCAUSER directly in a CHLAUTH rule so that any provided user ID will never be used as the MCAUSER. This shows us that CHLAUTH rules which set the MCAUSER over-ride the adopted user.
CHLAUTH rules setting MCAUSER
Channel Authentication Records (CHLAUTH for short) were added in WebSphere MQ V7.1 and allowed you to set up rules to determine whether connections were allowed to connect at all, and if they were, what MCAUSER they should use. You could make these rules using SSL/TLS Distinguished Names, or IP addresses for example, and then set the required MCAUSER for the connection which matched the rule.
When thinking specifically about MCAUSER, there were two ways to set up a rule. Either apply an MCAUSER, by using USERSRC(MAP) MCAUSER(user-id) or let the channel run with the MCAUSER that it presented by using USERSRC(CHANNEL). In this latter case, that would allow the unauthenticated client-side user ID that we mentioned above be used, or it would allow the authentication user ID which had been password checked be used (and as mentioned above you could ensure that it was mandatory to provide one).
Security exit setting MCAUSER
The above sections show that there are quite a number of different ways to assign the MCAUSER to be used by a particular running instance of a SVRCONN channel. However, if you have some more complicated algorithm that needs to be used to determine the MCAUSER to set, then you always have the fall-back to use a Security Exit. Prior to WebSphere MQ V7.1, security exits were heavily used to do the job now done by CHLAUTH rules, and they are still available to use in combination with all of the above. The security exit wins out over any of the other ways to set exits, so it can take a peek at what was set by other methods and then decide to do something different. A security exit has access to the client-side user ID, the SSL/TLS Distinguished Names, the IP address, the user ID presented with a password, and the currently chosen MCAUSER, and can then set something else if needed.
Summary
There are various ways to ensure the MCAUSER user applied to any inbound client connection is the correct one. The most important thing is to ensure that only those connections which are allowed to use the channel can do so, and thus only the resources that should be available to those connections can be used.
I was prompted to write this blog post as a result of a question asked on the List Server.
Morag Hughson is a Certified IBM MQ Specialist
IBM Certified System Administrator – MQ V8.0
Find her on: 
MQGem Software 
Question: Is this true for an application using JMS instead of the MQI client?
LikeLike
Hi Lawrence, there was once a time when Java clients could not obtain the O/S process user ID, and so you could set the equivalent using the MQEnvironment class. Since (I think) WebSphere MQ V6 though, Java clients have been able to obtain and flow the user ID, so long as you weren’t over-riding it with the MQEnvironment class.
LikeLike
How to define CHLAUTH rule ?
LikeLike
Check out this post which contains Material about IBM MQ – CHLAUTH where there are links to various blog posts and presentations about CHLAUTH.
LikeLike
Hi Morag. After upgrading to MQ V8 on z/OS we have experienced this RACF “error”:
ICH408I USER(SVC_BAT_) GROUP( ) NAME(??? )LOGON/JOB INITIATION - USER AT TERMINAL ........ NOT RACF-DEFINED.
when a Windows application connects to a SVRCONN channel, which HAS an MCA-user defined:
The SVC_BAT_ user is the Windows user, and is not supposed to be defined in RACF.
I have experienced this earlier, but at the time the problem was on a SVRCONN channel with no MCA user defined, and I resolved the problem by defining an MCA-user on the channel.
I am aware, that the RACF message is an “I”-type (Informational), but our MSTR-task gets a lot of these messages, as the Windows clients do a lot of connects.
Can you confirm, that there has been a change in MQ V8 in this area, and is there an easy way to get around it?
LikeLike
Hi again. We have now discovered, what effects MQ V8 to make the RACF call for user validation.
For some reason the Windows user id were defined in the MCAUSER definition of the CHANNEL AUTHENTICATION TYPE(ADDRESSMAP) record. We have now removed the user from the MCAUSER field, and the ICH408I RACF messages have stopped.
LikeLike
I’m glad you’re all sorted. Yes, putting an MCAUSER in a CHLAUTH record that matches has the same effect as setting an MCAUSER on the channel definition (and in fact will override what is in the channel definition’s MCAUSER). Although why it only hit you when you upgraded to IBM MQ V8 is odd.
LikeLike
Hi Morag, we are facing an issue with user id authentication in IBM MQ V7.5. We disabled Channel Authentication for the Queue manager, but even still we are not able to connect to the IBM MQ server with new users (other than mqm). We are getting the below error on the server side.
AMQ5653: The user 'abcdce' is not defined.EXPLANATION:
The system call getpwnam("abcdce") failed with errno -1.
ACTION:
Create the user 'abcdce' and retry the operation.
----- amqzfubx.c : 4061 -----------------------------------------
03/04/2017 09:00:08 PM - Process(13252.84) User(root) Program(amqrmppa)
Host(abcdce-0934394) Installation(Installation1)
VRMF(7.5.0.2) QMgr(QMA)
AMQ9557: Queue Manager User ID initialization failed.
Please help us. How can we connect new clients without using user authentication?
Thanks in Advance.
LikeLike
Hi there,
Please be aware that even if you turn off Channel Authentication in the queue manager, a user ID still flows from the client machine up to the queue manager machine. This will normally be the logged on user from the environment where the client application is running. If there is nothing to over-ride the client machine’s user ID at the queue manager end (as described in the post above) then the client machine’s user ID will be used for Authorization checks. If the user ID from the client machine doesn’t exist on the queue manager machine (which is quite a common occurrence since their user ID domains are likely to be separate) then you will get the error you have seen. The reason it works for the ‘mqm’ user is simply because that user ID is already defined on the queue manager machine as part of the installation of IBM MQ.
If you want to allow un-authenticated clients to connect to your queue manager (ill-advised but certainly possible) you simply need to choose one of the ways described in the above post for over-riding the flowed client user ID, or alternatively define all the possible client flowed user IDs on the queue manager machine.
You would do well to reconsider your choice to turn off Channel Authentication since it is a good way to assign a user ID for a connecting client, and will stand you in good stead when you later do have a requirement for client authentication. There are lots of posts that will help you learn how to use CHLAUTH (see here for a list). You could put in a small number of simple rules for now to allow in your expected client users and while not truly authentication it would be a good start to learning how to use MQ securely.
Cheers
Morag
LikeLike
Hi Morag,
Can you please provide some detail explanation how to over-ride the client machine’s user ID at the queue manager end . if possible please provide the commands how to do that in IBM MQ 7.5 version in Linux environment.
Is there any way to connect IBM MQ manager without client user id and channel authentication is already disabled. if it is not secure also not an issue, what and all need to do in IBM MQ server to connect without user name in IBM MQ 7.5 version. please post the solution if possible to connect MQ server without sending username.
Thanks a lot for your reply.
LikeLike
As the blog post you are commenting against says, there are a number of ways to over-ride the client machine’s user ID at the queue manager end. If you do not want to re-enable Channel Authentication and you do not want it to be secure then the simplest way would be to use a Fixed MCAUSER on channel definition. This can be achieved by setting a user ID in the MCAUSER field that actually exists on the queue manager machine and which has the authority required to do whatever the client needs to do. This is not a way to run securely though and it would be wise for you to learn how to set up your queue manager in a secure manner. There is lots of information about that in the link I gave you in my previous answer.
N.B. You can’t connect without sending a username. All you can do is over-ride what is sent using one of the methods described in this blog post.
LikeLike
In recent recent versions that include APAR IT25839 the CHLAUTH rules will get called after the security exit. For more information see the blog “Behavioural changes to MQ client connections introduced by APAR IT25839”:
https://www-01.ibm.com/support/docview.wss?uid=ibm10725873
LikeLike