Troubleshooting RuleSet issues
One of the primary security mechanisms built into IAG and UAG is the RuleSet engine. This mechanism inspects every URL request submitted to IAG or UAG, and tries to match it to one of the preconfigured rules. These rules define URLs and patterns that are permitted, down to the parameter level. A rule may indicate that the request matching certain parameters should be rejected or accepted, and if the request does not match any of the existing rules, it will also be rejected. The rules are built using RegEx, which may be confusing to some, but in this case, it allows an administrator to specify what is permitted and what isn’t with a high level of detail, yet conserving on the number of rules (which affects the server’s performance). Here’s a sample screenshot of the server’s rule set:
When the administrator publishes new applications on the server, new rules are automatically generated according to parameters predefined as part of the application’s template. A blank server would have rules pertaining to InternalSite and a server with a blank portal trunk would also have “portal” related rules. Some templates add only a single rule, while others may add multiple rules. The above screenshot shows some rules related to the File-Access template, which include 18 rules.
As you can see above, each rule has several parameters. The Action indicates if this is a “reject” (deny) rule or an accept one. The URL specifies the URLs affected by this rule, including a RegEx pattern, which could be complicated to understand. The Rule also specifies how to handle parameters in the URL, and the HTTP Methods that are accepted.
At the bottom of the screen, we can see the parameters within the rule, and what they can be – length wise and type (string, number etc).
Normally when working with IAG or UAG, the predefined templates will include a set of rules that won’t need any manual intervention, but custom apps may need some. For example, creating a custom application based on the “Generic Web App” template will create a rule with the URL value set to “.*”, which means that any URL will be permitted. This may not be secure enough for some companies who feel the permitted URLs should be controlled more tightly.
A typical scenario that requires RuleSet troubleshooting is when a user tries to open an application from the portal, or perform some action with an application, but receives an error page that looks like this:
This error is quite cryptic to the user, but an administrator can easily see more details in his Web Monitor. Here’s a sample of how it would look like:
This error description is easy to understand – the URL contains an illegal path, and the rule is “default rule”, which means that UAG could not find a rule that would permit the request (in this case, for /internalsite/scripts/loginTimeout.js) and so it was rejected. Here’s another error:
This one is a little different – this time, the failure was because the request was using an HTTP Method that was not specifically allowed. As can be seen on the 2nd line, the disallowed method is “HEAD”, which is not always allowed by default. The HEAD method is used to retrieve just the header information about a file, without reading the entire file. It’s often used by network monitoring tools to check if a web server is responsive, but limiting that check to use the minimal resources.
Other variations of Rule violations can occur if a URL contains a parameter that is not allowed – one that is too long, or of a type that is not acceptable. For example, older versions of IAG had a bug in the default URL Set for OWA that prevented users from creating calendar items that occur in the year 2010 and onward. The rule, “OWA2003_Rule5” had the parameter “yy” set to allow the value of 200[0-9], which allows a calendar item for the years 2000-2009, but not 2010 or later:
This presented itself in the Event Monitor as this error message:
Request failed, URL rejected by URL Inspection rule. Trunk: owa; Secure=1; Application Name: OWA; Application Type: OWA2003SP1; Rule: OWA2003SP1_Rule5; Parameter: yy; Value: 2010; Failure reason: Parameter value failed 'Value' check; Source IP: 6.16.14.91; Method: GET; URL: /exchange/Brian/Calendar/?Cmd=new&mm=1&dd=12&yy=2010.
The fix was simple – change the Value to a string that allows for higher numbers. This was actually fixed in Update 3 for IAG 3.7 SP2. A string that allows higher number is “20[0-9]+” (without the quotes).
If you run into a situation where access is blocked, the 1st order of business would be to open the Web Monitor on the IAG server, and look for errors in the Security Log. If the event is related to Rule violation, inspect the message text to find out to which Trunk, Application and Rule it pertains, and see if it is related to the URL, or a parameter. The next step would be to open the make a backup of the Server configuration, as the Rule Set UI is complicated and a small mistake could cause to further trouble. Then, inspect the rule and try to figure out why it is blocking access.
Once you realize which part of the rule is blocking (Action, URL, Parameters, Methods, Parameter type, Param Value, Param length etc), experiment to determine the actual allowable value. One might be tempted to change the URL to “.*”, for example, which will solve the problem by allowing everything, but that might also expose the server to attacks. A good way to know what is required is to change the application itself to “learn mode”, which causes the server to log, but not enforce security rules. Then, use a URL recording utility like HTTPWatch, and explore the application as much as possible. Then, copy the recorded URLs to Excel and use Remove-Duplicates and sorting to figure out the URL patterns that should be allowed. Once you have that, you can start constructing the RegEx rules that will allow the application to run uninterrupted, but with the tightest possible security.