How can i add new user to my queue in WebSphere 7.5 MQ Explorer? I have a 90 day trial version and I don't have a administrator console :/ I don't know why...
I would like to connect to a queue that is placed on my server, but I can't connect with Administrator account.
The MQ Explorer doesn't allow changes to the O/S, so you'll have to create the user in the O/S by other means first.
However, if your user ID exists then you can use MQ Explorer to grant that user access to the queue. Bring up the list of queues in Explorer and then right-click on the queue whose authorities you wish to add the user to. Select Object Authorities -> Manage Authority Records... This will bring up the wizard that allows you to add a group or a user to the queue.
You will also need to allow that user to connect to the queue manager I suspect?
First off, go get the non-expiring version for which the product name is MQ Advanced for Developers. As of this writing, it is available in v7.5 and v8.0 and it is free. If you want support, IBM will let you throw money at them for that but the full-function, non-expiring product is free.
MQ now ships secure by default. When you first create a queue manager it rejects administrative connections over client channels. It would allow non-admin channels over SYSTEM.ADMIN.SVRCONN except that until you explicitly authorize them non-administrators have no rights on the QMgr.
(As of v8.0, the QMgr is also set by default to require ID and password but you needen't worry about this with MQ v7.5.)
If you are using a Linux or Windows QMgr and can start MQ Explorer on the host where the QMgr is installed, connect to the QMgr using bindings mode rather than a channel. If you are using an administrative user ID (one in the mqm group or on Windows also the Administrators group) then bindings mode will work.
If you must connect over a client channel, you will need to set up MQ to allow your administrative connection and/or low-privileged user connections. You can do this by disabling the CHLAUTH rules but that approach is strongly discouraged. Much better to learn how MQ security works than to disable it.
You can also define new CHLAUTH rules that permit the connection. The default CHLAUTH rules look like this:
dis CHLAUTH(*) all
1 : dis CHLAUTH(*) all
AMQ8878: Display channel authentication record details.
CHLAUTH(*) TYPE(BLOCKUSER)
DESCR(Default rule to disallow privileged users)
CUSTOM( ) USERLIST(*MQADMIN)
WARN(NO) ALTDATE(2015-05-28)
ALTTIME(15.10.02)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
DESCR(Default rule to allow MQ Explorer access)
CUSTOM( ) ADDRESS(*)
USERSRC(CHANNEL) CHCKCLNT(ASQMGR)
ALTDATE(2015-05-28) ALTTIME(15.10.02)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
DESCR(Default rule to disable all SYSTEM channels)
CUSTOM( ) ADDRESS(*)
USERSRC(NOACCESS) WARN(NO)
ALTDATE(2015-05-28) ALTTIME(15.10.02)
Note that the first rule says to block admin users on any channel. You can add a new rule that says to block some non-admin user on the channel you want to use for administrators.
runmqsc MYQMGRNAME
DEFINE CHL(MY.ADMIN.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('*NOACCESS') REPLACE
DEFINE CHLAUTH(MY.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(127.0.0.1) USERSRC(CHANNEL)
DEFINE CHLAUTH(MY.ADMIN.SVRCONN) TYPE(BLOCKUSER) USERLIST('*NOBODY')
The DEF CHL command defines a new channel for administrators, and sets the MCAUSER to a value that insures that channel won't start.
The first CHLAUTH rule tells MQ to replace the bad MCAUSER with the one from the connection request provided the request comes from 127.0.0.1 and only for MY.ADMIN.SVRCONN. Fill in your own IP address here. Preferably instead use a certificate instead of an IP address to authenticate the connection.
The second CHLAUTH rule is a bit tricky. There is no 'ALLOW USERS' rule so we have to use a rule of type TYPE(BLOCKUSER). But when we block users we have to provide a non-empty list of them. What we need is a CHLAUTH rule where the channel name is more specific than the default one and with a USERLIST value that does not contain *MQADMIN or your actual user ID. I use *NOBODY here because it makes it obvious that the intent is to not block anybody, and the value can never be an actual user ID.
Defining a channel just for admins to use is considered a Best Practice. Authenticating administrators based on the IP address or hostname is not. Once you get connected with your admin ID and get your QMgr configured, consider learning enough about MQ certificates to strongly authenticate administrator connections. And/or go to a V8.0 QMgr and client where you can log on using a password.
