| Author |
Message
|
| ivanachukapawn |
 Posted: Thu Apr 02, 2015 8:34 am Post subject: disable OAM in MQ 8.0.0.2 |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
As the MQ authentication/authorization scene in MQ 8 is anything but simple (an interactive mix of CHLAUTH, Connection Authentication, and OAM ), I decided to start with nothing - i.e. disabled connection authentication, default CHLAUTH, and disabled OAM. My plan after getting everything disabled was to begin with CHLAUTH backstop and USERMAP for clientID, and after that, to have just CHLAUTH and Connection Authentication configured for the non-privileged user where I have configured connection authentication for local OS (not LDAP) authentication.
But have a problem with disabling OAM. Apparently, (based on old mqseries.net posts - 2002 and 2011) a way to disable OAM is to remove the AuthorizationService specification in the qm.ini - I tried this:
Service:
#* Name=AuthorizationService
#* EntryPoints=14
ServiceComponent:
#* Service=AuthorizationService
#* Name=MQSeries.UNIX.auth.service
#* Module=amqzfu
#* ComponentDataSize=0
but on the QM startup, I now get this message:
AMQ7061: An expected stanza in an INI file is missing or contains errors:
Maybe OAM cannot be disabled in MQ 8.0.0.2 ?
Note: I tried commenting out the Service and ServiceComponent in qm.ini but got the same error on QM startup.[/code] |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Apr 06, 2015 5:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
rather than commenting out the stanza itself, why not try putting in blank values, particularly for the module ?
Just a wild guess, no basis in testing or docs. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Apr 06, 2015 6:45 am Post subject: Re: disable OAM in MQ 8.0.0.2 |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| ivanachukapawn wrote: |
| As the MQ authentication/authorization scene in MQ 8 is anything but simple (an interactive mix of CHLAUTH, Connection Authentication, and OAM ), I decided to start with nothing - |
You are correct in your observation that security in MQ is complicated. MQ is a complex product. Security is a complicated subject generally.
But I predict that your approach - disabling OAM first, then slowly adding security - will cause you far more effort and grief than simply addressing the known and well-documented security facilities that MQ provides.
I doubt your management and auditors will approve this approach. Disabling security is not a best-practice.
I strongly recommend that you get training. IBM offers two lecture and hands-on classes: WM207/WM209 IBM MQ System Administration, and WM212 Advanced System Administration - both for distributed platforms.
_________________
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 |
|
|
| ivanachukapawn |
| Posted: Mon Apr 06, 2015 7:35 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Bruce and Jeff,
My objective in disabling OAM was to avoid the ambiguities which are encountered when having a connection blocked while OAM, Connection Authentication and CHLAUTH are all enabled. I'm doing this testing because I found a difference in CHLAUTH functionality 7.5.0.4 vs 8.0.0.2 - (in 7.5.0.4, an IP specification is required to defeat an address ('*') backstop while in 8.0.0.2 a Morag-recommended USERMAP client record (without an IP spec) is sufficient) - I wanted to make sure that 8.0.0.2 did indeed function as specified in documentation and Morag posts. As it turned out, with FJB's help I got OAM correctly configured so I no longer needed to disable it in order to achieve clarity from testing results. Whether management would approve disabling OAM in MQ config is a moot point since I meant to disable OAM only for the testing described above and never for either lower or prod environments in the enterprise. For the record, I already have the training recommended in the Bruce post. Thank you all for your invaluable help and recommendations. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Apr 06, 2015 9:12 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Do you understand the differences in purpose between ADDRESSMAP and USERMAP?
_________________
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 |
|
|
| ivanachukapawn |
| Posted: Mon Apr 06, 2015 9:17 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Jul 08, 2015 4:36 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
somebody wrote: Do you understand the differences in purpose between ADDRESSMAP and USERMAP?
I replied: Yes. I wonder if you are aware that a UserMap record can specify an IP filter (effectively combining AddressMap and UserMap) . The pressing question for CHLAUTH in MQ7.5.0.4 is whether a pure UserMap record is sufficient to defeat an Address* BackStop rule - Morag says yes - my testing says otherwise.
However, my testing in MQ8.0.0.2 confirms Morag's "yes" answer. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jul 08, 2015 4:22 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
OAM and Chl Auth / Conn Auth are independent. After a channel has been authenticated and authorized, its effective MCA UserId is then used by OAM to authorize the Connection and any MQ objects that it opens.
If OAM authorization failures bother you, set up fairly generic profiles that allow access by Group, and then concentrate on resolving channel issues that you may have. Then, remove and set up proper OAM profiles that provide the minimum required authorization.
OAM should never be disabled.
_________________
Glenn |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Wed Jul 08, 2015 7:18 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| Despite the title of this thread, the subject of the thread since 4/6 has been CHLAUTH - I sidestepped violating any universal law and never disabled OAM. CHLAUTH is the issue - specifically the claim in documentation that the address* BackStop rule can be defeated by a more specific CHLAUTH allow rule - like a USERMAP rule (without an IP filter). The claim is valid for MQ8.0.0.2 but not for MQ7.5.0.4 according to my testing. |
|
| Back to top |
|
|
| cgache |
| Posted: Fri Jan 27, 2017 6:41 pm Post subject: |
|
|
Apprentice
Joined: 27 May 2013
Posts: 28
Location: Sydney, AUS
|
| ivanachukapawn wrote: |
| Despite the title of this thread, the subject of the thread since 4/6 has been CHLAUTH - I sidestepped violating any universal law and never disabled OAM. CHLAUTH is the issue - specifically the claim in documentation that the address* BackStop rule can be defeated by a more specific CHLAUTH allow rule - like a USERMAP rule (without an IP filter). The claim is valid for MQ8.0.0.2 but not for MQ7.5.0.4 according to my testing. |
why not just disable Channel Auth to solve your issue? although a quick work around but wouldnt recommend it long term.. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jan 28, 2017 5:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| cgache wrote: |
why not just disable Channel Auth to solve your issue? although a quick work around but wouldnt recommend it long term.. |
Because the issue was not authorization or channel auth as such, the issue was the difference in behavior between the 2 stated versions... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
