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!

Share

Found Block That Points Outside Data File At

Well, this is stupid. I decided to just fix my comments database, and then do some repairs on the tables, and for some reason Spam Karma ALSO had corrupted tables which resulted in the error of “Found block that points outside data file at (insert annoying table statement here)”. Ultimately, what should be done is all the tables in the exisiting database should be checked for errors, which can be done after getting an array of the tables, then just do a repair statement on them:

[php]

$repres = mysql_query(“REPAIR TABLE $tablename”);
$result = mysql_fetch_array($repres);

[/php]

so we just query and run the REPAIR command on all of the tables, and then it should repair them (the repair command is only supported by table type MyISAM btw). From my study of the error and the web server logs, it looked like all this happened because of the DoS attacks that have been happening, because the overload due to cache issue in requests was cut off by my hosting provider at first by rebooting the server. *sigh*

If I ever catch you DoS people, I am going to run you over with my car. Then back up and run over you again. The pull forward again to finish the job. Assholes.

Share

Web Service Security And SharePoint

Web Services, SharePoint, and Building Business Data Interoperability

Web services are becoming increasingly more commonplace within every business environment in numerous industries, and are particularly common within a SharePoint environment for a variety of different purposes. With the introduction of any new technology, as web services are to several enterprises, always brings into light new security issues that must be dealt with. Although Web services provide excellent transfer interoperability with various types of business data to expose and serve in relation to our SharePoint portal, there is also the need to harden and secure these Web services in order to mitigate any risk to SharePoint as well other business applications.

Back to the Basics: What Constructs a Web Service

In order to understand how we can secure web services, we must firstly examine exactly what constructs a web service, how it interacts, and how it functions.

Web services are composed of two main pieces of functionality, two main actors in the aggregate process. There is the web service provider, which is going to provide the stream of data, and the other end of this relationship is the Web service consumer, which is the client which is consuming the provided data. Building on these two actors, there are four main pieces of technology that allow list type of beneficial relationship to exist. The first of these is the Universal Business Registry (UBR).

The Universal Business Registry is the piece of technology that will allow a user to query for specific Web services based on explicitly supplied criteria. It is the third party mediator between the consumer and the supplier, allowing a consumer a uniform location to look for Web services of varying natures provided by several different businesses. The UBR is typically the first player in the Web service process; a user will query the UBR and attempt to find a Web service defined by their unambiguous requirements. Once a user supplies the conditions to the UBR, the UBR will return a list of services that the user can consume, and the user will select the most appropriate Web service to their need. Throughout the UBR query process, the protocol that is being used is UDDI (Universal Description, Discovery, and Integration). This is the same protocol that is going to be used when attempting to start the foot printing process to begin to gather information about different Web services.

After Selecting the Service

Now that user has selected the service that they wish to consume it will ask the UBR to supply an endpoint for their selected Web service for proper consumption. Once the user has the endpoint it can effectively start consuming and leveraging the Web service it has selected coupling with a reader or other API of choice. This endpoint is built upon a technology called WSDL (Web Services Definition Language) which will describe how these services are structured deployed, accessible, and proper usability. Throughout this entire process the HTTP protocol that is being used is known as SOAP (Simple Object Access Protocol) which piggybacks on top of each CTP packets to provide the underlying communication that we need.

Similar to any other type of attack on a SharePoint portal, the first action a malicious user will take is to gather as much information and research as possible in order to gain a knowledgeable standpoint about their target.

Just like with any other Web asset, there are methods and actions that will allow the user to fingerprint and gain more insight into a Web service in order to properly structure an attack.

Why Application Layer Firewalls Just Aren’t Enough

The only way to ensure a SharePoint portal is properly secured is by ensuring that any information that we expose in the portal is also secured. SharePoint is a web application, and therefore will typically always function over the standard HTTP ports, 80 and 443. Web services also function at this level which provides a majority of there benefits over other methods of data transmission. But with this comes evident security issues. Because most security appliances and applications try to examine packets that transfer over other ports often times web servers traffic is difficult to decipher as benign or malignant because it functions exactness aim as a SharePoint a HTTP traffic.

The most typical way to protect a SharePoint environment is by implementing some type o application layer firewall. This application layer firewall typically does packet inspection on the varying types of traffic that are passed through it, however for the reasons described above and Web services acting as a HTTP traffic is difficult for a firewall to distinguish between malicious traffic.

Three Main Pieces

There are three main pieces an attacker will take when trying to maliciously expose a Web service for whatever purpose.

  1. Web Service Footprint Done against the UDDI ( Universal Description, Discovery, and Integration)
  2. Web Service Discovery Queried against the UBR (Universal Business Registry) in order to expose endpoints for service consumption
  3. Web Service Fingerprinting Done Against the Web Service discovery URL in order to expose the technology that builds the web service

The first portion of any attack is information gather reading. In regards to Web service is relatively easy for a user with little or no knowledge about a business to find Web services will by that organization. Although list type of data is typically in a protected repository because the purpose of Web services is to promote interoperability through an open standard it becomes increasingly easy for knowledgeable user to gain valuable insight into what organize a and start to gather relevant information.

The Four Structures of the UBR

When discussing how Web service at a very basic level works, one of the key components between a provider and consumer was the universal business Registry. As discussed the UBR axes the mediator allowing businesses a place to expose Web services and a client a place to search and determine methods to consume those exact same Web services. Just as a person can do a whois check against the public Registry in order to gain more insight into such things as IP addresses, a user can query that UBR in order to gain the same type of insightful information. But there are several different queries that a user can in bulk on the UBR in order to gather some information. The four structures that are available are the business entity, business service, binding template, and the technical model also known as the tModel. How users will interact with the UBR is typically provided through an application programming interface supplied by the same company that provides the Web service. Since the protocols that are being used for this type of transmission are HTTP and SOAP, these application programming interfaces will have direct hooks into the same types of protocols. The API will incorporate into the W. STL in order for the user to extract the endpoint information so that they improperly consume the Web service. Since while we are foot crane we are attempting to gain more insight into a specific Web service is necessary to leverage these application program interfaces.

When beginning to footprint process just like a normal user we are going to query the universal business Registry in order to expose a list of all available Web services. The first that in actual footprint process is Web service discovery in order to expose the endpoints. The endpoint will contain the most relevant information about the Web service including the IP host address as well as other information about the location of specific resources. Without having this endpoint information the process of information gathering is infinitely more difficult and will not allow a user to enumerate through the different Web service information.

Share