Authentication Options and Limitations Using Proxy Server 2.0

ID: Q198116

The information in this article applies to:

Microsoft Proxy Server version 2.0

SUMMARY

This article describes the options and limitations for using authentication with Microsoft Proxy Server 2.0 and client Web browsers.

MORE INFORMATION

Single Proxy Server Scenario

Browser to Proxy Server Authentication

When you use a single proxy, any of the authentication methods between the proxy and the client browsers can be used; this includes Basic, Anonymous, and Windows NT Challenge/Response (NTLM) authentication.

NOTE: If NTLM authentication is used, the Web browser must support NTLM authentication. Currently, Microsoft Internet Explorer versions 3.02 and later support NTLM authentication.

Browser Authentication through a Proxy Server

When a proxy server is inserted into the system, between the Web browser and the Web publishing server, NTLM authentication between the client browser and the WEB publishing server will no longer work. In fact any authentication method relying on implicit end-to-end state (such as NTLM) will cease working.

The HTTP 1.1 specification states that all state is hop-by-hop only. End- to-end state can be achieved using a cookie or some other token distinct from HTTP. The most obvious symptom of this failing is client browsers receiving a message about authentication failure, such as "Access Denied."

Because the HTTP headers for proxy authentication are different from those for Web server authentication, it is possible to enable Basic authentication to the proxy and also do Basic authentication between a client browser and a Web publishing server while connecting through a Microsoft Proxy Server computer. Microsoft Internet Explorer supports this configuration.

In summary, Basic authentication does not require an implicit end-to-end state, and can therefore be used through a proxy server. Windows NT Challenge/Response authentication requires implicit end-to-end state and will not work through a proxy server.

Chained or Cascaded Proxy Servers

A chained proxy can be configured to perform authentication on its downstream proxy partner. In such a case, the downstream proxy is acting as a client browser. Because there is a downstream proxy between the client and the upstream proxy, all of the limitations for authenticating with a proxy (described above) apply.

The difference between this case and the single proxy case is that the administrator can decide to enable specific proxy-to-proxy credentials, including using NTLM between the proxies. This works because the proxy-to- proxy authentication is hop-by-hop.

Web browser clients will always authenticate with the first proxy server that they connect with. Credentials from the client Web browser are not passed to upstream proxy servers.

Reverse Proxy and Authentication

Enabling authentication to a reverse proxy is not recommended. A reverse proxy should be transparent to the browser client. Enabling authentication to the proxy violates this rule of transparency. To explain further, the reverse proxy appears to the browser to be the publishing Web server. Therefore, there is only one set of authentication headers for use in authenticating the browser to the proxy and to the publishing server. This means that the reverse proxy and the publishing server cannot have different identities.

As with a single proxy, inserting a reverse proxy will cause NTLM authentication between the client browser and the Web server to cease functioning. Although the reverse proxy is not an explicit proxy, it still operates as a proxy and therefore breaks any implicit end-to-end state that might have been present before it was installed.

It is possible to use Basic authentication to the reverse proxy and to the publishing server but this requires that the computers use the same account identities, that is the same names, passwords, and realms. Again this is because there is only one set of authentication headers. Furthermore, the reverse proxy will always pass on the authentication headers so the Web publishing server must be prepared to receive these headers. If the publishing server is not configured properly for this, unexpected behavior may result.

This is the only authentication method that will work. Microsoft recommends that Anonymous authentication is enabled on the WWW service of the reverse proxy computer regardless of whether or not Access Control is enabled on the Web Proxy service.

Simultaneous Forward Proxy and Reverse Proxy

In a configuration where a single proxy computer is operating as both a forward proxy computer and a reverse proxy computer and proxy authentication is desired, only Basic authentication will work. In addition, the publishing server must be configured to receive the authentication headers. Unfortunately, this dual use of the computer as a proxy and a reverse proxy computer conflicts with Microsoft's recommendation to not use authentication with reverse proxy, as enabling authentication for the proxy also enables it for the reverse proxy.

It is worth noting that a computer operating as a reverse proxy and a forward proxy can be configured to use both NTLM and Basic authentication successfully. In the forward proxy case, Internet Explorer will favor NTLM over Basic. In the reverse proxy case, Internet Explorer will act the same way and when the publishing server produces the "Access Denied" error, Internet Explorer will use Basic authentication and that will succeed. Note, that although this works, it also involves considerable overhead and therefore, may not be suitable if the reverse proxy path is used frequently.

Keywords :
Version : WINNT:2.0
Platform : winnt
Issue type : kbinfo