I have a queue manager QM_TEST created using the following MQSC command:
SET AUTHREC OBJTYPE(QMGR) GROUP('mq-user') AUTHADD(INQ,DSP,CONNECT,SET,SETALL)
SET AUTHREC PROFILE(SYSTEM.MQEXPLORER.REPLY.MODEL) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(INQ,DSP,GET)
SET AUTHREC PROFILE(SYSTEM.ADMIN.COMMAND.QUEUE) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(INQ,DSP,PUT)
DEFINE CHANNEL ($cname) CHLTYPE (SVRCONN) TRPTYPE (TCP) MCAUSER('tcs-mq-user') REPLACE
SET CHLAUTH($cname) TYPE(ADDRESSMAP) ADDRESS(*) MCAUSER('tcs-mq-user')
DEFINE QLOCAL ($dlqname) REPLACE
SET AUTHREC PROFILE($dlqname) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(ALL)
ALTER QMGR DEADQ($dlqname) FORCE
DEFINE LISTENER ($lname) TRPTYPE (TCP) CONTROL (QMGR) PORT ($port)
START LISTENER ($lname)
I have two queues TEST1 and TEST2 created using:
DEFINE QLOCAL ($qname) GET(ENABLED) PUT(ENABLED) MAXDEPTH($maxdepth) REPLACE
SET AUTHREC PROFILE($qname) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(ALL)
I am trying to copy messages from TEST1 to TEST2 using the q program utility:
q -xb -mQM_TEST -iTEST1 -mQM_TEST -oTEST2 -p20
However I get this error:
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May 2 2012 ]
Connecting ...failed. MQCONNX on object 'QM_TEST' returned 2035 Not
authorized..
I am running WebSphere MQ v7.1. q SupportPac is installed on the server and I am executing the q command on the server. I can't figure out a way to pass the channel name TEST_CHANNEL and port number 1414, is that the issue?
The program is connecting to the QMgr in bindings mode via shared memory rather than using the SVRCONN channel. You can verify this by ALTER QMGR AUTHOREV(ENABLED) then looking at the authorization event that is produced in the QMgr event queue. If you have installed SupportPac MS0P you can right-click on the queue and select "Format event messages" to see it in human-readable format. Either way, you should see that the ID being used to connect is not tcs-mq-user but rather whatever ID you are using to run the Q program. Try:
q -lmqic -xc -iTEST1 -oTEST2 -p20
The program will prompt you for the channel details when run with -xc.
The Q program can dump queues to files but it is not designed for that. The QLoad program from SupportPac MO03 is designed for that and will capture all aspects of the message and, if you are suitably authorized, also restore them intact. This includes message ID, timestamp, etc.
Finally, a quick note about the AUTHREC statements in your post. Since you have bothered to create a low-privleged MCAUSER and set authorities for it, I presume that you would like that ID not to have administrative privileges. Please be aware that granting a user +set or +setall on the QMgr allows them to manage authorization records using WMQ Explorer or anything else that uses PCF commands. Consider restricting authorities on the QMgr to +dsp +inq +connect.
Generally, the applications don't get access to the DLQ but rather get access to an application-specific backout queue. If the app is granted access to the DLQ it is usually only to put messages there and not to get them back out. This is because the DLQ is a system-wide resource and if the QMgr is shared, the messages from multiple apps might land in the DLQ. As a security precaution, restrict delete access on that queue to administrators. This way someone cleaning up after their app can't accidentally (or otherwise) delete the messages belonging to another app.
UPDATE:
Reviewing your post, I noticed another discrepancy. I had assumed that you were getting the 2035 Authorization Error because you were connecting in bindings mode with an ID other than mqm or tcs-mq-user. After looking again, I realized that you never authorized the mq-user group to the queues you are trying to access. You authorized it to the Command Queue and the reply model which aren't used in this scenario. (WMQ Explorer uses them.) So, add the following rules:
SET AUTHREC PROFILE(TEST1) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(PUT,GET,INQ,BROWSE)
SET AUTHREC PROFILE(TEST2) OBJTYPE(QUEUE) GROUP('mq-user') AUTHADD(PUT,GET,INQ,BROWSE)
This will solve the auths problem if in fact you are connecting as tcs-mq-user.
There isn't a way to pass the channel to Q on the command line, as far as I know, but it does accept the standard MQSERVER variable. For example:
export MQSERVER="$cname/TCP/localhost($port)"
...where $cname is the channel name and $port is the port. Here's my test:
tcs-mq-user:~> export MQSERVER="TEST.SVRCONN/TCP/localhost(1414)"
tcs-mq-user:~> q -xb -iTEST1 -mQMTEST -lmqic
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May 2 2012 ]
Connecting ...connected to 'JMSDEMO'.
No more messages.
tcs-mq-user:~>
As to why its not finding the client libs, do you have them installed?
tcs-mq-user:~> rpm -qa | grep MQSeriesClient
MQSeriesClient-7.5.0-0
Related
I trying to connect RFHUTIL from my laptop to remote MQ server but its show error
09.43.47 Open for temporary reply queue failed rc=2035
Error getting queue names
Below are from Queue Manager Error Log:
2/26/2021 02:43:44 - Process(2716.35) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(MCP-50-50-1-5) Installation(Installation1)
VRMF(9.1.0.7) QMgr(mq)
Time(2021-02-26T01:43:44.367Z)
RemoteHost(50.50.1.2)
CommentInsert1(g525097#mcp-50-50-1-5)
CommentInsert2(SYSTEM.DEFAULT.MODEL.QUEUE)
CommentInsert3(get)
AMQ8077W: Entity 'g525097#mcp-50-50-1-5' has insufficient authority to access
object 'SYSTEM.DEFAULT.MODEL.QUEUE'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: get
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.
Are you using any SYSTEM.*.SVRCONN channels? Because CHLAUTH rules (on the queue manager) can be blocking you.
RFHUTILC uses your Windows UserId for authentication (MQ v8.0 or higher) and authorization for MQ objects (i.e. queue manager, channels, queues, etc.)
Did your MQAdmin give your UserId, or group which your UserId is in, permission to access the queue manager and the queues?
From the error message you have provided in your question, you need to run the following MQSC command (that is a command issued using the runmqsc tool). If you don't have full authority over this queue manager then I suggest you ask your MQ administrator to run this command. If you do have full authority over this queue manager then make sure you are running the runmqsc tool with the same user id that your started the queue manager with, and that you are running it on the machine where the queue manager resides.
SET AUTHREC PROFILE('SYSTEM.DEFAULT.MODEL.QUEUE') OBJTYPE(QUEUE) GROUP(the-group-that-user-id-g525097-is-in) AUTHADD(GET)
If it still fails after you do this, please post the new error message because it will likely need other permissions and the error message, while similar, will be different.
Try to run this command on queue manager and then try to access
ALTER QMGR CHLAUTH(DISABLED)
I'm experiencing an odd behavior when running basic connectivity tests from my workstation to a remote MQ Server.
I am using amqssslc.exe to connect from a command prompt.
If I connect with nothing but a certificate store, it connects without issue, and returns a result indicating that it connected to the default queue manager, FOO:
C:\Program Files\IBM\MQ\Tools\c\Samples\Bin64>amqssslc.exe -k c:\mycerts\cert
Sample AMQSSSLC start
Connecting to the default queue manager
No client connection information specified.
Using SSL key repository stem c:\mycerts\cert
No OCSP configuration specified.
Connection established to queue manager FOO
Sample AMQSSSLC end
If I attempt to connect to the queue manager FOO, however, it returns a 2058 error, which typically indicates a queue manager name error.
C:\Program Files\IBM\MQ\Tools\c\Samples\Bin64>amqssslc.exe -k c:\mycerts\cert -m FOO
Sample AMQSSSLC start
Connecting to queue manager FOO
No client connection information specified.
Using SSL key repository stem c:\mycerts\cert
No OCSP configuration specified.
MQCONNX ended with reason code 2058
It does this even if I copy the name directly from the result. It fails quickly, and doesn't generate a log entry in my AMQERR01.LOG file.
Does this behavior indicate an issue with my CCDT file?
Update:
Per #JoshMc's suggestion, I ran the following command to get information about the vendor-supplied CCDT file:
echo DIS CHL(*) QMNAME CONNAME|runmqsc -n
The results indicated that no queue manager was specified in the file:
C:\Program Files\IBM\MQ\Tools\c\Samples\Bin64>echo DIS CHL(*) QMNAME CONNAME|runmqsc -n
5724-H72 (C) Copyright IBM Corp. 1994, 2016.
Starting local MQSC for 'MYQUEUE.TAB'.
1 : DIS CHL(*) QMNAME CONNAME
AMQ8414: Display Channel details.
CHANNEL(FOOCHANNEL) CHLTYPE(CLNTCONN)
CONNAME(CONNAME(xxx.xxx.xxx.xxx(1414),xxx.xxx.xxx.xxx(1414))
QMNAME( )
No commands have a syntax error.
If you review the source code located at C:\Program Files\IBM\MQ\Tools\c\Samples\Bin64\amqssslc.c you can see that it does the following:
If no queue manager name is specified it will set the queue manager name to NULL and print Connecting to the default queue manager
If no connection name is specified it will not setup the ClientConn, and ConnectOptions.ClientConnPtr is left at it's default NULL value, it will print No client connection information specified.
If a SSL key repository stem is specified it will set the SslConnOptions.KeyRepository to this value and print out Using SSL key repository stem <stem location> and then point ConnectOptions.SSLConfigPtr to the SslConnOptions.
After all of this it then issues a MQCONNX and specifies the the NULL queue manager name and the ConnectOptions. Because the ConnectOptions.ClientConnPtr is left at the default NULL value MQ will attempt to find the out how to connect to the queue manager via a few different other means. The order and where it looks for connection information is documented at the IBM v7.5 (or later) Knowledge Center page "Connecting IBM WebSphere MQ MQI client applications to queue managers". In your case it is picking up the CCDT file.
When you do not specify a queue manager name it looks for a entry in the CCDT with a blank QMNAME attribute and finds the CLNTCONN channel that you have defined where QMNAME is blank. A blank QMNAME on a CLNTCONN channel is a special case where the MQ client will connect to any queue manager name which is listening at CONNAME that you specify. Because you are specifying the SSL key repository stem it will use this key repository to connect to MQ with the SSLCIPH you have specified on CLNTCONN in the CCDT.
When you do specify the queue manager name FOO, it attempts to find a entry in the CCDT with the QMNAME attribute set to FOO, in your case it does not exist so you receive the 2058 or MQRC_Q_MGR_NAME_ERROR error.
Based on your update the CCDT channel does have a blank QMNAME attribute and the CONNAME lists two different IP(PORT) seperated by a common. With this configuration MQ will attempt first to connect to the first IP, if the connection times out or is ended for some other reason such as the channel on the queue manager being in STOPPED status, it will then attempt to connect to the second IP.
It is very possible they intend for you to connect with a blank or NULL queue manager name due to the benefit that the client will connect to any queue manager name that is listening on the CONNAME, in you case the first IP(PORT) might be queue manager FOO and the second IP(PORT) might be queue manager BAR.
If you want it to work with your CCDT when you specify -m FOO you would need to either create a new CCDT with a CLNTCONN channel with QMNAME(FOO), or add another CLNTCONN channel to your existing CCDT with QMNAME(FOO), note you can not have duplicate channel names in a single CCDT.
For more information on the CCDT and what queue manager name to specify see my answer to "Connecting to IBM MQ using CCDT file in JMS". The answer was related to JMS but the information applies to MQI clients as well.
You also have the option to specify all the details on the command line like Roger said. Run amqssslc.exe ? for usage information, it should look like this:
Sample AMQSSSLC start
Parameters: [-m QMgr]
[-c ChlName -x ConnName]
[-k KeyReposStem] [-s CipherSpec]
[-p any|rfc5280]
[-f] [-b none|128_bit|192_bit[,...] ]
[-o OcspURL]
I'm experiencing an odd behavior when running basic connectivity tests
from my workstation to a remote MQ Server.
Its not the program. You didn't specify enough parameters. Did you issue "amqssslc.exe ?" or look at the source? i.e. amqssslc.c
Where is the channel name? Where is the connection name? Where is the CipherSpec? etc...
This is a follow-up to: Can create Websphere Queue Manager but not connect
I'm trying to set up MQ on a development machine, but if I try to connect to it using my domain account it's unable to authenticate (AMQ4999). Digging a little further I find this in the error logs:
AMQ8079: Access was denied when attempting to retrieve group membership
information for user 'xxx#domain'.
Now I'm well aware of the known issue with MQ where it fails to authenticate domain accounts since it's unable to access their member information, and have confirmed from the logs that this is definitely what's happening here, so I tried overriding this using the following script gleaned from the previous post:
DEFINE CHL('DOTNET.SVRCONN') CHLTYPE(SVRCONN) MCAUSER('MUSR_MQADMIN#hostname')
SET CHLAUTH('DOTNET.SVRCONN') TYPE(BLOCKUSER) USERLIST('nobody')
SET CHLAUTH('DOTNET.SVRCONN') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL) ACTION(ADD)
However, even with this channel in place I still cannot connect to the queue manager while logged into my domain account. I'm still plagued with the exact same error I was getting previously. One thing I did notice was that MQ Explorer reports the channel as inactive even though I started it (although judging by my reading from IBM's website this is normal).
I'm still very new to MQ so I think I'm either missing something or did something wrong, but ideally I would like to be able to set up a dev environment where I can hit the service without having to rely on the 'runas' command. I should also emphasize that this is strictly for dev/learning so obviously I'm not concerned about security.
Update:
I found out what I was doing wrong -- sure enough I was missing a step. A little more background. Upon creating the QM I was trying to connect to it using a simple C# client. Originally I wrote code that looked like this:
var queueManager = new MQQueueManager("MyQueueManager", MQC.MQCNO_STANDARD_BINDING);
Also, when trying to connect via MQExplorer both appears to be using my domain credentials to authenticate. However when I explicitly created a properties object and specified the channel like such:
var props = new Hashtable() {
[MQC.HOST_NAME_PROPERTY] = "localhost",
[MQC.PORT_PROPERTY] = 1414,
[MQC.CHANNEL_PROPERTY] = "DOTNET.SVRCONN",
[MQC.USER_ID_PROPERTY] = "DevMQUser",
[MQC.PASSWORD_PROPERTY] = "p#$$w0rd"
};
var queueManager = new MQQueueManager("MyQueueManager", props);
Then everything worked correctly. I still need to run MQExplorer.exe as a local user (even explicitly setting credentials in Connection Details > Properties doesn't seem to work), but this isn't a big deal.
Thanks for the suggestions.
Try changing...
SET CHLAUTH('DOTNET.SVRCONN') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(CHANNEL)
To...
SET CHLAUTH('DOTNET.SVRCONN') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(MAP) MCAUSER(MUSR_MQADMIN)
The USERSRC(CHANNEL) says to take the ID that is presented to the channel, in this case the local process ID of your logged-in account, to override MCAUSER.
MQ Security diagnostics
For connectivity issues over channels, grab SupportPac MS0P and install into MQ Explorer. Then turn on Authorization Events and Channel Events and recreate the problem. If the connection is blocked by a CHLAUTH record, this shows up in the Channel Event queue. If it is blocked by OAM it shows up in the QMgr Event queue. From Explorer with MS0P installed, right-clicking on the queue name from the Queues panel opens a context dialog that includes "Format event messages" as an option. Select is and MS0P will parse the PCF message into human-readable values that show all the parameters that were presented to MQ and why it blocked the connection.
IBM MQ v8
If this is v8 of MQ, you also have ID and password checking to configure. If the QMgr points to an AUTHINFO record that specifies ID and password checking (IDPWOS) the password can't be blank if the ID is set. Even if the password authentication is set to OPTIONAL the check will be made if an ID is present on the channel, which the client code will ensure is true unless specifically overridden.
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.
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.
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?
I am trying to connect to Websphere MQ 7.1 with Hermes JMS but I am not able to. I have followed their giude, loaded all the jars without problems, set the plugin, set all the variables (hostname, port, transportType, queuemanager), checked the box at the bottom that says user and typed the username and password and after confirming I tried to discover however I get the following message back:
com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2035'.
at
com.ibm.mq.MQManagedConnectionJ11.(MQManagedConnectionJ11.java:233)
at
com.ibm.mq.MQClientManagedConnectionFactoryJ11._createManagedConnection(MQClientManagedConnectionFactoryJ11.java:553) at
com.ibm.mq.MQClientManagedConnectionFactoryJ11.createManagedConnection(MQClientManagedConnectionFactoryJ11.java:593)
at
com.ibm.mq.StoredManagedConnection.(StoredManagedConnection.java:95)
at
com.ibm.mq.MQSimpleConnectionManager.allocateConnection(MQSimpleConnectionManager.java:198)
at
com.ibm.mq.MQQueueManagerFactory.obtainBaseMQQueueManager(MQQueueManagerFactory.java:882)
at
com.ibm.mq.MQQueueManagerFactory.procure(MQQueueManagerFactory.java:770)
at
com.ibm.mq.MQQueueManagerFactory.constructQueueManager(MQQueueManagerFactory.java:719)
at
com.ibm.mq.MQQueueManagerFactory.createQueueManager(MQQueueManagerFactory.java:175)
at com.ibm.mq.MQQueueManager.(MQQueueManager.java:647) at
hermes.ext.mq.MQSeriesAdmin.getQueueManager(MQSeriesAdmin.java:107)
at
hermes.ext.mq.MQSeriesAdmin.discoverDestinationConfigs(MQSeriesAdmin.java:280)
at
hermes.impl.HermesAdminAdapter.discoverDestinationConfigs(HermesAdminAdapter.java:82)
at
hermes.impl.DefaultHermesImpl.discoverDestinationConfigs(DefaultHermesImpl.java:1126)
at
hermes.browser.tasks.DiscoverDestinationsTask.invoke(DiscoverDestinationsTask.java:77)
at hermes.browser.tasks.TaskSupport.run(TaskSupport.java:175) at
hermes.browser.tasks.ThreadPool.run(ThreadPool.java:170) at
java.lang.Thread.run(Thread.java:662)
After a few hours of trial and error and research on the net, it seems that the issue is that it cannot connect due to bad authorization however I am able to connect using Java code (Using same lib MQQueueConnectionFactory) and I am also able to connect using QueueZee with the exact same libraries, get a list of all queues and browse them so I know user authorization issues should not be the problem.
I am running Hermes JMS 1.14 and I tried using both Java 1.6.0_33 and 1.7.0_5. Websphere MQ is running on version 7.1.0.0 and the libraries were gotten from this installation on a remote server.
I tried setting the channel variable to SYSTEM.DEF.SVRCONN which is what I used in QueueZee to get it to work but still the same issue.
Has anybody seen this issue before and hopefully can shed some light in the situation?
At V7.1 the new CHLAUTH rules shut off access to all SYSTEM.* channels except SYSTEM.ADMIN.SVRCONN by default and do not allow any administrative access on any SVRCONN channel by default. In order to diagnose this it would be necessary to know what channel was used, the CHLAUTH rules that are set, the channel definition (in particular, the MCAUSER value) and whether the ID used is in the mqm group.
You didn't mention whether the QueueZee setup was also to a V7.1 QMgr or this one in particular. Taking a wild guess, I'd say that CHLAUTH rules are enabled and that the SYSTEM.DEF.SVRCONN channel is disabled at this point. Recommended steps are to define a new channel whose name doesn't start with SYSTEM. and make sure the ID used is not in the mqm group but is authorized as a non-admin ID.
Alternatively, an ID in the mqm group can be used but you'd have to define a CHLAUTH rule to allow it to work. For example, the default CHLAUTH rule uses CHANNEL(*) BLOCKUSER(*MQADMIN) and you could change that to CHANNEL(THE.NEW.CHL.NAME) BLOCKUSER('nobody'). The new rule would be more specific than the old rule and thus take precedence on your channel. It tells the QMgr to block the user ID 'nobody' but omits any mention of *MQADMIN. Since 'nobody' doesn't have access anyway but since *MQADMIN is not mentioned (and thus not blocked by thei rule) the effect of the rule is to allow admins on this channel.
As a quick, dirty and temporary measure, you can also ALTER QMGR CHLAUTH(DISABLED) to get the same behavior as in v7.0 and earlier QMgrs. Be aware though that this allows anonymous remote admin and remote code execution using the mqm user ID. That's why the default settings were changed. Now you must explicitly provision remote admin access if you need it.
For more on this topic, I recommend the Securing Your QMgr presentation from the IMPACT conference.
Note that the password the app sends in is not checked by the QMgr. The field exists so that channel exits can validate the password against AD, LDAP, etc. Without such an exit, the password is ignored. The user ID passed in by the client is either accepted at face value or modified by the channel's MCAUSER or by CHLAUTH rules.
Finally, when having authorization problems the easiest way to diagnose is to ALTER QMGR AUTHOREV(ENABLED) and then use SupportPac MS0P to decode the PCF messages in WMQ Explorer. The auths errors end up in the QMgr Event queue. Each message tells you the object that failed auths, the API call made against that object, the options of the call and the ID that made the call. Often we find the ID making the call isn't the one we wanted or that the program is using options it isn't authorized for so this can be extremely helpful.
Not really an answer, just a little research on the problem.
I have faced the same problem about hour ago. I am passing the username like domain\sortoflongusername and what i see in systemlog on WSMQ server is that my username is being truncated to 12 symbols.
I'm not really familiar with hermesJMS and soapui at all (just wanted to offer it to our testers to check it out as testing platform), so maybe anyone here does know about roots of this problem.