Search code examples
ibm-mq

Authorization errors with MQ8 + JDk8

when working JMS sample code , placed in application getting below Authorization errors with MQ8 + JDk8

MQException received while attempting reconnect: Reason Code=2035
 Exception text: com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'.

AMQERR01.LOG says

AMQ8077: Entity 'clientadmin' has insufficient authority to access object
'TLSTEST.QM'.

EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: connect
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.

AMQ9557: Queue Manager User ID initialization failed for 'clientadmin'.

EXPLANATION:
The call to initialize the User ID 'clientadmin' failed with CompCode 2 and Reason
2035.
ACTION:
Correct the error and try again.

Steps performed as below sites and commands , but dint resolve issue

http://www-01.ibm.com/support/docview.wss?uid=swg21680930 http://www-01.ibm.com/support/docview.wss?uid=swg21577137

ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL)
REFRESH SECURITY TYPE(CONNAUTH)
ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(NONE)
REFRESH SECURITY TYPE(CONNAUTH)
ALTER QMGR CHLAUTH(DISABLED)

Resolved with Below commands

Removed 'SecurityPolicy=user' , only set Auth as below and restarted QM

setmqaut -m TLSTEST.QM -t qmgr -p clientadmin +all
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n RECEIVE +all
setmqaut -m TLSTEST.QM -t queue -p clientadmin -n SEND +all

Just want to know , how i can set '+all' in all the queues in qmgr ? will set @ channel level to set for all queues in qmgr ?

Worked-Success with below commands and settings

'SecurityPolicy=user'  
    setmqaut -m TLSTEST.QM -t qmgr -p clientadmin +connect +dsp +inq
    setmqaut -m TLSTEST.QM -t queue -p clientadmin -n RECEIVE +put +get +browse +dsp +inq
    setmqaut -m TLSTEST.QM -t queue -p clientadmin -n SEND +put +get +browse +dsp +inq
Solution

  • AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) will require that if a password is sent that it is a valid password.

    The AMQ8077 error you are getting is because the user does not have permissions to connect to the queue manager.

    You must grant OAM permission to allow clientadmin to connect to the queue manager.

    By default on Linux you can grant MQ OAM permissions only against a group that a user is a member of, in your case a group that clientadmin is a member of. In MQ v8.0 and later if the following setting has been added to the qm.ini you can also grant OAM permission against the user itself:

    Service:
   SecurityPolicy=user

    The above setting is not required, it just allows two different ways to grant OAM permissions. This is documented in the IBM MQ v8.0 Knowledge center page "Principals and groups". This page states:

    UNIX and Linux systems

    ACLs are based on both user IDs and groups and you can use either for authorization.

    With Version 8.0, you can use the user-based model for authorization, and this allows you to use both users and groups. However, when you specify a user in the setmqaut command, the new permissions apply to that user alone, and not any groups to which that user belongs.

    See Installable services for more information.

    When you are using the group-based model for authorization, the primary group to which the user ID belongs is included in the ACL.

    The individual user ID is not included and authority is granted to all members of that group. Because of this, be aware that you can inadvertently change the authority of a principal by changing the authority of another principal in the same group.

    This is documented in the IBM MQ v8.0 Knowledge center page "Installable services". This page states:

    SecurityPolicy=user|group|default

    On UNIX and Linux systems the value specifies whether the queue manager uses user-based or group-based authorization. Values are not case sensitive. If you do not include this attribute, default is used, which uses group-based authorization. Restart the queue manager for changes to become effective.

    To grant OAM permission to connect to the queue manager against a group you can do it either with a MQSC command SET AUTHREC:

    SET AUTHREC PROFILE('self') GROUP('groupname') OBJTYPE(QMGR) AUTHADD(CONNECT,DSP,INQ)

    The same can be accomplished with a command line tool setmqaut:

    setmqaut -m <queue_manager_name> -t qmgr -g groupname +connect +dsp +inq

    To grant OAM permission to connect to the queue manager against the user itself you can do it either with a MQSC command SET AUTHREC:

    SET AUTHREC PROFILE('self') PRINCIPAL('clientadmin') OBJTYPE(QMGR) AUTHADD(CONNECT,DSP,INQ)

    The same can be accomplished with a command line tool setmqaut:

    setmqaut -m <queue_manager_name> -t qmgr -p clientadmin +connect +dsp +inq

    You would need to also grant PUT or GET access to the queue you want to access. The following example using a MQSC command SET AUTHREC is using the principal but you can change it to use a group if required:

    SET AUTHREC PROFILE('QUEUE.NAME') PRINCIPAL('clientadmin') OBJTYPE(QUEUE) AUTHADD(PUT,GET,BROWSE,DSP,INQ)

    The same can be accomplished with a command line tool setmqaut:

    setmqaut -m <queue_manager_name> -t queue -n QUEUE.NAME -p clientadmin +put +get +browse +dsp +inq

    Setting permission on Linux using -p without having SecurityPolicy=user is not recommended. This is because this action does NOT set the permission against the user specified with -p, it instead sets it against the primary group of that user at the time you run the command.

    This can cause various situations, a few examples I can think of are below:

    1. If you have two users with the same primary group and you provide them different access levels, they both end up with the same level of access that resulted from the last setmqaut command that you ran.
    2. Even if you provided them both the same level of access to begin with you may want to remove access from one of the two users and issue a similar command with the permission -remove specified. The result would not be that you removed the access from one of the two users, but you instead removed it from both users.
    3. It is not uncommon for the primary group of a unix account to change. If the user is not also a member of that same group as a secondary group after the change they will loose access to MQ.

    It is also not recommended to provide a non-administrative user with +all, if you do this you might as well add the user to the mqm group and provide them with full MQ administrative authority.

    You should instead provide the user with the specific permissions that are required. I provided in my example a limited set of permissions that should work for most applications.