First issue is that the QMgr must be able to resolve the ID passed to it. That means the ID either is defined locally or in a domain to which the QMgr has access. Normally, permissions are granted on the group and if so then it too must be resolved by the receiving QMgr.
Now comes the question of what, exactly, does the QMgr resolve? When you have a connection from a Windows machine to a QMgr on a Windows machine then the ID that is passed by the channel is the Windows SID which is a Universally Unique Identifier (UUID)and not the text string. Similarly, the group resolves to a Windows SID.
So, for example, you may have an ID called ADMINISTRATEUR defined locally on two Windows boxes and it still fails. The errors will say that the ID presented was ADMINISTRATEUR
and that the ID is not authorized and you can clearly see in the dspmqaut
commands that ADMINISTRATEUR
is authorized. Except what is happening is that ADMINISTRATEUR
on one host has its unique UUID and the account of the same name on the other host has a different UUID and Windows is looking at the UUID and not the text string.
When you have the same ID defined in multiple places, the QMgr must be able to differentiate between them. When it cannot, strange and unusual things occur.
For example, let's say you define a channel with MCAUSER('hatrix')
and then run setmqaut -p hatrix
. Let's further stipulate that the hatrix
ID is not defined locally but rather is defined in both DOMAINA
and DOMAINB
and that when the command is run, the DOMAINA
domain server is first in the search path.
The setmqaut
command resolves the name hatrix
to a UUID defined in DOMAINA
.
Later due to normal activity in the network, DOMAINB
rises to the first spot in the domain search path. Now when the MCAUSER('hatrix')
attempts to connect, the string hatrix
resolves in DOMAINB
which is a different UUID than the one the setmqaut
command resolved. The channel which was connecting normally suddenly throws a 2035 error.
The answer to this problem is to qualify both the setmqaut
command and the MCAUSER
value with the desired domain. For example, setmqaut -p hatrix@DOMAINA
and then MCAUSER('hatrix@DOMAINA')
will work regardless of whether DOMAINA
or DOMAINB
are first in the search path, or even if hatrix
is defined locally on the WMQ host server. (Assuming that hatrix
is indeed defined in DOMAINA
of course.
As a rule, you generally do not want to use the -p option on setmqaut
commands. The only exception is Windows hosts, and then only when the ID is qualified with a domain or server name as shown above.
Finally, leaving the channel's MCAUSER
blank is what allows your Windows ID to flow to the MCA and be used for authorization checks. What you need to realize is that there is no authentication going on. Yes, it's true that the Windows client will send its Windows SID. However if you run a Linux VM on your Windows box and connect with that, there is no SID to pass and so the Windows QMgr falls back to resolving the string value of the ID. That means anyone can connect to that channel as any ID just by asserting the desired ID from a non-Windows client.
So, strongly authenticate administrative connections with certificates. For low-privileged connections, use CHLAUTH rules or an exit to set the MCAUSER
rather than letting it flow through, and then use setmqaut
to make sure that MCAUSER
is not administrative. That means never grant +set
on the QMgr and +crt
on queues to non-admins and avoid +setid, +setall
wherever possible.
For lots more WMQ Security content, please go to t-rob.net.