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!


SharePoint and SmartCards (CAC Cards)

Have you worked with SharePoint and SmartCards?

I have, as in most military / federal environments you will find that users generally access your SharePoint instance through the use of a CAC (Common Access Card) card. It is the same as any other SmartCard just a little more jazzed up in general with some other information appended on it, nothing tremendously real fancy. Here is an example of a CAC card taken from the army .mil website:

The methodology and purpose between a CAC card and a SmartCard are pretty much the same. They are used so that a user can authenticate to all sort of client certificate aware objects. Within federal spheres though, CAC cards are generally mandatory.

But with SharePoint, SmartCards kind of are annoying. There are some caveats to setting up your environment within SharePoint in regards to maintaining CAC compliance, some which can be handled using inherent IIS settings, others, well, require custom development.

For a lot of people, the implementation of Smartcard security architecture into their SharePoint environment can be a relatively painless one. If you know that all of your users have Active Directory accounts, then you are ready to go, as doing some configuration in IIS will get you most of the way there. The way that this can be done is through a concept called client certificate mapping. Client certificate mapping will basically query for the client certificate off of the Smartcard, and map that to a pre-existing Windows account. In essence, this is not much different than the configuration that you end up with when using Integrated Windows Authentication since you will will still have valid Windows identity to put comparison operators against. If this is your case, the problems that you will run into are inherently bound to IIS. You biggest change is in the IIS metabase, since you will have to manipulate the metabase property that orchestrates SSL client connection negotiations. Meaning, you will tell SharePoint to always negotiate the certificate, which will help resolve client certificate re-negotiation deadlocks. This is done by setting the SSLAlwaysNegoClientCert Metabase Property to true.

While this works, it is not my ideal situation for large environments. I have many users that although have CAC / SmartCard cards that will not exist in the Active Directory tree that I can program against. This presents a large problem for me because my mapping will fail as the comparison operator will consistently pull a false value upon the matching return. I also can’t really imagine the implementing any type of management that would be beneficial in this type of scenario, because I would have to know the users password, which for a typically military unit, can be mammoth. Along those same lines, I would have to actually setup my 1-to-1 mapping scenario. I don’t want to undertake this task in any way share or form. If I went that route, I would be stuck with a management scenario, that would for the sake of a better word, become unmanageable.
Fortunately, through the use of ASP.NET it is possible to inject things in the ASP.NET request stream. This is a good thing. With several authentication methods that are offered in the realm of SharePoint, they are implemented as HTTP modules. For example, if you are using FBA with your SharePoint instance it is going to be using HTTP modules as well.

How an HTTP module works is pretty simple. Firstly, a SharePoint web request will be submitted to IIS. That web request will be mapped to ASP.NET, which will parse the page through the ASP.NET 2.0 engine which in essence is a web request hand-off. This is where the HTTP module comes into effect. Once the web request is handed off to ASP.NET there will be a query into the HTTP modules that exist in the configuration files on the server to determine if any should intercept and possibly manipulate the request. Although only certain modules may take effect, all the HTTP modules that are available are loaded.

If you want to see this in action, you can display the HTTP modules that are currently being instantiated from your SharePoint site through some small code using the Context.ApplicationInstance.Modules collection within a WebPart OnLoad event.

In the next post in this series, I will talk about how we can solve this issue through the construction of a custom HTTP module, and how we can manage our client certificates through database storage as opposed to relying on Windows Accounts. Following, we will see how we can exploit this concept further to implement a custom role provider that will plug into the HTTP module in order to provide a mechanism to redirect users whom don’t subscribe to a role to a default anonymous site, as well as implement strongly named  roles for the SharePoint environment.