January 26, 2011
Setting up security for all Team Projects on all involved TFS Components (TFS, SharePoint and SQL Reporting Services) for all individual users might be quite frustrating and error-prone from time to time.
I have seen this type of mismanagement once too many now. About time to publish some basic guidelines on how to manage Team Project security rights and permissions across all involved TFS components.
Download my recommended strategy for getting rid of the familiar red crosses in Team Explorer and manage TFS security wisely.
- New Team Project
- Group Membership for Team Project
- What about security for SharePoint and SQL Reporting Services
- Welcoming the TFS Administration Tool (v2.1)
- Make use of Active Directory groups
References used in the recommendation:
A final note to conclude: the explained Team Project permission sets are not the only available permission sets in the Team Project. Read my previous blogpost on fine-grained permissions in TFS 2010 for more information.
September 3, 2009
Recently (in TFS2008) I was stuck with the fact that I could not split up the permission to create/modify builds and the permission to create/modify build agents. In certain enterprise environments it might be necessary to revoke the right from development teams to create/modify build agents. Build agents may be for instance controlled centrally by an operations team that manages all build servers. In TFS2008 both tasks belong to the “Administer a buid” permission.
The good news is that TFS2010 will offer a lot more fine-grained permission sets! You will now have the possibility to set permissions on the Team Project Collection, on the Team Project, on the Build Definition level and on the Version Control repository!
- Team Project Collection
- Administer shelved changes
- Administer test controllers
- Administer warehouse
- Administer workspaces
- Alter trace settings
- Create a workspace
- Create new projects
- Delete a team project
- Delete team project collection
- Edit collection-level information
- Make requests on behalf of others
- Manage build resources
- Manage process template
- Manage work-item link types
- Trigger events
- Use build resources
- View build resources
- View collection-level information
- View system synchronization information
- Team Project
- Administer test environments
- Create test runs
- Create team project
- Delete test runs
- Edit project-level information
- View project-level information
- View test runs
- Build Definition
- View Builds
- Edit build quality
- Retain indefinitely
- Delete builds
- Manage build qualities
- Destroy builds
- Update build information
- Queue builds
- Manage build queue
- Stop builds
- View build definition
- Edit build definition
- Delete build definition
- Override check-in validation by build
- Version Control
- Check Out
- Check In
- Revise other users’ changes
- Unlock other users’ changes
- Undo other users’ changes
- Administer labels
- Manage permissions
- Check-in other users’ changes
- Manage branch
Great! There are a few permission that are new and that I certainly want to look into a bit deeper … but now let’s go back to my problem in TFS2008 and how to fix it in TFS2010. Right clicking the Team Project Collection brings me to the permissions on the Project Collection level.
The permission to Manage build resources allows people to create and modify build controllers and agents.
Right clicking Builds brings you to the permissions on the build definition level.
The permission to Edit build definition allows people to create and modify new build defnitions.