| Author |
Message
|
| harghgh |
 Posted: Mon Dec 14, 2015 12:15 pm Post subject: Authority lost after failover on MSCS |
 |
|
Novice
Joined: 26 Jun 2012
Posts: 12
|
The authority on specific objects lost after fail over of resources on MSCS.
We have queue manger configured on MSCS. Client applications are getting connected.
If queue is created on node 1 and authorization is provided. After the fail over to node 2 the authority are lost for this user on this queue. No authority remains for this user.
If again do the fail back to node 1 the authority are as it is. All the users are domain users.
Below are the logs getting generated in the error logs.
AMQ8077: Entity 'user1@domain' has insufficient authority to access object
'ABC'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: put
Need help to troubleshoot the same. Running MQ v8.0.0.4 on windows 2008R2. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Dec 14, 2015 12:35 pm Post subject: Re: Authority lost after failover on MSCS |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| harghgh wrote: |
| Need help to troubleshoot the same. Running MQ v8.0.0.4 on windows 2008R2. |
Your MCSC configuration is hosed. Even though these are domain users, node 2 doesn't believe those are the authorized users. I would suspect a SID / registry problem.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| harghgh |
| Posted: Mon Dec 14, 2015 12:46 pm Post subject: Re: Authority lost after failover on MSCS |
|
|
Novice
Joined: 26 Jun 2012
Posts: 12
|
| Vitor wrote: |
| harghgh wrote: |
| Need help to troubleshoot the same. Running MQ v8.0.0.4 on windows 2008R2. |
Your MCSC configuration is hosed. Even though these are domain users, node 2 doesn't believe those are the authorized users. I would suspect a SID / registry problem. |
Thanks for reply. Is there any simple test I can perform to ensure there is problem with the SID for any user for which I am getting problem. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 14, 2015 12:56 pm Post subject: Re: Authority lost after failover on MSCS |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| harghgh wrote: |
| Is there any simple test I can perform to ensure there is problem with the SID for any user for which I am getting problem. |
No idea. Post the same question in an MCSC forum; you're likely to get better answers.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 14, 2015 1:12 pm Post subject: Re: Authority lost after failover on MSCS |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| harghgh wrote: |
| Vitor wrote: |
| harghgh wrote: |
| Need help to troubleshoot the same. Running MQ v8.0.0.4 on windows 2008R2. |
Your MCSC configuration is hosed. Even though these are domain users, node 2 doesn't believe those are the authorized users. I would suspect a SID / registry problem. |
Thanks for reply. Is there any simple test I can perform to ensure there is problem with the SID for any user for which I am getting problem. |
Yes. Make sure that the ONLY local group you are using is the local mqm group. All other groups need to be domain groups. ALL users need to be domain users. Especially the service user. And it needs to have all those spiffy extra attributes as described in the doc... (allow domain query of group membership etc...)
Have the domain mqm group a member of the local mqm group on both sides!.
And check your group model in the security stanza! Make sure it is global!
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| blorro |
| Posted: Thu Jan 21, 2016 7:59 am Post subject: Re: Authority lost after failover on MSCS |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
Yes. Make sure that the ONLY local group you are using is the local mqm group. All other groups need to be domain groups. ALL users need to be domain users. Especially the service user. And it needs to have all those spiffy extra attributes as described in the doc... (allow domain query of group membership etc...)
Have the domain mqm group a member of the local mqm group on both sides!.
And check your group model in the security stanza! Make sure it is global!
Been working on a similar issue for quite some time now and a PMR registered resulted in a recommendation to use "Principal names" instead of the Local Groups we have setup for MQ Auth on our cluster nodes.
(MQ Version 8.0.0.4, W2008r2 MSCS).
Now, i asked if there would be any difference setting AD-Groups in the local groups versus AD-Users in the local groups and the answer from the tech was a bit unclear .
What we do know and understand is that AD-users in Local Groups dont rock!
With principal names we surely have retained authorities across cluster nodes (joe@domain) but this matches badly with our current admin tools.
(Built in scripts, with hardcoded -g for granting authority).
Majority of our QueueManagers are singlenodes but there are 4 QueueManagers running on MSCS.
What do you recommend , as there is no way we can add domaingroups directly to the cluster nodes ?
We dont want to compromise security and add service accounts into mqm group (service user for mq is domain user ). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 21, 2016 8:58 am Post subject: Re: Authority lost after failover on MSCS |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| blorro wrote: |
What we do know and understand is that AD-users in Local Groups dont rock!
|
Indeed and the main reason for this is that the local group has a different gid on each side. So as soon as you fail over the permissions are lost...
| blorro wrote: |
With principal names we surely have retained authorities across cluster nodes (joe@domain) but this matches badly with our current admin tools.
(Built in scripts, with hardcoded -g for granting authority).
Majority of our QueueManagers are singlenodes but there are 4 QueueManagers running on MSCS.
What do you recommend , as there is no way we can add domaingroups directly to the cluster nodes ?
We don't want to compromise security and add service accounts into mqm group (service user for mq is domain user ). |
This is why you need to authorize the global (AD) group.
Domain groups are not added to the cluster nodes. They are added to the domain. The clustered nodes are members of that domain, or authenticate against that domain...
User administration as to which group the users are part of, becomes now a domain admin thing...
You don't need to add the service user into the local mqm group. I'd expect it to already be a member of the domain mqm group which in turn is a member of the local mqm group...
Review the infocenter and make sure the service user has all the required permissions (logon as service, batch, query domain group info, act as part of the os, etc... etc...)
Any other permissions need to be given to a global group. No need for local groups for permissions. If fact they are highly discouraged.
Now you just need to make sure you have the global group security stanza in the qm.ini and bounced the queue manager after changing that entry...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| blorro |
| Posted: Thu Jan 21, 2016 9:58 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
Thanks for the super-fast reply.
I got some work to do.
Just one last question regarding this particular topic:
- To grant MQ authority to a AD-user, all that is needed is a Global group in the same domain and the particular user needs to be in that specific global group.
As long as the QueueManager has the same domain membership and service users set up correctly, everything should work ?
No need to create groups on any of the cluster nodes ?
If so , then have some work todo , correcting some documentation and ordering some global groups. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 21, 2016 11:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| blorro wrote: |
Thanks for the super-fast reply.
I got some work to do.
Just one last question regarding this particular topic:
- To grant MQ authority to a AD-user, all that is needed is a Global group in the same domain and the particular user needs to be in that specific global group.
As long as the QueueManager has the same domain membership and service users set up correctly, everything should work ?
No need to create groups on any of the cluster nodes ?
If so , then have some work todo , correcting some documentation and ordering some global groups. |
And don't forget the security stanza in the qm.ini! It is needed!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| blorro |
| Posted: Wed Feb 24, 2016 5:06 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
Setting :
Security:
GroupModel=GlobalGroups
Indeed works, thanks for that help.
However, we have the MQ Admin group on each QueueManager which is a local one.
Even though we set the Globalgroup in QM.ini, we do still see that our mqadmin group has authority @servername too.
Reading the IBM docs:
https://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.con.doc/q018900_.htm?lang=en
a Question arises:
Will Enabling Groupmodel=Globalgroups also leave the option to grant MQ Authority on local groups ? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 24, 2016 5:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| blorro wrote: |
Setting :
Security:
GroupModel=GlobalGroups
Indeed works, thanks for that help.
However, we have the MQ Admin group on each QueueManager which is a local one.
Even though we set the Globalgroup in QM.ini, we do still see that our mqadmin group has authority @servername too.
Reading the IBM docs:
https://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.con.doc/q018900_.htm?lang=en
a Question arises:
Will Enabling Groupmodel=Globalgroups also leave the option to grant MQ Authority on local groups ? |
Granting authority to local groups is what got you into this mess in the first place. Local groups don't have the same GID on both nodes...
This is why the only allowed local group is the mqm group.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| blorro |
| Posted: Thu Feb 25, 2016 6:10 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
True, local groups on a MSCS gave us a bucketfull of trouble.
How about naming the AD-Groups, max lenght on the group name ?
(As our enterprise tools add a prefix of 8 characters to each group created )
In the "The top 15 WebSphere MQ best practices" found here:
http://www.ibm.com/developerworks/websphere/library/techarticles/0807_hsieh/0807_hsieh.html
There is a statement saying:
"For MQ authorizations, even though the maximum length of group names and user IDs is 20 characters, keep them under 12 characters to prevent complications."
What kind of complications could that present ?
I'd wish they expanded a bit on that detail, any clue ?
(In our devbench we autorized a group with 16 chars in the group name without issues). |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 25, 2016 6:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The complication is an o/s thing. Search google for 'group name length restrictions'.
I found this:
| Quote: |
1. Group name length limits
A group name (e.g. dialout) has a length limit, usually hardcoded in the operating system. This limit varies across different UNIX systems and implementations.
NIS: 8 characters (source)
HPUX: 8 characters, 16 starting from HPUX 10 (source, source)
AIX: 8 characters, 255 for AIX 5.3 and above (source)
Debian: 16 characters (source, defined in shadow at compile-time)
Redhat: 16 characters, 32 starting from 2005 (source, source, source)
Solaris: 8 characters? (source)
Active Directory: 11 or 64 characters (source unclear) |
_________________
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: Thu Feb 25, 2016 9:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| blorro wrote: |
True, local groups on a MSCS gave us a bucketfull of trouble.
How about naming the AD-Groups, max lenght on the group name ?
(As our enterprise tools add a prefix of 8 characters to each group created )
In the "The top 15 WebSphere MQ best practices" found here:
http://www.ibm.com/developerworks/websphere/library/techarticles/0807_hsieh/0807_hsieh.html
There is a statement saying:
"For MQ authorizations, even though the maximum length of group names and user IDs is 20 characters, keep them under 12 characters to prevent complications."
What kind of complications could that present ?
I'd wish they expanded a bit on that detail, any clue ?
(In our devbench we autorized a group with 16 chars in the group name without issues). |
Traditionally for authorizations and username / groupnames things over 12 characters were presenting challenges to WMQ. With the MQCSP structure you can now use a password that is over 12 chars in length.
Just to be on the safe side limit your user / group names to 12 chars in length...
If you have the time you can experiment and see where it breaks...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| blorro |
| Posted: Mon Mar 14, 2016 6:59 am Post subject: |
|
|
Acolyte
Joined: 09 Jan 2014
Posts: 57
Location: Sweden
|
Experimenting done.
WMQ 8.0.0.4 on Windows 2008R2 :
Global Authority group name with 21 Characters works.
22 characters does not work.
"AMQ7026: A principal or group name was invalid."
So now we know that, and loads of other new learnings.
thanks all for helping out !  |
|
| Back to top |
|
|
|
|
