| Author |
Message
|
| fjb_saper |
 Posted: Tue Oct 15, 2013 4:16 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Time for a trace and PMR, I think. 
One more thought... 'userid' is not equal to 'userid@mydomain' as the authorization is bein done on the sid.
May be the sid you are passing as VPN linked is different from the Sid being passed when you are RDP'd ??
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Tue Oct 15, 2013 5:52 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Peter, I know you may have already done this but do the results of the following command differ when you use the two different access methods?
Also, on the connection that fails, what happens when you login to yourself again or su to an equally permitted account?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Oct 15, 2013 7:19 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
One more thought... 'userid' is not equal to 'userid@mydomain' as the authorization is bein done on the sid.
May be the sid you are passing as VPN linked is different from the Sid being passed when you are RDP'd ??
|
Going on the theory that the SID presented when I am logged on from home is different than the SID presented when I am logged in at work, even though I type in the same ID and password into the same physical laptop in both case, it could make sense that pp12345 is not equal to pp12345 when it comes time for the QM to do its thing with that ID. HOWEVER….
A. The Queue Manager in this scenario is running on Linux. Does that eliminate the Windows SID from the conversation?
B. When I use a second channel that has a blank MCAUSER and no CHLAUTH rule that covers that channel name, I can connect to the QM, whether its pp12345 logged on at work or pp12345 logged on at home. I can access the queues my group membership says I can, and I get the 2035s I’m supposed to when I try to access a queue I’m not supposed to. Why would CHLAUTH be sensitive to SIDs (if they are in play at all, see point A) but the setmqaut rules don’t care?
When I log on at home I’m logging into my laptop before I establish the VPN, logging into the ‘domain’ and not the local laptop name, so cached credentials are in play. Once my VPN is established I do execute my log on script again to establish my shared drive mappings, and I assume to log into my domain again, this time for real. So I’ll buy the idea that the SID being presented over the client connection is different when I’m coming in over the VPN. But why would setmqaut rules be immune to that (which have historically been very sensitive to SIDs in my experience) but the CHLAUTH rules get tripped up by it?
At least this problem is consistent. I’ve repeated it 3 different days/nights. Things work just fine on the intranet, but the CHLAUTH rule for User mapping fails to fire when dealing with a connection over a VPN. I’m building a new QM today on a new server and will test against it. If it works the same way against a second QM its PMR time.
On the MQ List Serve, before I clarified that I was using a non Windows QM, T.Rob suggested:
| Quote: |
| “So, whip up a SVRCONN with no mapping and put user@domain-or-host in the MCAUSER and keep changing the domain-or-host part until you find one that works. Then put that fully-qualified value in the channel mapping rule for your target channel. If the client-facing part of the CHLAUTH (the part that evaluates the client ID on the connection) is resolving strings, this will work all the time. If not you'd actually have to know all the user@host and user@domains that could be sent in.” |
I can’t create a channel with pp12345@myhost because the MCAUSER field is restricted to 12 characters on non Windows platforms. This being a Linux queue manager I would only be able to get in the first few letters of the host name.
A channel with pp12345@mydomain in the MCAUSER allows me to connect and I see the channel running as pp12345@mydomain. Reminder: Another channel with a blank MCAUSER and no CHLAUTH rule runs as pp12345 (no domain appended), whether I connect from home or the office.
I set up a new channel with a Bogus ID in the MCAUSER.
I then set up a CHLAUTH rule looking for pp12345@mydomain to match against for this new channel.
| Code: |
DISPLAY CHLAUTH (PETER.TEST.6) ALL
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.6) TYPE(USERMAP)
DESCR( ) CUSTOM( )
ADDRESS(*) CLNTUSER(pp12345@xxx)
MCAUSER(abc123) USERSRC(MAP)
ALTDATE(2013-10-15) ALTTIME(08.48.24) |
The rule does not see the client connection as a match. I am in the office right now. The connection is rejected and the user ID in the Authority Event message is the bogus ID hard coded in the channel. Sooooooo, this says to me the CHLAUTH is behaving slightly differently than setmqaut / OAM but we (or at least I) already suspected that.
Apparently pp12345 or pp12345@domain are being treated the same by the OAM, but CHLAUTH is somehow seeing things differently.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Oct 15, 2013 7:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| smdavies99 wrote: |
Peter, I know you may have already done this but do the results of the following command differ when you use the two different access methods?
Also, on the connection that fails, what happens when you login to yourself again or su to an equally permitted account? |
If I go directly to the Linux server and log in as pp12345 and do a whoami, I get pp12345.
I'm not clear on what you're suggesting / asking in your second statement. The topology is I am using my Windows Laptop to make an MQ Client connection to a QM on a Linux server. And I also RDP into a Windows Server as a seperate test case for making a client connection from that Windows server to the Linux QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 15, 2013 4:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
If I go directly to the Linux server and log in as pp12345 and do a whoami, I get pp12345.
I'm not clear on what you're suggesting / asking in your second statement. The topology is I am using my Windows Laptop to make an MQ Client connection to a QM on a Linux server. And I also RDP into a Windows Server as a seperate test case for making a client connection from that Windows server to the Linux QM. |
The oam makes no difference (setmqaut) because this is entirely in the Linux/Unix realm. The chlauth makes a difference because at that time the translation from Windows to Unix id has not yet happened.
So if you set up your rule for clientId = myid@mydomain and mcaUser = mymcauser do you always get the same result? Are you always sending the same myid@mydomain?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 15, 2013 4:14 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
If I go directly to the Linux server and log in as pp12345 and do a whoami, I get pp12345.
I'm not clear on what you're suggesting / asking in your second statement. The topology is I am using my Windows Laptop to make an MQ Client connection to a QM on a Linux server. And I also RDP into a Windows Server as a seperate test case for making a client connection from that Windows server to the Linux QM. |
The oam makes no difference (setmqaut) because this is entirely in the Linux/Unix realm. The chlauth makes a difference because at that time the translation from Windows to Unix id has not yet happened.
So if you set up your rule for clientId = myid@mydomain and mcaUser = mymcauser do you always get the same result? Are you always sending the same myid@mydomain?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Oct 15, 2013 5:02 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| fjb_saper wrote: |
Time for a trace and PMR, I think.
One more thought... 'userid' is not equal to 'userid@mydomain' as the authorization is bein done on the sid.
May be the sid you are passing as VPN linked is different from the Sid being passed when you are RDP'd ??
Have fun |
FWIW, IBM SupportPac MA0Z can be defined on the SVRCONN channel as a Receive and Send exit. It will show the userid and ip address that are flowed from the Client at connect time.
MQ trace will also show the TCP packets to and fro.
_________________
Glenn |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Oct 15, 2013 5:15 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
The oam makes no difference (setmqaut) because this is entirely in the Linux/Unix realm. The chlauth makes a difference because at that time the translation from Windows to Unix id has not yet happened.
|
Documented anywhere? Or just an educated guess? Seems logical, but see below. The test does not support the theory.
| fjb_saper wrote: |
So if you set up your rule for clientId = myid@mydomain and mcaUser = mymcauser do you always get the same result? Are you always sending the same myid@mydomain? |
| peterpotkay wrote: |
I set up a new channel with a Bogus ID in the MCAUSER.
I then set up a CHLAUTH rule looking for pp12345@mydomain to match against for this new channel.
| Code: |
DISPLAY CHLAUTH (PETER.TEST.6) ALL
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.6) TYPE(USERMAP)
DESCR( ) CUSTOM( )
ADDRESS(*) CLNTUSER(pp12345@xxx)
MCAUSER(abc123) USERSRC(MAP)
ALTDATE(2013-10-15) ALTTIME(08.48.24) |
The rule does not see the client connection as a match. I am in the office right now. The connection is rejected and the user ID in the Authority Event message is the bogus ID hard coded in the channel. |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 15, 2013 9:39 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
The rule does not see the client connection as a match. I am in the office right now. The connection is rejected and the user ID in the Authority Event message is the bogus ID hard coded in the channel. |
Is that substantiated by he runcheck ?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 16, 2013 4:28 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| PeterPotkay wrote: |
The rule does not see the client connection as a match. I am in the office right now. The connection is rejected and the user ID in the Authority Event message is the bogus ID hard coded in the channel. |
Is that substantiated by he runcheck ? |
RUNCHECK gets a hit in that case.
| Code: |
DISPLAY CHLAUTH(PETER.TEST.6) MATCH(RUNCHECK) CLNTUSER('pp12345@xxx') ADDRESS('11.222.3.44')
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.6) TYPE(USERMAP)
ADDRESS(*) CLNTUSER(pp12345@xxx)
MCAUSER(abc123)
|
yet when I connect over that channel, logged into my laptop at work into the xxx domain, the actual connection does not cause this CHLAUTH rule to fire. I need to repeat this test over a VPN connection from home. At least at work, the domain is not something that should be appended to the CLNTUSER in teh CHLAUTH rule for this non Windows Queue Manager.
I have yet to see an example or documentation anywhere that uses a domain qualified ID in the CLNTUSER field in a CHLAUTH rule.
Still at work, connecting over another channel with another CHLAUTH rule where the CLNTUSR is specified without the domain it works as expected, but only at work. That fails to map as expected over a VPN connection, the actual problem that started this whole thread.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Oct 16, 2013 7:25 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Sorry I missed this thread earlier - was out of the office for a few days.
I find the easiest way to diagnose these types of issues is to set a CHLAUTH rule to make the connection you are trying to map fail. For example:-
| Code: |
| SET CHLAUTH('PETER.TEST.6') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) |
and then look at the error message that is in the AMQERR01.LOG.
This will show you all the bits that we are using to match against in the CHLAUTH rules. For example it will end with:-
| Code: |
| The active values of the channel were 'CLNTUSER(pp12345)'. |
This will show you value that the CHLAUTH matching is working against. For client users, CHLAUTH matches against the LongMCAUser which is the unpolluted version of the user ID, i.e. it is the one that hasn't been upper cased or lower cased (depending on platform).
If you make a rule with the same value as that - it should match. If it doesn't, I would go the PMR route too!
Cheers
Morag
P.S. Saw your comment about blog post suggestion - Noted!
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 16, 2013 9:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hughson wrote: |
I find the easiest way to diagnose these types of issues is to set a CHLAUTH rule to make the connection you are trying to map fail. For example:-
| Code: |
| SET CHLAUTH('PETER.TEST.6') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) |
and then look at the error message that is in the AMQERR01.LOG.
This will show you all the bits that we are using to match against in the CHLAUTH rules. |
Good idea. I created a new channel without any restrictions and a blank MCAUSER. I used amqscnxc and was able to connect. I created the rule to ADDRESSMAP any connection to NOACCESS and used amqscnxc. MQRC 2035 as expected and the MQ Error log entry shows:
| Quote: |
The inbound channel 'PETER.TEST.3' was blocked from address '11.222.3.444'
because the active values of the channel matched a record configured with
USERSRC(NOACCESS). The active values of the channel were 'CLNTUSER(pp12345)'.
|
That was while logged in at work where things work as expected. The next time I'm connected over VPN I will try and connect over this channel and see with the entry in the log is. If its the same pp12345 then we got a real mystery and its PMR time. If it shows the ID in some other format then hopefully it will be clear how to define the rule to catch that.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 16, 2013 4:30 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Success!!! 
When I got home I tried to connect over the channel that had this CHLAUTH rule block all connections on it.
| Code: |
DISPLAY CHLAUTH (PETER.TEST.3) ALL
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.3) TYPE(ADDRESSMAP)
DESCR( ) CUSTOM( )
ADDRESS(*) USERSRC(NOACCESS)
WARN(NO) ALTDATE(2013-10-16)
ALTTIME(12.48.04) |
The above rule was suggested by Morag as sort of a diagnostic rule that was expected to fail, but in the process would record the incoming ID. Apparently the only way to get this info short of a running a trace.
The connection attempt from home over VPN failed as expected with a 2035, and the QM error log recorded this:
| Code: |
AMQ9777: Channel was blocked
EXPLANATION:
The inbound channel 'PETER.TEST.3' was blocked from address '11.222.333.444'
because the active values of the channel matched a record configured with
USERSRC(NOACCESS). The active values of the channel were 'CLNTUSER(PP12345)'. |
The connection attempt from the office (no VPN involved) failed as expected with a 2035, and the QM error log recorded this:
| Code: |
AMQ9777: Channel was blocked
EXPLANATION:
The inbound channel 'PETER.TEST.3' was blocked from address '11.111.77.444'
because the active values of the channel matched a record configured with
USERSRC(NOACCESS). The active values of the channel were 'CLNTUSER(pp12345)'.
|
Over the Intranet the ID is presented as lowercase pp12345, and over VPN as uppercase PP12345. Why the difference?!
MQ Client is MQ 7.5.0.2 on Windows 7 Laptop
MQ Server is MQ 7.5.0.2 on Red Hat Linux server.
At this point its obvious I needed a rule to cover both IDs, upper and lower case.
So back to the original channel PETER.TEST.1 and its CHLAUTH rule, er, rules we go.
| 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-16) ALTTIME(20.06.46)
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) |
And the connection from home over the VPN finally gets mapped by the new rule that looks for upper case PP12345. Just need to verify that the other rule for the lowercase pp12345 will still work for when I'm in the office and not using VPN.
So I learned a good diagnostic trick (thanks Morag!), and we apparently got a pair of rules in place that cover both scenarios now. The big question is: Why is the ID's case changing simply by using VPN or not?
And is this only specific to CHLAUTH? Because the OAM never got tripped up by this - it would allow or reject my access to queues as expected regardless of from where I was connected if I was using a channel not dealing with the CHLAUTH rule.
And Morag, in your upcoming post on how to maintain existing CHLAUTH rules, could you also include the use case where we have 2 rules with the same exact name like above? How would I specify which one I wanted to edit or delete if they both have the same name and are of the same type?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 16, 2013 7:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Peter, I believe for the delete command you have then to get specific (adding the clntuser) until you can distinguish between the 2. Did you try it?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Oct 17, 2013 1:00 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| PeterPotkay wrote: |
| And Morag, in your upcoming post on how to maintain existing CHLAUTH rules, could you also include the use case where we have 2 rules with the same exact name like above? How would I specify which one I wanted to edit or delete if they both have the same name and are of the same type? |
Yup - will do 
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
