| Author |
Message
|
| kalali |
 Posted: Tue Jul 16, 2013 6:48 am Post subject: OAM issue for mq objects on multi instance queue maanger |
 |
|
Newbie
Joined: 01 Mar 2011
Posts: 5
|
I have two multi instance queue managers with same name on node 1 and node 2 on windows 2008 servers. These queue managers share the same data and log files on a SAN disk. At any point of time one of the queue manager will be active.
Recently, I have created few mq objects and provided Permissions(OAM) on node1 queue manager. When i stopped the queue manager on node1, queue manager on node2 became active and i could see the mq objects which were created in node1 are available in node2.
However, permissions which i provided for mq objects for a particular user on node1 is not reflected in node2.
below are few more details:
MQ version: 7.0.1
Operating system: Windows 2008 servers
user id: user id created as a local user with domain group.
I expect the permissions which we gave in node1 to reflect in node2 automatically.
can any one help me out to know why the permissions(OAM)is not reflected in node2.
Thanks in advance. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Tue Jul 16, 2013 9:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Local 'UserApple' on server 1 is not the same as local ID 'UserApple' on server 2, even though the names look exactly the same. The Windows SIDs are different for both these IDs and MQ stores the permissions against the SID.
Use a domain user account, not local IDs.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kalali |
| Posted: Tue Jul 16, 2013 10:09 pm Post subject: |
|
|
Newbie
Joined: 01 Mar 2011
Posts: 5
|
Hi Peter,
Thanks for the reply.
actually, the user UserApple is in the group usergroup(usergroup being in domain) and OAM which i provided on node1 is for the group "usergroup".
Below is the command which i ran on node1.
setmqaut -m QMGRNAME -n Queuename -t queue -g usergroup +browse +get +inq +put
Does it still mean that the above OAM wont be reflected in node2.
Thanks for your time. |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Jul 16, 2013 11:56 pm Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Have you refreshed the OAM cache? Without REFRESH SECURITY, the queue manager cannot identify the changes in group / user membership. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 17, 2013 7:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Are both UserApple from Server1 and UserApple from Server2 in that domain group?
As Tibor said, if group memberships change after you ran a setmqaut command you need to refresh MQ security so the new group memberships are recognized.
You should fully qualify that domain group in the setmqaut command in case the same group name exists in another domain or locally on one of your servers.
Save yourself some grief - make UserBanana a domain ID and grant permissions against the domain ID.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Jul 17, 2013 9:26 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| PeterPotkay wrote: |
Are both UserApple from Server1 and UserApple from Server2 in that domain group?
As Tibor said, if group memberships change after you ran a setmqaut command you need to refresh MQ security so the new group memberships are recognized.
You should fully qualify that domain group in the setmqaut command in case the same group name exists in another domain or locally on one of your servers.
Save yourself some grief - make UserBanana a domain ID and grant permissions against the domain ID. |
Peter,
If you are telling them to do:
| Code: |
| setmqaut -m <QmgrName> -g group@domain bla bla bla |
Then that will not work as WMQ resolves all groups locally and if they aren't local, it respond with "AMQ7026: A principal or group name was invalid". |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 17, 2013 8:02 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Does your mq service ID have permissions against the Domain to query domain group membership? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 18, 2013 3:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| JosephGramig wrote: |
Peter,
If you are telling them to do:
| Code: |
| setmqaut -m <QmgrName> -g group@domain bla bla bla |
Then that will not work as WMQ resolves all groups locally and if they aren't local, it respond with "AMQ7026: A principal or group name was invalid". |
I always used fully qualified principles and not groups on Windows only, so I don't have any experience with using fully qualified domains in the setmqaut command, but check this link out:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.ref.adm.doc/q083500_.htm
| Quote: |
-g GroupName
The name of the user group for which to change authorizations. You can specify more than one group name, but each name must be prefixed by the -g flag.
For WebSphere MQ for Windows only, the group name can optionally include a domain name, specified in the following formats:
GroupName@domain
domain\GroupName |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kalali |
| Posted: Thu Jul 18, 2013 9:15 am Post subject: |
|
|
Newbie
Joined: 01 Mar 2011
Posts: 5
|
Hi Tibor,
I didn't do a security refresh rather restarted the queue manager on node2. I believe if we restart the queue manager, i wont need to refresh security explicitly.
Even after the queue manager restart, i couldn't find the OAM on node2.
Issue was fixed, once i execute the OAM and refreshed security on node2 queue manager(same OAM command which was executed on node1).
My main intention of posting this question here is to know the actual reason why the OAM was missing on node2
_________________
Regards,
Praveen. |
|
| Back to top |
|
|
| kalali |
| Posted: Thu Jul 18, 2013 9:31 am Post subject: |
|
|
Newbie
Joined: 01 Mar 2011
Posts: 5
|
Hi Peter,
[You should fully qualify that domain group in the setmqaut command in case the same group name exists in another domain or locally on one of your servers. ]
i think its a gud practice to follow your recommendation. Going forward, we will consider this point.
do you have any idea how the mq in windows stores authorisations when permissions are granted against a group. Does it still store the authorisations against the SID of the user id's in the group to which we granted permissions?
As per the below link, permissions when granted for a user id will be stored against the SID of the user id. I wonder if the mq behavior is same even when we provide permissions against group.[http://www.ibm.com/developerworks/websphere/techjournal/1003_mismes/1003_mismes.html]
_________________
Regards,
Praveen. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 18, 2013 5:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| kalali wrote: |
Issue was fixed, once i execute the OAM and refreshed security on node2 queue manager(same OAM command which was executed on node1) |
And did you fail back to Node 1 at that point to see if things still worked there?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 18, 2013 7:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kalali wrote: |
Issue was fixed, once i execute the OAM and refreshed security on node2 queue manager(same OAM command which was executed on node1) |
And if you dump the authorizations on node1 you will see the group authorized on node 1 and a sid number authorized as well. Same thing happens when you look at the group authorization dump on node 2.
What you have done is authorize the local group on each node. The SID # is just the same group on the other node....
Your mq service ID needs to have the permissions to look up the Domain group membership (this is set up in a policy on the domain server as presumably your mq service account is a domain account).
Then when doing your authorizations you need to specify the domain group (group@domain). This way you should only need to define the authorization on a single node and have it work also on the other node.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Jul 19, 2013 10:27 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 26, 2013 4:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And for V 7.5 make sure you have the right groupModel in the Security Stanza. (Browse the infocenter for it) (globalGroups?)
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kalali |
| Posted: Sun Jul 28, 2013 7:06 am Post subject: |
|
|
Newbie
Joined: 01 Mar 2011
Posts: 5
|
Thanks for all your replies. It really helped to understand the issue better.
Finally, i got to know the root cause of the issue.
in WIndows, MQ stores authourisations against the SID of the user id and the user id's which we created were local. So its obvious that the setmqauth command executed on node1 will not reflect on node2 as the SID of the user will be different on node1 and node2.
as peter suggested, its always better to create the user id as a domain rather a local user. If we create the user id as a doman, authorisations given on node1 will be reflected on node2.
Thanks for all your time.
_________________
Regards,
Praveen. |
|
| Back to top |
|
|
|
|
