| Author |
Message
|
| PeterPotkay |
 Posted: Thu Oct 10, 2013 3:50 pm Post subject: Cannot get CHLAUTH Client ID Mapping to work |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
My client is MQ 7.5.0.2 on a Windows 7 desktop.
The Queue Manager is MQ 7.5.0.2 on a RHEL 6.4 server.
CHLAUTH is enabled.
| Code: |
DISPLAY QMGR CHLAUTH CMDLEVEL
AMQ8408: Display Queue Manager details.
QMNAME(MYQM) CHLAUTH(ENABLED)
CMDLEVEL(750) |
Here’s the MQ Client channel I’m testing with on my Lab server.
| Code: |
DIS CHANNEL(PETER.TEST.1) ALL
AMQ8414: Display Channel details.
CHANNEL(PETER.TEST.1) CHLTYPE(SVRCONN)
ALTDATE(2013-10-10) ALTTIME(18.51.26)
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) DISCINT(0)
HBINT(30) KAINT(AUTO)
MAXINST(999999999) MAXINSTC(999999999)
MAXMSGL(104857600) MCAUSER(BOGUS_ID_123)
MONCHL(QMGR) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) TRPTYPE(TCP) |
And here is my CHLAUTH rule.
| Code: |
DISPLAY CHLAUTH (PETER.TEST.1) ALL
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
DESCR( ) CUSTOM( )
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123) USERSRC(MAP)
ALTDATE(2013-10-10) ALTTIME(18.58.23) |
I am logged into my PC as pp12345. And every time I connect to this queue manager over the PETER.TEST.1 channel the ID the channel runs as is BOGUS_ID_123. MQRC 2035. Authority Event message shows BOGUS_ID_123. Why is the CHLAUTH rule not kicking in and changing the connection to run as abc123?
If I blank out the MCAUSER on the channel, then I connect as pp12345. I happen to have access to some queues on this QM as this pp12345 ID and I can open those queues. If I do a channel status it shows me running as pp12345, not abc123 (see below). If I try and open some other queues I don’t have access to, MQRC 2035 and the Authority Event message shows the pp12345 ID. Again, why is the CHLAUTH rule not kicking in and changing my connection to abc123?
Nothing in the queue manager error logs.
| Code: |
display chstatus(PETER.TEST.1) all
AMQ8417: Display Channel Status details.
CHANNEL(PETER.TEST.1) CHLTYPE(SVRCONN)
BUFSRCVD(9) BUFSSENT(8)
BYTSRCVD(1628) BYTSSENT(1444)
CHSTADA(2013-10-10) CHSTATI(19.42.48)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(10.147.130.226) CURRENT
EXITTIME(0,0) HBINT(30)
JOBNAME(0000B7EF00000F73) LOCLADDR(::ffff:99.111.222.99(1414))
LSTMSGDA(2013-10-10) LSTMSGTI(19.42.49)
MCASTAT(RUNNING) MCAUSER(pp12345)
MONCHL(LOW) MSGS(2)
RAPPLTAG(ebSphere MQ\bin\amqsputc.exe)
SSLCERTI( ) SSLKEYDA( )
SSLKEYTI( ) SSLPEER( )
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(RECEIVE)
CURSHCNV(1) MAXSHCNV(10)
RVERSION(07050002) RPRODUCT(MQCC) |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Oct 11, 2013 12:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Peter, how about setting the rule to WARN and looking at the subsequent event message to see what blocked where, and why?
_________________
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: Fri Oct 11, 2013 12:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 11, 2013 1:17 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
It's not just me then...
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Oct 11, 2013 4:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I too tried to get to those articles by Morag and found the site down. But she was kind enough to include those articles in the end of her PowerPoint from the 2013 Tech Conferance.
But nothing is being blocked by CHLAUTH. I get a plain old fashioned 2035 if the MCAUSER of the channel is hard coded to a bad ID - my CHLAUTH rule didn't kick in to override it. And if the channel has a blank MCAUSER, the channel runs as my pp12345 ID, with expected success or 2035 depending on what queue I use. Again, its as if this CHLAUTH rule is completely ignored. Consequently there are no warnings to look for, nothing in the QM logs.
Its as if the rule didn't exist, or CHLAUTH was disabled. Hence why I included the display commands I did initially.
Check this out though...
| Code: |
DISPLAY CHLAUTH(PETER.TEST.1) MATCH(RUNCHECK) CLNTUSER(pp12345) ADDRESS(9.999.999.999)
ChlAuth not found
|
Not found?! In my previous post you clearly see the rule exists.
But watch this...
| Code: |
DISPLAY CHLAUTH(PETER.TEST.1) MATCH(RUNCHECK) CLNTUSER('pp12345') ADDRESS(9.999.999.999)
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123) |
So I added the quotes just around the CLNTUSER the run check command finds it, but without them it fails to get a match.
Hmmmm, this is a clue me thinks. 
Time to get some  , do a little more 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 11, 2013 4:46 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PeterPotkay wrote: |
...So I added the quotes just around the CLNTUSER the run check command finds it, but without them it fails to get a match.
Hmmmm, this is a clue me thinks.
Time to get some , do a little more |
You stated "...Queue Manager is MQ 7.5.0.2 on a RHEL 6.4 server..." and is it perhaps that pp12345 is being wrapped to upper-case?
_________________
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: Fri Oct 11, 2013 6:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| is it perhaps that pp12345 is being wrapped to upper-case? |
this was my first thought. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 11, 2013 7:02 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
When the channel does run, I see the effective User ID as lowercase pp12345.
When I try and access a queue I don't have authority to, the Authority Event contains the ID as lowercase pp12345.
I think everything is using lowercase during execution.
This morning, its working as expected. No changes were made to the channel or the CHLAUTH rules. The same test cases used yesterday that were not causing the mapping to kick in are working as expected today. The only thing done was after I posted originally I started playing with the RUNCHECK option of the DISPLAY CHLAUTH command to see what it returned. Its as if the RUNCHECK gave the QM a kick in the pants to start respecting this USERMAP CHLAUTH rule. Other CHLAUTH rules (not related to mapping User IDs) were working fine before this though. New USERMAP rules I have played with this morning all work right away as expected.
| Code: |
3 : DISPLAY CHLAUTH(PETER.TEST.1) MATCH(RUNCHECK) CLNTUSER('pp12345') ADDRESS('9.999.999.999')
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123) |
By the way, I tried this display command first without the quotes around the value in the CLNTUSER field and got “ChlAuth not found”. I guess this would be the MQSC display command folding my ID from lowercase to uppercase and PP12345 not matching pp12345, so the display command didn’t get a hit in that case. But I do believe its lowercase being used all around during execution.
I’m just puzzled why everything works normally this morning.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Oct 11, 2013 7:49 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Morag made it clear to me that in distributed, user IDs will always get converted to lower case (I was working on exits at the time). z/OS will always make the ID upper case.
MQSC command prompt always converts the command to upper case unless the params are in single quotes. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 14, 2013 4:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Interesting. I decided to play around with this some more last night. The behaviour reverted to what I had originally posted - the CHLAUTH rule to map pp12345 to abc123 was not being invoked even though I was connecting over the named channel and as that ID.
This morning its working again as expected.
My test cases are identical except for one thing I realized. When I'm working from home they don't work as expected, when I'm logged in at the office they work as expected. When I'm working from home I'm coming in over a VPN tunnel. The MQ Client connection originates from my physical laptop where I am logged in as pp12345, and the Queue Manager resides on a server inside our data center.
I originally set up the CHLAUTH rule when I was working from home and never got the expected mapping to work - my opening post. When I reported it started working, I was in the office. Last night it stopped working, I was at home. This morning its working again as I test from the office.
Even though there is no CHLAUTH rule based on IP address I did try the following when I was working from home. I RDP'ed onto an unrelated server that had MQ Client installed and repeated the same test. Even though I and my laptop were at home coming in over the VPN, my test case was executing directly on the server. The CHLAUTH rule worked. And I tried that same test this morning in the office, RDP'ing to the other server. It works. So its not IP based.
It seems the connection over VPN is doing something that causes the CHLAUTH rule to not fire. Its not IP address related, since I proved coming from different IPs doesn't matter, and there isn't an IP based CHLAUTH rule anyway. I thought maybe the ID that was sent by the client was somehow messed with over the VPN connection, but that's not it because when I tried to connect over another client channel with a blank MCAUSER and no CHLAUTH rule the ID shown in the running channel was pp12345. And if I tried to access a queue I wasn't allowed to the Authority Event showed pp12345.
Very odd. Anyone have any ideas why this is behaving like this?
I'm going to try one more time tonight from home and if the pattern persists I guess its time to run a trace on the Queue Manager for both test cases (from the office and from home) and open a PMR.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 14, 2013 11:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter saying in view of your test that the channel auth rule is not ip based is an illusion. It may not be exactly ip restricted but it may subnet restricted. I would expect all the host you RDP in from home to be in the same subnet and have a rule covering this.
However typically when connecting over VPN You use a different subnet. This may well mean that your rule is working fine.
Check what are the different ips assigned to your pc/laptop at home. Then verify the net mask and the verify the ip and netmask of a host that is working (rdp).
Then use runcheck with both the pc (rdp) ip and the vpn ip from home and see what rules are being hit.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 14, 2013 11:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
These are the only 4 CHLAUTH rules defined on this play queue manager:
| Code: |
DISPLAY CHLAUTH (*) ALL
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
DESCR( ) CUSTOM( )
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123) USERSRC(MAP)
ALTDATE(2013-10-10) ALTTIME(18.58.23)
AMQ8878: Display channel authentication record details.
CHLAUTH(MO71.ADMIN*) TYPE(BLOCKUSER)
DESCR(For MQAUSX protected channels for MO71)
CUSTOM( ) USERLIST(nobody)
WARN(NO) ALTDATE(2013-09-18)
ALTTIME(15.40.04)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
DESCR(Default rule to disable all SYSTEM channels)
CUSTOM( ) ADDRESS(*)
USERSRC(NOACCESS) WARN(NO)
ALTDATE(2013-09-13) ALTTIME(09.13.55)
AMQ8878: Display channel authentication record details.
CHLAUTH(*) TYPE(BLOCKUSER)
DESCR(Default rule to disallow privileged users)
CUSTOM( ) USERLIST(*MQADMIN)
WARN(NO) ALTDATE(2013-09-13)
ALTTIME(09.13.55)
|
I don't see how IP address has a role here. However, your idea is a good one just to confirm. I will record the IP address of my connection when I make a successful connection from home to this QM over my MO71 channel, and then post the results of the runcheck test with that IP as well as the internal IP. If there is a difference in the runcheck results that will need some explaining.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 14, 2013 2:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you tried on your usermap rule to set address('*') instead of leaving it blank? Would that have a different effect?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 14, 2013 4:42 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| Have you tried on your usermap rule to set address('*') instead of leaving it blank? Would that have a different effect? |
The MQ Explorer Wizard produces a CHALAUTH rule with blanks instead of an * if you don't specify an IP address.
Due to the difficulties of modifying existing CHLAUTH rules (Morag, we need a blog post on the nuances of modifying existing CHLAUTH rules)
I created a new channel and a new CHLAUTH rule, this time specifying an * for the IP address.
| Code: |
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.5) TYPE(USERMAP)
DESCR( ) CUSTOM( )
ADDRESS(*) CLNTUSER(pp12345)
MCAUSER(abc123) USERSRC(MAP)
ALTDATE(2013-10-14) ALTTIME(20.34.50) |
No change in behaviour. The mapping rule does not seem to exist when I'm connecting from my laptop to the QM over a VPN connection. But if I RDP into a server and make a client connection from that server to my QM the rule takes effect.
The effective UserID on a running SVRCONN channel is exactly the same as far as I can tell whether the connection originates from my laptop over a VPN or from my laptop internally (no VPN) or from an internal client server. Its always pp12345.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 14, 2013 4:51 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
Then use runcheck with both the pc (rdp) ip and the vpn ip from home and see what rules are being hit.
|
Here is the test using the IP address of the client server inside the data center. This test case has the mapping take effect, and the runcheck shows that. Actual IP address values changed to protect the innocent, although the # of digits is the same as the actual IP address.
| Code: |
DISPLAY CHLAUTH(PETER.TEST.1) MATCH(RUNCHECK) CLNTUSER('pp12345') ADDRESS('10.320.242.284')
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123) |
Here is the test using the IP address of my laptop coming in over VPN, as seen from the queue manager. This test case is the one where the mapping does NOT take effect. Actual IP address values changed to protect the innocent, although the # of digits is the same as the actual IP address.
| Code: |
DISPLAY CHLAUTH(PETER.TEST.1) MATCH(RUNCHECK) CLNTUSER('pp12345') ADDRESS('10.257.2.50')
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123)
|
According to the runcheck, and common sense, this should also cause the ID to be flipped from pp12345 to abc123, but for some crazy reason it does not.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
