Team Foundation Server for IT Professionals - Security: Part 2
In my last post, I provided a high level overview of the security layers present in Team Foundation Server (and related products). One of the challenges around the management of user credentials is that there are so many layers to secure. There are a few ways to mitigate the complexity.
The Developer Division Customer Product Lifecycle Experience Team (DDCPX) (https://blogs.msdn.com/ddcpxblg/) from Microsoft has released a power tool on GotDotNet that allows you to administer Team Foundation Server, Sharepoint and Reporting services security from one access point. You can download the tool from the following URL: https://go.microsoft.com/fwlink/?LinkId=59385
Another method way of mitigating the complexity is by setting all your credentials on the platform level (through Active Directory or on your Windows Server 2003 server in Workgroup mode). Create your groups (developers, project managers, business analysts, ect) as shown in the figure below and add the appropriate users to each group. You can also create sub-groups based on particular Team Projects. This will allow you to specify what users should have access to individual projects.
Once you have the groups and users set up, you can then add them to Team Foundation Server. To access the security settings for the server, open up Visual Studio 2005 (make sure Team Explorer has been installed), connect to your Team Foundation Server (Tools > Connect To Team Foundation Server), and then your Team Foundation Server security settings (Team > Team Foundation Server Settings > Security). You'll get a screen as shown below:
To add your groups to Team Foundation Server, simply click on the Add button and then select the 'Windows User or Group" radio button. One of the interesting quirks around the process is that you must define at least one Allow/Deny permission to the newly added group to remain on the list. By adding your AD or Windows Server 2003 groups to the server, it will automatically be added to the [SERVER]\Team Foundation Server Valid Users group. There may be some roles (such as the Project Managers) that you may want to add to the [SERVER]\Team Foundation Administrators. To make groups part of Team Foundation Server's administrator group, access the Group Membership settings (by clicking on Team > Team Foundation Server Settings > Group Membership). Double-click on [SERVER]\Team Foundation Administrators, and add your groups as shown below:
We can now drill down even further to the project level. To access a Team Project security settings (assuming you have already created a Team Project), right-click on your Team Project within Team Explorer and select Team Project Settings > Security. Add your Team Project sub-groups that you created in AD or Windows Server 2003 (in Workgroup mode). Each project also has Group Membership settings that allow you to add groups to Contributors, Readers, Project Administrators and Build Services. You can then define what users or groups are allowed to access features (such as version control). I'll cover this in detail in another posting.
So what is the point in going through this entire process? Now you can administer all your users directly from AD or your Windows Server 2003 Computer Management console (compmgmt.msc). Let's consider a scenario where a tester is leaving a company. If you remove the tester from a group such as TFS-Testers, they will no longer have access to Team Foundation Server (because they won't be a valid user on the server). If a Tester suddenly gets promoted to Test Lead, they can be added to the Test Lead group and receive certain administer level privileges. If one of your testers needs to be moved from one Team Project from another, it's simply a matter of removing them from one group and adding them to another. Setting up your permissions this way will allow any changes you make on the Workgroup/AD level to trickle down to the TFS feature level. This doesn't preclude you from being able to manage individual users and to make granular changes on Team Foundation Server, the goal is just to simply administering your team security as a whole.
This isn't a one size fits all solution. Some of you may say: "Hey, I'm a small software company, everyone works collaboratively on all projects and I can't set up the server as you describe. Everyone has to be able to create projects, and so forth". This particular scenario certainly makes administration a lot easier, but consider this. Even the most well intentioned and experienced user can make mistakes. By applying the principle of the Least-Privileged User Account (LUA) (which is a core security concept behind Windows Vista), you can mitigate accidents and malicious users alike. It's important to look at security from a business case perspective - how much will it cost you if you have to experience downtime? To learn more about LUA, click on the link beloq to view an informative TechNet article:
https://www.microsoft.com/technet/security/secnews/articles/lpuseacc.mspx
In my next posting, I'll discuss how to secure individual features within Team Foundation Server, and we'll look at security on the SharePoint Team Portal and Reporting Server.
-------------------------------------------------------------------------------
Jean-Luc David is a Toronto-based software developer, lecturer, author and Senior Consultant for ObjectSharp Consulting (https://www.objectsharp.com/jldavid/). He is also President and Founder of the Toronto Windows Server User Group (https://www.twsug.com). He started several years ago as an IT Pro working as tech support and server admin for several companies in the GTA. He recently received the Microsoft Team System MVP award last October for his work within the technical community, and he is currently working on several books on Team System. Jean-Luc can be reached at jl@twsug.com. His blog is accessible at: https://weblogs.asp.net/jld/.