Problems Accessing a Web Site Published in an IAG Portal

  • Article

1. Introduction

 

The IAG 2007 allows you to granular control for the URLs that are used for the applications that are published through the portal. Such flexibility and robustness can also cause problems if the administrator doesn’t know exactly how to make the appropriate restrictions. First thing that needs to be done is to understand how the application that you are trying to publish works. Without this understanding you might end up having problems such as the ones that are described in this post.

 

2. Symptom

 

The scenario is: customer is publishing the Company’s Payroll Web Site through the portal. When the user accesses the application, the first page has lots of missed images, as show below:

 

Figure 1 – First problem: missing images.

 

In a hurry to check the employee’s information the user didn’t care about the images and after typing the employee’s number he clicked in submit. The second error came up as show below:

 

 

Figure 2 – Second problem: restriction to access the web site.

 

3. Moving Further and Understanding the Issue

 

Those problems might have or not have the same root cause, one single culprit. It is early to say that one single component is causing this issue, thus you need to know where to look first to than start narrowing down the issue. For this case the first thing that we check is IAG Web Monitor, Event Viewer option, Security session:

 

 

Figure 3 – Warning ID 67.

 

This event was triggered because the URL for this application has an illegal path. Time to review the properties for this application. Here are the main tabs that we need to review for this type of error:

 

 

Figure 4 – Reviewing the application.

 

What we have here is:

· The address is correct.

· The path in the Web Server’s Tab is correct.

· The Web Settings are enough for this web site to work.

· The application’s URL in the Portal Link is also correct.

 

What will be the next step?

 

6. Gathering Data

 

Last week we troubleshoot SSL Handshake using Fiddler, although this is a powerful tool it will not help that much in this case since we can’t see the content because the access from the portal is encrypted (SSL). However, there is another great tool that can show a lot more about the HTTPs traffic; this tool is called HTTP Watch. The HTTP Watch Basic version is free however has limited functionality. The full version allows you to actually see the code of the page that you are trying to browse and much more details about the communication.

 

That will be one option (at least for this case) will be to get a netmon internally while trying to access the web server from the IAG itself. When I say at least for this case, is because the traffic inside is not encrypted (HTTP only), therefore we can see more details about this request. What we see in this case is:

 

GET Request and Response for the main page

10.1.1.5 10.1.1.63 HTTP HTTP:Request, GET /payrollcontoso/

10.1.1.63 10.1.1.5 HTTP HTTP:Response, HTTP/1.1, Status Code = 200, URL: /payrollcontoso/

GET Request and Response for the images that appears in the home page

10.1.1.5 10.1.1.63 HTTP HTTP:Request, GET /payrollcontoso/images/trans.gif

10.1.1.63 10.1.1.5 HTTP HTTP:Response, HTTP/1.1, Status Code = 304, URL: /payrollcontoso/images/trans.gif

10.1.1.5 10.1.1.63 HTTP HTTP:Request, GET /payrollcontoso/images/logo.gif

10.1.1.5 10.1.1.63 HTTP HTTP:Request, GET /payrollcontoso/images/collage_notext.jpg

10.1.1.63 10.1.1.5 HTTP HTTP:Response, HTTP/1.1, Status Code = 304, URL: /payrollcontoso/images/logo.gif

10.1.1.63 10.1.1.5 HTTP HTTP:Response, HTTP/1.1, Status Code = 304, URL: /payrollcontoso/images/collage_notext.jpg

 

At this point we know that there are more folders within payrollcontoso virtual directory. For this case, the IIS Administrator was not available and we couldn’t get more details about all the folders that exist within this directory. Knowing that, it is time to review the URL Set configuration in the IAG Trunk.

 

5. URL Inspection

 

If you review the Chapter 6 of IAG Advanced Configuration Guide you will understand in details how the content inspection happens when IAG is processing a request. In summary when IAG receives a request it checks if the path for this URL is allowed based on the URL Set and since we have the Check Out of the Box Rules selected in the Web Settings tab, it will also check for legal characters and forbidden encoding. For this particular error most likely we are not facing an out of the box rule restriction, otherwise the error message will be different and the event id will be 48. The URL Set for this case has the following rule:

 

 

Figure 5 – URL Set.

 

Here it is the problem:

 

Although the action for the Payroll_Rule1 has Accept the URL has the following definition:

 

/payrollcontoso/*

 

The URL settings use Regular Expression (RegEx) that has granular capabilities. The definition above doesn’t cover all the content within /payrollcontoso/ , if you are used to ISA Server you will think: hum, in ISA Server this will be enough. Yep, it will, but not in IAG. To cover all the content within /payrollcontoso/ you will need the following syntax:

 

/payrollcontoso/.*

 

Since the dot character "." matches any single character and an expression followed by an asterisks "*" can be repeated any number of times including zero, this should be the expression that you want to use to cover all the content within a directory.

 

Note: for more information in the Regular Expression for IAG review Appendix B of IAG Advanced Configuration Guide.

 

After changing this setting and activate the configuration the Payroll page was successfully accessed.

 

6. Conclusion

 

By understanding how IAG evaluate and process the URL you will be able to mitigate issues prior to deploy you application through the portal.