| Author |
Message
|
| nic3500 |
 Posted: Tue Dec 02, 2014 6:38 am Post subject: MQ Explorer from Windows to Linux, long user name |
 |
|
Newbie
Joined: 22 May 2013
Posts: 5
|
Greetings, here is the situation.
- On windows, MQ Explorer V7.5. No local queue manager.
- On Windows, my username is nicsuperlongname (enforced by my domain admins).
- On Linux (RHEL 6), MQ 7.5.
- On Linux, my username is nicsuper (max 8 chars, enforced by Unix team).
- nicsuper is in group mqm. I can use MQExplorer using my nicsuper user if I start it directly on Linux. I can administer everything.
I am trying to setup remote administration. I want to user MQ Explorer on Windows to administer that queue manager.
I ALWAYS get an AMQ4036 error. What I figured out already:
- there is a SYSTEM.ADMIN.SVRCONN on the queue manager.
- I think my user nicsuperlongname is being sent to MQ and since that user does not exist on Linux it does not work.
- So I configured my remote connection in MQ Explorer to enable user identification. In there I put my nicsuper Linux user name and password. Still same error.
- I even used BlockIP2 to let user nicsuperlongname in. I go through BlockIP2 correctly but when I get to the queue manager, same 4036 error.
So I think something needs to be done on the queue manager to allow the user nicsuper to administer the queue manager remotely? Do you have any idea what that could be?
Thanks Nic |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Dec 02, 2014 6:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQ 7.5 doesn't authenticate username/password.
What you want to do is put in a CHLAUTH rule, or more than one, that matches the SVRCONN you're using (which shouldn't be the default) and maps your IP address or etc. to the nicuser in the MCA.
Then you need to create a blockuser rule that fails to block the nicuser and matches your svrconn more tightly than the default rule which blocks everyone in the mqm group. |
|
| Back to top |
|
|
| nic3500 |
| Posted: Tue Dec 02, 2014 8:06 am Post subject: |
|
|
Newbie
Joined: 22 May 2013
Posts: 5
|
| Any good FM I could RTFM on that stuff? I was out of the MQ game for 3 years, and I have to catch up... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Dec 02, 2014 8:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
there are some lovely blog/devworks articles by Morag Hughson. Some poking around here should pop up some direct links, or searching on IBM's site may find them.
Or she may pop in here and provide direct links. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 02, 2014 9:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I think MQ only looks at the 12 character truncated userid (in lower case) on Unix hosts.
I would suggest logging connections in BlockIP2 so you can see what id comes to the exit. Also enabling authority events on the QMGR so you can see the cause of MQRC 2035 errors.
You can use BlockIP2 to truncate your Windows userid if you want to avoid having to define the 12 character name on the Unix host.
CON=*;nicsuperlong*;MCA=nicsuper;
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| nic3500 |
| Posted: Tue Dec 02, 2014 9:58 am Post subject: |
|
|
Newbie
Joined: 22 May 2013
Posts: 5
|
| Hi Zpat, I tried that, the then the MCA user gets blocked by the other security mechanisms. That is what I am trying to solve. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 02, 2014 10:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nic3500 wrote: |
| Hi Zpat, I tried that, the then the MCA user gets blocked by the other security mechanisms. That is what I am trying to solve. |
You need to find Morag's blog links. They've been referenced in a number of posts in here.
Essential information on the v7.5 security
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Dec 02, 2014 11:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 02, 2014 11:20 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Well obviously the nicsuper id has to be able to access MQ.
That's easy - ensure it's defined on unix, in an appropriate unix groups and granted access to the QM via ACLs (if not in the mqm group).
Disable CHLAUTH if you don't want to add any rules for now.
As I said - enable authority events and look at the event messages to see why the MQRC 2035 occurs.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 03, 2014 2:38 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
| As I said - enable authority events and look at the event messages to see why the MQRC 2035 occurs. |
Or check the queue manager log for the failure entries...
_________________
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 |
|
|
| zpat |
| Posted: Wed Dec 03, 2014 3:18 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
QM log doesn't always show them unfortunately.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 03, 2014 3:40 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
| QM log doesn't always show them unfortunately. |
Which is why I always recommend setting the MQS_REPORT_NOAUTH environment variable - it's generally a lot quicker than naffing around with event messages.
_________________
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 |
|
|
| zpat |
| Posted: Wed Dec 03, 2014 5:03 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
That doesn't always work either.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Dec 03, 2014 5:12 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
| That doesn't always work either. |
Really? And was a PMR raised?
_________________
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 |
|
|
| zpat |
| Posted: Wed Dec 03, 2014 5:32 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Life's too short when event messages work fine.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
