Team Foundation Server uses the concept of permissions to allow certain people to do certain things, while restricting others from doing the same thing. For example, to create a new workspace, your user account, or a group that contains your user account, must have the Create a workspace permission. Team Foundation Server has permissions for most things, from being able to access a project, to being able to start a build. This enables you to fine-tune user's access to team projects and to Team Foundation Server. There are two explicit settings for each permission in Team Foundation Server: Allow and Deny. The Allow setting enables a particular permission. Unless permission is set to Allow, the user or group cannot use that particular permission.
The Deny setting disables a particular permission. The Deny setting always overrides the Allow setting. For example, if you are a member of two different groups, and one group has Allow set for a particular permission, and the other group has Deny set for the same permission, you will not be able to use that permission. Even though one of the groups you are a member of has that permission allowed, because of your membership in the other group, you are blocked.
By default, most permissions are set to neither Allow or Deny. Basically, they are left unset, which is technically a setting of its own. If permission is not explicitly set to Allow or Deny, then by default, the user is denied access to that permission. Team Foundation Server would rather be too stingy with its permissions than too generous.
The Team Foundation Server Security Model also allows for inheritance of security permissions. This ties back into the ability to unset a permission. If you are a member of two different groups, and one group has a permission set explicitly, and it is not set at all in the other group, then inheritance allows you to use the permission as it is set in the first group.
Finally, you can also set security permissions in other parts of Team Foundation Server, specifically in Version Control and in the Work Item Tracking Areas section. The Version Control permissions can be set at the server level all the way down to the individual file level, while the Work Item Tracking Areas section is set at the project level only.
Team Foundation Server was designed to be easy to administrate. As such, it has its own built-in security model. This permits the Team Foundation Server administrator to deal with security issues, such as creating new groups, adding users to groups, and assigning group permissions, without having to have full access to the Active Directory or other network resources. By providing both UI and command-line tools, the Team Foundation Server administrator can use the tools he feels comfortable with to modify any security permissions.
Team Foundation Server has two levels of groups. Global groups are groups that exist at the server level. These groups provide access to the different server-level permissions. Project groups are groups that exist on the individual project level. These groups provide access to the different project-level permissions.
In addition to these two group levels, which are built into Team Foundation Server, you must also administer groups within Windows SharePoint Services and SQL Server Reporting Services to grant users the ability to create new team projects. Team Foundation Server's security groups are specific just to Team Foundation Server. But the project creation process also requires the ability to set up a Windows SharePoint Services Web site, and the ability to create reports in SQL Server Reporting Services. Therefore, the user needs administrative rights to these other groups. Currently there is no way to give these rights through Team Explorer.
There is, however, an unsupported downloadable tool that provides one common interface to administer users on all three platforms. It's called the Team Foundation Server Administration Tool, and can be found at codeplex.com/Wiki/View.aspx?ProjectName=TFSAdmin. It is worth looking into, as it should save you some time doing administrative work.
Now that we have briefly touched on the different groups, let's dive into each one in more detail.
Team Foundation Server comes installed with three global groups:
Team Foundation Administrators - This group can perform any operation on Team Foundation Server and have total administrative control. It should be restricted to a small number of users.
Team Foundation Valid Users - This group allows users access to the Team Foundation Server. It automatically contains any users or groups added to Team Foundation Server
Service Accounts - This groups contains the service accounts used by Team Foundation Server.
If you are running Team Foundation Server Workgroup edition, there is a fourth group, called Team Foundation Licensed Users. This group explicitly lists the users who have access to the Team Foundation Server. It can contain a maximum of five users, as the Workgroup Edition is restricted to a five-user maximum.
You can also create new global groups and assign them global-level permissions, as needed. All groups are added to the Team Foundation Valid Users group automatically when created.
Just as there are global groups, there are global permissions related to those groups. The following table shows the different global-level permissions in Team Foundation Server. The Permission column is the name of the permission. The Action ID column specifies the parameter to use when setting this permission via the command-line tools. Notice that some of the rows do not have an Action ID. That is because you will use a different command-line tool, which does not require an Action ID, for setting those permissions. You learn more about that later in this chapter.
The following table shows global level permissions:
Permission | Which Means | Action ID |
---|---|---|
Administer shelved changes | You can delete someone else's shelved changes. | No Action ID for this |
Administer warehouse | You can change warehouse settings. | ADMINISTER_WAREHOUSE |
Administer workspaces | You can create and delete workspaces for other users. | No Action ID for this |
Alter trace settings | You can change trace settings on the Team Foundation Server. | DIAGNOSTIC_TRACE |
Create a workspace | You can create a workspace. | No Action ID for this |
Create new projects | You can create new team projects. | CREATE_PROJECTS |
Edit server-level information | You can edit global groups and their permissions. You can also edit project groups and their associated permissions. | GENERIC_WRITE |
Manage process template | You can export, create, edit, and import process templates into Team Foundation Server. | MANAGE_TEMPLATE |
Trigger events | You can fire a project alert event in Team Foundation Server. This permission is usually restricted to the service accounts. | FIRE_EVENT |
View server-level information | You can view global group membership and permissions but cannot make any changes. | GENERIC_READ |
View system synchronization information | You can monitor synchronization of event changes, such as access control list (ACL) changes. | SYNCHRONIZE_READ |
This table shows the default Allow permissions assigned to each global group:
Group | Default Allow Permissions |
---|---|
Team Foundation Administrators | Team Foundation Administrators have Allow access on all permissions. This cannot be changed. |
Team Foundation Valid Users | Create a workspace |
View server-level information | |
Service Accounts | Administer shelved changes |
Administer warehouse | |
Administer workspaces | |
Create a workspace | |
Trigger events | |
View system synchronization information |
When you create a new team project, project level groups are created for you automatically. What groups are created and what project level permissions those groups have depend on the process model you selected when you created the team project. If you use the MSF for Agile Software Development process, you get the following groups:
Build Services
Contributors
Project Administrators
Readers
In addition, the three default global groups, mentioned previously, are also added to the project. You can also create new project-level groups, and give them the appropriate permissions. As with global permissions, there are also project-level permissions. These are permissions that are applied to a specific Team Project. The following table shows the project level permissions for Team Foundation Server:
Permission | Which Means | Action ID |
---|---|---|
Administer a build | You can create, edit, and delete build types, as well as stop builds that are in progress. | ADMINISTER_BUILD |
Delete this project | You can delete projects from Team Foundation Server. | DELETE |
Edit build quality | You can edit build quality of a build. | EDIT_BUILD_STATUS |
Edit project-level information | You can edit the project-level information of a team project. | GENERIC_WRITE |
Publish test results | You can add and remove test results from team project portal. | PUBLISH_TEST_RESULTS |
Start a build | You can start a build using a build type. | START_BUILD |
View project-level information | You can view all build information for builds within a team project. | GENERIC_READ |
Write to build operational store | You can update the build database store. | UPDATE_BUILD |
This table shows the default Allow permissions assigned to each project group and global group for the MSF for Agile Software Development process model:
Group | Default Allow Permissions |
---|---|
Build Services | Edit build quality |
Publish test results | |
Start a build | |
View project-level information | |
Write to build operational store | |
Contributors | Publish test results |
Start a build | |
View project-level information | |
Project Administrators | Project administrators have Allow access on all permissions. This cannot be changed. |
Readers | View project-level information |
Team Foundation Valid Users | View project-level information |
Team Foundation Administrators | Team Foundation Administrators have Allow access on all permissions. This cannot be changed. |
While most of the security settings are handled by Team Foundation Server, you may still need to manage security settings in a couple of other areas. These are in Windows SharePoint Services and SQL Server Reporting Services. To be able to create new Team Projects, you must have the appropriate security settings in WSS and SQL Server Reporting Services. Besides having the TFS Create New Projects permission, a user must have administrative privileges on both WSS and Reporting Services. These privileges are required only if you are wanting to give a user or group the ability to create new team projects. "Giving Users Team Project Create Ability" in Chapter 2 describes in detail how to configure these privileges.
You can set security permissions in two other sections: Version Control and Work Item Tracking Areas and Iterations.
The following table shows the Version Control Permissions:
Permission | Which Means |
---|---|
Read | You can read the contents of a folder or file. |
Check out | You can check files out of the repository. |
Check in | You can check files into the repository. |
Label | You can apply a label to items in the repository. |
Lock | You can lock an item so no one else can update it. |
Revise other users' changes | You can change another user's check-in notes or changeset comments. |
Unlock other users' changes | You can remove a lock someone else has on a file. |
Undo other users' changes | You can undo a pending change from someone else. |
Administer labels | You can make changes to the labels of another user. |
Manipulate security settings | You can set the security permissions on folders and files. |
Check in other users' changes | You can check in changes made by another user. |
This table shows the default Allow permissions assigned to each project group and global group in Version Control for the MSF for Agile Software Development process model. Again, these default permissions are dependent on the process model chosen when the Team Project is created:
Group | Default Allow Permissions |
---|---|
Build Services | Read |
Check out | |
Check in | |
Label | |
Lock | |
Contributors | Read |
Check out | |
Check in | |
Label | |
Lock | |
Project administrators | Project administrators have Allow access on all permissions. |
Readers | Read |
Service accounts | Service accounts have Allow access on all permissions. This cannot be changed. |
Team Foundation administrators | Team Foundation administrators have Allow access on all permissions. This cannot be changed. |
Using Version Control Explorer, you can get very granular with your security permissions, applying them at the server level, folder level, or even to individual files.
The other section is the Work Item Tracking Areas and Iterations. The following table shows lists the permissions for this section:
Permission | Which Means | Action ID |
---|---|---|
Create and order child nodes | You can create new child nodes and reorder existing child nodes. | CREATE_CHILDREN |
Delete this node | You can delete area nodes. | DELETE |
Edit this node | You can rename area nodes. | GENERIC_WRITE |
Edit work items in this node | You can edit work items in an area node. | WORK_ITEM_WRITE |
View this node | You can view security settings for an area node. | GENERIC_READ |
View work items in this node | You can view work items in an area node. | WORK_ITEM_READ |
This table shows the default Allow permissions assigned to each project group and global group for the MSF for Agile Software Development process model:
Group | Default Allow Permissions |
---|---|
Build services | Edit work items in this node |
View this node | |
View work items in this node | |
Contributors | Edit work items in this node |
View this node | |
View work items in this node | |
Project administrators | Project administrators have Allow access on all permissions. This cannot be changed. |
Readers | View this node |
View work items in this node | |
Team Foundation valid users | View this node |
Team Foundation administrators | Team Foundation administrators have Allow access on all permissions. This cannot be changed. |
The user who created the project | Edit this node |