ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Solved:Connect broker to 2 different instances using 2 Users

Post new topic  Reply to topic Goto page Previous  1, 2
 Solved:Connect broker to 2 different instances using 2 Users « View previous topic :: View next topic » 
Author Message
mqjeff
PostPosted: Thu Sep 12, 2013 9:18 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Maybe you copy/pasted wrong, but the commands you gave were not correct.

If you are trying to use mqsisetdbparms, you have to specify the Broker name when you call mqsicvp.

Code:
BIP8872W: Verifies a broker. Verifies a user datasource to be used within the broker, or compares pr
imary and secondary datasources for equivalence.
Syntax (1):
 mqsicvp <brokerName>
Syntax (2):
 mqsicvp <brokerName> -n <primaryDatasource> [-c <secondaryDatasource>] [-v]
Syntax (3):
 mqsicvp -n <primaryDatasource> -u <primaryDatasourceUserId> -p <primaryDatasourcePassword> [-c <sec
ondaryDatasource> -i <secondaryDatasourceUserId> -a <secondaryDatasourcePassword>] [-v]


Command options, syntax (1):
 <brokerName>
 The broker name.

Command options, syntax (2):
 <brokerName>
 The broker name.
 -n <primaryDatasource>
 The name of the datasource to verify.
 This datasource must have been previously associated with the broker using mqsisetdbparms.
 -c <secondaryDatasource>
 The name of the second datasource.
 If specified, the function of this datasource is compared with that of <primaryDatasource>.
 This datasource must have been previously associated with the broker using mqsisetdbparms.
 -v
 Causes extra, untranslated, diagnostics related to supported CASTS to be output by the command.

Command options, syntax (3):
 -n <primaryDatasource>
 The name of the datasource to verify.
 -u <primaryDatasourceUserId>
 The user identifier to be used to connect to <primaryDatasource>.
 -p <primaryDatasourcePassword>
 The password associated with <primaryDatasourceUserId>
 -c <secondaryDatasource>
 The name of the second datasource.
 If specified, the function of this datasource is compared with that of <primaryDatasource>.
 -i <secondaryDatasourceUserId>
 The user identifier to be used to connect to <secondaryDatasource>.
 -a <secondaryDatasourcePassword>
 The password associated with <secondaryDatasourceUserId>
 -v
 Causes extra, untranslated, diagnostics related to supported CASTS to be output by the command.

BIP8007E: Mandatory argument missing.
When using this command interface the user should supply the mandatory argument.
Correct and reissue the command.
Back to top
View user's profile Send private message
abhyyy
PostPosted: Thu Sep 12, 2013 9:31 am    Post subject: Reply with quote

Voyager

Joined: 29 Sep 2011
Posts: 83

Using the same commands (as USER1) and working for DSN1 but not for DSN2 (may be , since it is created by USER2).

Since command is working for DSN1 so I know that I am doing copy/paste correctly and using the right commands. But just want to know if anyone has any ideas on why its not working for DSN2.
_________________
----------------------
NeVeR StOp LeaRnInG.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Thu Sep 12, 2013 12:41 pm    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

the only reason it wouldn't work for the second DSN, that I'm aware of, is that the mqsisetdbparms wasn't done right.
Back to top
View user's profile Send private message
mgk
PostPosted: Fri Sep 13, 2013 7:51 am    Post subject: Reply with quote

Padawan

Joined: 31 Jul 2003
Posts: 1642

What is the authentication mechanism the DB is using? If it is using "Integrated Windows Authentication" then it will try to login using the credentials of the user running the command, not the ones specified by mqsisetdbparms. To use the values set by mqsisetdbparms you need to use "SQL Server Authentication" and have set up an ID in SQLServer for both users.

Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.
Back to top
View user's profile Send private message
abhyyy
PostPosted: Fri Sep 13, 2013 8:29 am    Post subject: Reply with quote

Voyager

Joined: 29 Sep 2011
Posts: 83



Thanks MGK.

This is the exact mistake I did . I can check the server on Monday and confirm(hopefully) that this suggestion worked !!
Will update the post as soon as I verify that.
_________________
----------------------
NeVeR StOp LeaRnInG.
Back to top
View user's profile Send private message
abhyyy
PostPosted: Wed Sep 18, 2013 7:42 am    Post subject: Reply with quote

Voyager

Joined: 29 Sep 2011
Posts: 83

Thanks MGK and everyone. That was the exact problem.

If I may ask 1 question that my client is interested in and I am not sure about the answer, tried searching it too.

Context :
--------------
When we set the userID and password using mqsisetdbparms , the password is written in plain text.

Question :
--------------
How can the password be retrieved from broker ?

Basically, What he is asking is if it is possible that someone can retrieve the SQL user password (used during mqsisetdbparms command) from broker and misuse it ? Does IBM take care of password's security ?
_________________
----------------------
NeVeR StOp LeaRnInG.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Wed Sep 18, 2013 7:59 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

there is no command to display the password from an mqsisetdbparms.

The password is stored on the file system, in the broker internal registry.

It is obfuscated, but not encrypted.

It is exactly and only as secure as the broker file system.
Back to top
View user's profile Send private message
abhyyy
PostPosted: Wed Sep 18, 2013 8:46 am    Post subject: Reply with quote

Voyager

Joined: 29 Sep 2011
Posts: 83

Thanks for replying. This is exactly what I wanted to hear.

But I can't find any IBM document or even a webpage on this and client is expecting one.

Any help on this front ?
_________________
----------------------
NeVeR StOp LeaRnInG.
Back to top
View user's profile Send private message
Vitor
PostPosted: Wed Sep 18, 2013 9:44 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

abhyyy wrote:
Any help on this front ?


Raise a PMR asking if you can extract the password from the WMB registry. When IBM say there isn't without going into the file system directly, that's an official IBM answer (as good as the InfoCenter) and adds weight to the need to properly secure the file system.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
abhyyy
PostPosted: Thu Sep 19, 2013 2:43 am    Post subject: Reply with quote

Voyager

Joined: 29 Sep 2011
Posts: 83

Thanks for the advise.

Making this Topic as Solved.

Thanks everybody for your advise and time. Really appreciate that.
_________________
----------------------
NeVeR StOp LeaRnInG.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Solved:Connect broker to 2 different instances using 2 Users
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.