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

http.sys Kernel Driver and aspnet_filter.dll

Before getting started into creating the most secure MOSS or WSSv3 site that we can, it is prudent to firstly understand how SharePoint processes the relevant requests that it is handling and serving to external clients with an internet facing, as well as an internal site.

When an initial request is made to SharePoint, it is possible that the request actual never makes it to have been parsed by the ASP.NET handler that will push out the relevant SharePoint page. The first layer of permissions processing that SharePoint will handle are those that are given by the Windows kernel, gaining support from that substance of the HTTP driver that will ultimately serve the request through the relevant pipe. This HTTP driver is known as http.sys which is the primary handler for the SharePoint request, and has some mechanisms that deal with information handling and serving that help to protect the overall server environment.

The first of these is minimizing the request throughput in regards to URL length that can exist within a SharePoint URL. Although it is relatively common within a SharePoint URL for the URL name to become lengthy, the overall URL and its associated request assets size may never exceed 16k, the path segments can never be above 255 segments, and the length of a specific segment should not exceed the length of 260 characters, although this is a rather generous size in any respect, particularly if you have taken the time to carefully name your SharePoint sub sites correctly. The actual body of the request is not handled at this point, rather it is handled by ASP.NET. In any respect, hitting this type of restrictions is atypical within a common SharePoint environment, however keeping them in mind will ensure that your uses have the most fluid and consistent user experience and your application architecture doesn’t subjugate itself to undo service downtime. This comes primarily into play when developing custom applications and WebParts that leverage the SharePoint framework that may implement query string values. When developing the specific WebPart, is important to keep in mind that the amount of characters that exist in the WebPart query string do not exceed 260 characters otherwise the kernel mode restrictions will come into play.

There is a good purpose behind this restriction type. Several types of attacks that may happen against a SharePoint environment take on the role of appending various characters against the overall URL structure, by which it would allow arbitrary commands or code to be executed on the server. As well, if a malicious user where attempt to try various types of these attacks against the SharePoint server, it would result in possible service disruption as SharePoint struggles to serve the malformed user request. In order to track these malicious requests as they happen against a SharePoint environment, it is best to maintain active study of the HTTP logs so that pertinent addresses can be blocked if necessary (i.e. booted attempts). This log exists with all the rest of the IIS logs in the system 32 log directory, and will give you all the GET requests that may have been malicious towards your SharePoint environment.

Once the kernel level checks are done on the request from the client, it is time for ASP.NET 2.0 to begin handling the request, since this is the underlying basis that SharePoint is built on. This is handled by aspnet_filter.dll, which is also known as the ASP.NET worker process routine. This is kicked in following the whatever other ISAPI filters are placed on the IIS virtual server outside of the ASP.NET runtime ISAPI extension, which, in the current version of SharePoint as opposed to previous versions is fortunately none. The important concept to grasp however is that the kernel mode HTTP driver is the first level that is subjected to the request.

aspnet_filter.dll is the following section that is implemented after the request has passed through the kernel mode driver. This happens before managed code is executed. The aspnet_filter is responsible for two main actions, protecting those directories that are under ASP.NET supervision, and translating cookie less tickets into HTTP headers. The last of these is very important, since cookies less tickets are imperative for session state functionality. The other is protecting the directories that are managed under ASP.NET, which is related to the cookie less tickets since it happens after the ISAPI filter processes those tickets. The URL that a user request will be processed, and if it stats a certain directory that ASP.NET deems as protected, such as: /bin, /app_code, /app_data, /app_globalresources, /app_localresources, /app_webreferences, or/app_browsers, IIS will take over and return an error to the user.

Share

First Steps in Implementing ISA Server With SharePoint

* This article was written in the context of Internet Security and Acceleration (ISA) 2006, a technology now considered deprecated with the introduction of Forefront Threat Management Gateway (TMG). Variations may exist. *

First Steps in Implementing ISA Server With SharePoint
After the initial installation of ISA server, securely publishing your SharePoint portal is a fairly straightforward process that can be facilitated by either a network or SharePoint administrator. Within ISA server 2004, this process typically required setting up the appropriate listeners and web publishing rules so that the proper resources can be hit by the appropriate enterprise users. However, this process is streamlined with built in publishing mechanisms within ISA server allowing a flexible approach to how an enterprise will securely publish a SharePoint machine or arbitrary SharePoint resources.
The first step in implementing a ISA publishing architecture for SharePoint is to open the initial ISA management interface.
 
Step 1 — Open the ISA Administration Interface
Firstly, you must directly interact with the ISA server by logging onto the ISA Server machine either directly, through MSTSC, RDC, or other remote software such as DameWare, Tilovi, or others.
 
Start -> All Programs -> Microsoft ISA Server -> ISA Server Management.
 
Step 2 Enter Into Your ISA Firewall Policy
On the ISA machine, once you have the interface open, you must open the firewall policy dialog.In the ISA interface -> Expand Arrays -> Expand the Server Network / Domain -> Select the Firewall Policy
Step 3 Enter Into the SharePoint Publishing Dialog
Select Tasks (should open the Firewall Policy Tasks) -> Select Publish SharePoint sites (the third of the steps provided within the firewall policy dialog).
 
Step 4 Provide Basic SharePoint Server Information
Once you start the Publish SharePoint Sites wizard, you will be asked to provide some basic information regarding the publishing that you are going to setup. On the first set o dialogs, enter a common name for the publishing rule, such as SharePoint Sites.
 
Step 5 Select a Publishing Type
Depending on your installation, you will be asked to provide a publishing type which can vary heavily depending on organization by organization, the two within SharePoint are single server or web farms. You can publish multiple SharePoint site collections on different virtual servers, or a single site collection on multiple load balanced servers. The three options that you will receive are:
  • Publish a single web site or an external load balancer
  • Publish a server farm of load balanced web servers
  • Publish multiple websites 
Step 6 Select Your Internal Publishing Rules
The next step after finishing how the network publishing configuration will take place within your SharePoint environment, the next step will be how users will access it both internally and externally. The next dialog that will appear is the internal publishing details dialog, which will ask you to firstly specify the internal site name. This is typically something easy to remember that maintains a corporate DNS strategy, such as sharepoint.com or portal.com. If you are going to use SSL internally to connect to your SharePoint site, there is check box below this entry where you should specify that it is going to be used, saying ISA Server will use SSL to connect to the SharePoint site. This is required if you are going to use SSL bridging, which is recommended configuration if you are going to maintain a secure deployment. You will be able to see your site address in the grayed out box below, ensure that this address is correct.
 
Step 7 Select How Users Will Access Your Site Externally
The next dialog that you will see is Public Name Details, and depending on how you desire your users to access the portal, can vary. Within most organizations, it is common that this will take the form of the same site address that is used internally, sharepoint.com or portal.com, since it is desired to maintain conformity of access and not confusing to most users. You should enter this address after you select from the dialog drop down for accept requests for. In this drop-down, select the domain name.
 
Step 8 Set Up The Web Listener For the SharePoint Site 
The next dialog that you will see is the web listener dialog, where you should select the HTTP selection, since this is setting up mechanisms where ISA server will facilitate listening for varying web requests. You can also edit existing web listeners, or add a new web listeners as they exist within your ISA environment.
 
Step 9 Setting up the Authentication
Following, you will have to setup authentication types on the Authentication Delegation page. This will not effect the authentication that you have setup for your portal, there is no direct interaction where ISA will manipulate previous settings on your SharePoint environment. This is to setup a handshaking between the server systems. On this screen, you are going to select Negotiate (Kerberos/NTLM), since these are the two authentication types that are available within your SharePoint portal. There are a variety o other options, including
  • No Delegation allow end-to-end authentication
  • Basic authentication
  • NTLM authentication
  • No Delegation do not allow end-to-end authentication
  • Kerberos Constrained Delegation
It is feasible to setup custom Authentication delegation because how client credentials are delegated will vary from organization to organization. However, within most environments, Kerberos/NTLM is the most common when publishing SharePoint assets.
 
Step 10 Setting up User Sets
Most times, this dialog is not necessary for a basic SharePoint setup, therefore, simply select next.
 
Step 11 Completing the SharePoint Publishing Wizard
Confirm all the settings that you have made, by selecting the finish dialog which will complete the wizard. Depending on the complexity o your environment, there might be additional prompts that are required to fill in information, however for general SharePoint publishing these are the only steps that you need in order to complete the publishing of your SharePoint assets.
Share