| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Client on W2K Connecting AIX 4.3 (Error 2035) |
« View previous topic :: View next topic » |
| Author |
Message
|
| ayoung |
 Posted: Fri Dec 20, 2002 11:39 pm Post subject: MQ Client on W2K Connecting AIX 4.3 (Error 2035) |
 |
|
Newbie
Joined: 20 Dec 2002
Posts: 3
Location: Alton, IL
|
Using amqscnxc.exe from my W2K workstation with 5.2 client installed I can connect to any Wintel QMGR but when I attempt to connect to AIX or an OS400 QMGR I receive a Reason Code 2035.
I know what the error is but I am not sure how to allow my W2K workstation to connect to my RS6000 or AS400 QMGRs.
I don't think AIX or OS400 would appreciate me trying to set up Windows domain stuff in their respected security managers.
I know that the solution will be simple and most likely something I overlooked.
_________________
Andy |
|
| Back to top |
|
 |
| VivekMeshram |
| Posted: Mon Dec 23, 2002 8:23 pm Post subject: |
|
|
Voyager
Joined: 25 Mar 2002
Posts: 83
|
Hi Andy,
Check the MCAUSER('mqm') . did you mentioned it. Error Code 2035 means you are not atuorised to connect to QM, Please check your ServerConnetion Channel Parameter for MCAUSER.
_________________
Thanks
Vivek S Meshram.
·IBM Certified Specialist – IBM WebSphere MQ v5.3 / v5.2 |
|
| Back to top |
|
|
| MichaelR |
| Posted: Tue Dec 24, 2002 5:03 am Post subject: 2035 and MQ Client |
|
|
Apprentice
Joined: 20 May 2002
Posts: 37
Location: Tampa
|
Andy,
Contrary to Vivek's post, I would recommend granting *PUBLIC MQCONN permission to your AS/400 QMgr (not sure of comparable AIX value). This enables MQ Client connectivity from all entry points.
You will than have to address the 2035 issue at the MQ Object layer. There are at least 3 ways to address this. First, as Vivek's post indicates, you can define an MCAUSER value. I strongly recomemnd NOT using the MQM and MQADMIN values here. This would expose your entire MQ object base. Keep in mind that ANY MQC connecting via this channel as the MCAUSER would have equal access to the respective MQ objects.
The second approach is to establish a "one to one" relationship at the User Profile level between your MQClients and hosts. Because the MQClient product "encapsulates" the clients logged on or executing UserId in each MQI call, your MQM is validating the permission of your Windows Users. Not a problem if you use some type of Single Signon product. Without SSO, this can become a bit of a pain. This is minimized slightly if you use one of your MQM's as a gateway to the other. Connectivity and access is basically managed at the entry point.
The third approach would be to use MQ Security Exits between the clients and QMgr's. You could dynamically "set" the MCAUSER value from within the Secexit based upon some "user defined/supplied" authentication method.
I've used the 3rd approach where I've defined a specific SVRCONN channel for EVERY MQC connection, each having the specific SYSTEMS UserId of the requesting workstatin definind in the MCAUSER field. I employ a security exit program to validate the requesting clients TCP/IP address, thus "locking" the channel to an inbound IP address. There is a little more MQ Admin (defing SVRCONN channels) involved but it does guard against GENERIC access from any MQC in our network.
Hope this helps!
MichaelR
 |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
