ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » Backstop-rule and exception no working

Post new topic  Reply to topic Goto page Previous  1, 2, 3
 Backstop-rule and exception no working « View previous topic :: View next topic » 
Author Message
ivanachukapawn
PostPosted: Wed Mar 18, 2015 7:52 am    Post subject: Reply with quote

Knight

Joined: 27 Oct 2003
Posts: 561

FJB

On March 10th you wrote:

Quote:
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.

What did the dis chlauth match runcheck say?

Have fun


There appears to be a fundamental disagreement (Morag vs FJB) regarding CHLAUTH design and functionality. So according to you, in order for a CHLAUTH rule to defeat an address-* backstop rule it must include an IP specification. Morag disagrees - but in my environment all testing so far has supported the contention that IP specification in the CHLAUTH rule is needed in order to win over the address-* backstop.

When testing without the IP specification in the USERMAP rule, the connection attempt was blocked - and the RUNCHECK explanation of the blockage incorrectly stated that the userID was blank and I know that the userID is being supplied by the client app - so at the very least, there is fault in related CHLAUTH documentation (including MATCH (RUNCHECK) ALL) -

So on March 10th, your stated opinion was that an IP specification is needed in order to win over an address-* backstop rule. Do you know of IBM documentation which supports that opinion?
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Mar 18, 2015 8:38 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

I also said
fjb_saper wrote:
Strange. Did a test with usermap only (no ip specified) and it behaved like all ips allowed... Which version and fixpack are you using for your test?

This shows it as behaving as designed. Once I got this behavior I did not investigate further. I was testing on 8.0.0.2 ...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
ivanachukapawn
PostPosted: Fri Apr 03, 2015 9:49 am    Post subject: Reply with quote

Knight

Joined: 27 Oct 2003
Posts: 561

FJB,

I also ran tests on 8.0.0.2 and confirmed that CHLAUTH works as designed there - I was able to win against address('*') backstop rule with a USERMAP rule for client ID which did not specify IP.

But it doesn't work as designed in 7.5.0.4 - I am hoping that 7.5.0.5 (scheduled for release April 2015) fixes this issue. Currently this is not a show-stopper issue for me as I am able to effectively configure a subnet specification on the USERMAP client rule which gets the job done in 7.5.0.4.

Regardless, thank you very much for your assistance on this issue -
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3 Page 3 of 3

MQSeries.net Forum Index » IBM MQ Security » Backstop-rule and exception no working
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.