Using Team Foundation Server Proxy for extranet deployment

Team Foundation Server utilizes a Proxy to improve performance by caching copies of source control files. The Proxy is situated in a remote location, local to the developer needing the files but away from the main server. The remote office is typically connected to the main server through a slow link. The Proxy helps each user avoid a costly download of the files to their workspace across the slower connection by caching files. When a requested file is not in the local cache, the file is downloaded by the proxy to its local cache from Team Foundation Server, before returning the files to the client. Refer to https://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx  for a more detailed description of the Proxy operation.

In this blog I will describe an improvement that has been implemented in the Orcas Beta 1 release for authenticating users with the proxy in the extranet scenario, where clients and proxy are located in one user domain, while the main server is in a different, non-trusted domain.

Team Foundation Server Proxy uses a pre-authenticated ticket scheme for determining whether a requesting user is authorized to access the requested file. In this scheme, the user’s client contacts the main source control server and if the user is authorized, the client is provided a digitally signed ticket that contains the details of the file being requested. The client then presents this download ticket to the proxy server. The only requirement for clients to receive files from the Proxy is IIS authentication (using NTLM). The proxy treats a valid download ticket from the client as evidence in itself that the client is authorized to receive the file(s).

From the perspective of authentication there are essentially 4 deployment scenarios, tabulated below (we do not distinguish here between multiple trusted domains in the intranet).

The proxy adds little value in Scenario IV and this scenario will not be discussed further. The key restriction until now was that the client used the same credentials to connect to the main server and to the proxy. This can either be the user’s logon credentials (referred to as default credentials), or alternate credentials supplied in the command line or through the UI prompt when connecting to the main server (referred to as TFS credentials). This works well for scenarios I and II, but not with scenario III. The workaround required until now was to create local accounts on Proxy that matches the alternate TFS credentials. This is a feasible workaround for small shops (say 5-10 users), but introduces maintenance overhead if there are many users at the remote site.

DCR Implementation in Orcas release

A possible fix for scenario III is to use the original, default credentials instead of alternate TFS credentials when connecting from TFS client(s) to Proxy. This has been implemented in Orcas Beta 1. The exact sequence is as follows.

1. Version Control client file downloader attempts to connect to proxy server with same credentials used to connect to the main server (TFS credentials).

2. Upon receiving an authentication failure, the proxy download will be retried once with default credentials.

3. If this succeeds, the session will subsequently always use default credentials when connecting to the proxy.

This exchange happens only once per session, which is the running lifetime for Visual Studio. For command line, it is each invocation of tf.exe. Thus the overhead is minimal for VS or even for large sync operations using command line. We should note that this fix introduces no penalty with scenarios I or II.

As a point of clarification for scenario III, we still require a local account on the main server that matches Proxy service account credentials, for the main server to authenticate the proxy when the latter connects to download files during a cache miss. This workaround is much less annoying than the one described earlier per user.

 Vasu