Understanding Test Button Results on Forefront TMG 2010
1. Introduction
The Web Publishing Rule Test Button was first introduced in ISA Server 2006 SP1 with the objective of providing ISA administrators the ability to test a rule before putting it into production. As explained in the ISABlog post ISA Server 2006 SP1 – Problems that Go Beyond the Test Button, this feature had some limitations, including the one described in that post. Forefront TMG 2010 enhanced the capabilities of Test Button by adding more tests and details about the test’s results. Some of those improvements are illustrated below:
1) Better explanation when there is a delegation mismatch:
You should be aware that the test button does not actually test user authentication between Forefront TMG and the published Web site. Instead, the test button issues an anonymous GET request to the Web site and evaluates the response it receives. For instance, if the Web publishing rule Delegation tab specifies Basic Delegation and the Web site fails to include Basic authentication as one of the allowed methods, the test button considers the delegation test to have failed.
2) Pathping results are also included in the test:
Pathping is a tool that has been included in Windows Server since Windows 2000. It operates similar to tracert, but extends this functionality to provide a much more detailed analysis of the network path between Forefront TMG and the published server. The goal of including this in the test button is to help the Forefront TMG administrator in identifying core networking issues.
However there are some scenarios where the test button’s result shows an HTTP error in the description field while the test result indicates a pass state. To explain a scenario where Test Button can be tricky to understand, we are going to use a test rule result against a simple web site that is being published by Forefront TMG using NTLM Delegation. The GUI shows all items in green, however if you select the /Log folder you will see the description below:
Here it is the network trace of this request and response cycle:
Forefront TMG sends the GET Request
10.20.20.1 10.20.20.10 HTTP HTTP:Request, GET /log/
- Http: Request, GET /log/
Command: GET
+ URI: /log/
ProtocolVersion: HTTP/1.1
Via: 1.0 TMGFW
Host: dc01
UserAgent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) Fetch API Request
Connection: Keep-Alive
HeaderEnd: CRLF
IIS replies with the 401
10.20.20.10 10.20.20.1 HTTP HTTP:Response, HTTP/1.1, Status Code = 401, URL: /log/ , Using NTLM X-Powered-By: Authentication
- Http: Response, HTTP/1.1, Status Code = 401, URL: /log/ , Using NTLM
X-Powered-By: Authentication
ProtocolVersion: HTTP/1.1
StatusCode: 401, Unauthorized
Reason: Unauthorized
+ ContentType: text/html
Server: Microsoft-IIS/7.5
+ WWWAuthenticate: Negotiate
+ WWWAuthenticate: NTLM
X-Powered-By:
XPoweredBy: ASP.NET
Date: Wed, 17 Feb 2010 15:11:33 GMT
ContentLength: 1293
HeaderEnd: CRLF
+ payload: HttpContentType = text/html
Notice that the response from the Web server is 401 Unauthorized,. The green result in this case is an expected behavior in Forefront TMG 2010. The delegation test state is based solely on the response headers received from the published server. If the Delegation tab is configured for NTLM and the Web server response with WWW-Authenticate: NTLM, the test button mechanism considers this a successful delegation state because the Web server 401 response includes a WWW-Authenticate header that matches the authentication delegation selection in the rule being tested.
Note: the same behavior can also happen if the published server responds with 403 forbidden, the test button result may also shown as green.
Authors
Yuri Diogenes
Sr Security Support Escalation Engineer
Microsoft CSS Forefront Edge Team
Nitin Singh
Support Engineer
Microsoft CSS Forefront Edge Team
Technical Reviewers
Jim Harrison
Program Manager
Microsoft Forefront Edge CS Team
Doron Juster
Senior SDE
Microsoft Forefront Edge CS Team