Insight

Insight from Agora Consultants

External User in Team Foundation Server (TFS) with Active Directory

In our organization we develop software for clients.  As part of that process we need to gather feedback from our clients when they encounter a bug.  We use Team Foundation Server 2010 internally for all aspects of our software development practice including bug collection.  We wanted to collect our client's bug reports in TFS as well. Team Foundation Server requires that all users be members of Active Directory.  Naturally, our external clients are not members of our Active Directory.  Some companies handle this by creating a single Active Directory account and requiring their external testers to all login with that account.  This is not ideal since nobody really knows who created the bug.  Other companies handle this by creating Active Directory accounts for all external testers.  For us this was not practical since over time we would have 100s of external testers that would clutter our Active Directory.  Additionally, this poses a security risk since you have created domain accounts for external users. The solution is to use a second domain for your external users.  This can either be a Windows Server running as a domain controller or you could install Active Directory in Application Mode (ADAM) on a server (or even a workstation).  The following steps will guide you through the process of creating the secondary domain and integrating it with Team Foundation Server. Step 1 - Create the domain The full details for setting up a Windows Server and Active Directory are beyond the scope of this blog, but in summary you need to do the following: Install Windows Server 2003 or Windows Server 2008 on a standalone server (i.e. the server is not part of your corporate domain) Add the Active Directory role to your server Add DNS role to your server Your new domain should be something different than corporate domain (e.g. mydomain-ext.local) At this point you should have a working domain controller that you can create external users on. Step 2 – Configure DNS First you should configure the DNS on external domain controller to forward requests to your corporate DNS.  This will allow the secondary domain to resolve DNS queries to your corporate domain and the internet.  Open the DNS console in MMC, then right click on your server and select Properties.  Next, select the Forwarders tab and enter the IP addresses of your corporate DNS servers. Now on the corporate DNS you need to tell it how to get to the domain controller for your secondary domain.  Open the DNS console in MMC on your corporate domain and right click on the server and select Properties.  On the Forwarders tab click New and enter the name of your secondary domain and add the IP of the secondary domain DNS server. Step 3 - Establish trust between your corporate domain and the secondary domain Next you need to tell your corporate domain to trust your secondary domain.  This will allow users to authenticate in the secondary domain and use resources (if permitted) in the corporate domain.  The trust relationship can be one-way or two-way.  One-way is all you need, but in screen shot below you will notice that the relationship I create was two way.  I did this so I could be an administrator on the secondary domain controller with my corporate domain account.  The level of trust you create is up to you. Open the Active Directory Domains and Trusts console in MMC.  Right click on your corporate domain and select Properties.  Click the Add Trust button and follow the wizard to create the trust. At this point you should have a trust relationship established between the two domains.  If you want to test this you can try to set the permission on a domain resource such as a file share and when you click the Locations button you should now see both domains. Step 4 - Create external users and groups in the new domain Now you are ready to add your external users to the secondary domain.  I would recommend creating new Organizational Units (OUs) either under the Users OU or under a new OU.  In the example below I created a root OU named External Users and then a new OU under that for each client.  Create your users in the appropriate OU.  Create a group in each OU and add all the users in that OU to the group.  For example under Client ABC you will have User 1 and User 2 and a group named Client ABC Testers with members User 1 and User 2. Next add a group named TFS WIOV Users and add all your external user groups to this group. Step 5 - Add the TFS WIOV Users group to the Work Item Only View Users group in Team Foundation Server Unless you buy licenses for your external users they are only permitted to use Work Item Only View (WIOV) on TFS.  You need to add the external users to a special WIOV group on TFS so they will see the WIOV site.  On the TFS server launch the TFS Administration Console.  Click the Application Tier, then Group Membership.  Select the Work Item Only View Users group and click Properties.  Next click Windows User or Group in the Add Member section and click the Add button.  Add the TFS WIOV group that you created in your secondary domain. By doing this you now only need to add additional external testers to the TFS WIOV group in your secondary domain and they will automatically be part of the TFS WIOV Users group. Step 6 - Add the external users or groups to Team Foundation Server We’re almost there!  Now you need to explicitly add the users or groups to TFS projects.  This is the same as adding internal users.  In Visual Studio select the project in the Team Explorer, right click and select Team Project Settings then Group Membership. You can now add your external tester group (e.g. Client ABC Testers) directly to one of the pre-existing groups or create a new group.  I prefer to create a new group to allow greater control over their permissions. Click New and create a group named External Testers.  Once the group is created click Properties, select Windows User or Group in the Add Member section and click the Add button and add your external tester users or groups (e.g. either User 1 and User 2 explicitly or just Client ABC Tester group).  I prefer to add the group that way you only have to add users to the group in Active Directory and you don’t have to come into Visual Studio to add the users individually. Step 7 - Setup security for external users to meet your needs You have now added the external users to the project, but they don’t have permission to do anything.  The last step is to configure permissions for the External Testers group.  In Visual Studio select the project in the Team Explorer, right click and select Team Project Settings then Security.  Select Team Foundation Server Group in the Add section and click the Add button.  Select the External Testers group for your project.  Once the group has been added check Allow for View project-level information and click Close. In Visual Studio select the project in the Team Explorer, right click and select Team Project Settings then Areas and Iterations.  On the Areas tab click Security.  Once again add the External Testers group as above.  Once the group has been added check Allow for “Edit work items in this node”, “View this node”, and “View work items in this node”.  Click close. You’re done! Conclusion At this point external users should be able to use the Team Foundation Server Work Item Only View (WIOV) website by going to http://<TFSserver>:8080/tfs/web/.  They will see the WIOV version of the TFS website which allows them to create new work items and view the work items that they created.  A summary of what is happening is shown below. An additional benefit to this approach is that your external testers can use the same domain account to test web applications that require domain login. About the Author Kevin Walker is a partner at Agora Consulting Partners.  Kevin is responsible for the Application Lifecycle Management practice which focuses on application development and process improvement using Team Foundation Server.  Contact Kevin at kwalker@agorainc.com.

Exceptions Happen - Deal With It!

In my last post (Mosquito Coils and Software Design) I discussed how defensive design can be used to ensure a product can still be used even after a failure of one part of the system.  Defensive design can be divided into many different areas.  Clearly one of the areas to concentrate on is security measures.  Attacks such as code injection and cross-site scripting are common security vulnerabilities that can be mitigated using good design.  Defensive design should also include the eventuality of failure.  It is important to have high quality processes for developing good code, but you must also consider what happens when thing go wrong. Exceptions will happen – deal with them! All applications will encounter exceptions at some point in their life.  Exception management should be a fundamental part of your application design.  Your design should, at minimum, consist of a code and process to handle: Exception Throwing – Exception are “thrown” when a chunk of code cannot do what it was designed to do.  See the MSDN article (http://msdn.microsoft.com/en-us/library/ms229030.aspx) for some excellent best practices on throwing exceptions. Exception Handling – Once your application throws an exception you need to handle it.  There are really only three things you can decide to do: (a) Burying the exception.  This is the least desirable (even unacceptable) since the user or the developer will never know about the exception except the user may complain the application is not working correctly; (b) Notify the user about the exception.  This is typically done with a dialog box and some additional information to let them know that things did not go as planned; (c) Notify the user and log the exception.  This is the best option since the user knows that something happened and the QA and development team can analyze the exception.  See http://msdn.microsoft.com/en-us/library/ms229005.aspx for best practices on handling exceptions. Issue Management – Once the exception has been logged the team needs to determine what do about it.  Is it an operations issue or a code issue?  Does it need to be fixed?  If so, when should it be fixed and by whom?  Tracking an exception through its eventual final disposition is a critical part of Application Lifecycle Management. Agora Exception Tracker One of the most exciting components of the Agora Development Framework is Exception Tracker.  The Exception Tracker was written as an extension to the Microsoft Exception Management Block.  Now a standard component in every application we write, the Agora Exception Tracker has the capability of publishing exceptions from an application to a web service, the Windows Event Log, a text file, or as email.   Other Considerations Other key things to consider in your design to enable you to have a more robust application include: Performance counters - Make use of the perfomance counter capabilities within Windows the track the health of your application. Configuration files or Database settings - Place as much of the configuration options into configuration files or into the database.  Allowing the administrator to tweak and configure your applications at runtime can eliminate a whole class of issues. Abstract language and regional settings from the application - Keeping all languate and regional settings out of your application and in resource files or the database will pay huge dividends.  Not only does this allow you to reach a broder audience quickly, you will also get the advantage of being able to make changes to the application at runtime.  (See Garry English's article on editing resource files - http://www.agorainc.com/insight/vol1iss1ResourceFiles.htm)