Introduction to Microsoft Team Foundation Server

Permission Inheritance

Some permissions are managed through a hierarchy. Within this hierarchy, permissions can be inherited from the parent or overridden. Security groups assign a set of permissions to those members of the group. For example, members of the Contributors group or Project Administrators group are assigned the permissions that are set as Allowed to those groups.

If a permission isn't directly allowed or denied for a user, then it may be inherited in two ways.

• Users inherit permissions from the groups to which they belong. When a permission is allowed for a user directly or through membership in a group that has that permission, and it is denied, either directly or through group membership, the permission is denied.

• Object-level permissions that are assigned for nodes of a hierarchy - areas, iterations, version control folders, work item query folders - are inherited down the hierarchy. That is, a user's permissions that are set at area-1 are inherited by area-1/sub-area-1, if the same permission is not explicitly allowed or denied for area-1/sub-area-1. If a permission is set explicitly for an object, like area-1/sub-area-1, then the parent node is not inherited, regardless of whether it is denied or allowed. If it's not set, then the permissions for that node are inherited from the closest ancestor that has the permission explicitly set.

When permission is Not set for a user or group, the user or group can be affected by the explicit state for the permission for groups to which they belong because permissions in TFS are inherited. For example, when you review the permissions for a user or group, you might see both Allow and Inherited allow set for permissions. The latter permission is inherited from some other group the user or group belongs to. In this example, a user might belong to a group at the project level and a group at the collection level in a project. If one of those groups has a permission that is explicitly set to Allow and the other group has the same permission Not set, the user will have the Inherited allow permission to perform the actions that are controlled by that permission. The user inherits permissions from both groups, and the Allow permission takes precedence over the Not set permission. 

To understand why a permission is inherited, you can pause over the permission setting, and then choose Why?. A new window will open. It displays the inheritance information for that permission.

Some object-level Security dialog boxes provide an Inheritance on/off option. Use this option to disable inheritance for folders, shared queries, and other objects. 

Do's and Don'ts when assigning permissions

Do's:

Use Windows groups when managing lots of users.

Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project.

When adding many teams, consider creating a Team Administrators group to TFS where you allocate a subset of the permissions available to Project Administrators.

When adding teams, consider what permissions you want to assign to team leads, scrum masters, and other team members who may need to create and modify area paths, iteration paths, and queries.

Dont's:

Don't add accounts to the Readers group that you've added to the Project Administrators group. Doing so causes a Deny state to be assigned to several permissions.

Don't change the default assignments made to a valid users group. If you remove or set the View instance-level information permission to Deny for one of the Valid Users groups, no users in the group will be able to access the team project, collection, or deployment, depending on the group you set.

Don't assign permissions that are noted as 'Assign only to service accounts' to user accounts. 

You can't change the permission settings for the Project Administrators group or the Project Collection Administrators group, which is by design. However, for all other groups, you can change the permissions.