Comments (11)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 SteveWebb commented Permalink

Updated in 3 spots to add USERSRC(NOACCESS) to the examples.

2 rathnak commented Permalink

Can you please help me on the below doubt.

How can i allow an ID if its connecting from a particular IP or two? For example, connection should be allowed only if user ID 'mango' connects from IP and from no other IPs.
Also is there anyway i can couple multiple sets of same kind? like two or three ids and from specific IPs.
I can achieve this using BlockIP but using chlauth, i am not sure about the same using chlauth.
Thanks in advance.

3 Morag Hughson commented Permalink

Hi Rathnakaran,

You can allow client-side user ID 'mango' in from IP address with this rule - this assumes that running the SVRCONN as 'mango' is what you want to do (and that 'mango' is not a privileged user ID). If you also have the backstop rule in place then that covers the "and from no other IPs" requirement.
SET CHLAUTH(channel-name) TYPE(USERMAP) CLNTUSER('mango') ADDRESS('') DESCR('Allow mango in only from this IP') USERSRC(CHANNEL)
You can have as many lines like this in your CHLAUTH configuration as you have user IDs or IP address to state. Each CHLAUTH line like the above is similar to a BlockIP2 configuration file line.

4 ivanachukapawn2 commented Permalink

You wrote:
Now that we have closed the door on all remote connections we can start to put more specific rules in place to allow certain connections in. Here are some examples:

SET CHLAUTH('*.SVRCONN') TYPE(USERMAP) CLNTUSER('mhughson') MCAUSER('hughson@hursley')
question: are these examples meant to be a list - any one of which could be used successfully as a positive exception to the strong backstop_rule?

5 Morag Hughson commented Permalink

Hi John,

The list of CHLAUTH examples is a list of possible rules you might put in place to allow in connections. You are correct that any one of them would be a positive exception to the back-stop rule.

6 ivanachukapawn2 commented Permalink

I created a BackStop-Rule as recommended by you.

Then I created an 'allow' rule very similar to your example:
your example: SET CHLAUTH('*.SVRCONN') TYPE(USERMAP) CLNTUSER('mhughson') MCAUSER('hughson@hursley')
however, connection attempts made by appID on channel QMGRNAME.SVRCONN were blocked by the BackStop-Rule. I described this problem on and renowned MQ guru fjb_saper replied
"The usermap rule should be sufficient. But you neglected to specify the IP in the usermap. Which means the backstop rule wins... " - in other words, I believe fjb_saper is asserting that in order to defeat a address *-based backstop-rule, you must specify an address (or subnet) in the address field of the USERMAP CHLAUTH record. Your example USERMAP record has no address specified - is this an oversight?

7 Morag Hughson commented Permalink

You don't need to add an IP Address to a USERMAP rule in order for it to win over the backstop rule. Are you sure your connection is being blocked by the backstop rule and not by the *MQADMIN privileged user banning rule that is there by default? What does your error message say? If appID is in the mqm group then it would be blocked by that. I have other posts about how privileged user IDs are treated, you should have a read of them.

8 ivanachukapawn2 commented Permalink


This is getting 'curiouser and curiouser'. The guru was quite specific in his assertion ( that if the backstop rule is address *, then in order to defeat it you need an IP/Host specification. A specific quote from fjb is:
"It depends on what the backstop rules relies.
Say you have a backstop rule relying on ip *=> all ips are blocked.
So you have a more specific usermap rule with no ip information.
Backstop rule still in effect!.
If you add ip information to your usermap then the backstop rule is overlayied by the more specific usermap rule. "
Morag, to answer your questions:
Q Are you sure your connection is being blocked by the backstop rule and not by the *MQADMIN privileged user banning rule that is there by default?
A I'm sure. The app ID is non-privileged and is not in the 'mqm' group
Q What does your error message say?
A Not sure I remember the message from before I applied the fix - might have been 2035 Not Authorized
Q Are you sure your connection is being blocked by the backstop rule?
A When IP not specified, the connection gets blocked by the backstop rule. (I ran Match (RUNCHECK) ALL), and then, when I specify a subnet in the address field, I do get the connection.

9 Morag Hughson commented Permalink

I am quite sure :-) The TYPE(ADDRESSMAP) is less specific than a TYPE(USERMAP) or indeed any other TYPE(...MAP) and so a matching TYPE(USERMAP) will match instead of the ADDRESSMAP regardless of whether it has an ADDRESS restrictor added to it. I will head over to that thread on to say the same.

10 MartinCorr commented Permalink

Hi Morag, this is really useful info, nice and concise thanks!

I have a dev machine that is running MQ on standalone Win2008, so no domain users. I have a java client on another machine that I am running from the command line to connect to some MQMRs on the standalone. Now Ive gone into the MQ explorer and removed the auth record under the channel to deny all (this is just dev), but when I try to connect from the client with a logon user ID that isn't in the MQM group I get this in WinApp log:
Authorization failed because the SID for entity 'administrato' cannot be obtained.
and the client app gets the usual not authorised error.
So MQ is not rejecting the connection it just doesn't know about that user (although there is actually a local administrator account but I guess its being truncated) but even if there are no auth records configured. Am I doing something wrong here?
thanks, martin

11 Morag Hughson commented Permalink

Hi Martin, You are correct that CHLAUTH a is not the thing blocking you in this case. The protocol that sends the user Ids over from the Client to the queue manager sends a 12-character user ID and (when Windows) a SID. So this means you need to either: Use a 12 character or less user IDs, or ensure that the client and queue manager machines are in the same Windows domain (and thus can interpret each other's SIDs) and MQ is configured to be aware of this.