Author |
Message
|
leo> |
Posted: Thu Jun 07, 2007 10:49 am Post subject: RC 2063, AMQ8561 error |
|
|
 Apprentice
Joined: 06 Oct 2004 Posts: 42
|
We have a MQ5.3 qmanager running on on Windows (NT) 2003 box. This box is on our DMZ and does'nt have connections to our directory server. Also running on this box is a web application on IIS, which sends messages to the qmanager on the same box. The webapp has been designed to use client connection to MQ QM (on the same box)
Whenever the client tries to connects it receives a MQ RC 2063 error:
And on the server's AMQERR01.LOG I am seeing the following messages:
AMQ8561: Domain controller unavailable.
EXPLANATION:
WebSphere MQ was unable to contact the domain controller to obtain information
for user 'network service@NT AUTHORITY'.
ACTION:
Ensure that a domain controller for the domain on which user 'network
service@NT AUTHORITY' is defined is available. Alternatively, if you are using
a computer which is not currently connected to the network and have logged on
using a domain user ID, you may wish to log on using a local user ID instead.
I got the "network service" user on windows box to mqm group, did a REFRESH SECURITY, and even restarted the Qmanager. I am still getting this same error.
Could you please let me know if I am missing something here?
Thanks _________________ IBM Certified System Administrator - Websphere MQ V5.3 |
|
Back to top |
|
 |
RogerLacroix |
Posted: Thu Jun 07, 2007 11:35 am Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Hi,
In the original install of MQ, someone set it up to do remote userid/group checking.
Believe it or not, the easiest thing to do is:
- Uninstall MQ,
- reboot,
- Install MQ (local account setup ONLY),
- reboot,
- Install any CSDs
- reboot
- Give appropriate privileges to web UserId (NOT in the mqm group),
And voila done.
Regards,
Roger Lacroix _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Jun 07, 2007 11:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Um.
Or just re-run the "Prepare WebSphere MQ Wizard".
Or just reconfigure IIS, or the IIS security configuration for the web application so that it doesn't use that particular userid, but uses a predefined userid in the local security domain. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Thu Jun 07, 2007 12:14 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
jefflowrey wrote: |
Or just re-run the "Prepare WebSphere MQ Wizard".
|
The last time I tried that, it wouldn't switch from domain acount lookups to local account lookups.
Regards,
Roger Lacroix _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Jun 07, 2007 12:17 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
RogerLacroix wrote: |
jefflowrey wrote: |
Or just re-run the "Prepare WebSphere MQ Wizard".
|
The last time I tried that, it wouldn't switch from domain acount lookups to local account lookups. |
Hum. I guess I've never tried that particular direction. I've mainly used it to avoid playing around with DCOMCFG to change the user. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
leo> |
Posted: Thu Jun 07, 2007 2:56 pm Post subject: |
|
|
 Apprentice
Joined: 06 Oct 2004 Posts: 42
|
I am having few basic questions. Any pointers would also be great.
Why is that this kind of security verifications being done only when a client connects to QM via server connection channel? This time I tried to connect from a machine (A) inside firewall to one on DMZ (B).
I tried to create a sender-receiver channels (with all default values) between QMs on A and B, and the channels start without any issues.
But if I connect using any MQ tools (like mqmon, mqexplorer) using server connection channel, I am getting the security error and the server's log shows this:
Quote: |
-------------------------------------------------------------------------------
6/7/2007 18:43:19
AMQ9245: Unable to obtain account details for channel MCA user ID.
EXPLANATION:
WebSphere MQ was unable to obtain the account details for MCA user ID
'subbagu'. This user ID was the MCA user ID for channel 'SYSTEM.DEF.SVRCONN' on
queue manager 'B2BACC' and may have been defined in the channel definition, or
supplied either by a channel exit or by a client.
ACTION:
Ensure that the user ID is correct and that it is defined on the Windows local
system, the local domain or on a trusted domain. For a domain user ID, ensure
that all necessary domain controllers are available.
----- amqrsrva.c : 711 --------------------------------------------------------
6/7/2007 18:43:19
AMQ8075: Authorization failed because the SID for entity 'subbagu' cannot be
obtained.
EXPLANATION:
The Object Authority Manager was unable to obtain a SID for the specified
entity.
ACTION:
Ensure that the entity is valid, and that all necessary domain controllers are
available.
----- amqzfubn.c : 1949 ------------------------------------------------------- |
Thanks _________________ IBM Certified System Administrator - Websphere MQ V5.3 |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Jun 07, 2007 3:00 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
I thought the error message is quite clear.
The user trying to access the qmgr is not known to the server hosting the qmgr.
So it cannot resolve the group or permissions issue.
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
leo> |
Posted: Thu Jun 07, 2007 3:07 pm Post subject: |
|
|
 Apprentice
Joined: 06 Oct 2004 Posts: 42
|
Actually I was trying to ask what user authentication is being done on a sender-receiver channel connection? How is it working even though the user starting the sender channel is a domain user and at the other end, the QM does not have connection to domain controller. _________________ IBM Certified System Administrator - Websphere MQ V5.3 |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Jun 07, 2007 6:21 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
MQ does not do any authentication of users, it relies on the OS to do that.
It only does authorization of users.
As I hinted at, this is likely a configuration issue with ISS - either the global security for IIS, or the specific security for the web application you are running under IIS. It is trying to pass along the ID that the entire IIS instance is running under, and that's almost certainly not what you want it to do. You almost certainly want IIS to be running the web app as a particular user that is authorized to MQ with only those specific priviledges that it needs for that particular application.
And all of the "generic" accounts in Windows security - like "network user" and "local system" and "guest" and etc... have very strange interactions with other security domains, particularly when you don't have a firm idea if they're being passed by NAME or by SSID. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
leo> |
Posted: Fri Jun 08, 2007 12:35 pm Post subject: |
|
|
 Apprentice
Joined: 06 Oct 2004 Posts: 42
|
Found this while looking for a solution:
Quote: |
WebSphere® MQ authorization check fails when application runs under the Network Service account.
Cause
Windows® OS function NetUserGetLocalGroups does not support the domain of NT AUTHORITY, and a userid of Network Service (which Windows will use automatically in some situations, such as when using DTC). Because of this MQ cannot enumerate the local groups of which it is a member, and subsequently cannot check the MQ authorizations. Therefore it is not possible to explicitly authorize this userid with the required +connect authority needed to finish the transaction.
Solution
WebSphere MQ V5.3 - complete the following steps to work around this issue:
Alter the SVRCONN channel the client app is connected to and add an MCA user id that is authenticated by MQ, and to which the Network Service account would be changed on an incoming connection request. Give +connect authority to this MCA user id, so that the connection succeeds.
Run REFRESH SECURITY against your queue manager before attempting to connect after making a change.
|
So created a user on the MQ box, gave that user +connect, +put for the queues and configured the SYSTEM.DEF.SVRCONN channel's MCA attribute to use this userid. This solved the issue. As of now, there is only one application running on this box. Please let me know if you think this solution has any scalability issues or anything in general. _________________ IBM Certified System Administrator - Websphere MQ V5.3 |
|
Back to top |
|
 |
Vitor |
Posted: Fri Jun 08, 2007 2:17 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
leo> wrote: |
Found this while looking for a solution:
Quote: |
WebSphere® MQ authorization check fails when application runs under the Network Service account.
Cause
Windows® OS function NetUserGetLocalGroups does not support the domain of NT AUTHORITY, and a userid of Network Service (which Windows will use automatically in some situations, such as when using DTC). Because of this MQ cannot enumerate the local groups of which it is a member, and subsequently cannot check the MQ authorizations. Therefore it is not possible to explicitly authorize this userid with the required +connect authority needed to finish the transaction.
Solution
WebSphere MQ V5.3 - complete the following steps to work around this issue:
Alter the SVRCONN channel the client app is connected to and add an MCA user id that is authenticated by MQ, and to which the Network Service account would be changed on an incoming connection request. Give +connect authority to this MCA user id, so that the connection succeeds.
Run REFRESH SECURITY against your queue manager before attempting to connect after making a change.
|
So created a user on the MQ box, gave that user +connect, +put for the queues and configured the SYSTEM.DEF.SVRCONN channel's MCA attribute to use this userid. This solved the issue. As of now, there is only one application running on this box. Please let me know if you think this solution has any scalability issues or anything in general. |
I'd have defined a new channel but that's because I dislike using SYSTEM objects for applications. But I'd use the method you outline. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|