| Author |
Message
|
| KoGor |
 Posted: Tue Oct 10, 2017 2:48 am Post subject: COD and "Authorization failed as the SID..." |
 |
|
Voyager
Joined: 09 Nov 2005
Posts: 81
Location: Moscow,Russia.
|
Hi all!
Have faced recently with a problem that cannot solve.
I have two Windows AD Domains INT and EXT. In each domain there are MQ managers INT.MGR and EXT.MGR
Both managers are running from domain users: INT\int_mq_srv and EXT\ext_mq_srv
All security is disabled.
I have created local windows user "ext_mq_user" and included it in local mqm group on both mq manager servers.
The EXT.MGR is sending all messages to INT.MGR using sender/receiver channel. MCA user for this channel is "ext_mq_user". All messages is putted into INT.MGR successfully.
There is an application that get all messages from INT.MGR using mq client channel where MCA USER is set to "int_mq_user"." int_mq_user" is a local user in local mqm group on manager INT.MGR. When application gets a message from queue a COD should be sent to EXT.MGR, but I get an error on INT.MGR(attached screenshot):
Authorization failed as the SID 'xxxxxxx' does not match
the entity 'ext_mq_user'.
EXPLANATION:
The Object Authority Manager received inconsistent data -
the supplied SID does not match that of the supplied entity
information.
I have tried to change mq client MCA user to int_mq_user but with no success. What am I doing wrong? Could not find any solution still.
https://photos.app.goo.gl/CXVpoggDO1CYjYmC3 |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Oct 10, 2017 6:47 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Is there a cross-domain trust? It's implied as it appears the user's SID does not match.
Are you able to add the domain ext_mq_user account to the local mqm group on the INT.MGR server?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| KoGor |
| Posted: Tue Oct 10, 2017 9:07 am Post subject: |
|
|
Voyager
Joined: 09 Nov 2005
Posts: 81
Location: Moscow,Russia.
|
| No, domains are not trusted. Ext_mq_user is local user on both managers. Domain users are ext_mq_srv and int_mq_srv, from which MQ services are running. All other users are local. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 10, 2017 1:05 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| KoGor wrote: |
| No, domains are not trusted. Ext_mq_user is local user on both managers. Domain users are ext_mq_srv and int_mq_srv, from which MQ services are running. All other users are local. |
Any reason codes in the queue manager log, and which user does that SID match?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 10, 2017 8:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Remember entities in windows are recognized by their SID.
So user alpha in domain A has a different SID than user alpha in domain B.
As you have no cross domain trust established you are falling foul of that problem for the messages being sent with int_mq user or ext_mq user.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| KoGor |
| Posted: Wed Oct 11, 2017 2:13 am Post subject: |
|
|
Voyager
Joined: 09 Nov 2005
Posts: 81
Location: Moscow,Russia.
|
Is there any solution? I cannot find in information center anything close to my problem. It's impossible to enable cross domain trust between domains. They are separated by firewall from security reasons.
Is it OAM who read and compare user's SID during an establishing connection? Because there is a MCA user in channel exists and regular messages handling with no problems. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 11, 2017 2:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| KoGor wrote: |
Is there any solution? I cannot find in information center anything close to my problem. It's impossible to enable cross domain trust between domains. They are separated by firewall from security reasons.
Is it OAM who read and compare user's SID during an establishing connection? Because there is a MCA user in channel exists and regular messages handling with no problems. |
What happens if you put the MCAUser on the receiver end of the channel?
COA / COD messages are sent with the user on the message and that is the user from the other domain... One of the possibilities would be to add that user (inclusive domain information) to the qmgrs local mqm group.
The downside is that the service user of the qmgr would need to have domain privileges to read group membership for both domains...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 11, 2017 4:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
User "x" in Domain 1 will have a different UUID from User "x" in Domain 2.
You either need to, somehow, magically, create a user x in Domain 1 with the same UUID as the user x in Domain 2, and risk the wrath of your Domain Admins....
Or explain the issue to your Domain Admins and ask them how to resolve it... I suspect they will then set up cross domain authentication. Or tell you that it's not allowed because of security issues.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Oct 11, 2017 1:31 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| fjb_saper wrote: |
| COA / COD messages are sent with the user on the message |
Not technically correct.
- COA messages are sent with the queue manager's UserId
- COD messages are sent with the UserId from the original message.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 11, 2017 7:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| RogerLacroix wrote: |
| fjb_saper wrote: |
| COA / COD messages are sent with the user on the message |
Not technically correct.
- COA messages are sent with the queue manager's UserId
- COD messages are sent with the UserId from the original message.
Regards,
Roger Lacroix
Capitalware Inc. |
Thanks Roger, learning every day. I thought both were afflicted with the same problem... needing the userid of the original message to be authorized...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 12, 2017 1:25 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
For COAs, its the User ID of the program putting the message with the COA Report Option set that needs authority, not the queue manager User ID.
When this is a RCVR or CLUSRCV channel from another QM, then its the ID that that channel is running as that needs the authority. This may or may not be the same ID that the QM is running as (i.e. mqm).
https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.ref.dev.doc/q097680_.htm
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Oct 13, 2017 8:47 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Ok, technically true but on distributed platforms, it is unheard of to have the queue manager and the MCA run under different UserIds whereas on z/OS this is common.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 13, 2017 5:05 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We run all our RCVR and CLUSRCVR channels as non mqm. On all platforms. The accounts they do run under don't have access to certain queues we would never want a remote queue manager sending to, things like command queues and initiation queues.
The channels are actually defined with a hard coded MCAUSER with zero access. Only when MQAUSX and/or CHLAUTH decide the remote QM is legitimate is the channel allowed to run as the non mqm account.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
