Preventing cross team access to VSTF projects
So I maintain this Visual Studio Team Foundation server (VSTF for short) for Microsoft's architect evangelists to use when working with outside companies on a common project, usually a technology adoption project or a proof of concept. Microsoft uses the term "engagement" for any collaborative project like this. Since I don't want to create a whole new source control server for each new engagement (one is hard enough) I need a way to keep different VSTF projects hidden from other users on the same server. It seems like a common scenario that a full fledged source control system could handle, and ya know, VSTF does support it. How to do it, however, is not a documented scenario so I decided write down the bread crumbs on how I got there.
- Be very afraid of SERVER\Team Foundation Valid Users since it creeps up everywhere in your team projects. There is no policy that keeps it from being added to any new project, so you have to be vigilant in keeping it out of the team projects.
- Create an AD sec group that will contain all users of the server. Add it to the root of your server security in VSTF and give it the "View server-level information" right. Yeah, I know, it does the same thing as Valid Users group but it doesn't get modified dynamically. After creating this group, you can now remove the Valid Users group (as long as you are prepared to accept that this is not recommended by the documentation). Now you can sleep easier since all access is now secured in an active directory group.
- Create AD security groups to manage your users on a per project basis. It's easier to manage that way especially if you have tools for managing AD. In my case, for each engagement I create a "leads" security group and a "users" security group. Add these team groups to the server access security group.
- Create the new team project site on the VSTF server.
- Get the TFS Administration Tool. Do it now or you will lose your mind on the next step.
- Use the admin tool to add your groups to the new team project site. If you don't have the tool, you will have to add the groups manually to the VSTF Service, SQL Reporting Services and to SharePoint Portal Services. One side effect of using the groups is that in this new structure you only need to add users in one place, the AD group, as opposed three places.
Assuming I got all the bread crumbs here, anyone logging in from one team will not be able to see the projects of other teams, nor be able to make changes to them. One other thing I recommend is useing OUs to further segregate teams from each other and to allow team leads to admin the security groups in their own OUs.