Finding out which BorderManager rule is Blocking a Site without NWAdmin



By: sspallut

May 14, 2008 11:06 am

Reads: 239

Comments:0

Rating:0

By Stephen Spalluto

Problem:

Now more than ever it is more difficult to provide end-users with the resources they need and yet comply with organizational acceptable use policy(-ies) and maintain network integrity and security. Many school districts that have used BorderManager and third party filtering solutions, such as SurfControl, for a number of years are used to end-user complaints of being blocked out of sites that have legitimate organizational benefits. In the past, an Admin could open NWAdmin, drill down to the user, the logs and find out what rule number was triggering the block.

Since the release of BM 3.8 and subsequent BM 3.9, the use of NWAdmin has been lost and with it, so has the ability to determine what rule was triggered when a user requested that a particular site be open for access.

After searching user groups for many months, I decided it was time to contact Novell Engineers to see how to determine what rule was triggered. The engineer I spoke with confirmed my findings and reported CSAudit no longer handles the logging of the rules triggered so there is no longer a direct way to determine what rule is triggering an event…or is there?

Solution:

Here’s what I’ve discovered as a solution that can be as quick and easy as the old NWAdmin way. Our District uses BM 3.9 and SurfControl from WebSense with iManager as the Admin utility.

Here’s how it works when you get that call to release a site and it’s not obvious what rule would be triggering the event.

  1. Obtain the exact URL from the end-user.
  2. Open the URL using an unrestricted account to see the access that should be happening. Many times, sites redirect or reference other associated sites not in the domain of the requested site that can be the sole reason for the block and so you need to discover all that is happening when a user attempts to access that location.
  3. If you don’t already have a recent backup of your BM Rules then you’ll need to create one. If you have a recent backup, skip to Step 5. If no backup, open iManager, go to BorderManager then Access Rules, select your BorderManager Server, and click OK.
  4. Click BACKUP button and copy and paste your rules to a text file as directed. Save.
  5. Open the BM Backup file.
  6. Go to Edit | Find or Ctrl+F to open a Find Box. Type in part of the URL to see if it is specifically listed anywhere in the backup of your rules being as general as possible. You may need to select a few single words or phrases from the URL to search your backup list successfully.
  7. If not in the list, go to SurfControl’s “Test A Site” site (currently found at http://mtas.surfcontrol.com/mtas/MTAS.asp) and see if the URL or domain is on one of their lists that you may have selected for denial.

One of those two resources should reveal the source of the denial. If not, open your log file and see if there are redirects that are denying the access rather than the site they are trying to access. Follow the same procedure as in Steps 6 and 7.

Other third party filtering solutions may have similar capabilities to search their lists. See their documentation for availability.

Environment:

  • BorderManager 3.8 or higher
  • BM Rules w/ logging activated particularly on deny rules.
  • iManager w/ BorderManager Plugins on the BorderManager Server.
  • Third Party Filtering Solution this example references SurfControl by WebSense.
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: ,
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Comment