| Author |
Message
|
| k_anand2585 |
 Posted: Thu Dec 29, 2011 8:17 am Post subject: MQ client not conneting to MQ server which is under DC |
 |
|
Acolyte
Joined: 03 Nov 2011
Posts: 50
|
Hi Friends,
I have configured domain controller with 2 nodes which are inside MSCS cluster. The client machine is in different subnet trying to connect MQ cluster with virtual IPaddress.
When client tries to connect to virtual IP address it throws exception ofOpen MQQueue...
MQQueueManager: AccessQueue ended with CompCode: 2, Reason: 2035; MQRC_NOT_AUTHORIZED
Now i have applied all authorisation to qmanager to queue to channels however not able to understand where the issue lies.
created a group mqc(domain local)
created a user mqc_tasco
assigned this user to domain group and mqc group
At Clinet machine
created the user mqc_tasco assigned to mqc
All the ports are opened.
The question is how the user which is outside domain will communicate with MQ server which is inside domain controller.
NOTE:: when the MQ server is not in domain just inside one subnet like all machines in lan than the client machine conencts with MQ server machine but once the amchines goes inside domain control , the client does not connect...at client end its only MQRC 2035. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Dec 29, 2011 8:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This isn't an IP problem. The user connecting through the client isn't being recognised as the user that has the authorisation, most likely because that user is being passed with a different domain or the SID doesn't match.
Get your Windows admin to verify that all the domain settings are correct & if that doesn't help enable security events on the queue manager to see what user id is actually reaching the queue manager.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| k_anand2585 |
| Posted: Thu Dec 29, 2011 8:44 am Post subject: |
|
|
Acolyte
Joined: 03 Nov 2011
Posts: 50
|
The environement is Windows 2008 r and MQ version is 7.1 also i tried to refresh the security ,display mq authorisation,
Basically trying to authorize against the domain mqm group.
I will tru to enable security events in the Qmanager .. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 29, 2011 11:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You should not have an MQ Client channel on your Queue Manager with a blank value for MCAUSER, and rely on the client to send their ID oveer the channel. Why? Its too easy for them to pick another ID and get more access than they need. What if they choose to run their app under an ID in your MQ Admin group?
A. Make sure the "mqc_tasco" ID is a domain ID, so that it has the same Windows SID regardless of which node your QM will run on in your MSCS cluster.
B. Create a SVRCONN channel on the QM for this client and only this client.
C. Put the ID "mqc_tasco" in the MCAUSER field of the channel.
D. Grant the "mqc_tasco" ID the minimum rights it needs via the setmqaut command. On Windows its OK to grant permissions to a specific ID. On Unix, always grant the permissions to a group, and then populate the group with only the IDs you want to have that access.
E. If the "mqc_tasco" ID has more authority to your QM than you would want your worst enemy to have, you must then insure your new Client Channel with "mqc_tasco" in the MCAUSER field can only be used by the client(s) you intend, so now protect the new channel with SSL or a Security Exit.
F. Begin testing.
G. Enable Authority Events at the QM level if you get any authority errors.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 29, 2011 7:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
E. If the "mqc_tasco" ID has more authority to your QM than you would want your worst enemy to have, you must then insure your new Client Channel with "mqc_tasco" in the MCAUSER field can only be used by the client(s) you intend, so now protect the new channel with SSL or a Security Exit.
F. Begin testing.
G. Enable Authority Events at the QM level if you get any authority errors. |
I believe he mentioned WMQ V7.1?
He needs to maintain the channel access list. Isn't by default everybody denied in V7.1? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| k_anand2585 |
| Posted: Fri Dec 30, 2011 3:37 am Post subject: |
|
|
Acolyte
Joined: 03 Nov 2011
Posts: 50
|
Hi
A. Made the "mqc_tasco" ID as a domain ID, so that it has the same Windows SID regardless of which node your QM will run on in your MSCS cluster.
B. Created a new SVRCONN channel on the QM for this client .
C. Put the ID "mqc_tasco" in the MCAUSER field of the channel.
D. Grant the "mqc_tasco" ID the rights it needs via the setmqaut command.
setmqaut -m NYQT1 -n "TASCO_CLIENT" -t chl -p mqc_tasco -remove
setmqaut -m NYQT1 -n "TASCO_CLIENT" -t chl -p mqc_tasco +chg +dlt +dsp +ctrl +ctrlx
Still the message is not coming to the server |
|
| Back to top |
|
|
| k_anand2585 |
| Posted: Fri Dec 30, 2011 3:40 am Post subject: |
|
|
Acolyte
Joined: 03 Nov 2011
Posts: 50
|
The same worked in lan in one domain but as the MQ servers went into domain and the mq client to another domain and subnet we are facing this issue.
Also last time we had tried on MQ 7.0.3 and now the setup is on 7.1 |
|
| Back to top |
|
|
| k_anand2585 |
| Posted: Fri Dec 30, 2011 3:43 am Post subject: |
|
|
Acolyte
Joined: 03 Nov 2011
Posts: 50
|
MQ server logs
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
'Adminstrator'. This user ID was the MCA user ID for channel 'TASCO_CLIENT' on
queue manager 'NYQT1' 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. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 30, 2011 4:35 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| k_anand2585 wrote: |
MQ server logs
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
'Adminstrator'. |
Typo in channel definition. Did you mean to put 'Administrator'?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 30, 2011 7:11 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| PeterPotkay wrote: |
E. If the "mqc_tasco" ID has more authority to your QM than you would want your worst enemy to have, you must then insure your new Client Channel with "mqc_tasco" in the MCAUSER field can only be used by the client(s) you intend, so now protect the new channel with SSL or a Security Exit.
F. Begin testing.
G. Enable Authority Events at the QM level if you get any authority errors. |
I believe he mentioned WMQ V7.1?
He needs to maintain the channel access list. Isn't by default everybody denied in V7.1? |
New QMs created in MQ 7.1 will have Channel Authentication enabled, but with only a couple of rules to start with: privelaged IDs will be blocked, and all the SYSTEM* channels are blocked. Otherwise things should work as if the QM was created at MQ 7.0 or earlier, without Channel Authentication. As long ask_anand2585 is not using a SYSTEM* channel, or trying to use a privileged ID this shoulod not be an issue.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/mi77190_.htm
To simply matters for someone trying to get access to work for the first time on a new system, I'd suggest getting things to work with Channel Authentication records turned off, to eliminate the added complexity of IDs possibly being rejected or mapped to other IDs due to some Channel Authentication records someone decided to add.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/zs14190_.htm
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 30, 2011 7:15 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| k_anand2585 wrote: |
Hi
A. Made the "mqc_tasco" ID as a domain ID, so that it has the same Windows SID regardless of which node your QM will run on in your MSCS cluster.
B. Created a new SVRCONN channel on the QM for this client .
C. Put the ID "mqc_tasco" in the MCAUSER field of the channel.
D. Grant the "mqc_tasco" ID the rights it needs via the setmqaut command.
setmqaut -m NYQT1 -n "TASCO_CLIENT" -t chl -p mqc_tasco -remove
setmqaut -m NYQT1 -n "TASCO_CLIENT" -t chl -p mqc_tasco +chg +dlt +dsp +ctrl +ctrlx
Still the message is not coming to the server |
The error message you are showing doesn't match with what you said you did in Step C.
Those are not the setmqaut commands you need. You have to grant access for the ID to the Queue Manager and to the queues you intend to use. It wouldn't hurt to have the command you did list if you intended this ID to do those things to that client channel, but I don't think that is what you want or need.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| k_anand2585 |
| Posted: Tue Jan 03, 2012 5:24 pm Post subject: |
|
|
Acolyte
Joined: 03 Nov 2011
Posts: 50
|
Hi Guys,
The issue was resolved.
First we tried to send the sample amqsputc rather than our customsied client application with trace enabled and security events enabled we were able to isolate the issue.
the user mqc_tasco was assigned to domain mqm,mqm group,domain users AND in server conenction channle in MCA i have given mqc_tasco also this time i made sure server conenction channel was les than 12 characters.
And surprisingly there was no error messge of authorisation.
With trace enabled we cud see it the user mqc_tasco getting connected to the MQ server.
Thanks for all your help specially PeterPotkay and fjb_saper.You guys are doing wonderfull work |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jan 03, 2012 5:32 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I'm a bit confused. Exactly how did you resolve this?
_________________
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 |
|
|
| k_anand2585 |
| Posted: Tue Jan 03, 2012 7:41 pm Post subject: |
|
|
Acolyte
Joined: 03 Nov 2011
Posts: 50
|
2 changes i made
1> At domain controller i added the user to domain admin which i had not done which was told by the system person
2> At MQ level i just changed the channel name to accomodate 12 words characters. also mq autorisation was given for that user to QM,Queue,Channels. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jan 04, 2012 1:30 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| k_anand2585 wrote: |
| ...1> At domain controller i added the user to domain admin which i had not done which was told by the system person... |
Why? For what reason does the ID need to be a domain admin?
_________________
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 |
|
|
|
|
