Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
18 replies Latest Post - ‏2013-03-12T23:57:47Z by SystemAdmin
SystemAdmin
SystemAdmin
8523 Posts
ACCEPTED ANSWER

Pinned topic MQ Administrator on z/OS Question

‏2013-02-25T10:32:51Z |
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.

Thanks !
Updated on 2014-03-06T12:04:59Z at 2014-03-06T12:04:59Z by Morag Hughson
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-04T02:50:20Z  in response to SystemAdmin
    Good question.
    http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/sy13770_.htm
    links to
    http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/zs00150_.htm
    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.

    G.
  • amreinm
    amreinm
    1 Post
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-04T13:21:34Z  in response to SystemAdmin
    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)
    • SystemAdmin
      SystemAdmin
      8523 Posts
      ACCEPTED ANSWER

      Re: MQ Administrator on z/OS Question

      ‏2013-03-04T23:55:38Z  in response to amreinm
      >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)

      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?

      G.
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-05T11:09:08Z  in response to SystemAdmin
    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 ?
    • SystemAdmin
      SystemAdmin
      8523 Posts
      ACCEPTED ANSWER

      Re: MQ Administrator on z/OS Question

      ‏2013-03-05T22:53:28Z  in response to SystemAdmin
      It might be worth making a Service Request to IBM to get an official answer for this question. We would all like to know :-)
    • SystemAdmin
      SystemAdmin
      8523 Posts
      ACCEPTED ANSWER

      Re: MQ Administrator on z/OS Question

      ‏2013-03-12T16:05:00Z  in response to SystemAdmin
      There is no concept on z/OS of a privileged user - that is, a user that can do anything without being granted the specific access to do that. All user IDs on z/OS must be granted the specific authority to do the operation they need.

      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.
      Cheers
      Morag
      • SystemAdmin
        SystemAdmin
        8523 Posts
        ACCEPTED ANSWER

        Re: MQ Administrator on z/OS Question

        ‏2013-03-12T23:57:47Z  in response to SystemAdmin
        Morag wrote:
        >*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).

        G.
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-08T14:04:04Z  in response to SystemAdmin
    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.
    • SystemAdmin
      SystemAdmin
      8523 Posts
      ACCEPTED ANSWER

      Re: MQ Administrator on z/OS Question

      ‏2013-03-11T22:26:25Z  in response to SystemAdmin
      In theory, it should make no difference to MQ what security facility is being used on z/OS.
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-12T11:18:44Z  in response to SystemAdmin
    I have pasted below the description of *MQADMIN from the description of the SET CHLAUTH command.

    USERLIST
    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.
    As you can see, on z/OS, if you specify USERLIST('*MQADMIN') it will blcok the CHINIT and MSTR user IDs.

    Cheers
    Morag
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-12T11:26:04Z  in response to SystemAdmin
    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.
    Thanks.
    • SystemAdmin
      SystemAdmin
      8523 Posts
      ACCEPTED ANSWER

      Re: MQ Administrator on z/OS Question

      ‏2013-03-12T14:25:52Z  in response to SystemAdmin
      There is no concept of a privileged user on z/OS. All users have to be explicitly authorised to access any resources they need, unlike the mqm group on distributed.

      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.

      Cheers
      Morag
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-12T14:45:22Z  in response to SystemAdmin
    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
      T.Rob
      30 Posts
      ACCEPTED ANSWER

      Re: MQ Administrator on z/OS Question

      ‏2013-03-12T15:26:16Z  in response to SystemAdmin
      Hi Peter,

      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?

      T.Rob
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-12T15:41:20Z  in response to SystemAdmin
    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 ?
    • SystemAdmin
      SystemAdmin
      8523 Posts
      ACCEPTED ANSWER

      Re: MQ Administrator on z/OS Question

      ‏2013-03-12T16:15:43Z  in response to SystemAdmin
      We have a number of concepts here that are clashing and confusing folks. Let me try to clear these up.

      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).

      Cheers
      Morag
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-12T17:42:24Z  in response to SystemAdmin
    Thanks T-Rob and Morag. I think I have a much better understanding of it now.
  • SystemAdmin
    SystemAdmin
    8523 Posts
    ACCEPTED ANSWER

    Re: MQ Administrator on z/OS Question

    ‏2013-03-12T17:42:40Z  in response to SystemAdmin
    Thanks T-Rob and Morag. I think I have a much better understanding of it now.