| Author |
Message
|
| dwmllr |
 Posted: Tue Jul 31, 2012 2:08 am Post subject: .Net MQ Client Connection Authentication Failure |
 |
|
Newbie
Joined: 31 Jul 2012
Posts: 5
|
Hello
I've been searching the forums and will continue doing so, just posting to ask help for the specific issue I have since I am under pressure to get an installation up and running with the client on my neck.
I have a C# application (using the amqmdnet.dll libraries) on a Win 2008 machine which has v7.0.1.8 of the MQ client installed trying to connect to a remote QM. We were supplied a user name and pwd for the connection to the QM, created a local account with the same user name and run the client application under that user name.
We don't have direct access to the QM box to investigate but were sent some logs from the QM admin, the entry resulting from our connection attempt looks as follows:
[2012/07/31 14:51:43.446][10.113.85.140][QMGRTST][SYSA.SVRCONN][theusr][Authentication Failure][[compat]: 3004-300 You entered an invalid login name or password. ][]
theusr is the user name which our client application is run under. Tried setting MQC.USER_ID_PROPERTY and MQC.PASSWORD_PROPERTY in the properties passed to the queue manager constructor with no success - from what I've read these are not sent to the queue manager and have no effect.
Any suggestions about how I can pass the user and password we were provided or how else I need to go about creating the client connection will be appreciated.
Regards
Dave |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Jul 31, 2012 2:25 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Looks like a mainframe QM. Do they use a security exit?
Does the userid exist in RACF, is it defined in upper case?
Is the password convertible between ASCII and EBCDIC? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jul 31, 2012 2:43 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
| Looks like a mainframe QM |
Mainframe queue manager names are only ever 4 (four) characters in length - it's a z/OS sub-system thing - so if QMGRTST is the name it would have to be zLinux, in which case, would it use RACF?
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Jul 31, 2012 4:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
That doesn't appear to be an MQ error message or system log message as far as I know.
Ask your MQ Admin to set an MCAUSER on the SVRCONN you are using. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 31, 2012 4:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| That doesn't appear to be an MQ error message or system log message as far as I know. |
Likewise with @zpat - I'd ask if there's a security exit in use. Or if the target queue manager is using LDAP or similar to authenticate users rather than the OS.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dwmllr |
| Posted: Tue Jul 31, 2012 8:46 am Post subject: ! |
|
|
Newbie
Joined: 31 Jul 2012
Posts: 5
|
Thank you for all the replies, I still have a lot to learn about MQ security so any help is appreciated, being in a situation where one has no access to the MQ server to search logs etc. makes things a bit more tricky.
I don't know the source of the log file, its name suggested it was a "MQServer Authentication Log", will try and find out. What I do know now is that the MQ server host is running AIX, don't know yet if some sort of central authentication is in use.
The authentication requirement has since been "disabled" (again - don't know what that entails) for the channel I am connecting on and the data started flowing .... will have to cross that bridge soon though.
Thanks again! |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 31, 2012 8:50 am Post subject: Re: ! |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dwmllr wrote: |
| I don't know the source of the log file, its name suggested it was a "MQServer Authentication Log", will try and find out. What I do know now is that the MQ server host is running AIX, don't know yet if some sort of central authentication is in use. |
Note that base WMQ doesn't use any password supplied to it (it authorizes rather than authenticates a user) so even the text of that message sounds like something other than WMQ.
Also 8 out of 10 AIX admins who expressed a preference said their boxes used LDAP to control users. I'm just sayin'...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dwmllr |
| Posted: Wed Aug 01, 2012 7:06 am Post subject: |
|
|
Newbie
Joined: 31 Jul 2012
Posts: 5
|
Spoke with the QM admin today and learned that the authentication is implemented by a security exit.
Now from what I read thus far trying to populate credentials from within my .Net application (or any non-Java app) will get me nowhere since such credentials do not reach the QM.
It is also my understanding that one possible solution would be to implement a security exit on our client-side. Is this correct and are there any alternatives?
Thank you for the information thus far - it helped me ask the right questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 01, 2012 7:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The User Id and Password fields should in theory actually reach the security exit on the other side.
That assumes that the security exit on the other side trusts those fields... |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 01, 2012 7:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| dwmllr wrote: |
| Spoke with the QM admin today and learned that the authentication is implemented by a security exit. |
Hah!
| dwmllr wrote: |
| Now from what I read thus far trying to populate credentials from within my .Net application (or any non-Java app) will get me nowhere since such credentials do not reach the QM. |
Such credentials should however reach the security exit. What reaches the queue manager is the result of whatever actions the security exist takes.
Why not ask the admin who told you about the security exit how it expects credentials to be delivered to it? You can't be the only person trying to connect to this queue manager so the admin must have explained to other people how to do it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| dwmllr |
| Posted: Wed Aug 01, 2012 11:31 am Post subject: |
|
|
Newbie
Joined: 31 Jul 2012
Posts: 5
|
Thank you Vitor. Please let me know if I am heading in the right direction:
My understanding is that the security exit provides handles to two structures (exit parameters and channel parameters) as well as a data buffer and some offset and length parameters for the buffer and that it is up to the implementer of the client-connection exit to agree with the implementer of the server-side exit on how certain information (e.g. user credentials) will be represented in the buffer. Is this what you mean by asking the admin how the security exit expects the credentials to be delivered?
I've found the following article which describes how exits can be implemented in .Net. If my understanding as above is correct I will find out from the admin how the credentials need to be populated and attempt implementing a security exit in this manner.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzav.doc%2Fun10580_.htm |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 01, 2012 11:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| dwmllr wrote: |
Thank you Vitor. Please let me know if I am heading in the right direction:
My understanding is that the security exit provides handles to two structures (exit parameters and channel parameters) as well as a data buffer and some offset and length parameters for the buffer and that it is up to the implementer of the client-connection exit to agree with the implementer of the server-side exit on how certain information (e.g. user credentials) will be represented in the buffer. Is this what you mean by asking the admin how the security exit expects the credentials to be delivered? |
Yes, and what I meant by "if the security exit trusts these fields".
Again, you may or may not need to write an exit on your side. But no progress can be made until you determine what the exit on the other side is expecting. That is the significant downside to security exits, and why it is generally better to use built-in functionality - like SSL and MCAUSER and the new chlauth stuff in 7.1 and later. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 01, 2012 12:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| you may or may not need to write an exit on your side. |
| mqjeff wrote: |
| But no progress can be made until you determine what the exit on the other side is expecting. |
| mqjeff wrote: |
| That is the significant downside to security exits, and why it is generally better to use built-in functionality - like SSL and MCAUSER and the new chlauth stuff in 7.1 and later. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 01, 2012 12:39 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| I noticed that a security exposure APAR had been issued on the new CLAUTH feature recently. Apply the latest fixpack. |
|
| Back to top |
|
|
|
|
