Authentication failure while trying to access a website through TMG as forward proxy
This post is about an issue I came across while working on a case and thought of sharing with all. It was not a straight forward issue; well a lot of them are not! J , Issue was with a certain website hosted on an external web server, when users in the internal network of TMG server try to access this website through TMG server, they get authentication prompt and after entering the user credentials, user gets page could not be displayed on the browser.
In this scenario the access rule on TMG, required users to authenticate. Customer had another network which was behind ISA server 2004 sp3 and same website for the user was working without issues.
Troubleshooting
After verifying that, all the basic settings were correct on the TMG server. I collected Network monitor on the client and TMG data packager as explained in this link simultaneously, http://blogs.technet.com/b/sooraj-sec/archive/2010/04/10/instructions-for-isa-data-packager-to-collect-data-in-repro-mode.aspx, for working and non-working scenario.
Data Analysis.
In the Network monitor traces taken on the client I saw a weird behavior, shown and discuss below. If we look at following snapshot, we can see few Get Requests/Responses marked. It is a get request for same URL.
If we look into the details of the network traces, After the TCP handshake we see first get request. In response to that we see proxy authentication required message back from the TMG server.
Details of the Proxy authentication message from the TMG server, which is status code 407, proxy authentication required.
Then client responds with credentials using Kerberos token shown below
Then we get reply from the TMG server with http status code 401, authentication required.
This response was actually coming from web server(we confirmed by looking at network traces taken on the external NIC of the TMG server) and TMG server was forwarding to client, that’s how user was getting authentication prompt on his browser. But in network traces we can see this was happening again and again i.e. first TMG sends 407 proxy authentication required and then forwards 401 status code and finally connection gets reset by client. In above 401 messages we can also see that web server who is hosting the web site is using NTLM authentication.
Research and Resolution
Found following explanation
*************************
AuthPersistence Usage in IIS 6.0
In earlier versions of IIS, the AuthPersistence metabase property had three possible settings. Two of the settings allowed administrators to enhance performance by specifying persistence based on the existence of a proxy server. Administrators could use either of those AuthPersistence settings to force IIS to negotiate one-time-per-client connections and then use those credentials for subsequent requests over the same connections. These two settings have been removed from IIS 6.0 for security reasons.
In IIS 6.0, the only valid setting for the AuthPersistence metabase property is AuthPersistSingleRequest, and NTLM is the only IIS 6.0 authentication protocol that honors this setting. The setting for AuthPersistSingleRequest is honored only in the following circumstances:
• |
Integrated Windows authentication is set to NTLM. |
• |
Integrated Windows authentication is set to Negotiate, and NTLM authentication is used. |
In either of these cases, AuthPersistSingleRequest is False — that is, not set — for backward compatibility with earlier versions of IIS. A value of False means that authentication persists for subsequent requests over the same connection.
In IIS 6.0, all other authentication protocols assume that the value of AuthPersistSingleRequest is True — that is, set — so authentication persists only for a single request over a connection. IIS 6.0 automatically resets authentication at the end of a request and forces each subsequent request over the same connection to authenticate.
****************************
As per above explanation AuthPersistSingleRequest should beFalse
( http://msdn.microsoft.com/en-us/library/dd447565.aspx ) in our scenario on TMG server and we can proxy NTLM authentication.
Then checked this property in ISAinfo, we found that customer had set its value to Boolean 1 as shown below on TMG server’s internal network.
This is a com property and we cannot set its value through GUI, We found that customer had imported an xml file to import configuration from another server and this setting was set to 1 in that xml, after changing its value to default 0 in that xml file and importing it again, issue got resolved and we were able to access the website through the TMG server.
As I mentioned in this scenario, customer modified this property unknowingly while importing and we were able to revert that. This property cannot be modified through GUI, so if you encounter similar issue and find this property changed to 1 then change tracking tool can be used to see what changes happened (any imports as discussed here) else engaging MS support would be the right thing to do to get it back to default.
Note: ISAInfo is one of the logs you can collect while collecting TMG data packager data, more about it and TMG data packager can be found in this link http://www.isaserver.org/tutorials/Advanced-Forefront-TMG-debugging.html, in short this log has ISA/TMG configuration information.
Author
Suraj Singh
Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team.
Technical Reviewers:
Richard Barker
Sr. Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team
Comments
- Anonymous
May 26, 2012
Very well explained, thanks for your efforts.. You always present things in a very simple and detailed manner which makes it more effective and efficient and very easy to understand.... as always :-)