| Author |
Message
|
| Vgowda |
 Posted: Tue Feb 14, 2012 6:07 am Post subject: Unable to access Remote Broker |
 |
|
Acolyte
Joined: 11 Dec 2007
Posts: 61
Location: Bengaluru
|
Hi,
I am trying to connect to remote WMB V 6.1.0.3 (on windows server 2003) from WMB toolkit V6.1.0.3 (local machine- windows XP). Both the systems are on different Domains, Can anybody let me know what all configurations need to be done to access Remote Broker from my Local WMB Toolkit?
Broker, QM and Listener are Running.
It gives me this error :
| Quote: |
BIP0915E The MBT cannot connect to the QM BRKQM.
User vinay.narayan is not authorized to connect to queue manager 'BRKQM' (MQ reason code 2035 while trying to connect) |
Can anybody let me know what kind of authorization shd be given on the server?
I tried to give below mentioned command on WMB server but it threw me prinicipal invalid :
| Quote: |
C:\Documents and Settings\vinay.laxmi>setmqaut -m BRKQM -t qmgr -p vinay.narayan@TESTDOMAIN +connect
AMQ7026: A principal or group name was invalid. |
Any anyone throw me thoughts on the same?
_________________
Regards
Vinay |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Feb 14, 2012 6:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You need to give the user broker authorization as well as mq authorization. |
|
| Back to top |
|
|
| Vgowda |
| Posted: Tue Feb 14, 2012 7:07 am Post subject: |
|
|
Acolyte
Joined: 11 Dec 2007
Posts: 61
Location: Bengaluru
|
In the above mentioned was there anything wrong in MQ Authorization command? but it throws invalid principal name...
Can u share anylinks for the same? It would be gr8  for me 
_________________
Regards
Vinay |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Feb 14, 2012 7:28 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| Vgowda wrote: |
In the above mentioned was there anything wrong in MQ Authorization command? but it throws invalid principal name...
Can u share anylinks for the same? It would be gr8 for me |
The windows user on your local development machine ideally is your broker user name (from AIX)... sounds strange but, when you use a VM, then thats not a problem at all.
The other technique I know of is to set the MCAUSER in the Channel (that you use to connect to) to the broker user id. Though there are issues with that (Please someone explain ).
_________________
Just use REFERENCEs
Last edited by mqsiuser on Tue Feb 14, 2012 7:33 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 14, 2012 7:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| The windows user on your local development machine ideally is mqsiuser or mqsibrk (whatever your broker user name is)... |
No. That's a terrible idea. Even for a development machine. If you don't learn the basics of security at the development level, you'll never get used to it at the production level.
| mqsiuser wrote: |
| The other technique I know of is to set the MCAUSER in the Channel (that you use to connect to the Broker to, e.g. SYSTEM.BKR.CONFIG) the broker user id. Though there are issues with that. |
yes, that still doesn't mean that the necessary permissions have been set in the broker/config mgr to ensure that the Toolkit user is authorized to connect to the Broker and the relevant Egs and authorized to deploy to them.
The necessary mqsi commands to perform this authorization are, of course, documented in the V6.1 Information Center. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Tue Feb 14, 2012 7:59 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| mqjeff wrote: |
| You need to give the user broker authorization as well as mq authorization. |
I guess he needs to create the user "vinay.narayan" (or make sure that the domain-user is valid) on Win2003 and then issue the commands ?!
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 14, 2012 8:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqsiuser wrote: |
| mqjeff wrote: |
| You need to give the user broker authorization as well as mq authorization. |
I guess he needs to create the user "vinay.narayan" (or make sure that the domain-user is valid) on Win2003 and then issue the commands ?! |
No. He needs to have authority to talk to the config manager's qmgr and needs to be given the permissions against the config manager... see the infocenter for 6.1!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 14, 2012 8:08 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| mqjeff wrote: |
| You need to give the user broker authorization as well as mq authorization. |
I guess he needs to create the user "vinay.narayan" (or make sure that the domain-user is valid) on Win2003 |
Does he?
Is that what the documentation on the relevant command says? Is the ConfigMgr going to use OS level authentication to validate the user?
Clearly, MQ does, and so if the intent is to use the same user for both MQ and Broker permissions, then certainly the relevant user needs to be valid on the Broker server. |
|
| Back to top |
|
|
| Vgowda |
| Posted: Tue Feb 14, 2012 9:36 pm Post subject: |
|
|
Acolyte
Joined: 11 Dec 2007
Posts: 61
Location: Bengaluru
|
I created local user by name 'vinay.narayan' on Windows Server and added to mqm and mqbrkrs group, and gave MCA user Id as vinay.narayan on SVRCONN channel name it worked.
Thank you all for your valuable suggestions 
_________________
Regards
Vinay |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 15, 2012 5:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vgowda wrote: |
| I created local user by name 'vinay.narayan' on Windows Server and added to mqm and mqbrkrs group, and gave MCA user Id as vinay.narayan on SVRCONN channel name it worked. |
It's also allowed anybody who uses that channel unrestricted access (via the mqm & mqbrkrs) to all of the components at an admin level without any checking.
You've fixed the authorization problem by effectively removing the authorization security.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
