Managing Groups, Users, and Permissions
Team Foundation Server, Windows SharePoint Services, and SQL Server Reporting Services all maintain their own information about groups, users, and permissions. Your operations plan should include managing this information when you perform certain tasks, such as:
-
Creating a team project in Team Foundation Server.
-
Changing the membership of a team project.
-
Creating a custom user group.
-
Adding or removing a user or a group of users.
-
Changing permissions for a user or a group of users.
-
Moving Team Foundation Server to a different environment.
For example, every time you create a team project in Team Foundation Server, you must ensure that the users for that project have been added to the appropriate groups and that they have the permissions that they require to do their jobs. You will need to build the checklist for this into your operations plan.
To make managing users and permissions easier, you can add users to Active Directory groups that are specific to their organizational roles. You can then add those groups to Team Foundation Server, Windows SharePoint Services, and SQL Server Reporting Services, and assign appropriate permissions to those groups. By taking this approach, you can reduce the amount of configuration and management that is required for individual users. However, you still must carefully consider how you want to manage users and permissions, not only for team projects in Team Foundation Server, but also across Team Foundation Server, Windows SharePoint Services, SQL Server Reporting Services, and the Windows operating system itself.
Managing Users and Groups Across Projects
When you manage Team Foundation Server and the projects on each server, you should ask some basic questions, such as those that follow. Your answers to these questions can help you determine what groups and permissions are appropriate for your deployment needs.
- Do team projects require unique permissions, or should all contributors have access to all team projects? This question is a major factor in determining how many groups you need to manage your users.
-
If you can grant contributors the same permissions for all projects, the simplest approach is to use a single Active Directory group to manage those permissions.
-
If you must grant specific permissions for each team project, you might need to manage a complex matrix of groups. In this situation, you must determine whether you can manage users and groups more easily in Active Directory or in Team Foundation Server, Windows SharePoint Services, and SQL Server Reporting Services. If you can create and manage Active Directory groups, you can create these groups more easily than managing users for each team project across the three programs. However, if you have limited control or no control over the creation and management of groups in Active Directory, you will almost certainly have to manage users and groups in Team Foundation Server, Windows SharePoint Services, and SQL Server Reporting Services. You can still create custom groups to help manage the specific permissions for those users.
- What groups will your organization require? You should review the standard groups in Team Foundation Server and determine whether they meet your needs. As mentioned previously, if your organization requires additional groups to perform specific business roles, you can create them by creating custom groups in Team Foundation Server. To define custom groups, you should determine what activities members of that group perform, and what minimum permissions they require to perform that work. As you add more groups, management becomes more complex and more costly. A good design balances the needs of security against the additional overhead. To help strike this balance, you can determine the smallest number of users for which you will create and maintain a custom group, and then you can consolidate groups that are smaller than the size that you chose. If necessary, you can grant specific permissions to individual users, instead of to groups. However, this strategy also increases the administrative overhead. Common sense is your best guide, but you should never grant users and groups more permissions than what they require to perform their work.
- Will all users exist in the same domain or workgroup? Depending on your configuration, Team Foundation Server can support users and groups from more than one domain, or users from both a workgroup and a domain. For more information, see Managing Team Foundation Server in a Workgroup, Managing Team Foundation Server in an Active Directory Domain, and Trusts and Forests Considerations for Team Foundation Server on the Microsoft Web site.
- Will all contributors have the same access to the entire version-control tree, or will permissions vary for each contributor? You manage permissions for Version Control similarly to how you manage permissions for file systems. You can create specific permissions for a folder or allow it to inherit permissions from its parent. As an alternative, you can explicitly deny permissions to one or more folders. By combining these approaches, you maximize flexibility in how you can define permissions. If you must restrict specific parts of the version-control tree, you should design the folder structure to make managing permissions easier. Because you can take advantage of inheritance, you should design the folder structure so that specific permissions are applied to as few folders as possible. For more information about how to control access to source code, see Team Foundation Source Control Permissions on the Microsoft Web site.
- Do you need to manage permissions uniquely for builds on the build server? If you must manage permissions on the build-server shares, you must maintain Active Directory groups to accomplish this task. Ideally, you can use the same groups for Team Foundation Server permissions as for build shares. Otherwise, you must add and maintain additional Active Directory groups for this purpose.
Project Roles and Associated Default-Group Memberships
When you create a project in Team Foundation Server, the project has three default groups to which you can assign users and groups of users: Project Administrators, Contributors, and Readers. In addition, the Team Foundation Administrators group appears as a group in every project. Your operations plan should include managing the membership of these default groups when you perform certain tasks, such as:
-
Creating a team project in Team Foundation Server.
-
Changing the membership of a team project.
-
Adding or removing a user or group of users to or from a default group.
For example, if a team of developers joins a team project, and you manage users in the default groups, you will need to add those developers to the appropriate groups. For each business role in Team Foundation Server, you must create groups and assign permissions to those groups or users in Team Foundation Server, Windows SharePoint Services, and SQL Reporting Services.
Every business has required functions that translate into roles, or, to put it more simply, into jobs that have specific responsibilities and duties. You must determine what group memberships and permissions are appropriate for each person's role in Team Foundation Server. Also, you must determine what group memberships and permissions match that role most closely in Windows SharePoint Services and SQL Server. If the default groups in Team Foundation Server are not specific enough to meet your business needs, you can create custom groups with specific permissions to better map to business roles. As the following table outlines briefly, you must assign each user to a group in each program, based on what role the user plays:
|
Business Role
|
Program
|
Required Group Memberships
|
| Project Lead | Team Foundation Server | Project Administrators |
| | Windows SharePoint Services | Site Administrators |
| | SQL Server Reporting Services | Content Manager |
| Project Contributor | Team Foundation Server | Contributor |
| | Windows SharePoint Services | Contributor |
| | SQL Server Reporting Services | Browser |
| Project Reader | Team Foundation Server | Reader |
| | Windows SharePoint Services | Reader |
| | SQL Server Reporting Services | Browser |
| Team Foundation Server Administrator | Team Foundation Server | Team Foundation Administrators |
| | Windows SharePoint Services | SharePoint Administration group in SharePoint Central Administration |
| | SQL Server Reporting Services | Content Manager System Administrators |
Project Leads
A project lead is generally in charge of a team project and can maintain a work item database, a team project portal, and the permissions and security for that project. Project leads cannot create team projects.
Project Contributors
A project contributor is the hands-on manager, designer, developer, or tester who works on a project. Project contributors know about Team Foundation Server, but they use it only as a tool to deliver their commitments.
Project Readers
A project reader is a high-level project manager, business analyst, or a manager on a related project. Project readers must be able to see the status of a particular project, but they do not contribute specific deliverables to that project. A project reader has no work items that are associated with the project.
Team Foundation Server Administrators
An administrator of Team Foundation Server is an IT administrator who manages the server itself. Members of this role have more permissions than any other user of Team Foundation Server. Administrators maintain Team Foundation Server, and they administer permissions and security for users and groups. For most organizations, members of this role create projects and manage the overall health and operation of the server, but they are not necessarily involved in any particular project. Members of this role might customize the process guidance for their organization, if the process guidance does not vary between projects.
For more information about default groups in Team Foundation Server, see Default Groups on the Microsoft Web site. For more information about how to set group membership for each of these roles, see Team Foundation Server Administrator Permissions, Team Foundation Server Project Lead Permissions, and Team Foundation Server Contributor Permissions on the Microsoft Web site. For more information about how to customize process guidance, see Customizing Team Foundation Server for Your Business on the Microsoft Web site.
Customizing Groups and Permissions in Team Foundation Server
In addition to the default groups, you can create custom groups to reflect roles that are described in your chosen process guidance or specific business needs. Your operations plan should include managing custom groups when you perform certain tasks, such as:
-
Creating a project in Team Foundation Server.
-
Changing the membership of a project.
-
Reviewing membership and permissions for each custom group.
-
Adding or removing a user or a group of users to a custom group.
-
Changing the permissions for a custom group.
For example, if a team of developers joins a project, and you manage users in custom groups, you will need to add those developers to the appropriate groups.
You must assign permissions to custom groups when you create them. These groups will not exist outside Team Foundation Server. Therefore, you must be sure that the users and groups that belong to these custom groups belong also to the appropriate groups in Windows SharePoint Services and SQL Server Reporting Services.
You can also customize the permissions that are granted to any group or user in Team Foundation Server, with the sole exception of the Team Foundation Server Administrator group. As a best practice, you should assign users to groups and then customize the permissions for those groups in Team Foundation Server, instead of to individual users.
For more information, see Custom Groups, Team Foundation Server Permissions, and Team Foundation Server Default Groups, Permissions, and Roles on the Microsoft Web site.
Tools for Managing Users and Groups
As mentioned earlier, Active Directory provides a powerful way to manage users and groups across Team Foundation Server and the programs on which it depends. If you cannot manage groups by using Active Directory, you can define and manage groups inside Team Foundation Server itself. Because security groups for Team Foundation Server are contained in each installation, you must manage security groups on each server. However, members of the Team Foundation Server Administrator group will have complete control over those groups. Nevertheless, you still must add the users in these groups to the appropriate groups in Windows SharePoint Services and SQL Server Reporting Services.
After you have determined the best way to manage users and groups across your deployment, you can directly add, modify, deactivate, reactivate, view, and remove users to and from Team Foundation Server, Windows SharePoint Services, and SQL Reporting Services. Admittedly, this process is cumbersome and subject to error, especially over time. A few external tools can help you manage this process. The following tools are not part of Team Foundation Server itself and are not supported as part of the product. However, they might help you in your specific deployment:
Team Foundation Server Administration Tool - By using this tool, you can add users to Team Foundation Server, Windows SharePoint Server, and SQL Server Reporting Services quickly through one common interface. Also, you can change permissions on one or more of those programs, identify errors, and view all users and their permission sets across Team Foundation Server, Windows SharePoint Server, and SQL Server Reporting Services. This tool is published on CodePlex, Microsoft's open source project hosting Web site. For more information, see Team Foundation Server Administration Tool on the Microsoft Web site.
Team Foundation Server Permission Manager - By using this tool, you can add or remove members from groups in Team Foundation Server, roles in SQL Server Reporting Services, and roles in Windows SharePoint Services. Also, you can set permissions in Team Foundation Server at the server and project levels, set AreaPath and version-control permissions, and create users in Team Foundation Server. In addition, you can assign permissions to a group that are identical to those of an existing user or group that you specify, and save user permissions as a template for later use. For more information, see Team Foundation Server Permission Manager on the Microsoft Web site.