MQRC_NOT_AUTHORIZED error while connecting to Websphere MQ 7.1 - ibm-mq

Question

I am "very" new to IBM Websphere Mq, I'll try to give as much details as possible.
I've got Websphere MQ 7.1 installed on Windows server 2003 running on Vmware Workstation. The Host is running Windows 7 with Websphere MQ Client and my ASP.NET application. (My application is supposed to connect to Windows server 2003 Websphere's Queue manager via SVRCONN channel, the Websphere client installed on the host is used just for testing purpose, connecting WMQ Client to WMQ Server results in an AMQ4036 access not authorized error, which leads to conclusion server configuration needed!)
Both System can ping each other and are on the same local network. (did I also mentioned that port 1415 is opened and TCP listener is running on the server virtual machine?)
ASP.NET code segment :
queueManager = new MQQueueManager(queueManagerName, queueProperties);
with queueManagerName matching the server's queue manager and queueProperties as following:
queueProperties[MQC.HOST_NAME_PROPERTY] = "192.168.203.128";
queueProperties[MQC.PORT_PROPERTY] = 1415;
queueProperties[MQC.CHANNEL_PROPERTY] = "QM_TEST.SVRCONN";
queueProperties[MQC.USER_ID_PROPERTY] = "";
queueProperties[MQC.PASSWORD_PROPERTY] = "";
when compiling I get the MQRC_NOT_AUTHORIZED exception and this following logs in AMQERR01.log on server side (NOTE: The IBM WMQ is installed in french language, the logs are generated in french, but I think you'll manage to understand the error.)
3/04/2013 21:32:25 - Process(1120.3) User(MUSR_MQADMIN) Program(amqzmur0.exe)
Host(HATRIXX-82HDFHA) Installation(Installation1)
VRMF(7.1.0.2) QMgr(QM_TEST)
AMQ6287: WebSphere MQ VC:\Program Files\IBM\WebSphere MQ (Installation1).
EXPLICATION :
Informations système WebSphere MQ :
Produit :- Windows Server 2003, Build 3790: SP1 (MQ Windows 32-bit)
Version :- C:\Program Files\IBM\WebSphere MQ (Installation1)
Informations hôte :- 7.1.0.2 (p710-002-121029)
ACTION :
Aucun(e).
-------------------------------------------------------------------------------
13/04/2013 21:32:25 - Process(2128.11) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(HATRIXX-82HDFHA) Installation(Installation1)
VRMF(7.1.0.2) QMgr(QM_TEST)
AMQ8075: L'autorisation a échoué car il est impossible d'obtenir le SID de
l'entité 'hatrix'.
EXPLICATION :
Le gestionnaire des droits d'accès aux objets n'a pas pu obtenir le SID de
l'entité spécifiée. Cet incident peut être dû à l'absence de la machine locale
du domaine (l'entité ne peut donc pas être localisée) ou à l'inexistence de
l'entité.
ACTION :
Vérifiez que l'entité est valide et que tous les contrôleurs de domaine requis
sont disponibles. Il peut être nécessaire de créer l'entité sur la machine
locale.
----- amqzfubn.c : 2227 -------------------------------------------------------
13/04/2013 21:32:25 - Process(2524.7) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(HATRIXX-82HDFHA) Installation(Installation1)
VRMF(7.1.0.2) QMgr(QM_TEST)
AMQ9245: Impossible d'extraire des détails de compte pour l'ID utilisateur de
canal MCA.
EXPLICATION :
WebSphere MQ n'a pas pu extraire des détails de compte pour l'ID utilisateur de
canal MCA Hatrix. Il s'agit de l'ID utilisateur MCA pour le canal
QM_TEST.SVRCONN sur le gestionnaire de files d'attente QM_TEST. Il peut avoir
été défini dans la définition de canal ou fourni par un exit de canal ou un
client.
ACTION :
Vérifiez que l'ID utilisateur est correct et qu'il est défini dans le système
local Windows, le domaine local ou un domaine de confiance. Dans le cas d'un ID
utilisateur de domaine, assurez-vous que que tous les contrôleurs de domaines
nécessaires sont disponibles.
----- cmqxrsrv.c : 1778 -------------------------------------------------------
13/04/2013 21:32:25 - Process(2128.11) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(HATRIXX-82HDFHA) Installation(Installation1)
VRMF(7.1.0.2) QMgr(QM_TEST)
AMQ8073: Echec de l'autorisation. Le SID ((None)) n'a pas pu être corrélé.
EXPLICATION :
Le gestionnaire de droits d'accès aux objets n'a pas pu faire correspondre le
SID spécifié à des informations connues d'entité et de domaine.
ACTION :
Assurez-vous que l'application fournit un SID reconnu sur ce système, que tous
les contrôleurs de domaines nécessaires sont disponibles et que les règles de
sécurité sont correctement définies.
----- amqzfubn.c : 4351 -------------------------------------------------------
DISPLAY CHLAUTH(QM_TEST.SVRCONN) command returns:
CHLAUTH(QM_TEST.SVRCONN) TYPE(USERMAP)
DESCR( ) CUSTOM( )
ADDRESS(*) CLNTUSER(HATRIX)
MCAUSER( ) USERSRC(CHANNEL)
WARN(NO) ALTDATE(2013-04-13)
ALTTIME(13.53.03)
AMQ8878: Affichage des détails relatifs à l'enregistrement d'authentification de
canal.
CHLAUTH(QM_TEST.SVRCONN) TYPE(USERMAP)
DESCR( ) CUSTOM( )
ADDRESS(*) CLNTUSER(MQM)
MCAUSER( ) USERSRC(CHANNEL)
WARN(NO) ALTDATE(2013-04-13)
ALTTIME(13.57.59)
AMQ8878: Affichage des détails relatifs à l'enregistrement d'authentification de
canal.
CHLAUTH(QM_TEST.SVRCONN) TYPE(ADDRESSMAP)
DESCR( ) CUSTOM( )
ADDRESS(*) MCAUSER(ADMINISTRATEUR)
USERSRC(MAP) WARN(NO)
ALTDATE(2013-04-13) ALTTIME(01.53.52)
(note that i have added couple rules, and USERID Hatrix does not exist, i have included it in a SET CHLAUTH command for testing purpose)
I thought it has to do with MCAuser so I gave it a try with the MCAuser set to "Administrateur" (which is the admin's name on WMQ) and connecting with:
queueProperties[MQC.USER_ID_PROPERTY] = "Administrateur";
Still gives me the same error but with different server side log output:
13/04/2013 21:41:18 - Process(1120.3) User(MUSR_MQADMIN) Program(amqzmur0.exe)
Host(HATRIXX-82HDFHA) Installation(Installation1)
VRMF(7.1.0.2) QMgr(QM_TEST)
AMQ6287: WebSphere MQ VC:\Program Files\IBM\WebSphere MQ (Installation1).
EXPLICATION :
Informations système WebSphere MQ :
Produit :- Windows Server 2003, Build 3790: SP1 (MQ Windows 32-bit)
Version :- C:\Program Files\IBM\WebSphere MQ (Installation1)
Informations hôte :- 7.1.0.2 (p710-002-121029)
ACTION :
Aucun(e).
-------------------------------------------------------------------------------
13/04/2013 21:41:18 - Process(2524.8) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(HATRIXX-82HDFHA) Installation(Installation1)
VRMF(7.1.0.2) QMgr(QM_TEST)
AMQ9776: La canal a été bloqué par l'ID utilisateur.
EXPLICATION :
Le canal entrant 'QM_TEST.SVRCONN' a été bloqué à partir de l'adresse
'192.168.203.1' parce que les valeurs actives du canal étaient mappées sur un
ID utilisateur qui devrai t être bloqué. Les valeurs actives du canal étaient
**'MCAUSER(Administrateur) CLNTUSER(Hatrix)'.**
ACTION :
Prenez contact avec l'administrateur système qui examinera les enregistrements
d'authentification de canal pour s'assurer que les paramètres corrects ont été
configurés. Le commutateur ALTER QMGR CHLAUTH permet de contrôler si les
enregistrements d'authentification de canal sont utilisés. La commande DISPLAY
CHLAUTH peut être utilisée pour interroger les enregistrements
d'authentification de canal.
----- cmqxrmsa.c : 1004 -------------------------------------------------------
13/04/2013 21:41:18 - Process(2524.8) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(HATRIXX-82HDFHA) Installation(Installation1)
VRMF(7.1.0.2) QMgr(QM_TEST)
AMQ9999: Le canal 'QM_TEST.SVRCONN' vers l'hôte 'FAIROUZ (192.168.203.1)' s'est
terminé anormalement.
EXPLICATION :
Le programme du canl s'exécutant sous l'ID processus 2524(488) pour le canal
'QM_TEST.SVRCONN' a pris fin anormalement. Le canal est 'FAIROUZ
(192.168.203.1)'. Dans certains cas, son nom ne peut pas être déterminé et il
est représenté par '????'.
ACTION :
Examinez les messages d'erreur précédents du programme de canal dans les
journaux des erreurs afin de déterminer la cause de l'incident. Notez que ce
message peut être totalement exclus ou supprimé en réglant les attributs
"ExcludeMessage" ou "SuppressMessage" sous la strophe "QMErrorLog" dans le
fichier qm.ini. D'autres informations figurent dans le guide d'administration
du système.
----- amqrmrsa.c : 925 --------------------------------------------------------
What I couldn't understand is, what's the use of USERID and PASSWORD in the queuemanager properties in ASP.NET where the USERID identified in WMQ is "Hatrix" (which is the windows 7 account's name).
Do I have to create a new USERID "Hatrix" in WMQ in order to make my code works? (i couldn't figured out how )
Thanks in advance,
MqDebug.

Answer 1

First issue is that the QMgr must be able to resolve the ID passed to it. That means the ID either is defined locally or in a domain to which the QMgr has access. Normally, permissions are granted on the group and if so then it too must be resolved by the receiving QMgr.
Now comes the question of what, exactly, does the QMgr resolve? When you have a connection from a Windows machine to a QMgr on a Windows machine then the ID that is passed by the channel is the Windows SID which is a Universally Unique Identifier (UUID)and not the text string. Similarly, the group resolves to a Windows SID.
So, for example, you may have an ID called ADMINISTRATEUR defined locally on two Windows boxes and it still fails. The errors will say that the ID presented was ADMINISTRATEUR and that the ID is not authorized and you can clearly see in the dspmqaut commands that ADMINISTRATEUR is authorized. Except what is happening is that ADMINISTRATEUR on one host has its unique UUID and the account of the same name on the other host has a different UUID and Windows is looking at the UUID and not the text string.
When you have the same ID defined in multiple places, the QMgr must be able to differentiate between them. When it cannot, strange and unusual things occur.
For example, let's say you define a channel with MCAUSER('hatrix') and then run setmqaut -p hatrix. Let's further stipulate that the hatrix ID is not defined locally but rather is defined in both DOMAINA and DOMAINB and that when the command is run, the DOMAINA domain server is first in the search path.
The setmqaut command resolves the name hatrix to a UUID defined in DOMAINA.
Later due to normal activity in the network, DOMAINB rises to the first spot in the domain search path. Now when the MCAUSER('hatrix') attempts to connect, the string hatrix resolves in DOMAINB which is a different UUID than the one the setmqaut command resolved. The channel which was connecting normally suddenly throws a 2035 error.
The answer to this problem is to qualify both the setmqaut command and the MCAUSER value with the desired domain. For example, setmqaut -p hatrix#DOMAINA and then MCAUSER('hatrix#DOMAINA') will work regardless of whether DOMAINA or DOMAINB are first in the search path, or even if hatrix is defined locally on the WMQ host server. (Assuming that hatrix is indeed defined in DOMAINA of course.
As a rule, you generally do not want to use the -p option on setmqaut commands. The only exception is Windows hosts, and then only when the ID is qualified with a domain or server name as shown above.
Finally, leaving the channel's MCAUSER blank is what allows your Windows ID to flow to the MCA and be used for authorization checks. What you need to realize is that there is no authentication going on. Yes, it's true that the Windows client will send its Windows SID. However if you run a Linux VM on your Windows box and connect with that, there is no SID to pass and so the Windows QMgr falls back to resolving the string value of the ID. That means anyone can connect to that channel as any ID just by asserting the desired ID from a non-Windows client.
So, strongly authenticate administrative connections with certificates. For low-privileged connections, use CHLAUTH rules or an exit to set the MCAUSER rather than letting it flow through, and then use setmqaut to make sure that MCAUSER is not administrative. That means never grant +set on the QMgr and +crt on queues to non-admins and avoid +setid, +setall wherever possible.
For lots more WMQ Security content, please go to t-rob.net.

Answer 2

Use setmqaut to assign permission to "Hatrix" UserID but it is better to do it against a group rather than a UserID.

Answer 3

fixing...the command is
setmquat -m qmgrname -t qmgr -p username +allqmi
whrere:
qmgrname is the name of qmgr
username is the account name under eclipse is running and that account is not in ban list.