| Author |
Message
|
| Ice |
 Posted: Fri Nov 20, 2009 6:34 am Post subject: access rights(once again) |
 |
|
Newbie
Joined: 18 Nov 2009
Posts: 6
|
Sorry for i post common problem again, but all the threads i looked at didn't help in my case.
I have QueueManager (7.0.1) installed on windows pc, which is not in domain.
I have simple application, which works fine, when run on pc with Queue manager, but when i launch it from domain pc - it returnm error 2035.
I use all default settings(created QM and some queues without changing default settings, and using default channel).
from what i read in other topics on access problems i understand that everything should work fine, as there is no access control..but now i see that there still is something.. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Nov 20, 2009 7:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| as there is no access control.. |
Yes there is.
Did you do your test with mqm group auth on the non-domain server?
Have you tried a setmqaut control command to grant the appropriate authorizations to the user/group on the domain server?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Ice |
| Posted: Fri Nov 20, 2009 12:51 pm Post subject: |
|
|
Newbie
Joined: 18 Nov 2009
Posts: 6
|
| bruce2359 wrote: |
Did you do your test with mqm group auth on the non-domain server?
Have you tried a setmqaut control command to grant the appropriate authorizations to the user/group on the domain server? |
how can I do this?
I tried using local admin pwd (setting pwd\login when connecting to MQ), but saw no difference(maybe I did something wrong  ) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Nov 20, 2009 1:06 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
I tried using local admin pwd (setting pwd\login when connecting to MQ), but saw no difference(maybe I did something wrong  |
What username did you use? Is that username in the mqm group?
What do you mean by (setting pwd/login when connecting to MQ)?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Nov 20, 2009 9:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As your qmgr is not in the domain (running with a local account) you may want to add the domain user that is receiving the 2035 to a local group on the qmgr's box that has the required information.
Run refresh security on the qmgr before trying to connect again with that user. For the domain authentication of the user to work properly on the qmgr's box, you may have to set up some trusted relationship between the domain admin box and the MQ Server box. Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Ice |
| Posted: Mon Nov 23, 2009 1:24 am Post subject: |
|
|
Newbie
Joined: 18 Nov 2009
Posts: 6
|
thanks for all answers..
I think it's easier for me to move qmgr on domain pc.
as for login\pwd - i tried to use this when doing MQCONN:
| Code: |
MQCSP SecCon = {MQCSP_DEFAULT};
SecCon.AuthenticationType = MQCSP_AUTH_USER_ID_AND_PWD;
SecCon.CSPUserIdPtr = strId;
SecCon.CSPUserIdLength = _tcslen(strId);
SecCon.CSPPasswordPtr = strPwd;
SecCon.CSPPasswordLength = _tcslen(strPwd);
Connect_options.SecurityParmsPtr = &SecCon; |
not sure if that's correct to do so, but I failed to find similar examples of login\pwd usage.. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Nov 23, 2009 3:29 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Ice wrote: |
| not sure if that's correct to do so, but I failed to find similar examples of login\pwd usage.. |
Do not send your username and password in the MQCONN call unless your queue manager is set up to do something with this information.
It is extremely unlikely that your queue manager is set up to offer authentication. It is a big effort to do so, as it involves writing a new authorization service to replace MQ's OAM. Hence I do not think it is necessary or even useful to send an MQCSP on the MQCONN call.
But perhaps I am wrong - is your queue manager running a special authorization service? |
|
| Back to top |
|
|
| Ice |
| Posted: Tue Nov 24, 2009 7:04 am Post subject: |
|
|
Newbie
Joined: 18 Nov 2009
Posts: 6
|
| mvic wrote: |
But perhaps I am wrong - is your queue manager running a special authorization service? |
no.
I already understood that providing login\pwd was incorrect.
we decided to move QMgr from that out-of-domain PC to PC inside domain |
|
| Back to top |
|
|
|
|
