| Author |
Message
|
| ranjha100 |
 Posted: Thu Jul 05, 2012 3:32 pm Post subject: Websphere MQ .Net help code 2035 = Not Authorized |
 |
|
Novice
Joined: 05 Jul 2012
Posts: 15
|
I am trying to connect to Websphere MQ 7.0.1.4 server running on SunOS 5.10 using C# code.
MQQueueManager queueManager = new MQQueueManager("QM_testmgr", "mychannel", "host");
However, I am getting code 2035 = Not Authorized.
When I try to connect through Java code, I am able to make the connection without any errors.
I read somewhere that when connecting through .net, the MCA of the remote channel has to be set.
My question is how do I do that on the server side on SunOS. I am not very good with UNIX but I have access to the machine to submit whatever commands I need to. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Jul 05, 2012 6:56 pm Post subject: Re: Websphere MQ .Net help code 2035 = Not Authorized |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
| ranjha100 wrote: |
I am trying to connect to Websphere MQ 7.0.1.4 server running on SunOS 5.10 using C# code.
MQQueueManager queueManager = new MQQueueManager("QM_testmgr", "mychannel", "host");
However, I am getting code 2035 = Not Authorized.
When I try to connect through Java code, I am able to make the connection without any errors.
I read somewhere that when connecting through .net, the MCA of the remote channel has to be set.
My question is how do I do that on the server side on SunOS. I am not very good with UNIX but I have access to the machine to submit whatever commands I need to. |
Use MQExplorer to do that... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| ranjha100 |
| Posted: Sun Jul 08, 2012 12:22 pm Post subject: Re: Websphere MQ .Net help code 2035 = Not Authorized |
|
|
Novice
Joined: 05 Jul 2012
Posts: 15
|
| fjb_saper wrote: |
Use MQExplorer to do that... |
i am a newbie with UNIX, how do you use MQExlorer in Solaris? I can login to the machine using Putty, but don't know what commands to submit. Any help will be appreciated.
Thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Jul 08, 2012 1:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
You use the MQExplorer from windows to attach to the Solaris QMGR. Presumably on a channel you have authority on...
Then setup the parameters for your channel...
Otherwise look at the setmqaut command. Ask your MQ Admin to run it on solaris... and remember to work at group level and not principal level...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| WBI_User21 |
| Posted: Fri Jul 13, 2012 2:45 am Post subject: |
|
|
Voyager
Joined: 12 Jun 2007
Posts: 98
|
.net application always send user-id under which application is running while establishing connection to the QMGR (if you are not setting user-id in the code explicitly). QMGR OAM checks if user-id is authorised to connect to QM before granting connection.
You can follow one of these methods to get rid of 2035 error:
1. Add application userid in mqm group on UNIX server and refresh security on QMGR. This will grant application userid admin privleges (i.e app can perfor ALTER and DELETE operation on MQ objects) which is a risk.
2. You can add application userid in MCA user attribute of server connection channel
ALTER CHL(<CHLNAME>) chltype(SVRCONN) mcauser('<APPUSERID>')
3. Or you can have different unix group created on MQ server and grant restricted privileges (i.e MQCONN/X,MQPUT,MQOPEN,MQGET, MQCMIT etc )to the group using setmqaut command and have application userid added in the group...
4. Consider SSL... |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jul 13, 2012 5:44 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| WBI_User21 wrote: |
| 1. Add application userid in mqm group on UNIX server and refresh security on QMGR. This will grant application userid admin privleges (i.e app can perfor ALTER and DELETE operation on MQ objects) which is a risk. |
NO! Don't ever suggest this, even with the qualification you provided.
| WBI_User21 wrote: |
| 3. Or you can have different unix group created on MQ server and grant restricted privileges (i.e MQCONN/X,MQPUT,MQOPEN,MQGET, MQCMIT etc )to the group using setmqaut command and have application userid added in the group |
This was closer and should have been your first suggestion. No application IDs should ever be in any group that has any form of administrative control, limited or otherwise.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| WBI_User21 |
| Posted: Mon Jul 16, 2012 12:37 pm Post subject: |
|
|
Voyager
Joined: 12 Jun 2007
Posts: 98
|
Thanks exerk ...
I understand the risk. But other 2 solutions are much complicated and demands UNIX admin skills. Consider an env. where queue mgr is accessed in client mode shared across multiple applications (50 +) for different environments . I need to create 50 + different groups and add them into UNIX group with restricted privileges on MQ or we need to run setmqaut against each queue and run this whenever new interface is deployed.
I would prefer to add user in mqm group and enable config events on the queue manager and trap the application and raise high alert if there is any attempt to modify or tamper QM objects. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Jul 16, 2012 12:43 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| WBI_User21 wrote: |
Thanks exerk ...
I understand the risk. But other 2 solutions are much complicated and demands UNIX admin skills. Consider an env. where queue mgr is accessed in client mode shared across multiple applications (50 +) for different environments . I need to create 50 + different groups and add them into UNIX group with restricted privileges on MQ or we need to run setmqaut against each queue and run this whenever new interface is deployed. |
Script it!
| WBI_User21 wrote: |
| I would prefer to add user in mqm group and enable config events on the queue manager and trap the application and raise high alert if there is any attempt to modify or tamper QM objects. |
By the time you've trapped the attempt it will already be too late. Re-arrange the following words into a well known phrase: door, bolting, horse, stable, the, after etc.
Being an admin is about making life easy - and you can't do that when the security people are shining a very bright light in your face and asking you why and how the security breach happened.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| WBI_User21 |
| Posted: Mon Jul 16, 2012 1:00 pm Post subject: |
|
|
Voyager
Joined: 12 Jun 2007
Posts: 98
|
| Thanks again .. I don't disagree and security is paramount. Our project do follow complex process for .. though we have trusted applications and api's used in app. are controlled and distributed by MQ admins. There should have been easier way to do this. In my opinion, IBM should have come up with unix/windows group with restricted privileges (like mquser with dis/connect/open/put/get/cmit/rollback permission only) which is in-built in the product itself. This would have made life of mq admins easy .. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 16, 2012 1:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WBI_User21 wrote: |
| I would prefer to add user in mqm group and enable config events on the queue manager and trap the application and raise high alert if there is any attempt to modify or tamper QM objects. |
So you do prefer to have a lock on the door to your house, or just leave the door open and have a really good alarm that reports to the police that something's just been stolen?
I put it to your that your audit & security people will be unimpressed by your ability to determine when fraud has occured & will insist you instead take some measures to prevent it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 16, 2012 1:11 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WBI_User21 wrote: |
| though we have trusted applications and api's used in app. are controlled and distributed by MQ admins. |
So does every large organization, yet they still take the time and effort to set up security properly.
| WBI_User21 wrote: |
| There should have been easier way to do this. |
There is. It's called "scripting".
| WBI_User21 wrote: |
| In my opinion, IBM should have come up with unix/windows group with restricted privileges (like mquser with dis/connect/open/put/get/cmit/rollback permission only) which is in-built in the product itself. |
They did. There's a specific option in the setmqauth command to set that group of permissions to a group. As to setting up such groups at install time, how much effort is that to do this post-install with a script?
The answer is "not much", because I've done it a number of times.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WBI_User21 |
| Posted: Mon Jul 16, 2012 1:37 pm Post subject: |
|
|
Voyager
Joined: 12 Jun 2007
Posts: 98
|
Thanks for criticism .. I don't deny that scripting is easier. I do it in my project too ...and there is little overhead of book keeping which can't be avoided ...
But let me put couple of points on the table which might put the things in perspective. If you have happened to work on Oracle database administration - you will realise that point I am trying to make. Oracle installer checks for two UNIX groups dba, dboperator groups (sorry - I don't remember exact group names). By default installer grants users in dba gets SYSDBA privileges on database where as users in dboperator will have lesser privileges which is required to connect to database.
Why not have similar mechanism in MQ!!
I am trying to compare Oracle and MQ security aspects .. and seems to be Oracle has got much better and easier approaches.
I know that Oracle and MQ are different products with different purposes .. but security aspect is no different. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 16, 2012 2:28 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
| WBI_User21 wrote: |
| I know that Oracle and MQ are different products with different purposes .. but security aspect is no different. |
You are wrong.
I refer you to the WMQ Security manual (or InfoCenter equivalent).
Do you grant root authority to everyone? It would certainly be easier than creating application-oriented groups - each with appropriate (limited) permissions?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 16, 2012 8:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
Compare this:
By default users not in an MQ admin group or connecting remotely (V 7.5) have NO access granted to them!...
So you tell me, which is the more secure product, WMQ or Oracle?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Jul 16, 2012 11:35 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
You're comparing apples and oranges - Oracle is a database, WMQ is not. As with any differing products, some aspects of security will be common, but far more will not be.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
