Using SSL On The TFS Application Tier

It is common within acutely sensitive development environments to incorporate SSL between the different tiers of TFS. Generally, the approach to do this is to modify the configuration to leverage the AT (Application Tier), and then we modify the configuration for the build server to use SSL as well. When this is done, you will notice that 9 times out of 10 that you can browse to the SSL site via FQDN to the builder server agent service. The certificate will even look like the application took correctly. However, you will get the error:

The request failed with an HTTP status 403: Forbidden

To get around this, do three steps:
1) Open the build service configuration file located at Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\tfsbuildservice.exe.config, change the value of AllowedTeamServer to the URL of your TFS. Changing http for https in the value should work.
2) Search the registry for AllowedTeamServer and change the value of all occurrences you find.
3) Restart the build service.

Then you should be good to go!


The Basics of Claims – Part 6 – Setting up Claims Based Identity

There are some things you will need to do in order to get claims based systems in place. When you follow these steps you will be able to understand more about the overall foundation that is in place.

Adding logic to the applications in order to support the claims is necessary. You will need this to be able to validate the incoming security token and the claims that are inside of it. Through the WIF (Windows Identity Foundation) you will get a common program where they can be verified. You need to make sure that the WIF and the ASP.NET applications are referenced separately.

Next you need to decide if you will built an issuer or use one that is already in place. It is easier to use the ADFS v2 in order to have an issuer for your tokens. Most of the time it is going to be too complicated to create one unless you have an employee with such experience. There are many types of 3rd party software out there that you can use to build your own though if you really want to. These are skills much higher than the basics we are going to cover in this material though.

As you develop applications you will be able to use a stub issuer. This is going to return the claims you need. WIF also supplies a local issuer that is available for prototypes and for the development of the Visual Studio.

Now you are ready to configure the application to the trust of the issuer you selected. Any application out there will trust the issuers of it to correctly identify and authenticate the users before claims can be attached based on the identities in place. It is important to realize this is a one way street the application trusts the issuer but the issuer doesn’t trust the application.

There is plenty of room for variables and creativity when you are talking about claims. Some of them though are more common due to the needs out there. For example they will ask for a person’s name, email address, and even groups they belong to. An issuer can be out there for different claims so the application will need to know what claims are offered.

There are plenty of questions that have to be answered, and you will want to discuss them with an issuer before committing. For example there is the XML document that the issuer has to provide with an application. This has a copy of the issuer certificates so that the right public key can be used to verify tokens as they come in. There is also a listing of the claims that an issuer offers, the URL where tokens are asked for, and many technical details that help with the actual formatting of the token.

There is a wizard program in the WIF that allows the identity of the application to be configured based on all of this data. Once you provide the URL to the wizard for the issuer that you will be using it is going to download all of it and configure the application for you. Then you are ready to configure the issuer so that it knows all about the application.

In order for that to happen you are going to need to provide some basic information. They will want to know what the URI is that identifies the application. They will need to know if all of your applications require claims or not. Do you want the tokens to be encrypted? If the answer is yes, they need to know what key to use. Providing information about the URL for the application so that it can receive tokens is also necessary.

Every application is different so there is a reason why they don’t all need the same claims. There can be an application where the role requires the first and last name of the user. Then there can be another claim where the email address is required. Make sure that any application doesn’t end up getting more information about a user than it really needs. You  need to make sure you are well within the realm of all privacy laws out there.

You will likely be interested in build a claims based application that has a level of security in place. This is why you will need the SSL for the issuer as well as for the application. This is going to serve to protect the information in the token from anyone that may be snooping around. There are applications that require higher levels of security so they can be encrypted to provide it. There will be a certificate and a key needed to that the token can be issued for such an application.

It is the use of the Metadata that allows the information to be shared so easily. There is a tool in the WIF called FedUtil.exe that will generate this for you within an application. There is no need to have to configure any of the setting manually.


CAC Enabled Anonymous Sharepoint Sites

By: Noni Hernandez
Enterprise Architect

If you worked/have worked or plan on working within the DoD environment, security will be a subject that haunts your dreams. Not that security isn’t prevalent in the private sector, but given the nature of our work security is a top priority if not the number one priority. That being said, I have been working with the DoD’s PKI for the past few years so I am fully aware of the scope and implications of providing a secure computing environment. Recently I was tasked with bringing all of our publicly available servers to a secure standard. This involved deploying a load balanced ISA 2006 array and protecting all of our services available through the NIPRNET or commercial internet. One of my projects was securing our SharePoint farm by only allowing access through our ISA array. Normally this would be a task completed in one’s sleep, depending on the authentication model being utilized. However, being a DoD element brings on specific requirements that must be met to ensure the protection of our data. Enter the CAC, or Common Access Card, and the utilization of the DoD PKI to enforce a more secure environment.

Inherently, ISA 2006 has great support for the client certificate authentication model, but there are some constraints. The main one being ISA will only allow such a connection by querying your domain to authenticate an active member of your domain. This is perfectly fine, except for the notion of having a publicly available page with limited information, on an anonymous access model. This is where things begin to get tricky. As I stated earlier, one requirement handed down by the DoD is to secure all publicly available servers via CAC authentication. This means granting access to your public site to anyone with a valid CAC. If you are publishing your anonymous site and giving direct access to your farm, then deploying this scenario is rather simple, but you are leaving your server vulnerable to possible unauthorized access simply by giving direct access. So naturally we will need to publish this site through our ISA array to provide that layer of security. This is where I first ran into problems. If you are configuring an access rule in ISA then enabling client certificate authentication requires the user be an active member in your domain with their CAC registered to that account. If you choose to leave the certificate request on the web server and set the authentication request on the listener to ‘No Authentication’ and the authentication delegation to ‘No delegation, but client may authenticate directly’, you will most likely receive a 408/Request timed out error when attempting to access the page. I was stuck on this error message for weeks after attempting numerous combinations to make this work.

After many sleepless nights(and even worse, nightmares!) trying to create a solution to this problem, I finally came across the solution only after being requested to secure another server behind our array. So here is the method I developed to allow a user access to our anonymous SharePoint site, with the only stipulation being they have a valid CAC.

Step 1.

On your ISA array, instead of creating a SharePoing Site Publishing Rule or a Web Site Publishing Rule, select ‘Non-Web Server Protocol Publishing Rule’. Give it a meaningful name so your admins will be able to easily identify what the rule is performing, I chose ‘HQ Anonymous SharePoint Site[CAC Enabled]’. After you click next enter the IP either the individual server or the load balanced IP utilized to reach the site. After clicking next, you’ll need to click new to create a modified version of the HTTPS/SSL protocol, I named it ‘HTTPS[HQ Anon]’ to again reflect its utilization. After clicking next you’ll need to first create an Inbound TCP protocol using the Port Range 443 to 443. This is basically stripping down the methods used by ISA, i.e. compression, masking, to allow an SSL connection but still generating a proxy connection to our internal site to protect the data. After clicking OK, you’ll need to do the same thing and create and Outbound connection with the same parameters, this will allow the client certificate request to be passed back to the end user for a successful handshake. After clicking OK and then Finish you should see your new protocol in the ‘Selected Protocol’ dropdown list. Click Next and select the network that will be listening for these requests, most likely ‘External’ and then click the Address button. Since I am using a load balanced array I already have a VIP ready to be utilized for this published site, so I choose ‘Specified IP address..’ and then select the IP I will be using to publish this site and then click Add so this rule is only answering requests sent to this specific IP. After you select the IP and click OK, click Finish to complete the creation of the rule.

Step 2.

After you have created the rule, double click the new rule to view the properties. Click on the ‘To’ tab and change the ‘Request for the published server’ setting to ‘Requests appear to come from the ISA Server computer’. Once you have verified all the settings are correct from steps 1 and 2 then click ‘Apply’ and ‘OK’. This should conclude the ISA configuration portion!

Step 3.

On your SharePoint farm, you’ll need to open the IIS settings and then navigate to your anonymous site and view the properties. When you have the properties open, navigate to the Directory Security page and then click Edit on the Secure Communications section. Here you’ll need to select ‘Require secure channel’, ‘Require client certificates’, and then ‘Enable certificate trust list’. Click New to create a new Trust list, click Next and then click ‘Add from File’. You’ll need to select the DoD Root CA 2 and I have also set DoD CLASS 3 Root CA from where you have these certificates stored. Click next and then give it a name, i.e. DOD CTL, click next and then Finish. After clicking OK all the way through to the Directory Security page of the anonymous site properties, you are done!

So as you see, it’s really not a complicated process. But in the grand scheme of things, we all know that we tend to over think and over complicate things to engineer solutions. I am more than guilty of this, I lost weeks of sleep to prove it! This configuration guide is set on a pretense that you do have some preliminary items configured, and that you reached the dead end at the same point I did. If did not being to lose your hair because of this, and have just begun your descent into madness, then you need to know that there are some steps that should be completed before reaching this stage.


Thank you Noni for agreeing to write this post! I think everyone will agree this is a valuable contribution to the DoD – SharePoint community!