Is there any way to completely remove an user from a TFS2013 server (even from project valid users list).
I've a developer who is part of different collections/projects (around 50) and it's hard to remove them from each and every collection/project. Also if I go and remove manually I'm not sure how accurate it will be. They are moved to a different project and are not using TFS anymore. I want to remove him completely.
When a user with access to Team Foundation Server (TFS) leaves a company, an administrator would typically remove them from Azure Active Directory or Active Directory. This will automatically void their user account and remove their ability to access or connect to TFS.
In your case to remove an obsolete account from TFS, usually need to delete the user from all groups/collection they belonged to. You could remove it from Global Security dialog in security of team project collection. In the Users and groups list, click the user whom you want to remove, and click Remove.
For multiple collection/groups, you could also use tfssecurity command.
Use tfssecurity /i command to list users belongs to which groups
tfssecurity /i "domain\account" /server:http://serverName:8080/tfs
And using tfssecurity /g- command to remove that user from a group
tfssecurity /g- "[TeamProject1]\Contributors" n:domain\account /collection:http://serverName:8080/tfs/Collection
Another solution could be using this 3-party software--Team Foundation Server Administration Tool it works with tfs 2013.
Moreover, changes you make to local or Active Directory groups do not get reflected in TFS immediately. Instead, TFS will synchronize those groups regularly.
A periodic clean-up job that is executed removes people from the global groups. If you just wait, they will disappear in a couple of days. They will not have access to any of the TFS assets however.
Well, you could also kick it off: Force TFS to sync with Active Directory
Related
I have a script that we are using to configure security in our on-premise TFS 2017 instance. We want to give the Contributors group access to change iteration info for a project (which normally only the Project Admins can do). I was able to accomplish giving them access to create new iterations under the Admin > Work > Iterations tab by running the following commands:
tfssecurity.exe /a+ Iteration $rootIterationUri CREATE_CHILDREN "n:[$projectName]\Contributors" ALLOW /collection:$collection
tfssecurity.exe /a+ Iteration $rootIterationUri DELETE "n:[$projectName]\Contributors" ALLOW /collection:$collection
tfssecurity.exe /a+ Iteration $rootIterationUri GENERIC_WRITE "n:[$projectName]\Contributors" ALLOW /collection:$collection
However, I also want them to be able to change the default team's iteration settings as well (changing the default iteration, what's in the Backlogs hub, etc.) and I can't find how to do that. Does anyone know what I can run in TfsSecurity to grant this access?
If you want to configure the default team's settings, you must either be a team administrator or a project administrator.
So, you need to add the Contributors group to team administrator or a project administrator group.
eg:
tfssecurity /g+ "[ProjectName]\Project Administrators" "n:[ProjectName]\Contributors" /collection:http://server:8080/tfs/DefaultCollection/
I'm managing an instance of TFS 2015. I added a special TFS group to a branch to deny access to certain users. I now want to remove this group from the branch, but I don't see how it's possible. I'm currently looking in the Version Control tab under the TFS Control Panel for the project, where I added the group to the branch to begin with. Is there a place to specifically remove a TFS group from a branch? Otherwise what is a reasonable work-around?
You can use tfssecurity /g- to remove a user or a user group from an existing group. More details of tfssecurity command from MSDN. A example:
tfssecurity /g- groupIdentity memberIdentity [/collection:CollectionURL] [/server:ServerURL]
Or, refer to this issue Cannot remove user/group from area-level, iteration-level, version control, build security setting, it seems by design. Please try the method from the comment: 'If your user's permissions are all configured to "not set", then the user will be removed from the dialog the next time you launch it.'
I'm working with TFS 2015 using the ALM Rangers Development & Release Isolation Branching Strategy and Team Foundation Version Control. I would like to keep developers from checking code into the Main branch and letting them only work in Dev and Release branches. I want to allow the Project Administrators and above to perform the merges and check ins to Main.
With Team Web Access:
I selected the drop-down next to my Main branch and selected
"Security".
Set Inheritance to "Off".
For Contributors, Set Check in and a few other permissions to "Deny".
Saved Changes.
For Project Administrators, set the same permissions to "Allow"
Saved Changes.
TFS changed the values of each of the Project Administrators permissions to "Inherited deny*"
I have heard that setting "deny" can cause problems. Now I understand why I was told that. Is there a way to achieve my stated goal above, through standard TFS permission settings?
Cann’t reproduce your problem with the same settings in my TFS2015.
According to TFS permission setting, 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.
To achieve what you want, you can create a new group such as DenyMainGroup. Adding the developers to this group. Make sure your project administrator members don’t belong to it. For this group, set Check in and a few other permissions to “Deny”. For Contributors and Project Administrators, set the same permissions to”Allow”. Saved Changes.
If I load up TFS Web Access and go to Security > Users, I only see the 3 people I've added to my team. However, when I try to assign a task to someone in Web Access or in Visual Studio, it lists a bunch of users from the domain (not all users, looks like all IT people). Where does this come from? How can I change it... without exporting, editing and importing files via command line?
update: I found this line in the MSDN documentation:
Team Foundation \Team Foundation Valid Users
Members of this group
have access to Team Foundation Server. This group automatically
contains all users and groups that have been added anywhere within
Team Foundation Server. You cannot modify the membership of this
group.
I really don't understand... this is our own team's server, a separate install from the main dev team. I have no idea how these other 30 or 40 users got in this group. Major bonus <3 for any help on this. MikeR's answer will allow me to set administrators as the only assigness which will technically fix the issue, but I'd rather be able to use the groups as they were intended if possible.
The problem was that [TEAM FOUNDATION]\Valid Users included [TEAM FOUNDATION]\Team Foundation Administrators which included [BUILT IN]\Administrators
In the TFS Server Administration Console I selected Application Tier and clicked Group Membership. I then double-clicked on [TEAM FOUNDATION]\Team Foundation Administrators and removed [BUILT IN]\Administrators.
Now I only see my team and not all the SQL admins and engineers that were local admins on the server. All without any command line or addons.
This list of possible assings is defined in the WorkItemTypeDefinition. Usually you would export and import this. If you have the TFS PowerTools (http://visualstudiogallery.msdn.microsoft.com/b1ef7eb2-e084-4cb8-9bc7-06c3bad9148f) installed, you can directly work with the WITD in Visual Studio.
To do this, open "Tools->Process Editor->Work Item Types->Open WIT from Server". Choose the TeamProjectCollection you want to connect to and than choose the TeamProject and WorkItemType you are having trouble with.
Check the rules for "AssignedTo" field. Default could be the "ValidUser" rule, which includes every permitted user in TFS. Remove that rule and add a new one "AllowedValues" rule with values like "[project]\Project Administrators", than only "Project Administrators" can be assigned to this Work Item.
If there is already a group defined and not all "ValidUser", remove users from the group set is set there.
Is there a way to deactivate a project in TFS? (not delete, just deactivate so nobody can checkout or checkin)
This is more of a precaution rather than a hard enforcement. We have a project that was branched but was recently merged to a trunk. This project is no longer in use and I don't want anyone to accidentally use it by checking in/out any of its content. It will eventually be deleted when we have tested the merge completely
In Team Explorer, right click on the project and bring up Team Project Settings -> Group Membership. Go through each group, click Properties, and remove all users and groups from each group. This should prevent anyone who doesn't have a TFS administrator role from being able to check the code out. It may even prevent TFS administrators from being able to check it out without first adding themselves back to the correct project group.
I think this will work, but you should try it as I've never actually done it.
If you still want the project to be available, somebody could just put a lock on the project to prevent check-ins and check-outs. It will remained locked by the user who locks it until either the user unlocks it or their workspace is deleted. An admin can also unlock it using tf.exe.
You can lock a project, branch, folder, or file by right clicking on it and selecting the Lock option from the context menu (note: what you are locking has to exist physically on your drive). This page describes the various types of locks you can place on an item.
For work, I wrote a plug-in to automatically place a check-out lock on production branches once certain criteria are met. The lock is held by the account running the TFS services (in our case, Network Service). Nobody can check-out or check-in files in these branches until somebody uses tf.exe to unlock the branch.