Recently, I worked on a case where the customer had published multiple web applications using the template ‘Other Web Application (Application Specific Hostname)’. The application type was specified as “web”. When users accessed some of the applications, it worked but while accessing the rest, they were getting the error “You have attempted to access a restricted URL” (screenshot below)
When we checked the UAG Web Monitor logs, we got the following information about the user request “Warning 09/19/2013 15:45:21 67 URL Path Not Allowed Security Trunk1 (S) UAG1 A request from source IP address **.**.**.**, user ***** on trunk Trunk1; Secure=1 for application Web Application1 of type Web failed. The URL /test/default.aspx contains an illegal path. The rule applied is Default rule. The method is GET. “
So, it appeared that UAG was not able to match the URL with any of the configured URL sets on that particular trunk where these applications were published. And because of that our request was getting denied by the default rule.
Next, we checked the URL Set to see if we have created rules that would allow the required URL paths. The rule naming format is based on the Application Type specified at the time of creation of the application. Rules beginning with ‘<ApplicationType>_’ only will be applied for the corresponding applications. In our case, we had the following configuration:
We checked the URL Set for rules that begin with web_ . We could see only one rule present matching that naming convention (web_Rule1). This allowed all the paths.
So, this URL Set rule should have taken care of all the paths accessed by the clients, but still, we had an inconsistency in the behavior since some applications did not generate this error, while others did.
You must be wondering how come we were still getting denied even though we have a rule for that application type which allows everything. Please pay attention to the name of the Application Type and the name of the rule under URL Sets. As you can see, they have been configured with different case, meaning that the Application Type has ‘W’ (upper case) while the rule name is entirely lower case. And that’s what seemed to be the cause behind the request not being able to match with the rule.
We added another rule to the Rule Set and named it Web_Rule2 and allowed all the paths which were required. After activating the new UAG configuration, users were able to successfully access the published application.
The key takeaway is that URL set rule names are case sensitive and care must be taken while writing rules for user-defined application types. I hope this post helps you in resolving such issues which you may run into during your deployment.
Security Support Engineer – Microsoft Forefront Edge Team
Security Support Escalation Engineer – Microsoft Forefront Edge
Security Sr. Support Escalation Engineer – Microsoft Forefront