| Author |
Message
|
| exerk |
 Posted: Tue Jun 12, 2012 5:19 am Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
That says "Nobody can connect to this channel UNLESS they are using SSL.[/quote]
I thought that applied ONLY if the SSLCIPH attribute was populated?
_________________
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 Jun 12, 2012 5:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| mqjeff wrote: |
That says "Nobody can connect to this channel UNLESS they are using SSL. |
I thought that applied ONLY if the SSLCIPH attribute was populated? |
I defer your question to the documentation.
Last edited by mqjeff on Tue Jun 12, 2012 5:50 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jun 12, 2012 5:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Extracted from the InfoCenter:
SSL Client Authentication (SSLCAUTH)
SSLCAUTH is used to define whether the channel needs to receive and authenticate an SSL certificate from an SSL client. Possible values are:
OPTIONAL If the peer SSL client sends a certificate, the certificate is processed as normal but authentication does not fail if no certificate is sent.
REQUIRED If the SSL client does not send a certificate, authentication fails.
The default value is REQUIRED.
You can specify a value for SSLCAUTH on a non-SSL channel definition, one on which SSLCIPH is missing or blank. You can use this to temporarily disable SSL for debugging without first having to clear and then reinput the SSL parameters.
SSLCAUTH is an optional attribute.
_________________
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 |
|
|
| firelior |
| Posted: Tue Jun 12, 2012 6:55 am Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
| bruce2359 wrote: |
Extracted from the InfoCenter:
You can specify a value for SSLCAUTH on a non-SSL channel definition, one on which SSLCIPH is missing or blank. You can use this to temporarily disable SSL for debugging without first having to clear and then reinput the SSL parameters.
SSLCAUTH is an optional attribute. |
Well I changed it to optional, and still the same error.
I also checked on my own computer where it does work and I had the same configurations(SSL Required).
Again - My error message is:
| Code: |
AMQ9575: DCE Security: failed to get the user's login name.
EXPLANATION:
System call 192.168.50.55 to get the login name of the user running WebSphere
MQ client application process 5 failed with error value -1. This occurred in
security exit function create_cred. The exit will now attempt to open channel
using the DCE default login context.
ACTION:
If you wish to run using the DCE default login context take no action. If you
wish to run using the user's login name as the DCE security exit principal
examine the documentation for the operating system on which you are running MQ
clients and reconfigure the operating system as necessary to allow the
192.168.50.55 call to succeed. |
I believe the error has to do with something that relates to the fact that the remote server can't get the host name of my computer(The server is not in a domain).
Even when I ping to my computer like this:
ping -a 192.168.50.55
It should have resolved my host name but it doesn't
Is there any way to pass that?
why is that causing such a problem?
Can't you connect to mq websphere when you are not in the same/any domain? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 12, 2012 6:57 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| firelior wrote: |
| Can't you connect to mq websphere when you are not in the same/any domain? |
Yes, depending on whether the ability to do so has been set up, i.e. user accounts and OAM etc.
You still haven't answered my question in regard to channel names...
_________________
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 |
|
|
| firelior |
| Posted: Tue Jun 12, 2012 7:57 am Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
| exerk wrote: |
Yes, depending on whether the ability to do so has been set up, i.e. user accounts and OAM etc.
|
What do I need to set up?
| exerk wrote: |
You still haven't answered my question in regard to channel names...
|
I opened a new queue manager on the same server because I thought the problem maybe with the queue manager, but it still got me the same error.
The channel is now QM.CONN.
And I don't have any CLIENT-CONNECTION - only SERVER-CONNECTION. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 12, 2012 8:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
At this point in time, because there seems to be a mass of confusion, I strongly suggest uninstalling WMQ, clearing off every reference to it on your laptop/desktop/server/whatever, rebooting, and re-installing; then start again from scratch.
_________________
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 |
|
|
| firelior |
| Posted: Wed Jun 20, 2012 2:58 am Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
Hi again,
I tryed uninstalling, removing everything and starting again from scratch.
Nothing changed.
But because some time has passed I will specify what is my current status:
Server Side:
I have a Windows Server 2008 R2 Enterprise that runs MQ Websphere 7.1
The server has a Queue Manager named QM
and a Listener on port 1414.
The QM doesn't have any channels and I removed all the channel authentication records - so nothing blocks anything.
Client Side:
I am trying to connect using .net. with these configurations:
The ip of the client in 192.168.50.55(you will see it in the error on the server side)
| Code: |
connectionProperties.Add(MQC.HOST_NAME_PROPERTY, 192.168.50.54);
connectionProperties.Add(MQC.CHANNEL_PROPERTY, "SYSTEM.DEF.SVRCONN");
connectionProperties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
Manager = new IBM.WMQ.MQQueueManager("QM", connectionProperties);
|
The Error:
The Error on the client side:
| Code: |
MQRC_CHANNEL_CONFIG_ERROR
|
The error on the server side
| Code: |
AMQ9575: DCE Security: failed to get the user's login name.
EXPLANATION:
System call 192.168.50.55 to get the login name of the user running WebSphere
MQ client application process 5 failed with error value -1. This occurred in
security exit function create_cred. The exit will now attempt to open channel
using the DCE default login context.
ACTION:
If you wish to run using the DCE default login context take no action. If you
wish to run using the user's login name as the DCE security exit principal
examine the documentation for the operating system on which you are running MQ
clients and reconfigure the operating system as necessary to allow the
192.168.50.55 call to succeed.
|
Notes:
1. The server is not connected to any domain.
2. When installing Websphere MQ - I was asked:
"Do you need to configure a domain user ID for Websphere MQ to run under" and I selected NO. (Because the server is not in a domain)
3. These configurations works when I have the client and server on the same machine
Questions
1. Do I have to use special configurations for non domain servers on the server-connection?
Like using MCA User
2. I have no idea what else to do...any suggestions?
Thank you |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 20, 2012 3:07 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| firelior wrote: |
1. Do I have to use special configurations for non domain servers on the server-connection?
Like using MCA User |
You should be doing this anyway! Try it and see what happens, and under what user are you running the application? And, is your client machine in a domain?
_________________
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 |
|
|
| firelior |
| Posted: Wed Jun 20, 2012 6:00 am Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
I tryed doing this anyway.
But I am not sure what exactly to put there.
I tryed many things.
My client machine is running in a domain - yes. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 20, 2012 6:07 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| firelior wrote: |
I tryed doing this anyway.
But I am not sure what exactly to put there.
I tryed many things. |
Then post exactly what you did try. Did you set up a user on the server? Did you grant the required authorities to that user? Did you put that user in the SVRCONN?
| firelior wrote: |
| My client machine is running in a domain - yes. |
So the domain userid under which your app works is being flowed to a non-domain server - see any potential issues with that? BIG HINT!
_________________
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 |
|
|
| fjb_saper |
| Posted: Wed Jun 20, 2012 6:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
you are flowing user@mydomain to a machine for which the authentication has no way of checking group membership of said user.
Can you even add user@mydomain to any of the groups on the mq machine?
Does the MQ service user have rights to check membership on the domain server?
You would be better served to use MCAUser for all your SVRCONN type channels, and why don't you add SSL too as long as you are looking into the security aspect of things...
Now using the channel authority records you could also force a local userid on the message depending on whatever rule you setup... So removing all the channel access records is not necessarily a good thing... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| firelior |
| Posted: Wed Jun 20, 2012 10:43 pm Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
Thank you for your last answers, I think we are getting close..
| exerk wrote: |
So the domain userid under which your app works is being flowed to a non-domain server - see any potential issues with that? BIG HINT!
|
It is said there that:
| Quote: |
| WebSphere MQ connections to queue managers running under domain accounts on other computers might fail. |
But is there anyway to pass that? like with MCAUser?
| fjb_saper wrote: |
Can you even add user@mydomain to any of the groups on the mq machine? |
No - the server is a "stand alone", the only thing that connects it to my computer is that it is in the same subnet.
| fjb_saper wrote: |
Does the MQ service user have rights to check membership on the domain server?
|
- Again No :/
It doesn't even know of the domain..
| fjb_saper wrote: |
You would be better served to use MCAUser for all your SVRCONN type channels, and why don't you add SSL too as long as you are looking into the security aspect of things...
|
I don't want to add ssl yet, I want first to work without.
| exerk wrote: |
Then post exactly what you did try
|
What I tryed is to put in the client side:
MQC.USER_ID_PROPERTY to "Test"
and in the channel properties on the server side to put MCA USER ID to "Test"
I also did this:
| Code: |
SET CHLAUTH('QM.CONN') TYPE(USERMAP) CLNTUSER('Test') USERSRC(MAP) MCAUSER('MUSR_MQADMIN') ACTION(ADD)
|
and also tryed putting in the clntuser the domain user of the client:
| Code: |
SET CHLAUTH('QM.CONN') TYPE(USERMAP) CLNTUSER('user@domain') USERSRC(MAP) MCAUSER('MUSR_MQADMIN') ACTION(ADD)
|
QM.CONN is the name of the server-connection I added
And still - the same error :| |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jun 21, 2012 12:21 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
1. Create a new group and user local on your server, and give that group the required authorities to the resources it needs, e.g. connect to the queue manager and open etc. on queues;
2. Create a new SVRCONN channel, with the appropriate channel authorities and the user above as the MCAUSER;
3. Try your connection without MQC.USER_ID_PROPERTY set, then with MQC.USER_ID_PROPERTY set.
If you still have problems then post the definitions of the SVRCONN, the CHLAUTH, and the setmqaut commands.
_________________
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 |
|
|
| fjb_saper |
| Posted: Thu Jun 21, 2012 4:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| Code: |
SET CHLAUTH('QM.CONN') TYPE(USERMAP) CLNTUSER('user@domain') USERSRC(MAP) MCAUSER('MUSR_MQADMIN') ACTION(ADD)
|
QM.CONN is the name of the server-connection I added |
You should have to add another chlauth entry specifically allowing user MUSR_MQADMIN for the channel. The default is to refuse access to that user on any channel. (in Unix it would be mqm). So what you just did here was map the user to a user with no access...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
