| Author |
Message
|
| pmbsa2 |
 Posted: Thu Apr 28, 2011 12:52 am Post subject: 2035 .net 3.5 Security Problems |
 |
|
Novice
Joined: 24 Jun 2009
Posts: 21
|
Hi, I am struggling to make a server connection to my Queue manager from a .net 3.5 application, I am hoping somebody has seen this before.
In the code I am setting the userid to pass through but that seems to be ignored, instead the name of the box with a $ on the end is used which then fails because that ID doesnt exist and certainly has no mqm access. This is what I am seeing in the Trace anyway.
Is there any way to force the username property to be used, I have tried with both MQEnvironment.UserId = userID; and setting MQC.USER_ID_PROPERTY, the effect is the same.
any advice would be appreciated.
thanks
Paul |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Apr 28, 2011 12:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Plan your solution using something other than userids. |
|
| Back to top |
|
|
| pmbsa2 |
| Posted: Thu Apr 28, 2011 1:11 am Post subject: |
|
|
Novice
Joined: 24 Jun 2009
Posts: 21
|
| Hi, thanks for the reply but could you elaborate a little please? I am a bit of a novice. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 28, 2011 1:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQ security generally only provides authorization and not authentication.
You can set up SSL with MQ channels to allow you to use the certificate to provide authorization - "we know this is who they say they are because we trust the certificate" - and then use the OAM to provide authorization to a role specific ID.
In MQ terms, you would set SSLPEER on the svrconn to ensure that only certificates with correct distinguished names are allowed to connect to the channel.
And then you would use MCAUSER to force anyone connecting to a given SVRCONN into a role specific ID.
If you try to rely on the client to present a username, you are basically leaving the network open, because you can't generally trust that the client is who they say they are. |
|
| Back to top |
|
|
| pmbsa2 |
| Posted: Thu Apr 28, 2011 3:23 am Post subject: |
|
|
Novice
Joined: 24 Jun 2009
Posts: 21
|
thanks for that. I was wondering if there is a simpler way, perhaps if I descried what I am trying to do there may be alternatives.
The idea is to create a bridge between SQL Service Broker and MQ, in effect I will have an instance of SQL Server running on the same box as MQ.
I am simply writing some C# code to connect to a local QManager, take a message from Service Broker and put it to MQ.
It needs to be as simple and light weight a bridge as is humanly possible.
thanks
Paul |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 28, 2011 3:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Right, then ignore the userid and just set an MCAUSER on the channel used from SQL Server. |
|
| Back to top |
|
|
| pmbsa2 |
| Posted: Thu Apr 28, 2011 4:10 am Post subject: |
|
|
Novice
Joined: 24 Jun 2009
Posts: 21
|
Thanks, I have tried that, I still get 2035 unfortunatly. I have noticed in the event log that I get a warning message if I dont set a userID on the connections properties, perhaps that might be whats causing the problem.
'Authorization failed as the SID 'S-1-5-20' does not match the entity 'cod1069$'.
The Object Authority Manager received inconsistent data - the supplied SID does not match that of the supplied entity information.
Ensure that the application is supplying valid entity and SID information.'
What I dont get is that if I set a username the warning on the event log goes away, but no matter what I set it to the MQ trace indicates that the username passed to MQ is COD1069$ so I am completely confused as to what it actually needs.
I have MQC.TRANSPORT_PROPERTY set to MQC.TRANSPORT_MQSERIES_BINDINGS, I believe that is correct dor SERVER connections.
thanks
Paul |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 28, 2011 4:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you are using BINDINGS, then the qmgr must be on the same machine.
And then you aren't using a channel at all.
In that case, you must issue setmqaut commands for the user running the program, and don't need to set anything in userid.
In general, ignore the userid field you are setting. |
|
| Back to top |
|
|
| pmbsa2 |
| Posted: Thu Apr 28, 2011 4:17 am Post subject: |
|
|
Novice
Joined: 24 Jun 2009
Posts: 21
|
aah ok, thanks. The QM is on the same machine so I will give that a go and see where I end up.
thanks
Paul |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 28, 2011 1:30 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If the QM is on the same server, then you can connect in bindings mode (no client channel in use), or in client mode (even though you are on the same server, you opt not to use bindings mode and choose to client mode to the same server).
If the app is on a seperate server from the QM, then you will have to use client mode to connect directly to that QM - there is no choice of bindings mode to that remote QM.
Just wanted you to be aware that just because you are on the same server as the QM, doesn't mean 100% that you are bindings mode. Although it does seem likely in your case.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 28, 2011 2:16 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| PeterPotkay wrote: |
| If the QM is on the same server... |
Same server == in the same instance of the o/s. Server-bindings creates cross-memory calls from the app to the qmgr. The app and qmgr must be in the same o/s image for serve-bindings to succeed.
Client-bindings creates network calls from the app to the qmgr. The app and qmgr may be in the same o/s instance, OR need not be in the same o/s instance.
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Apr 29, 2011 11:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| PeterPotkay wrote: |
| If the QM is on the same server, then you can connect in bindings mode |
Yes, but pmbsa2 said that they WERE connecting in Bindings mode, and so the QM MUST be on the same machine. |
|
| Back to top |
|
|
| pmbsa2 |
| Posted: Mon May 09, 2011 2:04 am Post subject: |
|
|
Novice
Joined: 24 Jun 2009
Posts: 21
|
| Yup, all on the same server. I have it all sorted out now thanks. Direct Server connection. The issue was with the User that runs SQL Server Express in the end. |
|
| Back to top |
|
|
|
|
