| Author |
Message
|
| hguapluas |
 Posted: Thu Oct 07, 2004 10:52 am Post subject: MQ 5.3 (Windows) CSD07 & Domain Policies (Solved) |
 |
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
Oh what a combination!
1st, has anybody run into specific issues of putting CSD07 onto Windows MQ 5.3 systems? Wondering because I put it on a test box and it ran fine. Then put it on production and now am getting account authorization failures. But, I don't believe it is CSD07. Instead, I believe it is the rather untimely forcing of new domain policies onto the servers by the security group that is breaking MQ.
Has anybody had any experience and identified what areas of Windows Member Server, Domain, File & Print, and IIS policies can cause MQ to break. The basic error codes I am getting are AMQ4100 (on screen), AMQ6119 and 2147500058 0x8000401a (in FDC log).
I can fix these by re-registering the DCOM component (amqmsrvn -regserver) and dll file (regsvr32 amqmspsn.dll). Then I can access MQ again. But, within 12-24 hours, the same errors occur again and I have to re-register everything again. It appears that the domain policy refresh keeps breaking the links (at least I think it may be doing that). Any thoughts?
And, no I don't have control over how they are pushing the policies down. I am just the little creaton that has to live with the results - ugh!
Last edited by hguapluas on Tue Oct 12, 2004 1:19 pm; edited 1 time in total |
|
| Back to top |
|
 |
| JasonE |
| Posted: Fri Oct 08, 2004 1:45 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
I havent heard a problem reported quite like this. However, if you have a local policy which contradicts with the domain policy then the domain one will take precedence. Can you get the domain policy changed?
You can see the 'effective' policies in the Local Securty Policy tool - is it different when it works to when it fails for the MQ userid / mqm group? (There's no easy way to do this that I know of other than looking at each of the policies by hand). |
|
| Back to top |
|
|
| Nathan |
| Posted: Fri Oct 08, 2004 3:41 am Post subject: |
|
|
Acolyte
Joined: 15 Sep 2003
Posts: 52
Location: Rochester, NY
|
look at the local security policy -> User Rights Assignment -> Debug programs
See what the Effective settings are. If the domain user for mq is not listed, this is a problem. For the most part, I followed the instructions for created the domain user/group like the mq documents state. The problem occurs when the site's policies don't co-operate. I hope this makes sense and points you in the right direction. |
|
| Back to top |
|
|
| hguapluas |
| Posted: Fri Oct 08, 2004 6:48 am Post subject: |
|
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
Thanks for the replies folks. I am going through the domain and member server policies (our MQ is on a member server in the domain) and so far haven't found anything specific. I have looked at the domain level permissions as identified in the instructions for 2003 and have noticed that the readGroupMembership permission is no longer checked. I was hoping to know if anybody knew what part of any domain, member, or IIS policy would remove this permission at the domain level since it is needed for the account to query the domain groups.
I will look into the specifics you both have identified, especially the debug part to see what that tells me.
I keep telling our security folks to just add the requisite permission back but they keep wanting to know what part of what policy (they believe it is in the domain member policy) that has disrupted the account in the first place.
Wish me luck on my hunt for the fabled "pin in the hay stack"
Cheers |
|
| Back to top |
|
|
| hguapluas |
| Posted: Fri Oct 08, 2004 6:57 am Post subject: |
|
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
JasonE,
I checked the local security policy before and after using a box that is in a workgroup and a box in the domain and have found no differences that would cause the failure. Thanks for the suggestion though. If they back out the policies (again) and it starts working, I will take a snap-shot of the local security settings at that time to have as a reference point in the future. Personally, I think that the critical failure is at the domain AD level because of the lack of the readGroupMembership permission not being checked. The readGroupMembershipSAM is checked but not the other one and according to the docs, both need to be checked in a 2000 or newer environment. Thanks.
Cheers |
|
| Back to top |
|
|
| JasonE |
| Posted: Fri Oct 08, 2004 7:03 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Yes, without the delegate authority, the call to find out if a user is a member of the mqm group (or to get a list of the groups it is a member of, so setmqaut checks can be performed) fails with security errors. I doubt it would EVER work if this was the case, but I might be wrong  |
|
| Back to top |
|
|
| hguapluas |
| Posted: Tue Oct 12, 2004 1:18 pm Post subject: |
|
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
Have some answers to what happened.
1. Somehow the readGroupMembership permission was removed from the domain mqm group causing authorization problems when attempting to query group membership.
2. One of the Policy changes (of many pushed down) disabled the "Log on as a batch job" permission creating even more authorization related errors.
3. Somehow, the MQ Service on all the boxes stopped using the domain mqm account and were using the local MUSR_MQADMIN account to launch the service. This also caused authorization errors since the MUSR_MQADMIN account did not exist in the domain. This may have been the result of either one of the DC's going corrupt, multiple policy changes pushed at once, or both combined together.
4. After all of the above were corrected, the MQ Service on each box was re-configured to use the "proper" domain mqm account. It was also necessary to re-register one of the MQ Services (amqmsrvn -regserver) on one of the boxes before the account could be re-configured using the Prepare WebSphere MQ Wizard. And I had to remove some residual phantom SID account IDs that ended up in the Local Security Policy on another box before that MQ Service could be reconfigured.
Oh what a wonderful day it was! |
|
| Back to top |
|
|
|
|
