Learn to use Visual Studio, Visual Studio Online, Application Insights and Team
Foundation Server to decrease rework, increase transparency into your application and increase the rate at which
you can ship high quality software throughout the application lifecycle
Do you have code that should be seen by only a subset of members of your on-premises team project collection? Do you use Team Foundation Build (TFBuild)? If so, you must create some custom groups to reduce the risk that unauthorized team project collection members can use a build process to bypass team project permissions.
For example, you administer the following team projects:
You want only the members of each team project to be able to read the code it contains, as shown above. However, by default, TFBuild controllers are collection-scoped resources, and so have permission to access all code in the collection. This means people who are not members of a team project could use a build process to obtain the code it contains.
For example, Johnnie is a member only of TfvcProjectA, but it is in the same team project collection as TfvcProjectB. So he could create a build process that delivers him the content from TfvcProjectB. Specifically, he can:
To prevent this kind of access, implement some custom groups and deny the Project Collection Build Service Accounts group all permissions. For example, you are running four build servers as NETWORK SERVICE:
The following diagram details the membership and permission settings:
Q: Why must I deny permissions to members of the Project Collection Build Service Accounts group?
Note: This guidance applies only to on-premises Team Foundation servers. We don't support this scenario for Visual Studio Online team projects.
From the security page of team project collection, create the collection-level groups.
For each of your collection-level groups, grant the following permissions:
Add each build service account to one (and only one) of the collection-level groups.
Q: Where can I get the name of the build service account? A: See Deploy and configure a build server.
Modify the Project Collection Build Service Accounts group:
From the areas page of each of the team projects served by the collection-level group, grant work item permissions:
Set all the permissions of the Project Collection Build Service Accounts group to Deny.
From the build page of each of the team projects served by the collection-level group, grant build permissions:
Which kind of version control does your team project have?
From the version control page of each of the team projects served by the collection-level group, grant TFVC version control permissions:
From the version control page of each of the team projects served by the collection-level group, grant Git version control permissions:
From the security page of each of your team projects, create a project-level group:
For each project-level group, grant the following permissions:
Add the appropriate collection-level group to the project-level group:
A: To mitigate the risk of unauthorized access to team project resources, you should set all permissions of this group to Deny. Even if you personally are careful not to add members to the group, this could happen:
I invite you to post:
thanks for the information