TFS 2010 blocking Visual Studio 2008 users from some machines

Hi, 

I have read all the threads regarding similar issues with no luck.

Please see below the full description of my problem and the actions that were taken in attempt to solve it.

Issue description

Users who are not members of a TFS Administrators group, and use Visual Studio 2008 (with all its required updates), are unable to connect to our TFS 2010 sever and view the projects.

Notice – this only applies to those users that did not kept an open connection with the TFS (didn’t keep VS2008 open and connected). Users who kept a connection open can still use it (even if they don’t belong to a TFS admin group), while those that closed it, cannot connect.

Users that are members of a TFS Admin group, such as my own user credentials, are able to login from all computers, doesn’t matter if VS2008 was closed.

This issue does not apply to Visual Studio 2010 or 2012 , the same users who can’t login with VS2008 can login with VS2010/2012.

Conclusion

The problem is caused by TFS authorization layer (user permissions).

-         I was unable to solve the issue in its entirety.

-         Our exact issue is nowhere to be answered properly on the web that I could find.

-        

Workaround

A temporary workaround is to add users to the “[XX-Collection]\Administrators “ TFS group.

This has the unwanted side effect of giving users Admin privileges on our collection

Additional Findings

By sniffing the network packets on computers/users affected, when using the affected users to login – the user is not authorized to view the TFS projects / collections.

-         The exact error message is: ‘Access Denied:Username needs the following permission(s) on theresource NAMESPACE to perform this action: View collection-level’

-         The issue is caused following NTLM SSP noninteractive authentication to TFS (using Active Directory / XX domain). This works as follows:

1. (TFS2010 on Server) –
2.       The server (TFS2010) responds with a 401 status, indicating that the client must authenticate.
3.       [NTLMSSP_NEGOTIATE] The client resubmits the request with an "Authorization" header and its identity (Base-64 encode).
4.       [NTLMSSP_CHALLENGE] The server The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client with a 401 status reply (again, Base-64 encoded).
5.       [TCP] The client sends a TCP message with HTTP content
6.       [DCERPC] The server sends the following three items to the domain controller encrypted:
   1.       User name
   2.      Challenge sent to the client
   3.       Response received from the client
7.       [DCERPC] The domain controller replies with authentication success (not 100%because message is encrypted, but very likely because TFS sends HTTP/1.1 100 Continue to client after this):
   1.       The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
   2.      The domain controller compares the encrypted challenge it computed to the response computed by the client. If they are identical, authentication is successful.
8.       The server sends HTTP/1.1 100 Continue signifying to the client that authentication has likely succeeded (I am guesstimating this as shown above).
9.       [NTLMSSP_AUTH] Client requests authentication sending in part its username (e.g. Domain\Username)
10.   On failure: Server returns an Internal Server 500 error specifying that the user doesn’t have the View collection-level information permission.On success: Server returns an HTTP 200 OK status and the communication continues.

Failed attempts to solve the issue

1.       Repairing related client software
   1.       Reinstall Team Explorer 2008
   2.      Reinstall Visual Studio 2008 SP1
   3.       Reinstall VSTS 2008 Forward Compatibility Update
   4.      When this failed, retried the process including removal / reinstallation of VS 2008 itself
2.       On TFS, remove and reapply required security from all related groups associated with the user
3.       Deleting TFS cache folders
4.       Deleting user cache from TFS database (including group association) and reading the user from Active Directory Domain
5.       Disassociate client computer and domain, then rejoin domain
6.       On client server, change NT LAN Manager settings using group policy
7.       Changing client computer name to a new name
8.       Compared installed version between working and not working computers (Visual Studio 2008à About)
9.       Move TFS to the Servers OU and update Group Policy settings on the TFS server
10.   Creating a new group ‘bla’ in the instance level and associating active directory user to that group directly
11.   Multiple restarts of the server, IIS, and the XX-collection.