| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| WMQ v6 and Windows local install problems |
« View previous topic :: View next topic » |
| Author |
Message
|
| RogerLacroix |
 Posted: Tue Sep 18, 2007 9:55 am Post subject: |
 |
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Well, after going through the 20-questions at the client site, and them wondering if / how this would affect DEV/QA/ PROD, the answer back was no to adding my local musr_mqadmin to domain controller (AD).
So, the simplest thing was to uninstall WMQ v6.0.2.2, delete the MQ UserId and groups and reboot. I logged in as the local Administrator, installed WMQ v5.3, reboot, applied CSD13 and reboot.
I then logged in under my domain account, added it to the mqm group and started MQ Explorer. I created 2 queue managers, added test queues and test channels and now I am back where I was last Thursday morning.
I need a functioning queue manager (any recent version) to do development and testing work while at a client site. I don't need the latest and greatest. And yes, I know it will not be supported by IBM in 12 days but who cares, a working queue manager is better than a non-working queue manager.
I don't know what IBM has changed, or what was updated, but WMQ v6 most certainly acts differently when logging in locally with a domain account vs how WMQ v5.3 worked.
Regards,
Roger Lacroix
Capitalware Inc,
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
 |
| JasonE |
| Posted: Mon Nov 19, 2007 9:24 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
(Updating as this was referred to from another thread) I suspect the v6 wizard added additional checks to catch common problems at a guess, and given the description from higher up I am more suprised it worked at 5.3 than the fact it failed at 6.0
Basically in the abscence of any 'direction' on the security information from the command line/paramter file, MQ will create the MUSR_MQADMIN local account (local => not known to the domain controller), configure the MQ COM+ resource to start under that id and then try to start it. Finally it will query the group membership of the signed on userid.
With an NT4 Domain, standalone machine, or NT4 migrated to Active directory domain, this will work and all will be fine.
With a 'new' active directory domain this will fail - a non-authenticated user can no longer query information about userids as Windows tightened the security.
So when you tried it under Administrator - MUSR_MQADMIN was used and could validly query the group memberships of the Administrator account keeping everything local (you cannot put non-domain userids in domain groups so nothing needs to flow to any domain controllers referenced in any domain group contained in any local group).
When you tried if under a domain id, MUSR_MQADMIN fails because the local machine cannot indicate all the group memberships of your domain id alone. Hence the request would flow to the domain controller who would reject the call as it is an unknown userid (SID is unknown to DC and guests do not have the delegate rights).
The prepare wizard would then drop through to configuring the MQ COM+ component under the userid/password of the supplied domain userid. Then it will restart it, and query the signed on (domain) userid. Again, for this to work, the userid query will go to the domain controller. *IF* the domain userid has the delegate rights (which need to be explicitally added, they are not granted by default) then it will work, otherwise this call will fail.
At a guess your 5.3 install 'works' because you never need to validate domain userids through it and the prepare wizards may be slightly different and didnt check this condition.
If thats not that case then I have no idea why the 5.3 and 6.0 behave differently! |
|
| Back to top |
|
|
| rtsujimoto |
| Posted: Tue Nov 20, 2007 8:50 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
Roger,
What if you changed the password for MUSR_MQADMIN, then log in with that userid and see if 2035 is still an issue? |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Nov 20, 2007 8:55 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| rtsujimoto wrote: |
| What if you changed the password for MUSR_MQADMIN, then log in with that userid and see if 2035 is still an issue? |
No, I didn't think about logging onto the PC with a service account.
Jason, the MQ code for group membership/lookup appears to have changed between v5.3 and v6.0.
Your conclusions aren't correct.
1) The same PC was used in testing between WMQ v5.3 and WMQ v6.0
2) The same setup of WMQ was done each time (local WMQ account).
3) The same domain account was used in testing.
4) The same domain controller was used in testing.
The only thing that changed between the installs (and I did it several installs) was WMQ v5.3 vs WMQ v6.0.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| JasonE |
| Posted: Wed Nov 21, 2007 2:04 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Well, without sitting debugging it with logs from both its next to impossible to tell precisely what is going on. However from your original update my belief is its the prepare wizard identifying the problem on 6.0 which it didnt on 5.3.
The way it works (as described above) is definitely accurate - I've also gone through the code to see if there's any glaring differences in the prepwizard between 5.3 and 6.0 and there's very little non-SSL related changes between the two levels.
If you have the prepare wizard logs from the 5.3 and 6.0 install you are welcome to email me and I'll take a quick look (I believe you have my email, or PM me)
However I will also emphasize that it does more surprise me it worked at 5.3 than that it fails in 6.0 if you are mixing domain account use and local musr_mqadmin COM+ identity in an active directory domain.
(Out of interest, the domain account userid wasnt longer than 20 characters, was it?) |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Nov 21, 2007 9:48 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| JasonE wrote: |
| However I will also emphasize that it does more surprise me it worked at 5.3 than that it fails in 6.0 if you are mixing domain account use and local musr_mqadmin COM+ identity in an active directory domain. |
Well, having the ability to say 'local MQ only' (i.e. no domain controller) is the way it should be. The user's domain account is put in the local mqm group and then it does not need any domain controller privileges.
You say the Prepare Wizard was broken in WMQ v5.3 but I say it is broken in WMQ v6.0.
| JasonE wrote: |
| (Out of interest, the domain account userid wasnt longer than 20 characters, was it?) |
Actually, it was exactly 9 digits/numbers and do mean numbers. i.e. "701234567" If a domain UserId is all numbers, could that cause a problem?
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| JasonE |
| Posted: Thu Nov 22, 2007 4:58 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| Quote: |
| Well, having the ability to say 'local MQ only' (i.e. no domain controller) is the way it should be. The user's domain account is put in the local mqm group and then it does not need any domain controller privileges. |
The way MQ does its security (outside the prepare wizard - I'd have to check how that works) is not to enumerate the mqm group, but rather to call the operating system saying 'please give me a list of the local groups that this userid is a member of' (NetUserGetLocalGroups).
When you are asking about a domain id, then that domain id could be in a domain global group, and the domain group is then in a local group, (eg. we add 'Domain mqm' into the local mqm group during install) - hence it is extremely likely that the request will get directed through the domain controller and fail if the userid the request is running under is either not known or not authorized to query such information.
| Quote: |
| You say the Prepare Wizard was broken in WMQ v5.3 but I say it is broken in WMQ v6.0. |
Not quite - I am saying in the abscence of knowing what the actual cause / issue us, then my gut feeling is that I'm more suprised querying domain userids from a program running under a local userids (in an active directory domain) works at 5.3 than fails at 6.0 - However, suprise is not the same as saying its broken!
| Quote: |
| If a domain UserId is all numbers, could that cause a problem? |
No... |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
