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

What is Disaster Recovery in Relation To SharePoint?

* This article was written in the context of System Center Data Protection Manager 2006 (SCDPM), a technology now considered deprecated with the introduction of System Center Data Protection Manager 2007. Variations may exist. *

What is Disaster Recovery in Relation To SharePoint?
Disaster recovery in relation to SharePoint can mean many things, depending on the organization. Different enterprises use SharePoint for different purposes, ranging from implementing it solely for collaborating and communicating within virtual teams to using it solely for hooks into other server systems such as Team Foundation Server or Project Server. For whatever reason a company uses SharePoint, it is clear that there needs to be policies in place that will facilitate disaster recovery in the event that something may cause massive data loss for your portal. In essence, DR in relation to SharePoint can generally be thought of as processes, mechanisms, and policies that if data loss does occur for whatever reason that disrupts the portal to an irretrievable state it can quickly be returned to operational efficiency with little effort.
 
Why Should I Be Concerned With Disaster Recovery?
Disaster recovery can be an issue at many levels. Damage could inflict SharePoint file stores, custom development (ASP.NET 2.0 WebParts, SharePoint WebParts, or Framed Applications), design / branding efforts (master pages, manual modifications), and most importantly your stored business data. Without a disaster recovery policy and DR tools, your SharePoint environment can quickly become a central portion of business processes within an enterprise to a useless system leaving a bad taste in user’s mouth bringing SharePoint adoption to a standstill.
 
What Can I Do To Prepare for Proper Disaster Recovery?
There are several mechanisms that should be implemented in order to prepare for a disaster recovery situation. Some of which deal with implementing a proper disaster recovery policy, others are for implementing various types of software that will help to facilitate bringing your portal backup to speed if there is an event of large data loss.
 
What Types of Disaster Recovery Software Are Available?
There are several types of disaster recovery software that are based on varying types of software theories. In relation to the actually physical archiving of backup data, the three most popular are:
  1. Disk-to-Tape (DtT)
  2. Disk-to-Disk (DtD)
  3. Disk-to-Disk-to-Tape (DtDtT) 
Three of the most popular types of software are:
  1. RTR (Real Time Replication)
  2. CDP (Continuous Data Protection)
  3. DPM (Data Protection Manager)
How do I Choose the Appropriate Software for Disaster Recovery?
The software that you choose for your disaster recovery policy varies heavily on your organization. Some of the decision factors will be based on company cultural, some on functionality that you desire out of your DR bundles. As an example of cultural decisions, some shops will only implement Microsoft-centric software since it will generally build on and into other server packages and client software (as is the case with the Microsoft Operations Framework, since DPM will tie into Microsoft Operations Manager for management and reporting purposes), and is typically part of their Microsoft enterprise agreement(s). Some organizations are indifferent to the vendor, and are more concerned with varying functionality. When looking at replication or disaster recovery solutions, quick decisions are never the best ones. You have to examine each package in relation to your SharePoint environment, and possibly other systems that might be sheltered by the same solution.
 
Why is SharePoint a Difficult Product to Implement Disaster Recovery for?
SharePoint as a platform is subject to constant change, users uploading, modifying, and deleting documentation and other relevant portal assets, customizations being made to different site collections, and new portions of the portal being extended and de-extending everyday at every hour. Implementing disaster recovery for an environment that requires such an extent of synchronous backups during such intensive intervals during normal user hours is incredibly difficult. Ensuring that data is constantly intact in such a largely user adopted platform can also be problematic since the platform is almost constantly in use.
 
Is the Disaster Recovery Process a Task of a SharePoint Administrator, Network Administrator, or Users?
Protecting the assets of the portal is the responsibility of all of the above parties, and doesn’t all solely on the shoulders of just one position or person. The SharePoint administrator is typically most familiar with the status of the database and overall environment, the network administrator knows bandwidth usage and disk allocation within the network, and the users of the portal are typically the most familiar regarding specific assets within arbitrary site collections. The restore process depending on what has been lost can be the responsibility of either of the parties as well, as long as the process as it is tripped is documented, and doesn’t interfere with other SharePoint user activities.
 
What Does a Disaster Recover Policy Consistent of for SharePoint?
Here is a sample disaster recovery policy for SharePoint. It might have to be tailored to your environment more depending on what your corporate standards are, but will still be a good start. It is free to use with no copyright restrictions.
 
Is There Specific Disaster Recovery Software Exclusive To SharePoint?
There is no disaster recovery software made explicitly for SharePoint. However, such packages as Data Protection Manager are easily tailored to implement disaster recovery for a SharePoint environment, and can shelter other systems as well.
 
What Are the Prices of Disaster Recovery Software?
Disaster Recovery software can range from relatively cheap to exceedingly expensive and can depend on certain agreements with certain vendors (such as having enterprise agreements within Microsoft). It depends on what level of functionality you are seeking from the software. With real-time-replication, you can recover data within minutes of a disaster, but is not cost effective for small-to-medium (SMS&P) businesses, whereas DPM will be an hourly solution, but several thousands of dollars less and is relatively inexpensive to extend (buy more agents for) and maintain.
Share

Introduction to MOSS Security Architecture

Introduction to MOSS Security Architecture

The Microsoft Office Server System (SharePoint 2007) has many exciting new security mechanisms built into it that allows one to build a highly guarded collaboration environment that provide a unique, fluid user experience for all of the stored content. In previous versions of SharePoint, sometimes implementing very granular security options had the negative side effect of degrading the rich communications and collaborations feature of the product, required heavy development efforts, or additional hardware and software purchase.
 
Changes To The MOSS Security Architecture

 

There are however unique security features built into MOSS currently that allow one of the most robust, however secure, information worker centric environments to procure virtual teams within an organization. Building on technologies such as Windows Rights Management, Information Rights Management, and powerful permissions management, many afflictions that typically affect collaboration platforms can be solved through intuitive, internal security mechanisms.

Some of the MOSS security architectural possibilities are very industry exciting, specifically for those organizations that have to conform to certain business and legal regulations that stipulate certain privacy and security requirements, providing built in mechanisms for such popular regulations such as HIPPA and SOX.

Examples of Enhanced Security Provided by ASP.NET 2.0

Some of the greatest security enhancements in MOSS spawn from its new architecture and web application structure.

  • Since SharePoint relies on view states by default, and in the new version of Sharepoint this is protected through various hashing mechanisms through minor effort can be encrypted using some attributes, most notably the viewStateEncryptionMode attribute in machine.config of your SharePoint server.
  • Since one of the greatest enhancements is the introduction of forms based authentication possibilities into a SharePoint environment, forms authentication cookies and related authentication tickets are encrypted instead of being stored in plaintext, protecting authentication assets.
  • There are several options for enabling a session states (regardless of where the session information is stored), and therefore out-of-process session state assets are protected by the ASP.NET 2.0 framework, the backbone of MOSS.
  • For the pluggable authentication options of MOSS, if you are implementing a membership and role provider that is outside of the realm of the default windows authentication routines (which is, by default enabled), the related role manager cookies are encrypted. Along the same lines, if you have anonymous MOSS zones or a perimeter facing site with anonymous authentication enabled, those relevant cookies can be encrypted. For the membership providers, since they are stored in a variety of different systems, these passwords are stored hashed, if a heightened security option is more desirable, these passwords can be encrypted as well.

Why Was The Security Architecture Of SharePoint Changed?

There are several stages in order to implement sheltered knowledge management systems and secure collaborations environments, regardless of network architecture and operational access goals. SharePoint attacks are becoming increasingly relevant towards business operations and strategic business data warehousing as the product becomes increasingly commonplace throughout a variety of industries for an assortment of reasons.
 
Steps In Securing a SharePoint Environment
The first step in securing a SharePoint environment is to implement standards and policies with an environment, and just having these policies in place is not enough, they have to be enforced and adhered to by both portal users and administrators. These policies can vary in purpose and intent, as shown here in this index of SharePoint policies.
The second step is to investigate, implement, and maintain sister security and disaster recovery based server systems that will integrate and enhance your environment on a variety of levels.
 
Most Popular Security Shifts in SharePoint
Being built upon the new ASP.NET 2.0 platform offers SharePoint some unique security features that birth the possibility of several very lucrative environments. The two that are immediately evident are:
  • Forms-Based Authentication (FBA)
  • Pluggable Provider Model (Membership, Role, Session, and Profiles)

These two new options are incredibly popular options since they were the most requested features in previous version of SharePoint, and coupling the two options allows users to have an extranet / perimeter facing deployment that is unique and tailored to each specific instance.

Reasons SharePoint is Subject For Attack
The two most commonplace reasons SharePoint is a subject for attack are:
 
Data Theft Since SharePoint acts as an aggregator and warehouse for several layers of business information, a third party may try to capture vital enterprise data for any number of purposes, ranging from sale of this information to competitors or simply trying to pry into day-to-day operations.
 
Corporate Espionage Taking down a portal from an operational standpoint for businesses that are heavily dependent on it for operations can prove disastrous, and beneficial to a competitor that can take advantage of a weakened business state. This type of intended disruption has been well-documented throughout history through other systems (mostly through the battles between smaller communications companies in California, see here for more information regarding those DDoD attacks), and has translated over to SharePoint environments.
 
There are three main levels (tiers) of SharePoint security each of which has to be tackled individually and methodically maintained (loosely based on the OSI model):
  • Network Level
  • Web Application Level
  • Database Level
However, with certain procedures in place the threats to a portal can become vastly mitigated and an organization can collaborate in confidence.
Share