TechPrufer
Get started
Microsoft
Microsoft logoMicrosoft · Feature trail

Team Foundation Server Permissions Management

16 posts · May 2005 – Aug 2014

What this trail covers

This thread tracks patching and maintenance for Team Foundation Server (TFS) and Azure DevOps Server. It includes releases of security patches, cumulative updates, and detailed installation instructions for various scenarios like load-balanced application tiers and SQL mirroring/AlwaysOn configurations. The focus is on ensuring system stability and security through timely updates and adherence to proper installation procedures. This post details how to set up permissions for the security scenario.

All Microsoft trails
  1. Restrict Team Foundation Build permissionsThis post details a specific security configuration for on-premises Team Foundation Server (TFS) to restrict access to code via build processes. It outlines the creation of custom collection-level and project-level groups, and the precise denial of permissions to the 'Project Collection Build Service Accounts' group for work items, builds, and version control (TFVC and Git). This is presented as a solution to a problem where TFBuild controllers, by default, have collection-scoped permissions that could allow unauthorized access to code in different team projects.
  2. TFS 2012 Update 1: Permissions lost on attaching a collection–fix availableThis post announces a patch for TFS 2012 Update 1 that fixes a critical issue where permissions are lost when attaching a collection to a server running TFS 2012 Update 1 or when executing 'tfsconfig changeServerId'. The patch restores lost permissions and addresses issues with group membership import. Detailed installation instructions are provided for various configurations, including load-balanced application tiers and SQL Mirroring/AlwaysOn. The post also details the process of updating the patch if a previous version was installed and apologizes for the disruption.
  3. Choosing the Right Tool for the Task to Manage Projects, Collaborate, and Monitor Progress in Visual Studio ALMThis post provides a roadmap for choosing the best Team Foundation client (Team Web Access, Team Explorer, Microsoft Test Manager, Microsoft Excel, Microsoft Project) for specific project management, collaboration, and progress monitoring tasks in Visual Studio Team Foundation Server 2012. It details which clients support tasks like backlog grooming, sprint planning, test case creation, bug triage, requesting feedback, code reviews, and reporting (burndown, velocity, project timeline). It also highlights which clients allow offline work and the licensing requirements for certain features.
  4. When did my test plan get deleted? Who deleted my test suitetest run?Introduces a command-line tool (TFSLogs.exe) to parse and interpret the TFS collection database table 'tbl_AuditLog' for deleted test artifacts. The tool generates a CSV file with human-readable audit log entries, requiring TFS admin permissions and installation of Visual Studio 2010/2012 or TFS 2010/2012. It notes that the tool does not work against hosted TFS and that object IDs are needed to identify deleted artifacts.
  5. Quick Response Sample – Command line utility to manage Team Foundation Server Teams and UsersIntroduced a command-line utility (TFSTeams.exe) to manage teams and their members within Team Foundation Server 2012 RC. This utility was developed as a "Quick Response" sample by the ALM Rangers to address a feature gap identified during the setup automation for a Hands-on Lab. The sample code, based on the Team service and Identity Management Service (IMS) in TFS, allows for listing teams, creating new teams with descriptions, and adding users to existing teams. The post provides sample code extract (TeamWrapper.cs) and usage instructions.
  7. How to improve the performance of the first connect to TFSThis post introduces a method to improve the performance of the first connection to Team Foundation Server (TFS) by filtering the metadata cache for work items. It details how to update a specific registry value in TFS 2010 and TFS 2012 using a PowerShell script. The script loads the correct version of the Client assembly, targets either the configuration hive (for all collections) or the collection hive (for a specific collection), and sets the '/Service/WorkItemTracking/Settings/FilterMetadata' registry value to 'True' and '/Service/WorkItemTracking/Settings/ExcludedAgents' to 'WebAccess:witadmin'.
  8. What's New in the Visual Studio Team Foundation Server 11 Developer PreviewThis post announces the Developer Preview of Visual Studio Team Foundation Server 11, detailing numerous new features and enhancements across various aspects of application lifecycle management. Key updates include a redesigned UI for Team Web Access and Team Explorer, improved performance, and new pages like 'backlog', 'board', and 'alerts' in Team Web Access. Agile project management features are expanded with team definition, product backlog management, task boards, and burndown charts. Requirements management is enhanced with PowerPoint Storyboarding and Microsoft Feedback Manager. Developer productivity is boosted with 'My Work', 'Work Items', and 'Pending Changes' in Team Explorer, along with multi-party code reviews. Version control sees improvements in local workspaces, file comparison, rollback, and merge enhancements. Build definitions support multiple check-ins and unit test frameworks. Work item tracking allows inline images, video, and tables, and offers more customizable alerts. New work item types like 'Feedback', 'Code Review Request', and 'Code Review Response' are introduced. Administration features include enhanced team management, nested iterations, and date settings for sprints.
  9. Trusts and Forests Considerations for Team Foundation ServerThis post details the considerations for trusts and forests when deploying Team Foundation Server (TFS) across different Active Directory domains and forests. It outlines the supported Active Directory modes and functional levels, and the trust relationships required between various TFS components (clients, application-tier server, proxy server, data-tier server, build) to ensure proper authentication and authorization. It emphasizes that the domain of the Team Foundation application-tier server must trust the domain of the user and the TFSService account, and similarly for other components. It also notes that the Team Foundation Server Proxy computer's domain must trust the user's domain, and the application-tier server's domain must trust the proxy's service account domain. For the data-tier server, its domain must trust the TFSService account's domain, the TFSReport account's domain, and the application-tier server's domain. For Team Foundation Build, its domain must trust the service account's domain. The post also highlights that all other Active Directory domain configurations are unsupported and that appropriate cross-forest trusts are necessary when supporting work across multiple forests. It recommends installing TFS in a Windows Server 2003 domain environment for security considerations and suggests banning duplicate names and securing computer names by creator to avoid impersonation attacks.
  10. Moving a Team Project from One Version to the NextThis post describes the process of moving a team project from one version to the next. This involves creating a new team project, manually copying work items, setting user permissions one-by-one, copying documents, and recreating areas, iterations, check-in policies, and alerts. It also advises on determining if a new backup is appropriate due to the time-consuming nature of the migration process.
  11. Team Foundation Server PermissionsThis post discusses Team Foundation Server Groups, Permissions, and Roles, explaining that authorization for user actions is determined by permissions. It references two articles: 'Team Foundation Server Default Groups, Permissions, and Roles' for managing users and groups to implement a security model, and 'Team Foundation Server Permissions' for details on permission types and settings. The post acknowledges that providing an 'end-all-be-all best practice' is not feasible due to the complexity of the subject.
  12. Team Foundation Server Default Groups, Permissions, and RolesThis post details the default server-level, project-level, area-level, and source control groups and their associated permissions in Team Foundation Server. It also outlines how to align these default groups with roles from MSF for Agile Software Development and MSF for CMMI Process Improvement, either by assigning users to existing groups or by creating new groups for specific roles.
  13. Team Foundation Server PermissionsThis post introduces the concept of permissions in Team Foundation Server, detailing the default groups created for new projects (Project Administrator, Contributor, Reader, Build Services). It explains the explicit authorization settings: Deny (most powerful, overrides Allow), Allow (grants authorization), and Unset (implicitly denies, allows inheritance). Inheritance rules are described, with Deny taking precedence over Allow. The post then enumerates and describes server-level, project-level, area-level, and source control permissions, including their command-line names and descriptions.
  14. Getting Started with Team FoundationThis post introduces Team Foundation as a set of tools and technologies for team collaboration and project management. It details how Team Foundation enhances communication through project portals and Team Explorer, supports work item tracking with history and queries, integrates with Microsoft Project and Excel, and provides reporting capabilities. It also explains the concept of roles in process, security groups for permission enforcement, process enactment through XML customization, and tool integration within the IDE and through extensibility.
  15. Team Foundation Server Security ArchitectureThis post details the security architecture of Team Foundation Server, outlining the components that must be considered for security planning: the application tier, data tier, and client tier, along with their interactions. It describes the Team Foundation Server Object Model, including Common Services (Registration, Security, Linking, Eventing, Classification), Version Control, and Work Item Tracking. It also details the ASP.NET Web services on the application tier, the SQL Server 2005 databases on the data tier, and the client tier's use of these services and object models. Finally, it specifies default network ports and protocols (HTTP/8080 for Web Services, MS-SQL TCP/1443 for Data Tier, etc.) and outlines customizable HTTPS/SSL configurations.
  16. Team Foundation Server Security ConceptsThis post details the fundamental concepts of permissions in Team Foundation Server, including 'Deny', 'Allow', and 'Unset' authorization settings, inheritance, and precedence rules. It outlines server-level, project-level, work item tracking area-level, and source control permissions, and provides command-line equivalents. It also directs users to further resources for managing permissions.
  17. Team Foundation Server Default Groups, Permissions, and RolesThis post details the default server-level, project-level, area-level, and source control groups and their associated permissions within Team Foundation Server. It also outlines how these default groups and permissions align with the roles described in MSF for Agile Software Development and MSF for CMMI Process Improvement, and provides guidance on creating custom groups to match specific roles.
  18. Team Foundation Server PermissionsThis post details the fundamental concepts of permissions in Team Foundation Server, explaining the 'Deny', 'Allow', and 'Unset' authorization settings. It elaborates on permission inheritance and the precedence of 'Deny' over 'Allow'. The post categorizes permissions into Server-Level, Project-Level, Work Item Tracking Area-Level, and Source Control Permissions, listing specific permission names, their command-line equivalents, and descriptions for each category. It also outlines how these permissions can be managed through the Team Foundation Server user interface and command-line utilities.
  19. Setting Permissions in Team FoundationThis post details how to set up permissions for the security scenarios supported by Visual Studio Team System Beta 2. It outlines the required permissions for three roles: Team Foundation Server Administrator, Team Project Lead, and Team Project Contributor. For each role, it specifies the necessary group memberships across various systems including Application Tier and Data Tier Computer Groups, Team Foundation Server Groups, Windows SharePoint Services Groups, and Reporting Services Groups. Detailed step-by-step instructions are provided for adding members to these groups using Visual Studio, Computer Management, and Internet Explorer.