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!


Biometric Encryption

Well, so we have been talking about biometrics for a while, and eventually the concept of biometric encryption (fuzzy commitment schemes, secure sketching, biometric key binding, bioHashing, biometric signatures, etc. [it goes by many names]) was going to come up. To be honest the subject is actually relatively fascinating. I have just started researching it, so I figured I would share my findings about it. Maybe I will make up my own term like Super Adam Bio Hashing. That sounds sexy (said for the MVP group, who knows all about my desire to make every SharePoint feature as sexy as possible). Anyways, this is just going to be a general overview to introduce the concept, and give readers a better idea about the aggregate field.
Like some other things that come up on this blog, it really isn’t going to have a large relevance to SharePoint discussions, but either way it is interesting. I will look into maybe expanding this into the CryptoCollaboration concept sometime (which I am going to update in the next post with the programmatic sequence diagrams and a general architectural overview), but it is currently beyond my skill set honestly until I actually find some good research that describes the mathematics behind BE. I haven’t been able to pinpoint this type of material yet.

As stated, we already have a pretty good idea about the overall concept of biometrics, that it is measuring quantifiable objects about a principal, being either physical or behavioral parameters.  We know that biometrics generally runs on fundamental comparison operations, where the template (biometric blueprint) sample is taken from the principal and then this blueprint is employed for the actual identification and verification of the principal. This template is often referred to as the biometric template (which is why you see the fingerprintTemplateParams Property in the BioPoint API documentation) or a biometric principal blueprint. People often refer to the person that the sample (for template generation) is taken from as the enrollee of the template (since a lot of people consider a biometric system to be a publish / subscribe architecture), but I prefer to refer to the template person as the principal, so let’s refer to the user as the principal for the remainder of this post.

So, let’s talk a little bit about encryption, and we will then get into Biometric Encryption. We know a few things about encryption. We know that one of the more common cryptographic schemes that we see in general business applications consist of using a public and private key.

The concept of biometric encryption was originally coined by Dr. George Tomko, who really started to put the concept to work when leveraging fingerprinting biometrics. Although there a have been several grants in the past couple years that have allowed this area of research to expand, and some brief searching provides several smaller research firms that are integrating biometric encryption into their research schemes, it is IMHO still somewhat untapped. I think that it will be an explosive field once the true business value of it is taped though.

However, I digress….

So what the hell could we use biometrics for in the terms of encryption? We know the encryption is dependent on various types of strings, so how could we use biometrics as a string representation parameter and subject? That is an excellent question. The answer to the overall question to this is just a simple plain no, at first glance it is not feasible to use biometrics in the straightforward method that orthodox encryption routines function. A biometric sample is not representative of a string, it is an object, and therefore won’t work well within a typical encryption schemes.

Where BE becomes possible is when you slightly extend this concept into a more abstract sense. Although a template is going to be composed of a large bit representation, and it would be possible to extract a string from this representation, that is, IMHO, a poor approach. Furthermore, acquiring consistently exact biometric samples is never really possible because managing the distortion rates between the samples would become improbable, regardless of noisy compensators are factored into the software.  Cryptography is a rather exact science, and with that in mind, noise disturbances within the empirical data would not be acceptable and the related algorithms required for descrambling would fail.

It is also possible to use traditional cryptography against the stored biometrics blueprints in whatever medium that they are subject to depending on organization data storage standards. This would be a fairly customary situation, and not much different than traditional forms of cryptographic situations. The problem with this is there is still a point where someone, be it a server / database administrator, that would have access to the source template. Because the templates would have a period in which they are exposed to some user, there is a possibility for a breach. This is large concern with biometric data because the user would have access to some of the most sensitive information available regarding a user that could be used in order to possibly fabricate future biometric templates.

So, we have explored two options that are not very desirable, now let’s actually get to the point where BE shows us an actual favorable circumstance. If you want to view some more of the circumstances that arise from the use of biometrics and cryptography, A Study on PKI and Biometrics by FIDIS is pretty interesting and a lot more in-depth.

Rather, it is possible to instead unite an encryption key with a biometric template. This would, in essence, result in both the key, as well as the biometric template, becoming inaccessible and sheltered.

A cryptographic key is generated from a set of user input, usually something like a passphrase that can be remembered. For example, I could use the string sharepointsecurity in order to generate a cryptographic key, and because it is the name of my site, it is easy for me to remember. That cryptographic key can then be used in order to generate the encrypted string back into plain text. As opposed to taking this approach, we can graft the unique biometric parameters regarding a principal empirically, identically how it is done for normal template verification. Once the empirical data is harvested from the principal, it is united within the cryptographic key. In order to regenerate the cryptographic key, the correct sample must be provided to the system. As opposed to providing a passphrase which generates the cryptographic key, the key is generated when the principal first generates the template. It does not use the biometric template as a parameter for the key generation, and therefore the two units although united are not tangibly related. Because of this segregation between the biometric template and the key, they key can therefore be built, rebuilt, and destroyed regardless of the biometric sample.

This is neat, and results in the key protected by the biometric template. Sometimes people refer to this template as a private template or protected template. While the key is united with the biometric template, in its segregated state, as opposed to the key being used in order to encrypt a string representation, the biometric is used to encrypt the key. Quite an adjustment, and somewhat confusing at first, however really quite clever. This type of functionality has to be written by the user, as the algorithm doesn’t adhere to normal cryptographic criteria, so can branch in a variety of fashions.

Now, the concept of the two layers of keys is still consistent, there is a scrambling and descrambling process otherwise the cryptographic process being presented wouldn’t be an exceptionally impressive because it would only half way work.

When the actual process occurs, the principal will approach a biometric device in order to provide a sample. This template will be used in order to breach the biometric encrypted template, and the custom written algorithm will be used in order to present the sample. This algorithm will be architected so the presentation will captured and will be used in order to decrypt the key. This is pretty neat, because as opposed to any keys being used in order to the complete the cyclic encryption routines, the biometric template is used for the decryption, it’s kind of backswords however interesting.

There are some problems that have to be cleverly approach in regards to the biometric sample. When using biometric encryption, you are going to be querying against principal samples that tend to contain various amount of distortions. This type of variation has to be compensated for with custom code, and can be a pain in the ass without some sort of SDK provided with the biometric device in order to code compensate for the variations. In other posts I have talked about fuzzy logic, and the same thing is true with this, because there is a rather grey area that must be compensated for with the template comparison algorithm.

Once the key is extracted using this process, the actual application process can concurrently occur, which can be used for cryptographic key generation.

In any respect, this is just an overview of what BE is, and I am tired of writing about it. There a lot of other sources that will discuss it more in-depth if you really want to learn more about it.