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

SharePoint Security Software And Research view

What is the audience of the MOSS and WSS v3 SharePoint Security Software?

  • An executive who desires a quick overview of the findings and recommendations of security assessment and audits, as well as proper implementation of SharePoint security
  • A manager tasked with interpreting the findings of the collobration platforms assessment and deciding what action to take based on the recommendations, along with pre-emptive security consideration for a Microsoft Office SharePoint Server and Windows SharePoint Services
  • A technical staff member tasked with understanding the issues presented in a security assessment and implementing specific security recommendations based on presented best practices. This technician (typically the SharePoint administrator), will often time take the SharePoint Security Best Practices and mold them to their specific industry and organizational structure.

What is the purpose of SharePoint Security research, and How Does the Best Practices Guide and SharePoint Security Toolkit help in securing a SharePoint environment?
The purpose of MOSS and WSS v3 security research and software development (such as various pieces of SharePoint Security Software) is to identify any root cause of inappropriate behavior observed in the collobration software and identify whether it represents a possible security vulnerability to the SharePoint platform. Various pieces of SharePoint security software provides mechanisms to deal with arbitrary security concerns and architectural considerations, providing SharePoint administrators and developers the faculities to discover, research, and rememdy various security and custodial issues. If a software vulnerability is confirmed, the following action is to test and document this vulnerability and assist Microsoft in securing the software, thus protecting the customer base from abuse, as well as integrating the concern into the SharePoint Security Best Practices Guide. When a major issue is easily translated into a software requirement (such as issues that don’t generally imply a methology or something that is a complete human-oriented process) the is built into the SharePoint Security Toolkit WinForms Application as a “Security Module”. An example of a security module would be a page validator that consumes a arbitrary SharePoint WebForm, a packet sniffer, or a SharePoint centric log parser. It is atypical for a module in the toolkit to be programmed as a web based module since the access to the toolkit is restricted to the server, since most of the application hooks will rely on being on the machine.
What is the overall purpose of the SharePoint Security Best Practices Guide?
With an ever increasing amount of information in organizations being transmitted and collobrated on within a Microsoft Office Server System environment, it is important that security be considered in every phase of network and application design, as well as in maintenance. Although it is common that much organizational emphasis be placed on such things as physical networking and remote access methods, it is imperative that the core application security infrastructure of SharePoint not be overlooked. The SharePoint Security Best Practices Guide provides the human recommended human oriented tasks (i.e. such as proper configuration of forms based authentication), where as the SharePoint Security Toolkit provides application based mechanisms that allow a person to automate and investigate security based SharePoint issues.

A More Granular Explanation of the SharePoint Security Best Practices Guide

SharePoint quickly becomes the lifeblood of organizations once the user adoption process is realized and absorbed and virtual teams are finally built and solidified. Great care and focus must be taken to properly secure it to ensure that business data is safeguarded and that each aspect of the SharePoint infrastructure is accounted for and maintained.

This security best practices guide takes a look at every aspect that might afflict an organizations security beginning with the first line,the perimeter. Although many think that as long as the perimeter is secure the job is done, perimeter security is only a small piece of overall security.

Security and complexity are often inversely proportional. Every step taken whether it’s vulnerability and risk assessment, security policy and procedure development, deployment of mechanisms or user education should be as straightforward and simple as possible. The more cryptic the instructions and procedures, the more room for misunderstanding and misapplication.

The SharePoint Security Best Practices Guide takes this into consideration by providing easy to use guidelines for every level of SharePoint administrator. SharePoint security best practices provide a recommended method to handle a task, rather than presenting all of the options available. The recommendation might depend on your configuration environment, so the guide and presented tools need to be molded to a particular organization and are presented as independent to industry.

To explain this concept a little further, best practice recommendations can serve as guidelines for organizations, to assist them in providing timely and helpful information while involved with the SharePoint environment. Unlike many best practices, however, these recommendations do not contain all the practices that should be observed, but attempt to build a framework for any organization, in any industry, to build upon and make their own. Information-handling practices and SharePoint technology are changing rapidly, and organizations should continuously review and update their own situation to ensure compliance with the laws and principles of security and collaborative environment protection. It is recognized that specific or unique considerations, including compliance with other laws, may make some of these practices inappropriate for some organizations, and all legal regulations should be observed and taken into the arbitrary scenario. Implementing an effective SharePoint security program is essential for an organization to fulfill its responsibilities towards the individuals who entrust it with their personal and business information.

Why We Are Rethinking SharePoint Security
Perhaps the most compelling reason to rethink the security of SharePoint is to get a collaboration and communications platform with greatly improved security and robustness. Although there are some approaches in dealing with SharePoint security, building an overall security architecture can be extremely important. Typical collaboration security is more resembling of a growing mass of band-aids than a plan.
Our research takes a broad definition of security and robustness. The traditional focus of the security research community has been on protection from unwanted disclosure and corruption of data. We propose to extend this to availability and resilience to attack and failure. Any SharePoint platform should attain the highest possible level of availability, so that it can be used for critical activities, and it can serve in times of crisis.

Some of the actual security problems that plague information workers today are also not in SharePoint environment itself, but in the IW’s computers that attach to the SharePoint server. Therefore it is necessary to address security and deal with issues in the end-nodes as well as the network. Although a serious challenge, an opportunity to reach beyond the traditional network research and engage operating systems and distributed systems design.

The most vexing security problems are not just failures of technology, but result from the interaction between human behavior and technology. For example, demanding better identification of all SharePoint users, it might make tracking attacks and abuse easier, but loss of anonymity and constant surveillance might have a very poor effect on many of the ways that SharePoint is used.

There are specific design challenges in building a secure and robust SharePoint environment:

  • Any set of “well-behaved” hosts should be able to communicate among themselves as they desire, with high reliability and predictability, and malicious or corrupted nodes should not be able to disrupt this communication. Users should expect a level of availability that matches or exceeds the telephone system of today.
  • Security and robustness should be extended across layers. Because security and reliability to an end user depends on the robustness of both the network layer and the distributed applications.
  • There should be a reasoned balance between identity for accountability and deterrence and privacy and freedom from unjustified observation and tracking.

What is the attacker perspective used during security research?
During some of the development of the SharePoint Security Management Studio, various methods of vulnerability research is done starting at the web application level. Any of this exploitive testing of SharePoint software is done blind (black box), i.e. as an unauthenticated, unauthorized user attempting to subvert the platform, and in this case, gaining unauthorized access to the server or working through methods of privilege escalation.

Confirmation of exploitation and further research into the exact methods to exploit the platform is performed as a fully authenticated, administratively authorized user. This access is, however, in no way needed in order to execute various security methods (such as those that would allow unauthorized code to execute on a server, XSS, etc.).

What is the difference between white box and black box security testing?
In the above, there was a mention of black box testing. Within the security community, there are two approaches to penetration and vulnerability testing: “black box” and “white box“. Black box implies that when doing the penetration testing there is no previous knowledge of the environment to be tested other than the name of the company. White box implies significant background knowledge of the environment including the type of network, SharePoint version , application server platform , database platform, load balancers, firewalls, and other MS server systems that are involved.

What is the standard process that is used during SharePoint and WSS Security research?

1) Plan The Security Research and Scope
We mostly use black box approaches, however firstly it is best to determine if it’s a black box or white box approach, realizing that the black box approach is just a matter of minutes away from the white box approach. This helps to validate the security methodologies that we are recommending for perimeter based SharePoint deployments whereby an external user my attempt to gain access. Following, we typically decide what the success criteria are. Plot out whether known exploits will be performed and to what extent. The plan typically includes working with an internal member to monitor the work either via an IDS or manual monitoring so as not to adversely affect operations.

2) Gather Information About The Target, and Weave Information Into Aggregate Plan
The gathering information is often times called reconnaissance against the target. After obtaining IP address information, the next step typically involves scanning the range for listening ports and services, OS fingerprinting, grabbing banner information that might include contact information, running an SNMP sweep looking for public community strings, and gathering any other information that might come in handy when validating recommendations being placed into the SharePoint Security Best Practices Guide, and when building functionality into the SharePoint Security Toolkit.

3) Verify Approaches, Vulnerabilities, and Information
This is typically called analysis and can be accomplished in a number of ways, but all have to do with scanning the target IP range and comparing that information found to a vulnerability database for matches.

4) Perform Security Intrusion and Verify Approaches
The exploit(s) are framed around the vulnerabilities found. This is a pretty straightforward step, however determines whether the security portion should be crafted in to the SharePoint Security Toolkit, or whether it requires documentation into the SharePoint Security Best Practices Guide.

5) Cleanup the SharePoint Server
This is about cleaning up log files and making sure whatever settings or parameters were changed during the test are set back to their original condition. This requires excellent documentation during the test and work with the system and network administrators afterwards to make sure that the situation is satisfactory upon completion and is vital to determining whether the found portion should be integrated into any of the tools found on this site.

6) Report Out, Integrate Findings
The final report must map the findings (vulnerabilities found, exploits performed) to the risk the company might realize if the threats were realized. We also provide a remediation roadmap based on “best practices” and be available to discuss the various technology options and costs. At this point the various findings are integrated into one of the assets on this site, and the information is published.

The 90/10 Rule of Vulnerabilities and SharePoint Security Testing
The old 90 / 10 rule also applies to occurrence of critical vulnerabilities, meaning 90 percent of vulnerability exposure is caused by 10 percent of critical vulnerabilities. This means that ten percent of critical vulnerabilities cause nearly all exposure. This means that targeting initial remediation efforts on critical vulnerabilities with the highest degree of exposure are the most important focus to have when working with SharePoint vulnerabilities.

Share