Team Foundation Server [Manage User or Group in TFS)

Manage users or groups in TFS

For users to have access to your team project in Team Foundation Server (TFS), you need to grant them access. If you’re an administrator for a small team and restricting access isn’t important, simply add your team members to TFS.

However, if you need to grant access to a large number of users who perform different roles within the team, then the recommended practice is to create Windows or Active Directory groups, add these groups to TFS groups, and add the same groups to grant access to additional resources.

Steps to manage users and groups in TFSThe last three steps are optional. You only have to grant permissions for reports or the project portal if your team project has been provisioned with SQL Server Reporting Services or a SharePoint site. Also, you only have to change access levels if you need to enable an entire group to access premium features or if you want to enable stakeholders or non-licensed users limited access.

How TFS manages access

If you need to make sure that the right users have the correct access or permissions to features and functions, it helps to understand that TFS controls access through three inter-connected functional areas:

  • Access level management controls access only to features provided through TWA, the TFS web application. Based on their user license, administrators grant access to standard, full, or limited set of features. For licensing information, see, Visual Studio and MSDN Licensing Whitepaper.
  • Membership management supports adding individual Windows user accounts and groups to default TFS groups. Also, you can create TFS groups. Each default TFS group is associated with a set of default permissions. All users added to any TFS group are added to the Valid Users group. A valid user is someone who can connect to the team project.
  • Permission management controls access to specific functional tasks at different levels of the system. Object-level permissions set permissions on a file, folder, build definition, or a shared query. Permission settings correspond to Allow, Deny, Inherited allow, Inherited deny, and Not set.

Each functional area uses groups to simplify management across the deployment. You add users and groups through the TFS web service administration pages. Permissions are automatically set based on the TFS group that you add users to, or based on the object, project, collection, or server level to which you add groups. On the other hand, access level management controls access for all users and groups at the server level.

TFS access, membership, and permission managementNotes:

  • Standard Features: Includes access to the Home, Code, Work, Build, and administrative pages in Team Web Access (TWA). Go here to learn more about access levels.
  • AD: Active Directory. You can create local groups or Active Directory groups to manage your users. If you decide to use groups, make sure that membership in those groups is limited to TFS users. Because group membership can be altered by their owners at any time, if those owners did not consider TFS when they created those groups, their changes to membership can cause unwanted side effects within TFS.

Here’s what you need to know about permission settings:

  • Allow or Deny explicitly grants or restricts users from performing specific tasks, and are usually inherited from group membership.
  • Not set implicitly denies users the ability to perform tasks that require that permission, but allows membership in a group that does have that permission set to take precedence, also known as Inherited allow and Inherited deny.
  • For most groups and almost all permissions, Deny trumps Allow. If a user belongs to two groups, and one of them has a specific permission set to Deny, that user will not be able to perform tasks that require that permission even if they belong to a group that has that permission set to Allow.

    For members of the Project Collection Administrators or Team Foundation Administrators groups, Deny doesn’t trump Allow. Permissions assigned to these groups take precedent over any Deny set within any other group to which that member might belong.

  • Changing a permission for a group changes that permission for all users who are granted that permission through their membership in that group. In other words, depending on the size of the group, you might affect the ability of hundreds of users to do their jobs by changing just one permission. So make sure you understand the impact before you make a change.

Two useful tips for understanding the effects of change: The Member of tab shows the groups that an individual user or group belongs to. You can also hover over an inherited permission, and a Why? icon will appear. If you choose it, a dialog box will open with more information.

Security page, Contributor role, permissions

Set up groups for use in TFS deployments

Managing users in TFS is much easier if you create Windows or Active Directory groups for them, particularly if your deployment includes SharePoint Foundation and SQL Server Reporting Services.

Users, groups, and permissions in Team Foundation Server deployments

Team Foundation Server, SharePoint Products, and SQL Server Reporting Services all maintain their own information about groups, users, and permissions. To make managing users and permissions across these programs simpler, you can create groups of users with similar access requirements in the deployment, give those groups appropriate access in the different software programs, and then just add or remove users from a group as needed. This is much easier than maintaining individual users or groups of users separately in three separate programs.

If your server is in an Active Directory domain, one option is to create specific Active Directory groups to manage your users, like a group of developers and testers for all projects in the team project collection, or a group of users who can create and administer projects in the collection. Similarly, you can create an Active Directory account for services that can’t be configured to use the Network Service system account as the service account. To do so, create an Active Directory account for SharePoint Foundation and as the read-access data source account for reports in SQL Server Reporting Services.

Important note Important
If you decide to use Active Directory groups in TFS, consider creating specific ones whose purpose is dedicated to user management in TFS. Using previously existing groups that were created for another purpose, particularly if they are managed by others who are not familiar with TFS, can lead to unexpected user consequences when membership changes to support some other function.

The default choice during installation is to use the Network Service system account as the service account for Team Foundation Server and SQL Server. If you want to use a specific account as the service account for security purposes or other reasons, such as a scaled-out deployment, you can. You might also want to create a specific Active Directory account to use as the service account for SharePoint Foundation and as the data source reader account for SQL Server Reporting Services.

If your server is in an Active Directory domain but you don’t have permissions to create Active Directory groups or accounts, or if you’re installing your server in a workgroup instead of a domain, you can create and use local groups to manage users across SQL Server, SharePoint Foundation, and Team Foundation Server. Similarly, you can create a local account to use as the service account. However, keep in mind that local groups and accounts are not as robust as domain groups and accounts. For example, in the event of a server failure, you would need to recreate the groups and accounts from scratch on the new server. If you use Active Directory groups and accounts, the groups and accounts will be preserved even if the server hosting Team Foundation Server fails.

For example, after reviewing business requirements for the new deployment and the security requirements with the project managers, you might decide to create three groups to manage the majority of users in the deployment:

  • A general group for developers and testers who will participate fully in all projects in the default team project collection. This group will contain the majority of users. You might name this group TFS_ProjectContributors.
  • A small group of project administrators who will have permissions to create and manage projects in the collection. You might name this group TFS_ProjectAdmins.
  • A special, restricted group of contractors who will only have access to one of the projects. You might name this group TFS_RestrictedAccess.

Later on, as the deployment expands, you might decide to create other groups.

To create a group in Active Directory

  • Create a security group that is a local domain, global, or universal group in Active Directory, as best meets your business needs. For example, if the group needs to contain users from more than one domain, the universal group type will best suit your needs. For more information, see Create a New Group (Active Directory Domain Services).

To create a local group on the server

  • Create a local group and give it a name that will quickly identify its purpose. By default, any group you create will have the equivalent permissions of the Users default group on that computer. For more information, see Create a local group.

To create an account to use as a service account in Active Directory

To create a local account to use as the service account on the server

  • Create a local account to use as the service account and then modify its group membership and other properties according to the security requirements for your business. For more information, see Create a local user account.

Add users to team projects

As roles and responsibilities change, you might need to change the membership or permission levels for individual members of a team project. This is particularly true if your project depends on resources that use SQL Server Reporting Services or SharePoint Products because permissions for those resources are managed separately.

If all you want to do is add a user to an existing team in TFS, and you don’t have to worry about specific permissions for other resources, skip this topic and simply add them to a team.

Permissions are different than access levels. Access levels control what features are visible to users in Team Web Access, and are dependent on user licenses; permissions control a user’s ability to use features across TFS. If you’re just trying to give someone access to a team room or to Agile portfolio management and test case management features, you’ll want to change access levels, not permissions.

Verify your permissions in TFS

Before you change permission levels for others, make sure that you have the right level of permissions.

  1. Open the administrative context for your team project. Settings icon
  2. In the Security tab, under users, find your own name, and look at what groups you belong to and what permissions you have.
  3. If you aren’t a project administrator, you need to be. Find someone who is, and have them add you:

    You can add more than one person at a time

  4. If you need to make changes at the team level, change your context to the team overview. If you aren’t a team administrator, you can add yourself if you’re already a project administrator. Otherwise, have someone add you.

    Team administrators do not have to be team members

  5. Similarly, if you need to add users to SharePoint Products or SQL Server Reporting Services, make sure that you have the required permissions. For reporting, you must be either a member of the local Administrators group on the report server or be a member of a group specifically created to add users. The requirements for SharePoint Products are more complex. For more information about SharePoint 2013, go here.

Add users to a project in Team Foundation Server

  1. Open Team Web Access and navigate to the project where you want to add users or groups.

    Select team project from TFS home pageTip: Managing user access to TFS is much easier if you add user groups, not individual users. Learn how to Set up groups for use in TFS deployments.

    Choose the gear icon Settings icon to open the administration context for the project, and then navigate to the Security tab.

  2. In Groups, choose one of the following:
    • To add users who will require minimal access to the project, choose Readers.
    • To add users who will contribute fully to this project, choose Contributors. By default, the team group created when you created the project is included as a member of the Contributors group, so you could choose to add the new user as a member of the team instead, and the user would automatically inherit Contributor permissions. For more information, see Add team members to a team.
    • To add users who will act as project leads, choose Project Administrators.

    After you have chosen one of those groups, add a user or a user group.

    Choose the team project group and add members

  3. In Identities, specify the name of the user or group you want to add.

    Account entry box on Add a user or group dialog

    Tip Tip
    The first time you add a user or group to Team Foundation Server, you cannot browse to it or check the friendly name. After the identity has been added once in Team Foundation Server, you can just type the friendly name.
  4. Depending on the user, you might want to customize their permissions for other functionality in the project, such as areas and iterations or shared queries. You can also control access to projects, version control, build, and work items; learn how in Restrict access in TFS.

If your TFS deployment is integrated with SharePoint Foundation, you’ll need to manage membership in the SharePoint groups to grant permissions to the team project portal for your TFS users.

Add users to SharePoint Foundation

  1. Open your project portal. (If you’re not sure what the URL is, open Team Explorer, choose Settings, and then choose Portal Settings. The URL for the portal is listed.)
  2. Choose Share, and add users or user groups to the appropriate SharePoint groups.

    Choose the SharePoint group and add users

    • To add users who will require minimal access to the project, choose Readers.
    • To add users who will contribute fully to this project, choose Contributors.
    • To add users who will act as project leads, choose Full Control.

For more information about users and groups in SharePoint Products, go here.

If your TFS deployment is integrated with SQL Server Reporting Services, you’ll need to manage users in the appropriate SQL Server Reporting Services groups, or they won’t be able to view or edit those reports.

Add users to SQL Server Reporting Services

  1. Open Internet Explorer or another browser compatible with Reporting Services administration, and navigate to the following address, where ReportServer represents the name of the server that is running SQL Server Reporting Services:

    http:// ReportServer /Reports/Pages/Folder.aspx

  2. On the Home page, choose Folder Settings, and in Security, choose New Role Assignment and add users.
    • To add users who can act as readers of or contributors to the project, select the Browsers check box.

      Click or tab to selection and spacebar to check

    • To add users who will act as project leads, select the Team Foundation Content Manager check box.

      Choose the role assignment for the user or group

If you’re a member of Team Foundation Administrators, you can verify what features are available for your users by default, and see whether any users are members of groups that have access outside of the default level.

Verify features available for a user or group of users

  1. Open Team Web Access in administration mode, and choose Control Panel to navigate to the top-level administration context.
  2. Choose the Access levels tab.
  3. Choose the name of each license group in turn, and review the following information:
    • Which licensing group is set as the default group for the deployment. That group name will be followed by (Default). This is the group that all users of your deployment of Team Foundation Server will be assigned to by default.
    • Whether the user for whom you are determining licensing levels is a member of a different licensing group than the default group. If so, review the description of the features of that licensing group to better understand what features are and are not available to that user.
  4. To review the licensing group membership of all users in the deployment at once, choose Export Audit Log. The membership information will be exported to a comma-delimited file. Save or open the file.

Change access levels

Access levels allow groups of users to access features in Team Web Access (TWA) based on their license level when working in an on-premises deployment of Team Foundation Server (TFS). Certain features, such as test case management and team rooms, require Full access.

You only set access levels for on-premises TFS. For Visual Studio Online, account licenses control access to premium features.

As an administrator, you assign users or groups of users to one of the three levels of access—standard, full, and limited—based on the license that each user has.

Access level Required license level
Standard TFS client-access license (CAL).
Full One of these MSDN subscriptions: Visual Studio Ultimate with MSDN, Visual Studio Premium with MSDN, or Visual Studio Test Professional with MSDN.
Limited No license required. Assign Limited access to customers or stakeholders that you want to collaborate with but who aren’t on your team.

You can find out more about licensing from the Visual Studio and MSDN Licensing White Paper.

Add a user or group to an access level

If you’re managing access for a large group of users, a best practice is to first create either a Windows group or TFS group and add individual accounts to those groups.

  1. From the TFS home page (for example, http://myserver:8080/tfs), go to the server administration page.

    Go to the administration page

  2. Select the level and then add the user or group.

    Add the user or groupIf you don’t see the Access levels tab, you aren’t a TFS administrator and don’t have permission. Here’s how to get permission.

Quick reference to access levels and features

The following table indicates which features users can access based on their access level or Visual Studio Online license level. This information depends on your product version and is subject to change. For a full comparison of products and features, go here.

Feature areas On-premises TFS Visual Studio Online
Limited Standard Full Stakeholder Basic and Professional (1) Advanced MSDN Subscription
View my work items check mark check mark check mark check mark check mark check mark check mark
Standard Features (2) check mark check mark check mark check mark check mark
Version control using either Team Foundation version control or Git-based repositories check mark check mark check mark check mark check mark
Work item tracking check mark(3) check mark check mark check mark(3) check mark check mark check mark
Agile Planning Tools (4) check mark check mark check mark(5) check mark(5) check mark check mark
Agile Portfolio management check mark check mark(5) check mark(5) check mark check mark
Work item charting check mark(5) check mark check mark(5) check mark check mark
Build Automation check mark check mark check mark check mark check mark
Web-based Test Management check mark check mark check mark
Request and manage feedback check mark check mark check mark
Team rooms check mark check mark check mark
Home page administrative links check mark check mark check mark check mark check mark
Administer accounts, team projects check mark check mark check mark check mark check mark

Notes:

  1. Visual Studio Online Professional includes support for Office 365 business apps and the ability to work in one IDE to create solutions for the web, desktop, cloud, server, and phone.
  2. Standard Features include access to these hubs: Home, Code, Work, and Build. And, it includes access to administrative pages that support managing teams, membership, permissions, area and iterations, sprint schedules, and alerts.
  3. With Limited access, users can create and modify only those work items that the user creates and can query on their own work items only. With Stakeholder access, users can create and modify all work items, and can create and save queries on all work items under their My Queries folder.
  4. Agile Planning Tools include Agile Kanban and task boards and backlog and sprint planning.
  5. Read-only.
Standard access

With standard access, you can manage work in a product backlog

Changing velocity changes forecast lines…configure sprints with their own backlogs and task boards…

The sprint backlog shows items, tasks, and bugs…and view work in progress on the Kanban board.

View of the Kanban board

Full access

Full access includes access to everything included with Standard access, plus additional features.

For example, with Full access, you can work with portfolio backlogs.

Drill down to backlog items, bugs, and tasksYou also have access to team rooms.

Team room with messages and links to eventsAnd you can use the test case management tools.

New button in the test plan explorer paneYou can author charts to help your team visualize progress.

ALM_MC_DashboardYou can also request and manage feedback from customers.

Request feedback link on Home page

Limited access

Users who have limited access can create work items and edit the work items that they created, but they don’t have access to any other pages. This is also referred to as Work Item Only View. Here’s what limited access looks like.

View work items that you have created

To add a group of users to Limited access

  1. Create either a Windows group or TFS group.
  2. Add the user accounts to the group you just created.
  3. Add the group to Limited access.

    Limited access level, Add Windows user or group

Permissions and access levels

Of course, none of these levels of access expose information that you don’t have permission to view. Make sure your users have both the permissions and the access levels they need. If they’re members of the team, then they probably have the right permissions to use full and standard access.

Restrict access in TFS

Sometimes you don’t want all users in your deployment to have visibility into all projects in that deployment. By default, users who have permissions to access one project within a collection can view other projects within that collection, even if they don’t have permissions to modify work items or perform other actions in that project. If you want to restrict a particular group to just one project in the collection, you must take extra steps.

Restricting access to projects in the deployment

In Team Foundation Server, permissions explicitly set to Deny generally take precedence over permissions set to Allow. There are exceptions to this, but they generally don’t apply to user groups (and you can read more about these exceptions in Team Foundation Server permissions). So if you want to restrict a particular group from viewing a particular project, you must(1) create a specific Team Foundation Server group in that project, (2) add that restricted group to that project-level group, and then (3) explicitly set the View project-level information permission to Deny for that Team Foundation Server group. In other words, you specifically create a group for the users you don’t want to view a project, add that group to the project you don’t want them to view, and then set permissions on that group to restrict the users in that group from viewing that project. It’s a little counterintuitive, but it works!

  1. Open Team Web Access (TWA), change views to the administration context for the project by choosing the gear icon Settings icon, and choose the Security tab.
  2. On the Groups tab, create a TFS group.

    Create TFS Group link on Security admin pageThe CREATE NEW TEAM FOUNDATION SERVER GROUP window opens.

  3. In Group Name, specify a name for this group, such as “Reviewers.” Optionally, type a description for this group, and then choose OK.

    Create the Reviewers TFS groupThe group you just created appears in the list of TFS Groups. Make sure that it is highlighted in the list, and then choose the Members tab.

  4. Choose Add user.

    The ADD A WINDOWS USER OR GROUP window opens.

    Account names in Add a window or user group

  5. In Identities, specify the name of the group you want to add and save your changes.

    Add a group to the list of TFS Groups

  6. Choose the Permissions tab. In the permissions list, toggle the value of View project-level permission to deny, and then choose Save Changes.

Set administrator permissions for team project collections

In TFS, each team project collection is its own grouping of projects that can share reports, work items, and other items, all stored in a single database. Project collection administrators maintain the collection and administer permissions and security for other roles at the collection level.

Add a collection administrator in Team Foundation Server

  1. Open Team Web Access and switch to administration mode by choosing the gear icon Settings icon.
  2. Navigate to security at the collection level, and add a member to Project Collection Administrators.

    Navigate by clicking or tabbing

Add a user as a site collection admin in SharePoint Foundation

If your deployment is integrated with SharePoint Products, add team project collection administrators to the site collection administrators group in SharePoint Products. Skip this procedure if your deployment does not integrate with SharePoint.

  1. Open SharePoint Central Administration.
  2. Grant permissions that are appropriate for this user at the farm or the Web application level, depending on your security needs.

    For optimum interoperability, consider adding users of the Project Collection Administrators group to the Site Collection Administrators group in SharePoint Products.

    Follow guidance for your version of SharePoint

Add users in Reporting Services

If your deployment is integrated with a report server, add team project collection administrators to the Team Foundation Content Manager group in SQL Server Reporting Services. Skip this procedure if your deployment does not integrate with a report server.

  1. Open Internet Explorer running as an administrator.
  2. In the Address bar, specify the following URL, where ReportServer is the name of the server that is running Reporting Services: http://ReportServer/Reports/Pages/Folder.aspx
    Important note Important
    If you are using a named instance, you must include its name in the path of the reports. You use the following syntax, where ReportServer is the name of the report server for Team Foundation and InstanceName is the name of the instance of SQL Server: http://ReportServer/Reports_InstanceName/Pages/Folder.aspx
  3. On the Home page, choose Folder Settings, and add the user by granting them the Team Foundation Content Manager role as a new role assignment.

    Click and choose, or tab, spacebar, and enter

Set administrator permissions for Team Foundation Server

To perform system maintenance, schedule backups, add functionality, and do other tasks, administrators in Visual Studio Team Foundation Server (TFS) must be able to configure and control all aspects of TFS. That’s why TFS administrators require administrative permissions in the software programs that TFS interoperates with. You can quickly grant these permissions to administrators by adding them to the Team Foundation Administrators group in Team Foundation Server (TFS). However, you should only grant this level of permission to the minimum number of users needed to maintain TFS.

  1. On the application-tier server, add the user to the local Administrators group.

    Follow instructions for your operating system

  2. Open the administration console and add a console user.

    Click or tab, then input username

  3. Review the progress to make sure that the user account is added to all aspects of the deployment, including SharePoint and reporting resources.

    Review progressIf you’re running a standard single-server deployment, or a multi-server deployment without SharePoint or reporting, that’s it! However, if you have multiple application tiers, you’ll need to repeat these two steps on every application tier server. And if you have SharePoint or reporting on other servers, you might need to manually add administrative users to those products separately.

To grant administrative permissions in SharePoint Foundation

  1. On the server that is running SharePoint Products, open SharePoint Central Administration.
  2. Grant permissions that are appropriate for this user at the farm or the Web application level, depending on your security needs.

    For optimum interoperability, consider adding users of the Team Foundation Administrators group to the following groups in SharePoint Products:

    • Farm Administrators
    • Site Collection Administrators group for all site collections that the deployment of Team Foundation Server uses

    Follow instructions for your version of SharePoint Follow guidance for your version of SharePoint

To grant administrative permissions in Reporting Services

  1. Start Internet Explorer.
  2. In the Address bar, specify the following URL, where ReportServer is the name of the server that is running Reporting Services: http://ReportServer/Reports/Pages/Folder.aspx
    Important note Important
    If you are using a named instance, you must include its name in the path of the reports. You use the following syntax, where ReportServer is the name of the report server for Team Foundation and InstanceName is the name of the instance of SQL Server: http://ReportServer/Reports_InstanceName/Pages/Folder.aspx
  3. Choose Folder Settings, and then choose New Role Assignment.
  4. Add the account name of the user or group to whom you want grant administrative permissions and grant them membership in the Team Foundation Content Manager role.

    Click and choose, or tab, spacebar, and enter

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s