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 » Clustering » setting authorization properties for the application team

Post new topic  Reply to topic
 setting authorization properties for the application team « View previous topic :: View next topic » 
Author Message
chris boehnke
PostPosted: Tue May 27, 2008 5:55 am    Post subject: setting authorization properties for the application team Reply with quote

Partisan

Joined: 25 Jul 2006
Posts: 369

Hi Guys,
I have 2 QMgrs which are in cluster and both are full repositories. One QMgr, QM1 is running on Linux and the other QMgr, QM2 running on Mainframe.

The QMgr QM1 and an Application called 'A' oth are running on the same machine. The application "A" is trying to connect to QMgr QM1 with the user name "user123" and trying to put a message on a queue called "LOCAL1.QUEUE"

I provided the permissions for the user to connect to the QMgr, QM1
setmqaut -m QM1 -t qmgr -p user123 +all

and

I provided the permissions for the queue, LOCAL1.QUEUE as well.
dspmqaut -m QM1 - n LOCAL1.QUEUE -t q -p user123

When I do a dspmqaut...the user got all the privileges. I did a REFRESH SECURITY as well on the QMgr, QM1

Still the user, user123 is facing AUTHORIZATION ERROR, 2035 reason code in connecting to the QMgr, QM1.

Can anybody suggest any further areas to look in?.

Thanks in advance.
Back to top
View user's profile Send private message
chris boehnke
PostPosted: Tue May 27, 2008 7:39 am    Post subject: the application user should be part of mqm group??? Reply with quote

Partisan

Joined: 25 Jul 2006
Posts: 369

just wanted to know whether the user(application), user123 should be part of mqm group?.
I am wondering if the user, user123 is part of mqm group, that user got all the admin rights for the QMgr, QM1.

Let me know your thoughts..

Thanks.
Back to top
View user's profile Send private message
David.Partridge
PostPosted: Tue May 27, 2008 11:13 pm    Post subject: Reply with quote

Master

Joined: 28 Jun 2001
Posts: 249

1. I suggest as a matter of principle that you authorise to MQ using groups rather than principals. The reason is that on *nix systems when you authorise to a principal, you actually authorise that prinicipal's primary group, which can have unintended consequences.

2. No application user should ever be a member of mqm group, this give them full admin rights on the QMs.

3. Never grant +all on the qmgr or queues, on the qmgr typically you should grant +connect, and +inq only, and on the queue +get or +put or +brw as required and probably +inq.

4. Is the user perchance connecting via a client channel with MCAUSER set?
_________________
Cheers,
David C. Partridge
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed May 28, 2008 3:11 am    Post subject: Reply with quote

Grand High Poobah

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

As well for setting permission I usually start with +allmqi (which gives me a working set) and subtract from there. When using JMS you will always need to have inq as permission.

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » setting authorization properties for the application team
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.