ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » MQ Security: MCAUSER on SVRCONN channel

Post new topic  Reply to topic Goto page 1, 2  Next
 MQ Security: MCAUSER on SVRCONN channel « View previous topic :: View next topic » 
Author Message
Sam Uppu
PostPosted: Tue Sep 15, 2009 7:55 am    Post subject: MQ Security: MCAUSER on SVRCONN channel Reply with quote

Yatiri

Joined: 11 Nov 2008
Posts: 610

Hi Guys,
I always confuse with the MCAUSER settings on SVRCONN channels. The below are my understandings. Please correct me if I am wrong anywhere...thanks.

I. Defined a SVRCONN channel with blank MCAUSER
1. If the client app(whatever may be..java/C/Cobol etc) provides the application id in the MQMD of the msg and we(MQ admin) provide the setmqaut permissions for the qmgr and queues, the app will be able to access the qmgr and its queues.

2. If the app doesn't provide the application id in the userid field of MQMD of the incoming msgs, the MQListener process will assign its own UserId for connecting application.. i.e., mqm on UNIX, 'MUSR_MQADMIN' on windows, 'QMQM' for AS/400 etc.

II. Defined a SVRCONN channel with MCAUSER filled with application id 'App1'
1. Whether client application provide the userId or not in the incoming msg, the UserId will be replaced/ overwritten by MQ with the 'App1' for all the incoming messages.

Please correct me if I am wrong anywhere in my understandings.

Thanks.
Back to top
View user's profile Send private message
WMBDEV1
PostPosted: Tue Sep 15, 2009 8:01 am    Post subject: Re: MQ Security: MCAUSER on SVRCONN channel Reply with quote

Sentinel

Joined: 05 Mar 2009
Posts: 888
Location: UK

I'm not so sure about this point....

Sam Uppu wrote:

2. If the app doesn't provide the application id in the userid field of MQMD of the incoming msgs, the MQListener process will assign its own UserId for connecting application.. i.e., mqm on UNIX, 'MUSR_MQADMIN' on windows, 'QMQM' for AS/400 etc.


If the application code doesnt specify the field then (from memory) for the Java and .Net languages (and maybe others); it uses the username of the person running the process rather than the MQListener process just making it run as mqm.

The rest looks ok though
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Sep 15, 2009 8:04 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Sam, everything you wrote is correct.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 15, 2009 8:06 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

The channel receiver process has no access to the user name running the MQ application that put the message on the xmitq.

If a message is given to a channel receiver process (the MCA) that has a NULL userid in the message, then the message is put with the ID that is running the MCA. This is almost always the mqm/MUSR_MQADMIN id.
Back to top
View user's profile Send private message
Sam Uppu
PostPosted: Tue Sep 15, 2009 8:22 am    Post subject: Reply with quote

Yatiri

Joined: 11 Nov 2008
Posts: 610

Thanks for confirming my understandings.

Now,

Lets say we are using the 'App1' in the MCAUSER of SVRCONN channel and provided +connect on Qmgr, put/get/browse permissions on queues for 'App1' id(OAM)

Any malicious application can also access the Qmgr and its queues(put/get/browse) if that app knows the QMgr and its queue names, correct?. To avoid this SSL is only the option or do we have any alternative?. Do we have any security exits from IBM(cost free) which I am not aware of?.

I just wanted to know how you are securing the MQ in your organizations.

Thanks.
Back to top
View user's profile Send private message
WMBDEV1
PostPosted: Tue Sep 15, 2009 8:25 am    Post subject: Reply with quote

Sentinel

Joined: 05 Mar 2009
Posts: 888
Location: UK

mqjeff wrote:
The channel receiver process has no access to the user name running the MQ application that put the message on the xmitq.


I agree with this statement, but I thought that the client libraries (at least in the case of Java and .Net) put it in for you if you did not specify it. I thought (again from memory though) that my messages put from the Java app inherited my userid rather than that used by the channel.

If you tell me i'm still wrong then ill go away and convince myself one way or the other


Last edited by WMBDEV1 on Tue Sep 15, 2009 8:26 am; edited 1 time in total
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 15, 2009 8:26 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Sam Uppu wrote:
Lets say we are using the 'App1' in the MCAUSER of SVRCONN channel and provided +connect on Qmgr, put/get/browse permissions on queues for 'App1' id(OAM)


*Every* app, malicious or not, that can successfully connect to that Channel will ONLY be AUTHORIZED as 'App1'.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 15, 2009 8:28 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

WMBDEV1 wrote:
mqjeff wrote:
The channel receiver process has no access to the user name running the MQ application that put the message on the xmitq.


I agree with this statement, but I thought that the client libraries (at least in the case of Java and .Net) put it in for you if you did not specify it. I thought (again from memory though) that my messages put from the Java app inherited my userid rather than that used by the channel.

If you tell me i'm still wrong then ill go away and convince myself one way or the other


Newer releases of the Java libraries will populate this if they are capable of doing so.

.NET has always done this, afaik. There's never been a way to set the user id to NULL in .NET. It's funny, but .NET has none of the concerns about accessing OS native libraries that Java always had. I can't imagine why.
Back to top
View user's profile Send private message
WMBDEV1
PostPosted: Tue Sep 15, 2009 10:32 am    Post subject: Reply with quote

Sentinel

Joined: 05 Mar 2009
Posts: 888
Location: UK

thanks for the response jeff. I think that backs up the point I was trying to make about the ops point 2.

There may be a subtlety with what is meant by "the app" with one view being just the app code, and the other being the app code + mq client libraries. I was of course referring to the app code alone.

Your point about .net is correct also. I seem to remember getting a 2059 if you tried to explicity set the user Id.
Back to top
View user's profile Send private message
Sam Uppu
PostPosted: Tue Sep 15, 2009 12:48 pm    Post subject: Reply with quote

Yatiri

Joined: 11 Nov 2008
Posts: 610

We tested the below scenario in our development environment but the developer is getting 2035 error.

1. Created a qmgr - QM1 and a queue - LOCAL.QUEUE in it.

2. Defined a JAVA.SVRCONN channel and provided 'App1' application id in the MCAUSER.

Here are the permissions provided to the QMgr and queue:
Entity App1 has the following authorizations for object LOCAL.QUEUE:
get
browse
put
inq


Entity App1 has the following authorizations for object QM1:
inq
connect

A developer was trying to access this queue to put/get from his desktop and he is getting 2035 error.

Can you guys share your thoughts on this..why the developer is getting 2035 though I provided the perms to QMgr/ queue for the App id 'App1'?.

Thanks.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Sep 15, 2009 12:52 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Sam Uppu wrote:
We tested the below scenario in our development environment but the developer is getting 2035 error.

1. Created a qmgr - QM1 and a queue - LOCAL.QUEUE in it.

2. Defined a JAVA.SVRCONN channel and provided 'App1' application id in the MCAUSER.

Here are the permissions provided to the QMgr and queue:
Entity App1 has the following authorizations for object LOCAL.QUEUE:
get
browse
put
inq


Entity App1 has the following authorizations for object QM1:
inq
connect

A developer was trying to access this queue to put/get from his desktop and he is getting 2035 error.

Can you guys share your thoughts on this..why the developer is getting 2035 though I provided the perms to QMgr/ queue for the App id 'App1'?.

Thanks.

When in doubt try refresh security...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Sam Uppu
PostPosted: Tue Sep 15, 2009 12:58 pm    Post subject: Reply with quote

Yatiri

Joined: 11 Nov 2008
Posts: 610

FJ,
That didn't help. Still getting 2035 error.

Any further thoughts?.
Back to top
View user's profile Send private message
Sam Uppu
PostPosted: Tue Sep 15, 2009 1:32 pm    Post subject: Reply with quote

Yatiri

Joined: 11 Nov 2008
Posts: 610

When I try to connect and send a msg from my java client program on my desktop, I am able to send the msg.

My id is part of mqm group. But that should not matter as we are setting the MCAUSER with 'App1' and provided perms to qmgr/queue for the App1 id which should also work for him(developer).

Why the developer is getting 2035 from his desktop?. Not sure what the hell he is doing..
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Sep 15, 2009 2:41 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Sam Uppu wrote:
Why the developer is getting 2035 from his desktop?. Not sure what the hell he is doing..

We don't have a crystal ball either. So turn on Authority Events at the QM and see exactly what is missing. Obviously his app is using an option that you have not allowed, like +set or +passall.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Sep 16, 2009 5:26 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

What do error logs on both qmgr and client reveal?
_________________
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » General IBM MQ Support » MQ Security: MCAUSER on SVRCONN channel
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.