The chlauth rules provide a specific test for an MQ administrator. The special userid of *MQADMIN can be tested to see if a particular user is an administrator. On AIX I can make a particular user an administrator ( or remove them ) by putting them in the mqm group ( or removing them ).
My question is, what specific test will be applied when determining if a user is an administrator on z/OS ? ( I am a Top Secret user, but I can probably understand an answer provided for a RACF environment ).
The z/OS dataset SCSQPROC(CSQ4INSA) provides channel authentication rules which are similar to the defaults for a new queue manager on AIX ( rules which can be applied to an existing queue manager on z/OS ). These rules include the following:
SET CHLAUTH( '*' ) +
TYPE( BLOCKUSER ) +
USERLIST( '*MQADMIN' ) +
DESCR( 'Default rule to disallow privileged users' )
So it seems that the special userid of *MQADMIN is used on z/OS.
Pinned topic MQ Administrator on z/OS Question
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2014-03-06T12:04:59Z at 2014-03-06T12:04:59Z by Morag Hughson
Re: MQ Administrator on z/OS Question2013-03-04T02:50:20ZThis is the accepted answer. This is the accepted answer.Good question.
which does not list the privileged users for z/OS.
Its possible that this might be the CHIN address space userid on z/OS, as this is what is inherited if MCAUSER is left blank on a channel definition.
amreinm 060000H0N71 Post
Re: MQ Administrator on z/OS Question2013-03-04T13:21:34ZThis is the accepted answer. This is the accepted answer.Yes, there is a special userid of *MQADMIN is used on z/OS.
But it's different from what you might expect- maybe by mistake ?? I checked it again and this is how it works:
A z/OS queue manager takes the started task user from its master address space (*MSTR) as the *MQADMIN id- not the *CHIN user !
I can verify this behavior easily:
I have a z/OS queue manager named MQ13 running with started task (STC) users named as the STCs themselves- MQ13MSTR for the master address space and MQ13CHIN for the Chin address space.
All I need to check is the MQ Explorer, where I can specify the user ID to be associated to the Explorer MQI channel as a parameter in the "Connecton details" section.
I use the (default) SVRCONN channel - SYSTEM.ADMIN.SVRCONN,
and the channel auth blocking rule for blocking *MQADMIN access for any (*) channel is active.
I can connect the Explorer to the queue manager when the connect user ID is set to MQ13CHIN - and I can verify that this ID becomes active as the channel user by displaying the channel status and putting a test message to a queue.
When the Exolorer connet ID is set to MQ13MSTR, the connection is blocked, with the following message issued to the z/OS system log:
+CSQX776I +MQ13 CSQXRESP Channel SYSTEM.ADMIN.SVRCONN from 172.17.36.194 has been blocked due to userid, Detail: MCAUSER(MQ13MSTR) CLNTUSER(MQ13MSTR)
Re: MQ Administrator on z/OS Question2013-03-04T23:55:38ZThis is the accepted answer. This is the accepted answer.
- amreinm 060000H0N7
>+CSQX776I +MQ13 CSQXRESP Channel SYSTEM.ADMIN.SVRCONN from 172.17.36.194 has been blocked due to userid, Detail: MCAUSER(MQ13MSTR) CLNTUSER(MQ13MSTR)
OK, so it looks like the MSTR started task userid is treated as the MQ admin user on z/OS. Morag, can you confirm this?
Re: MQ Administrator on z/OS Question2013-03-05T11:09:08ZThis is the accepted answer. This is the accepted answer.When I access a mainframe queue manager from MQ/Explorer, the userid that is used is the userid from my windows session ( if MCAUSER is blank ), or a resolved userid from either MCAUSER or a chlauth rule. When I do this to access a queue manager on AIX, I can make that userid an admin by putting it into the mqm group of the lpar where the queue manager is running. THe question is, what do I do to make a userid an admin on a z/OS queue mamager ? We are running Top Secret on the mainframe, and we have been making assignments to selected userids. Whatever we have seems to allow the specified user to perform admin functions ( such as create a queue, start a channel, etc. ), but it does nat satisfy the special designation of *MQADMIN when coding a chlauth rule. The userids we have designated as asmins therefore can perform admin functions, but are not recognized as admins by chlauth rules. Either we are doing something wrong, or there is a bug in processing *MQADMIN on the mainframe. I am not an expert in this area, can anyone offer anything on this please ?
Re: MQ Administrator on z/OS Question2013-03-05T22:53:28ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
Re: MQ Administrator on z/OS Question2013-03-08T14:04:04ZThis is the accepted answer. This is the accepted answer.I do have an open PMR on this issue. For the IBMers, the number is 05957,370,000. I do not yet know if there is a bug in the way *MQADMIN is being handled on the mainframe, or if I am doing something wrong, or if the issue pertains to the fact I am using Top Secret ( and not RACF ). I do know that I can have a userid on the mainframe that appears to behave in every way like an administrator, but does not seem to be recognized by the test for *MQADMIN in a chlauth rule, as an administrator. ( consequently it is not being blocked by the default rules ). I opened this thread in case someone out there is using Top Secret and has experienced this issue.
Re: MQ Administrator on z/OS Question2013-03-12T11:18:44ZThis is the accepted answer. This is the accepted answer.I have pasted below the description of *MQADMIN from the description of the SET CHLAUTH command.
A list of up to 100 user IDs which are banned from use of this channel or set of channels. Use the special value *MQADMIN to mean privileged or administrative users. The definition of this value depends on the operating system, as follows:
- On Windows, all members of the mqm group, the Administrators group and SYSTEM.
- On UNIX and Linux, all members of the mqm group.
- On IBM i, the profiles (users) qmqm and qmqmadm and all members of the qmqmadm group, and any user defined with the *ALLOBJ special setting.
- On z/OS, the user ID that the channel initiator and queue manager address spaces are running under.
Re: MQ Administrator on z/OS Question2013-03-12T11:26:04ZThis is the accepted answer. This is the accepted answer.Thanks for your response.
Thus it seems that the use of *MQADMIN has a totally different purpose on z/OS than it does on AIX. On AIX we were told ( by T-Rob I think ) that the purpose was to keep out users who could otherwise perform administrative tasks on the queue manager. It clearly does not have this purpose on z/OS.
Re: MQ Administrator on z/OS Question2013-03-12T14:25:52ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
However, on z/OS one could argue (which is why it is so) that the MSTR and CHINIT user IDs have to have access to various system resources that you wouldn't want your remote users messing with, think the SYSTEM.CHANNEL.SYNCQ for example. Thus, we implied the meaning of *MQADMIN on z/OS to cover these generally more privileged users. If you prefer to allow these users to be asserted remotely, you can of course remove that rule.
Re: MQ Administrator on z/OS Question2013-03-12T14:45:22ZThis is the accepted answer. This is the accepted answer.I will confess that I don't really know how this all works. Mainframe security is handles here by a separate group of people ( our security department ). We provide them with selected userids that we want to have administrative access on a mainframe queue manager, and they code the permissions into Top Secret. This process seems to work, if your userid is one of those we provide to the security group, then you can do such things as create a queue, start a channel, etc. If your userid is not one of those users, then if you try to perform an administrative function ( such as create a queue ), you get a message AMQ4036, and your request cannot be satisfied. Therefore we have what appears to be a group of users who are MQ administrators on z/OS. I don't know how this is coded in Top Secret however.
We handle this in a similar fashion on AIX by putting the users into the mqm group.
Now the *MQADMIN designation can be used to block the privileged users on an AIX system, but it cannot be used to block the privileged users on z/OS.
It is therefore my conclusion that the *MQADMIN designator has a totally different meaning on z/OS than it does on AIX. In order to block a privileged user on z/OS using a chlauth rule, the userid has to be explicitly specified. On AIX, they can be blocked using *MQADMIN.
T.Rob 100000R8QH30 Posts
Re: MQ Administrator on z/OS Question2013-03-12T15:26:16ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
I would disagree with the conclusion that "the *MQADMIN designator has a totally different meaning on z/OS than it does on AIX." On both platforms there are groups and users that are known to be administrative and there are ways to make users administrative without adding them to these groups. The *MQADMIN covers the first case but not the second.
For example, *MQADMIN doesn't care or check that -t queue +crt was granted to the "staff" group on AIX making them all defacto administrators.
On z/OS WMQ knows that the IDs running QMgr processes are administrative and blocks those. Just like AIX, it doesn't know whether a group has been granted -t queue +crt. And if there were groups in z/OS that were mandatory and administrative, it'd block them too. And in that respect it'd act just like on distributed if there were a well-known admin group. However on z/OS no such well-known admin group exists which is the real difference between how z/OS and distributed work with respect to *MQADMIN. One has this group, one does not. But with respect to granting admin access to non-admin groups, *MQADMIN doesn't look for that nor was it intended to do so.
Does that help? Or did I just muddy things up worse?
Re: MQ Administrator on z/OS Question2013-03-12T15:41:20ZThis is the accepted answer. This is the accepted answer.Thank you T-Rob for your response.
It now sounds like we are giving administrative access to MQ users on AIX in a somewhat different way than what we do on z/OS.
On AIX, we simply put them into the mqm group. On z/OS I'm not sure exactly what we do. The end result seems to work in so much as the users we want to be MQ admins on z/OS are in fact admins, and everyone else is not. However it is obvious that on AIX the admins are recognized by the *MQADMIN test, and on z/OS they are not.
You now have me wondering if there may be a different way to make a user an MQ admin on z/OS ( different from whatever it is we are doing now ). I am wondering if there is a different way that will both make the user an administrator on MQ on z/OS and also be recognized by the *MQADMIN test on z/OS. Does anyone know if there is ?
Re: MQ Administrator on z/OS Question2013-03-12T16:05:00ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
If a user is granted specific access to do something, e.g. ALTER a QUEUE, and is not in the mqm group (for example) he is not considered privileged and does not match *MQADMIN. This is true on all platforms.
If you create a user on your AIX machine and do not put it in the mqm group, and then grant it access to +alt a certain queue, that does not make that user privileged. That user is not able to do everything, just what you have explicitly granted him ability to do.
*MQADMIN catches privileged users, those that are able to do everything without explicit access. It is not intended to catch everyone with the slightest smallest explicitly granted ability to do one admin task.
Hope this helps.
Re: MQ Administrator on z/OS Question2013-03-12T16:15:43ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
An MQ Administrator
A person who is able to make administrative changes to MQ, for example, ALTER QLOCAL, STOP CHANNEL, etc.
Authority to allow a user to be an MQ administator
This can either be
1. Explicit by means of a setmqaut command (or RACF, TopSecret, ACF2 profiles on z/OS)
2. Implicit by means of membership of the mqm group. We refer to this as being privileged. In this second case, there is no equivalent on z/OS.
CHLAUTH and the special user ID
The *MQADMIN test checks for privileged users, not for MQ Administrators (see above definition). Since there was no such concept on z/OS however, we defined what that would mean specifically for z/OS (MSTR and CHINIT user IDs).
Re: MQ Administrator on z/OS Question2013-03-12T23:57:47ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
>*MQADMIN catches privileged users, those that are able to do everything without
>explicit access. It is not intended to catch everyone with the slightest smallest
>explicitly granted ability to do one admin task.
That's just what I was about to post....
z/OS MQ doesn't have the immutable concept of UNIX 'MQ super user' mqm and 'MQ super group' mqm. It appears the intent of the *MQADMIN construct was to catch the well-known very powerful MQ admin users on the host OS, and not to catch other lower privileged MQ admin roles (ie. it doesn't search the MQ authority profiles for possible matches).