Book excerpt -- Chapter 12: Securing SharePoint Communication

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

This article is an excerpt from Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs, by Scot Hillier (Editor), Robert Bogue, Adam Buenz, Andrew Connell, Stacy Draper, Luis Du Solier Grinda, Todd Klindt, Jason Medero, Dustin Miller, Shane Perran, Joris Poelmans, Heather Solomon, Nick Swan, Jan Tielens, Mike Walsh, and Shane Young, and is property of John Wiley & Sons, Incorporated (978-0-470-16835-6), copyright August 2007, all rights reserved. No part of this chapter may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

Just as with all other Web-based applications, SharePoint is subject to electronic malicious actions of assorted types. Securing SharePoint is arguably one of the most unique and significant tasks that you will undertake when rolling out an initial SharePoint deployment, or securing a previously deployed SharePoint instance. The scope of securing SharePoint for your organization is considerable, from implementing transport layer security on the pipe to practicing appropriate Business Continuity Planning (BCP) strategies. By ensuring that all layers of security for SharePoint are accounted and planned for, you can mitigate numerous risks that would otherwise prove disastrous for your SharePoint infrastructure.

Fortunately, there are various avenues that you can exploit to procure effective SharePoint hardening mechanisms and security practices. Beyond the beneficial position that implementing appropriate SharePoint security practices will provide you and your organization, industries are subject to various business and governmental legal regulations that are generally federally mandated, therefore making securing SharePoint not an elective task.

The Breadth of SharePoint Security

The accessible techniques you can use to achieve a secure SharePoint information state range from built-in Windows Server 2003 and SharePoint security instruments to implementations of Microsoft sister server platforms that help you to procure secure Web application publishing, and provide stateful packet inspection of your SharePoint traffic. Following your implementation of these appropriate security standards, tools, and strategies, SharePoint can be used in a variety of circumstances within various industries, ranging from building influential custom facing business-to-business (B2B) extranets, to compelling internal intranets connecting your organization’s information workers.

The security of SharePoint spans a wide assortment of technologies, attributable in part to the fact that SharePoint (albeit enhanced) is fundamentally an ASP.NET 2.0 Web application. Generally, when people plan for the security of SharePoint, it is common that they only arrange the security of the Web application itself, while ignoring some or all of the associated technologies. This fallacy, however, procures a false secure mindset that negates architecting a truly secure collaboration environment.

The security of SharePoint houses many layers, starting at the machine level all the way to the subsequent pages served per user requests. Therefore, the security of SharePoint encompasses technologies such as Internet Information Server (IIS), ASP.NET, SQL Server, and associated server platforms assimilated into overall SharePoint operations. Consequently, when you are planning, designing, and hardening a SharePoint environment, you must consider, account, and integrate each of these correlations into your overall SharePoint security program.

Steps to SharePoint Security

Defining a universal security approach to execute with SharePoint is not feasible. To properly secure your SharePoint environment you must study, scrutinize, and strategize the variety of ways that you will leverage SharePoint. The results of this analysis should then be used as parameters to the building of the overall SharePoint security program. For different implementations, distinct security attributes must be implemented. However, no global standard can be defined, because it is an individual organizational decision.

For example, let’s say that you are deploying a small internal SharePoint implementation that allows users to collaborate on holiday planning events. In such an environment, you may deem transport-level security undesirable for the required effort of the IT team and performance overhead that it incurs because of handshaking negotiations. Furthermore, if the implementation is not heavily used, you may believe a very robust Disaster Recovery (DR) solution might not be required, because you consider the holiday planning data to be disposable.

Figure 12-1: OSI Reference Model

On the other end of the spectrum, let’s say that you are deploying an extranet acting as business-to-business partner portal, serving large quantities of content to other companies through the inherent SharePoint Web Content Management (WCM) features. The extranet being publicly available may be more easily subject to malicious information interception and other forms of attack. Therefore, you must implement transport-level security routines to protect your information in transit. Also, if your vital extranet information is being stored on an internal, detached SQL server, you must put a well-defined DR solution in place, practice it, and update it frequently to absorb new technology and inevitable realizations in your organization.

Although a universal security constant is not possible, you can take steps to harden your SharePoint environment, each binding to a tier that defines the inclusive SharePoint architecture. Although these steps are not completely comprehensive in what you should include in an overall SharePoint security program, they provide you with some foundational buildings blocks that are generally found in most properly sheltered collaboration environments, as shown in Figure 12-2.

Figure 12-2: Foundational building blocks of SharePoint security

First, you will see how you can secure the communication layer to mitigate any type of information transmission compromise. This generally involves implementing security protocols when serving requests to clients through the use of Secure Sockets Layer (SSL), and securing communication between the relevant SharePoint servers (inter-server) involved in farm communication through IPSec.

Second, you will see how to protect the network layer through the use of a Microsoft Internet Security and Acceleration (ISA) Server application firewall to build a DMZ (Demilitarized zone). The outcome of placing ISA Server in front of your internal network firewall will result in stateful packet inspection of your SharePoint traffic, thwart security bypassing, provide connectivity monitoring, and avert operational incidents such as denial-of-service (DoS) attacks. Using intuitive programmatic objects provided by the ISA API, you will see how to rapidly develop small applications and scripts that will streamline administrative tasks related to an ISA instance.

Approaching the securing of SharePoint in a layered manner (whereby each segment is analyzed) you will form a security blueprint known as threat modeling. Using threat modeling, the assets that build up SharePoint are identified and inventoried, the systems architecture is considered and disseminated, and threats to your SharePoint environment are measured for all of the analyzed individual levels. Throughout this chapter, you dive into some of these layers and examine solutions to harden each.

Secure the Communication Layer

You must take into account numerous considerations when you are beginning to secure the communication layer that SharePoint is employing to serve user requests. The communication stack is the backbone of how SharePoint will serve content to your users, providing the first line of defense, coupling with the network layer, building up how requested SharePoint information packets are eventually served.

Although it is feasible to group both the communication layer and network layer into one aggregate collection (because several technologies that each encompass tend to overlap), there are distinct differences between the two that you must take into account.

Characteristically, implementing encryption at the communication layer is the minimum level of security that an organization should consider for implementation, because it is commonly the least expensive, easiest to apply, and provides the most essential security attributes that should be included in a fundamental SharePoint security approach. There are two communication encryption protocols that you should take into consideration, one dedicated to securing client requests and another related to securing inter-server communication.

Differences between SSL and IPSec for SharePoint

When deciding on an encryption technology to protect traffic in transit, there are generally two types that are found within a SharePoint environment: Secure Socket Layer (SSL) and IP Security (IPSec). Several differences between the two make implementing either an attractive option for organizations. The choice basically breaks down to your organizational security needs, mandated corporate security standards, and how much effort you are willing to put forward. Optimally, a combination of both technologies can be leveraged to produce a mixed-mode environment that highlights requirements with the strength of each technology, notably using SSL for handling secure client requests for SharePoint content and IPSec for inter-server SharePoint farm communication encryption.

Architectural Differences Between SSL and IPSec

There are copious differences between IPSec and SSL that affect the decision of whether to implement either one of the technologies as a standalone encryption piece, or whether to employ a powerful mixed-mode environment. The most straightforward method to use when making the decision is to inspect the variations between the two encryption technologies, and to look at how each functions architecturally.

The principal architectural difference between SSL and IPSec is how each protocol is instantiated on an arbitrary server within a SharePoint farm. IPSec is instantiated as a machine layer setting because it is an IP layer protocol, existing at the layer three (network level) of the OSI stack (see Figure 12-1). Because of this low-level placement, it can be packaged into something very granular, such as the machine kernel using Bump-In-The-Stack (BITS), or offloaded outside the machine using Bump-In-The-Wire (BITW).

SSL, as opposed to the machine-level existence of IPSec, is a higher-level setting within the application layer of the OSI model. Therefore, it is instantiated on a per-application basis. SSL resides on the request stack above the actual information packet, deriving its plumbing from TCP/IP (however, below higher-level protocols such as HTTP). Because SSL is implemented on a per-application contract, SSL allows individual connections to be established, isolating security incidents as they occur. This differs from the IPSec protocol as far as which packet requests pool to a singular connection stream because of the machine-level configuration that IPSec exercises.

Because of these architectural dissimilarities, for your SharePoint environment, it is important to realize that IPSec is generally not considered a replacement for SSL. Because of where it sits on a machine, IPSec is meant to encrypt communication between two distinct servers, such as between your SharePoint Web Front-Ends (WFEs) and back-end SharePoint SQL databases. SSL, however, is meant to serve an arbitrary number of client requests, and, therefore, is the recommended encryption solution to use on your WFEs (because the number of users that will request content is generally not known). SSL in terms of IT team effort and required security knowledge is also much less complex and much quicker to put into production.

It is possible to force SSL protocol encryption between server communications using certificates, such as between the SharePoint WFE and back-end SQL database. However, there are performance considerations to take into account when you make that decision that make IPSec your wisest choice for inter-server communication.

SSL and IPSec tend to be very similar in terms of actual encryption performance, because the encryption routines that each provide tend to be identical, and, therefore, the scrambling processes tend to consume the same amount of computing cycles. However, the handshaking process that occurs between both services tends to be slightly faster when using IPsec. Furthermore, IPSec supports compression algorithms leveraging IP Payload Compression Protocol (IPComp), whereas with SSL, this is generally absent.

To function, IPSec will also use packet injection, because it modifies routed packets by placing a new TCP header onto the original packet. This is meant as a means to support other types of protocols such as UDP because SSL supports only TCP transmissions, and, therefore, slightly bloats the routed information.

Using a Mixed-Mode IPSec and SSL Solution

The most constructive way to set up your traffic encryption solution for a SharePoint farm is to utilize a mixture of SSL with IPSec, where you can leverage both technologies for their unique strengths. You can use SSL to secure client requests. However, you can secure the communication layer for inter-server SharePoint farm communication between specific servers providing functionality (such as Web application services, indexing, other search-related activities) and enterprise features (such as Excel Services and Forms Services that may run on other delegated machines) by using the machine-layer security settings provided by IPSec.

By using specific IPSec modes, you can ensure that the transmissions are secure by mandating that all machine-to-machine communication instantiated between two SharePoint farmed servers is using the IPSec protocol. This is accomplished by using an IPSec policy to prevent communication sniffing with blatant source and address parameter rules. Using this technique allows you to build an architecture known as no fallback machine or server isolation. This means that a network silo is fashioned between the IPSec-enabled machines, isolating them from the non-isolated machines by ignoring subsequent machine requests, crafting a proper, secure network segment for SharePoint operations.

For users requesting content off the SharePoint farm, you can then use SSL to encrypt the data that is being sent to users by using the functionality provided by Microsoft Certificate Services (MCS), SelfSSL (provided with the IIS 6.0 toolkit), or a public Certificate Authority (CA). This can be implemented alongside some of the inherent ASP.NET 2.0 provider and authentication functionality. Although basic authentication is generally the most used in regard to SSL, it is a best security practice to use the inherent provider functionality coupled with SharePoint Forms Based Authentication (FBA), because expiration-controlled cookies can then be used that are both tamper-proof and encrypted by default.

Although the influential encryption benefits of inter-server IPSec communication are the main purpose for its employment, there are also numerous other benefits that can be realized when implementing the proposed server isolation solution. Because there are going to be certain flagged attributes describing source and destination data when using IPSec, there is another layer of security introduced that allows you to verify packet reception and destinations between SharePoint farm servers. Furthermore, IPSec integrates directly in with Kerberos authentication, which provides distinct advantages over Windows NT LAN Manager (NTLM) authentication routines. You see how to disseminate, examine, and approach Kerberos authentication later in this chapter.

Setting Up IPSec No Fallback Isolation Between SharePoint Servers

When you enable IPSec with SharePoint, you generally will be configuring the encryption protocol between the SharePoint servers participating in the SharePoint farm, as well as the server incorporated as the domain controller (DC). This is done by generating an IPSec policy (consisting of appropriate filters, actions, and rules), and then assigning the policy you create to the participating farm members (such as the SharePoint Index and Search servers by exporting the IPSec policy). You can best think of a proper IPSec implementation as a subscription-based architecture, whereby each server that is participating in the overall IPSec scheme subscribes to the IPSec standard in order to communicate with each other, and within the policy, attributes assigned can control how that inclusive service communication happens.

Table 12-1 shows IPSec no fallback isolation policy elements.

Table 12-1: IPSec No Fallback Isolation Policy Elements

Element Name	Element Description
Create IP Filter List	The IP filter list will define the protocols and interface elements that establish access control to the SharePoint servers
Create IP Filter Actions	Determines how security is handled for both IPSec-enabled and non-IPSec-enabled machines
IPSec Policy	Determines the aggregate IPSec configuration and is used for deployment

Creating IPSec Reusable Batch Files

Although it is viable for you to establish IPSec filter lists, filter actions, and summative policies through the IPSec interface, it is often advantageous to script the required logic in reusable batch files to promote reuse throughout other SharePoint instances that you might be responsible for. To do this, you can use the netsh.exe command-line tool provided with Windows Server 2003 to create reusable .CMD scripts to consume whenever applicable, even for other server objects such as SQL clusters. As you will see, the Netsh IPSec context is a powerful option for quickly managing and configuring IPSec.

The first task is to create a policy object that will hold the policy name that is passed in as a string value. The policy is not immediately allocated because of the assign=no flag, which is intentional, because there are various attributes that still have to be added to the policy before it is consumed. The default value for this is also no. Therefore, to assign the policy, you must directly call this attribute out in your script, as you will see at the end of the script:

netsh.exe ipsec static add policy name="SharePointIsolationPolicy" 
assign=no

Once the policy object has been defined with a name, it is possible to subsequently add the appropriate filter lists and filter actions. First, you must define a filter list and give it a case-sensitive name. Executing the following command will instantiate an empty filter list, which can optionally take the description parameter as an argument if you want to specify more information about the filter list:

netsh.exe ipsec static add filterlist name="SharePointTraffic"

Once the filter list is identified, you can add the appropriate filters to the filter list to describe the source addresses, describe destination addresses, provide a brief description of the filter, describe the protocol that it is running under, describe subnet masks, and provide the relevant port information to define the interface requirements.

For example, you could create two filters to handle the most common protocols for SharePoint, HTTP and HTTPS. IPSec can handle any number of protocols (such as ICMP, TCP, UDP, RAW, or port-based protocols) because of where it exists in the machine stack. (IPSec modifies routed packets by placing a new TCP header onto the original packet.) Thus, it is possible for you to handle all acceptable protocols by setting protocol=any. The source and destination addresses that are being specified are fairly loose in the following example because they are accepting any source address and setting the destination address as the server that the SharePoint server is running on:

REM Create a filter to handle port 80 protocols (HTTP)
netsh.exe ipsec static add filter filterlist="SharePointTraffic" srcaddr=any dstaddr=me description="HTTP"  protocol=TCP srcport=0 dstport=80

REM Create a filter to handle port 443 protocols (HTTPS)
netsh.exe ipsec static add filter filterlist="SharePointTraffic" srcaddr=any dstaddr=me description="HTTPS" protocol=TCP srcport=0 dstport=443

Then, you can define the relevant filter actions, which are exercised afterward when defining the applicable access rules. This will also be the place where encryption routines can be defined. There are some arguments that you can use with the filteraction parameter that may appear to be confusing:

• The qmpfs argument defines whether to enable Perfect Forward Security (PFS), a cryptography concept targeted to eliminate unnecessary and unauthorized key reuse.

• The inpass argument specifies whether incoming packets can be non-secured in interception when relaying must be secured. This is generally an acceptable option, because the inter-server SharePoint farm communication can be locked down when outgoing from the server.

• The soft parameter is a failsafe measure that allows IPSec to go unsecure if other SharePoint farm servers don’t support IPSec. This is undesirable, because inter-server communication should be encrypted between all of the servers in your environment. So, the attribute of soft should be set to no.

• The qmsec (quick mode security settings) argument holds the main security arguments of the method. The qmsec parameter will specify the relevant encryption algorithms that are used when a new session key is creating (declared in the first parameter in kilobytes), and the session key lifetime.

In the following example, MD5 is used first, and then SHA1 is used:

netsh.exe ipsec static add filteraction name="SharePointOnly" qmpfs=yes 
soft=no inpass=yes action=negotiate qmsec="SP[MD5]:100000k/1000s 
SP[SHA1]:100000k/1000s"

More general filter actions can be defined and offered for later consumption (such as common allowing and blocking) by setting the action flags to either permit or block:

REM Add a filter action that will allow all users (permit all)
netsh.exe ipsec static add filteraction name="Allow" action=permit

REM Add a filter action that will deny all users (block all)
netsh.exe ipsec static add filteraction name="Block" action=block

After the filter actions are defined, you must restrict the relevant traffic so that the source address and destination addresses are set to receive from the relevant SharePoint server. The rules declaration makes it possible for you to define whether the rule should leverage Kerberos authentication by using the Kerberos=yes flag and defining whether keys are shared.

REM Add the appropriate static rules for IPSec

REM Define the permit all rule
netsh.exe ipsec static add rule name="Allow HTTP" policy=" 
SharePointIsolationPolicy " filterlist="SharePointTraffic " kerberos=yes
filteraction=Allow

REM Define the block all rule
netsh.exe ipsec static add rule name="Block All"  policy=" 
SharePointIsolationPolicy " filterlist="SharePointTraffic "  kerberos=yes 
filteraction=Block

REM Define the rule with the encryption previously defined
netsh.exe ipsec static add rule name="" policy=" SharePointIsolationPolicy " 
filterlist="SharePointTraffic " psk="SharePointSharedKey" 
filteraction=SharePointOnly

Now, the policy object contains all the relevant assets that are required for deployment, including the filter lists, filters, filter actions, and rules. For you to leverage the policy, the set method can be used against the policy object, and the assign attribute can be flagged with a yes value (which was previously flagged with the no value during the initial instantiation of the policy object). If you do not assign the policy, it will still be available from the policy store; however it will have no applicability.

netsh.exe ipsec static set policy name="IIS_Server_Policy" assign=yes

Once the policy is set, you can verify it in the IPSec Microsoft Management Console (MMC) snap-in or through more scripting. To verify the new policy through MMC, open the MMC snap-in and add the IP Security Monitor option, which should currently define the specific filters that were just created. To view the policy through scripting, you can use the following command:

REM Show the new policy in the policy store
netsh.exe ipsec static show all

Once the destination and source address values are set within the IPSec settings, if the servers are not called out within the policy settings, there will be no communication allowed except the values that were explicitly set.

After creating an IPSec policy, you may need to export and import the policy to other servers. For example, you may create a batch file that targets securing your search and index machines, because indexing typically is offloaded in SharePoint farms to siloed servers and its communication with the search servers is generally not encrypted. To export a created IPSec policy to all of the search computers, you can use the exportpolicy and importpolicy commands, which take the file paths to the IPSec policy as arguments, as shown here:

REM Export an IPSec Policy (.ipsec)
netsh.exe static exportpolicy c:\SharePointpolicy.ipsec
REM Import an IPSec Policy (.ipsec)
netsh.exe static importpolicy c:\SharePointpolicy.ipsec

Using this technique, you can select the servers that should subscribe to the policy within the SharePoint farm, and the communication that occurs between them can be restricted by the use of the IPSec policy, ensuring that any inter-server conversation happens with encryption.

Kerberos Authentication in SharePoint

As explained earlier, IPSec integrates directly with Kerberos authentication, which you have seen in the netsh.exe commands when creating a new static IPSec rule with the kerberos=yes argument set. Kerberos is commonly the best security selection for an authentication routine within a SharePoint intranet environment, although it tends to be put into practice less frequently because it is more complex to implement in comparison to NTLM (which doesn’t require much architect interaction).

Several benefits inherent to Kerberos authentication make it a very attractive choice for SharePoint intranet authentication.

Kerberos authentication tends to provide much more rapid processing for the concrete authentication routine because of the unique ticketing architecture that builds its backbone. This is because each requesting entity on the SharePoint network can request an authentication ticket, known as a Ticket to Get Tickets (TGT) from the Key Distribution Center (KDC). The ticket is granted by one of the main services that Kerberos provides, the Ticket-Granting Service (TGS), which constructs the ticket with specific parameters such as time-to-live fields (TTL), session keys encrypted against the hashed user password, and aggregate authorization information. Once the TGT is given to a user, it can be given to the KDC to generate service tickets for specific machines, which are then cached on the client machine. This means you can allow your users access to all the resources that exist within a specific, declared domain, such as to servers offering data from Microsoft sister server systems (such as SQL Analysis Services, Reporting Services, or others) without concern for double-hop authentication problems.

This is contrary to how NTLM authentication works. When one of your user requests is submitted for a specific resource that exists on a domain, it requires that the domain controller (DC) be contacted to verify the user credentials. Kerberos bypasses this inefficiency because the ticket that is being issued negates the need to communicate back with the DC to provide access to various domain resources, thereby increasing the performance of the overall authentication process.

The native encryption options that are offered to you with Kerberos are much more attractive as well. NTLM uses only symmetric cryptography, whereas Kerberos supports both asymmetric and symmetric cryptographic routines, thus increasing the overall options of confidentiality. NTLM also only supplies client authentication, whereby the client will request a resource of the server, the server will challenge the client, the client inputs the relevant information, and the server then validates the information that is submitted from the client. Kerberos does not work in this limited fashion. Kerberos supports both client and server authentication.

One of the most intrinsic segments of Kerberos authentication is the use of delegation (also known as authentication forwarding), which ties directly back into the concept of ticketing through the use of the KDC. Delegation is exceedingly significant when examining the features of multi-tiered authentication routines, which are increasingly common within SharePoint environments that tend to aggregate various business systems. Within any .NET application, when a user frequently accesses a specific resource, there is generally a small impersonation routine leveraged for an arbitrary user to act as a specified service when requesting an explicit resource. This is accomplished by calling the WindowsIdentity class and then using the Impersonate() method to impersonate the service Windows user.

Kerberos takes this concept a step further. A user is not granted access to a specific resource on behalf of the service account. Rather, with authentication forwarding, the service can get access to specific resources based on the identity of the user. Therefore, when a user enters a SharePoint environment and tries to gain access to a secondary database server that gets its relevant information from another server, the user can grant the relevant access to the secondary server that uses the user identity to give rights to the services. The user can then gain access to the third server, as opposed to using the service account for representation for authentication.

Setting Up Kerberos Authentication for SharePoint

To set up a SharePoint server for Kerberos, your first step is to set the relevant Web application (IIS Virtual Server) to use Kerberos as opposed to NTLM authentication (because NTLM is generally the default authentication routine in most environments). This can be done in three ways. Using any of these methods produces the same results.

Your first option occurs when creating or extending a new Web application through SharePoint Web Central Administration (WCAM). You are offered the option of changing the Web application authentication type between NTLM and Kerberos authentication.

For pre-existing applications, switch your authentication on an existing SharePoint Web application in WCAM by selecting Authentication Providers in the Application Management interface, and change the IIS Authentication Settings to use Negotiate (Kerberos) Outside of the main SharePoint interface. You can also use the adsutil.vbs script using the set method:

cscript adsutil.vbs set 
w3svc/SharePointSiteId/root/NTAuthenticationProviders "Negotiate,NTLM"

Lastly, you can also directly edit the IIS Metabase to change this property. Directly editing the IIS Metabase offers the greatest insight into the back-end operational structure of your SharePoint Web server. To change the authentication property within the IIS Metabase, first stop the IIS services, unless you have the “edit-while-running” feature enabled (direct Metabase edit configuration). Once the IIS service is stopped, navigate to the IIS XML Metabase file located in the \system32\inetsrv\ directory that contains the metabase.xml file. Before you make any changes, it is advisable to make a backup copy of the Metabase XML file. Because the Metabase file in IIS 6.0 is built upon well-formed XML, it is possible for you to directly edit it within your favorite text editor, such as Microsoft Notepad or Microsoft Visual Studio .NET.

The object in the Metabase that you need to locate is the IISWebServer object that specifies properties of each virtual server on the SharePoint machine. One of the child elements of the IISWebServer object is the NtAuthenticationProviders Metabase property, which specifies the attributes that should be associated when integrated authentication is being used for the virtual server (Integrated Authentication being the most common Virtual Server authentication setting that exists for SharePoint instances targeting an intranet deployment).

Whatever solution you are using to enable Kerberos, the NtAuthenticationProviders element should have the appropriate Kerberos string, as shown here:

NTAuthenticationProviders="Negotiate,NTLM"

What this IIS property is saying is that, first, Kerberos negotiation should be attempted when passing in the authentication header. If the negotiation fails with Kerberos (either because of the requesting user not providing enough authentication information, or the involved applications not supporting Kerberos authentication), then NTLM authentication is used to provide you with an authentication fallback.

Once the SharePoint Web application is set up to use Kerberos authentication using any of the described methods, the next step is to configure the SharePoint machine to be trusted for delegation, which allows a service to impersonate the user account to access various resources that exist across a network. Once this setting is enabled, the SharePoint service can access other network resources on the network by impersonating the user. This is done by opening up the Active Directory MMC snap-in, locating your SharePoint server, and, under the delegation properties of the server, checking the Trust Computer box under the Delegation tab.

Because it is common for SharePoint service accounts to run under domain accounts, you must also configure the service account to be trusted for delegation as well (so that it will be allowed to impersonate relevant users, no matter what account is running under the SharePoint Application Pools). To do this, follow the same method described to trust the SharePoint server for delegation. However, simply use the users container in Active Directory to enable the same setting for the relevant service account.

Finally, you must configure the resources that you want the account to impersonate to have the relevant Service Principal Names (SPNs). When registering an SPN, you are essentially specifying how the Kerberos authentication routine will authenticate to the relevant service, and then leveraging it. This is done by using the setspn.exe command, as shown here:

setspn -A HTTP/ServerName Domain\UserName

It is a best practice when you are setting up the SPN for Kerberos that the DNS and the NETBIOS names are both set for SharePoint through setspn, because it will provide coverage for all names that the user may specify (assuming that the NETBIOS names are unique across an environment). If this is generally not the case within your environment, it is best to instead just use the fully qualified DNS name to make the authenticated connections. If the naming conventions are unique, this setting is much more comprehensive, as shown here:

setspn -A SharePointService/SharePointMVP.com SharePointMVP\Adam

setspn -A SharePointService/SharePointMVP SharePointMVP\Adam

Certificate Solutions for Serving Clients

To harden SharePoint packet transmissions when serving SharePoint content to your clients, the pipe off of which your SharePoint instance is serving requests must be secured to encrypt the communications occurring between the requesting client machines and the SharePoint server farm. When enabling SSL, there are a variety of certificate architectural considerations that you must consider, including the following:

• Using a mutually trusted public CA certificate issuance (such as Verisign or another public CA)

• Using the embedded certificate solution that Microsoft provides through the use of MCS

• Issuing a mutually untrusted certificate through SelfSSL out of the IIS 6.0 toolkit

The most cost-effective way to approach using SSL is to either utilize an existing MCS infra-structure (because it is built into Windows Server 2003 as an available Windows Service) or to use SelfSSL (because it allows the quick creation and destruction of certificates because the SharePoint server administrator becomes responsible for the certificate life cycle). The MCS solution is typically an enterprise-based implementation, because the architecture of MCS is somewhat more complicated than the simpler SelfSSL self-certificate issuance option.

Using and Understanding Microsoft Certificate Services

When leveraging the embedded MCS certificate solution options, your appropriate organization PKI representatives or delegated certificate administrators typically have the option to deploy and revoke digital certificates that can be assigned for use with your SharePoint instances.

As shown in Table 12-2, MCS offers four modes of operation, allowing it to act as different CA types.

Table 12-2: Microsoft Certificate Services Modes of Operations

CA Type	Description of Type
Stand-alone root CA	Exists at the root of a disassociated network.
Stand-alone subordinate CA	Belongs to an established disassociated network. Obtains CA certificates from the stand-alone root CA, but can issue certificates in subordinates.
Enterprise root CA	Exists on an associated network at the root of the domain and is considered to be the most trustworthy. Has access to Active Directory.
Enterprise subordinate CA	Belongs to an associated network as a member of an established CA hierarchy. Obtains CA certificates from the stand-alone root CA, but can issue certificates in subordinates. Has access to Active Directory.

The implementation of MCS is not such a relatively straightforward task and requires a granular level of planning and design, because it equates to setting up an enterprise CA that signals the beginnings of a formal PKI infrastructure. Furthermore, MCS management and administration can become relatively complicated because it offers its own interfaces for development, using either the CryptoAPI interface (called CAPICOM), or leveraging the IISCertObj object to build the relevant scripts.

If you have an internal CA that is currently activated within your domain, to get a certificate for the SharePoint server, you are going to use the certificate Web enrollment site, or contact the appropriate Public Key Infrastructure (PKI) representatives. To begin the certificate request for your SharePoint server, you must follow these steps using embedded Windows Server 2003 functionality:

1. Open the IIS manager (Click Start, click Run, and type inetmgr) and expand the Server Name node.

2. Expand the Web Sites node. Right-click the SharePoint Virtual Server and select Properties.

3. Click the Directory Services tab.

4. Select Server Certificate.

5. Click “Create a New Certificate” and click Next.

6. Select “Send The Request Immediately to an Online Certification Authority” and click Next.

7. Choose a friendly name for the certificate, do not adjust the bit-length from 1024, and select Next.

8. In the Organization Information window, the Organization and Organization Unit Name textboxes should have relevant organization information. Click Next.

9. In the Common Name window, enter the fully qualified domain name (FQDN) for the SharePoint server. This will default to the name of the machine off of which you are requesting the certificate.

10. 10.In the Geographical Information window, enter in your country/region, state/province, and city/locality from where you are requesting the certificate.

11. Select the SSL port that the SharePoint application will use. The default for the port is 443, and it is not recommended to change this setting.

12. 1In the Certification Authority window, select the internal CA responsible for processing your certificate request.

13. The last window will allow you to finalize your request. Ensure that all the settings displayed in this window are correct.

14. Click Finish when you are done with the certificate request.

15. You can view your certificate on the View Certificate option within the Virtual Server properties under the Directory Services tab.

Because MCS becomes relatively involved when quickly trying to deploy a certificate solution, you can instead use a self-certificate issuance, which tends to be a quicker, self-manageable solution that provides a high level of self control. Self-issued certificates are an ideal option when you are setting up a development environment or staging environment.

Using SelfSSL to Create Self-Signed Certificates for SharePoint

If there is not an enterprise certificate architecture within your organization (either through the use of a public CA or through a corporate MCS implementation), you can create and issue a certificate easily through the use of SelfSSL, which is provided with the IIS 6.0 toolkit. Although using SelfSSL will allow the creation of a certificate for use with a SharePoint environment, if you are having more than a few internal employees access the site, it is best to request the certificate from a CA that all requesting parties can trust. However, using the SelfSSL utility is a good method to avoid the complications, cost, and corporate standards that come with the use of MCS or public CAs, and requires very little interaction from you as the SharePoint administrator.

To use SelfSSL.exe, you must first acquire some of the arguments that will be needed for the executable to function. The most difficult and obtrusive of these is the ID of the virtual server that the certificate is going to be run on. You can acquire this either through a user interface or programmatically through C# code.

To acquire the virtual server ID through a user interface, it is possible to use another tool out of the IIS toolkit called the Metabase Explorer, which will allow you to browse through the ServerBindings property from the IIS Metabase. Because the Metabase Explorer simply wraps the metabase.xml file with a UI client application, you could optionally open the metabase.xml file in a text editor to acquire the same information.

You can also explore the ServerBindings programmatically through managed code by creating a small iteration using the DirectoryEntry class out of System.DirectoryServices to represent an object in IIS and the ServerBindings property. Coupled with PropertyValueCollection, it is possible to house the relevant values of the ServerBindings properties, as shown here in C#:

DirectoryEntry mySharePointServer = new 
DirectoryEntry("IIS://localhost/w3svc/" + websiteID );


PropertyValueCollection serverBindings = 
mySharePointServer.Properties["ServerBindings"];
        for (int count = 0; count < serverBindings.Count ; count++)
          {
             (serverBindings[count]);
          }

Once you have the virtual server ID harvested to pass as an argument to the SelfSSL tool, the certificate can be generated by using some command-line executions that will create and assign the certificate to the SharePoint instance. SelfSSL, by default, will attempt to gather all the default values for the default Web site to give you a general idea of what the statement should look like. Table 12-3 shows the SelfSSL parameters.

Table 12-3: SelfSSL Parameters

CA Type	Description of Type
T (Trusted Certificate)	Add the certificate being created into the trusted certificates list, which will allow the certificate to be immediately consumed from the local browser.
N (Common Name)	This is the Common Name of Certificate. Ensure that this matches the FQDN of the site that SharePoint is running on; otherwise, you will encounter several certificate errors throughout the user experience.
K (Key Size)	The cryptographic key length, which is generally kept at the default of 1024.
V (Validity Days)	How long the certificate will be valid for (specified in days).
P (Port)	The SSL port for the certificate to bind to, which is generally kept to the default of 443.
Q (Quiet Mode)	Will overwrite any SSL settings that may be affected by the SelfSSL process. If not flagged, you will get a prompt asking you whether you wish to overwrite the SSL settings for the virtual server ID specified.

When building the SelfSSL statement to execute, it should look like the following:

selfssl.exe /N:CN= <Common Name>/K:<Key Length> /V:<Days>/S:<VID> 
/P:<Port>

Once the SelfSSL statement is executed, you can browse to the deployed SharePoint site by using the https:// as opposed to the http:// prefix with the URL configured for the SharePoint Web application. SelfSSL will take care of most of the default settings (such as calling the default 443 SSL port).

When executing SelfSSL, the process will overwrite any of your SSL settings for the target SharePoint Web application, so execute the command with care. If you are requiring SSL and 128-bit encryption for connections in your Virtual Server Secure Communications configuration, these settings must be manually set, and are not automated by SelfSSL.

You can require SSL for your SharePoint Web application within the IIS virtual server properties. This will force SSL encryption for all of your SharePoint traffic, not allowing the use of the HTTP protocol. This is generally a good option, because a user will not often be diligent enough to type in the https:// prefix when navigating to your SharePoint site. To force SSL encryption, follow these steps:

1. Open the IIS manager (Start  Run, and then type inetmgr) and expand the Server Name node.

2. Expand the Web Sites node. Right-click the SharePoint Virtual Server and select Properties.

3. Click the Directory Services tab.

4. In the Secure Communications group box, select “Require secure Channel (SSL)” and optionally select “Require 128-bit encryption.”

5. Click OK.

ISA Server and SharePoint

Because of the potential high costs of security breaches within a compromised SharePoint environment (in addition to the requirements to maintain compliance with business and legal regulations), it is often prudent for you to introduce more advanced security solutions. These can include application layer firewalls with stateful packet inspection, chained authentication, packet filtering, and reverse proxies through the use of Microsoft Internet Security and Acceleration Server 2006 (ISA Server).

In a SharePoint environment, the benefits of ISA Server include the use of an application firewall (that promotes application-layer filtering with stateful interrogation of SharePoint packets) and SSL bridging (that provides an end-to-end encryption solution). By using stateful interrogation against SharePoint traffic, the typical inspection of packets is enhanced. Legacy methods of packet inspection firewall technology will generally only inspect the header of a packet and the destination port, whereby the actual information payload is not scanned. However, ISA Server includes mechanisms that provide intelligent decisions to determine whether the traffic should be considered to be legitimate or malicious in intent.

There are three main tasks that you should perform in regard to ISA Server with SharePoint:

• Securely publishing your SharePoint server through the use of SSL bridging to support stateful inspection of traffic

• Configuring link translation to ensure that your sensitive and unintentional server names aren’t returned in SharePoint objects like the Core Search Results Web Part

• Setting up connectivity verifiers to monitor your SharePoint server to ensure communication between ISA Server and your SharePoint server

Of course, several other tactics and approaches can be exploited using ISA Server. The following basic three options are the ones most commonly found in an enhanced ISA Server environment with SharePoint (targeted at small to medium enterprises). Similar to the reusability introduced with IPSec through the use of scripts, the ISA Object Model allows you advanced capabilities to tap into its unique objects to streamline advanced tasks through two methods:

• Scripts for reusable code to automate administrative ISA tasks

• Using managed languages to build applications against ISA Server

With the SharePoint Publishing Rule Wizard, introducing ISA Server into your SharePoint environment has also never been easier. The wizard greatly eases the process of securely publishing your SharePoint Web applications.

Setting Up SSL Bridging with ISA Server for SharePoint

SSL bridging is one of the many ISA firewall features that promote a high level of security for SharePoint traffic on SSL-enabled pipes. Unlike advanced hardware firewalls (which can perform stateful inspection on solely HTTP traffic), ISA Server provides the alternative to inspect even encrypted SharePoint SSL traffic. SSL bridging supports this scenario, because the packets are decrypted on reception by the ISA Server, and then re-encrypted when the packet is then forwarded to SharePoint.

Two methods of SSL bridging configuration are supported by ISA Server and can be leveraged, depending on the SharePoint security environment needs:

• SSL-SSL bridging—This is the most comprehensive security solution because the traffic is SSL-encrypted from the point of origin to reception by the SharePoint server, covering all the related network endpoints. Stateful inspection of the traffic can occur as well, because the packet can be decrypted upon reception on the ISA Server interface before being re-encrypted again.

• SSL-HTTP bridging—This provides encryption of the traffic between the requesting SharePoint user and the ISA Server. Afterward, the transmission between the ISA Server and SharePoint is sent in plain-text, therefore credentials can be intercepted on the internal network.

Programmatically, you can access these types through the SecureProtocolRedirection and NonSecureProtocolRedirection properties of the ISA Administrative Object Model. These properties control how requests are forwarded when they are piped in through both a secure and unsecure connection. These types are also accessible through the PublishedServerType property, which will determine how piped requests are handled by a related Web Publishing Rule. Programmatic manipulation of ISA Server administration objects is discussed later in this chapter, along with an examination of how exploiting such objects can ease complex administration tasks.

SSL-SSL bridging is undoubtedly the most secure SSL scheme that you can implement for SharePoint. This is because the entire transmission process from creation of the client request to final content service by SharePoint is encrypted. This particular bridging process encompasses an SSL session between the client and external ISA Server interface, and a subsequent SSL session between internal ISA Server interface and the SharePoint server. The overall sequence that builds up SSL bridging is relatively straightforward, and once understood, the benefits of implementing a complete end-to-end encryption solution are immediately evident.

Although there are several granular sequences that go into an endpoint-to-endpoint encryption solution, some of the principal ones forming the foundation are shown in Table 12-4.

Table 12-4: SSL Bridging Sequence of Events

Process Name	Process
Initial Request	A client will request the SharePoint instance with the https prefix to establish a preliminary SSL session between the client and external ISA interface.
SSL Connection Is Established	The SSL session is established between ISA Server firewall and the client. Data transmission that occurs between the client and the ISA Server is encrypted.
Web Publishing Rule Query	Web Publishing Rules are queried as to whether there is one that contains a destination set with the requested FQDN of the passed request argument. The Web Publishing Rule contains the listener reference to the aliased server certificate in the ISA Server machine Trusted Root Certification Authorities.
Matched Destination Set	If a matching destination set is found, the request will be forwarded according to the instructions that are included in the Web Publishing Rule.
Packet Decryption and Inspection	ISA Server decrypts the SharePoint traffic and inspects it to determine whether or not the traffic is considered legitimate.
Create SSL Connection To SharePoint	ISA Server will then instantiate a new secure connection to the SharePoint server by using the ISA Web Proxy Service to act as the requesting client on the internal ISA Server interface.
Traffic is forwarded to the SharePoint server	Following the secure line establishment to the SharePoint server from the ISA Server interface, SharePoint packets are forwarded in encrypted format.

To enable SSL bridging, you must complete several Windows Server, SharePoint, and ISA configuration steps, each of which plays an intrinsic role in the overall communications process. Some of the steps are required to set the stage for the proper functioning of the ISA Server.

Setting Up Alternate Access Mappings (AAM)

The first of these groundwork steps is for you to set up Alternate Access Mappings (AAM) to ensure that your appropriate SharePoint URLs resolve to the correct content. There are two ways to configure Alternate Access Mapping Settings for the appropriate incoming and outgoing zones: using STSADM.exe or through WCAM.

This is an important step, because during the publishing of the SharePoint server, ISA Server will ask you whether or not you have achieved this task. ISA requires this information because SharePoint can be accessed from multiple URLs or locations, and still provide the same content to the user through the use of zones. AAM helps to resolve this issue by providing the means for appropriate URL resolution, so that users can type in the address http://www.sharepointmvp.com and they can be redirected to http://dmz.sharepointmvp.com. This step is pretty important, so it is better to have this done before starting the ISA Server publishing process.

The first way to implement AAM is through the use of the stsadm commands addzoneurl and addalternatedomain. The addzoneurl command will take the zone name that you are configuring for as a parameter, as well as the zonemapedurl, which takes the URL that the client will be requesting.

@ECHO ON


REM Adding an outgoing zone
stsadm.exe -o addzoneurl -urlzone extranet -zonemappedurl 
https://www.sharepointmvp.com -url https://dmz.sharepointmvp.com


REM Adding an incoming zones

The addalernatedomain command is arguably where you might run into some trouble, because it will tie more into how you configure ISA Server. It takes in the incomingurl parameter, which represents the URL of how the site will be requested (the URL of the SharePoint server). By default, ISA will forward the original host header when using the SharePoint Publishing Wizard. So, the incomingurl parameter should match the URL you are publishing that your users will request. For some reason, if after ISA is configured and you do remove this option, you must ensure that the incomingurl parameter matches the address that you configure ISA to forward.

stsadm.exe -o addalternatedomain -urlzone extranet -incomingurl 
https://www.sharepointmvp.com -url https://dmz.sharepointmvp.com

You can also set up the relevant AAM settings through WCAM. In the Operations tab in WCAM, under the Global Configuration group box, select Alternate Access Mappings. In the Alternate Access Mappings screen, you can edit existing URLs for zones and edit the Public zone URLs. When you are in the AAM WCAM interface, select the SharePoint Web application that you are publishing through ISA Server (typically in the Internet or Extranet zone). In this screen, ensure that the public URL that is being published by ISA Server is assigned to the Extranet zone, and add the internal URL (the DMZ URL) that will be used to forward the request. When you are finished, your AAM settings should have two URLs in the Extranet zone: the DMZ URL and the URL that people are using to request the site externally.

Using an Exported SSL Certificate

In an SSL bridging scenario, the ISA Server will sit in front of your SharePoint server, impersonating the SharePoint machine for user requests. For an SSL bridging scenario where packets are decrypted, inspected, and re-encrypted prior to routing, two certificates are required.

The first certificate will essentially impersonate the SharePoint server by using an exported SSL certificate from the SharePoint server or obtaining a properly configured certificate from a public CA. The certificate that sits on ISA should have a Common Name that corresponds to the SharePoint server so that it can intercept the client requests as requests traverse in for the SSL bridging to perform properly. The Common Name on the certificate that is installed on and is being presented by the ISA Server interface should match the FQDN of how people are requesting the SharePoint server. The SSL certificate on the SharePoint server should match the FQDN or IP Address that ISA is using to access the SharePoint server. Usually, when getting this certificate, it is best to procure it from an internal CA, because the ISA machine must be configured to trust the issuing source CA (which, in most organizations with an existing PKI infrastructure, is already configured as such).

Once the certificate is in ISA Firewall’s Machine Certificate Store, you will be able to bind the certificate to a Web Listener, which will be consumed by the Web Publishing Rule responsible for relaying the appropriate SharePoint requests presented to the ISA Server.

Getting the required exported certificate into the ISA Firewall’s Machine Certificate Store is a relatively straightforward task that can be achieved using some of the available Windows Server 2003 embedded wizards.

The first task is to export the certificate from the SharePoint server using the embedded certificate wizard provided with IIS 6.0 in Windows Server 2003. This certificate will be used to decrypt the SSL SharePoint packets that are intercepted from ISA Server. You can easily do this through the IIS Virtual Server Directory Security tab that offers management of the related SSL certificates:

1. From the Directory Services tab for the SharePoint Virtual Server, select View Certificate.

2. In the Certificate window, select the Details tab.

3. Select “Copy to File.”

4. Once the export process has begun, fill in the relevant details.

When exporting the certificate, it is very important to ensure that you are also exporting the private key (Figure 12-3). Otherwise, the SSL bridging configuration will fail. Be sure you note the password that is being used to protect the exported certificate, because this will be required later when adding the certificate to the ISA Firewall’s Machine Certificate Store. Once you have exported the certificate, you will have a new .pfx file that represents your exported certificate.

Figure 12-3: Exporting the private key

Once the certificate has been exported through the certificate wizard, it can be added into the ISA Firewall’s Machine Certificate Store by first bringing up the certificates MMC snap-in. Follow these steps:

1. Bring up the Run dialog by selecting Start  Run. Once the Run dialog box appears, enter MMC and click OK.

2. In the MMC console, select File and click Add/Remove Snap-in.

3. In the Add/Remove Snap-in dialog, click Add.

4. In the Add Standalone Snap-in dialog (Figure 12-4), click Certificates, and click Add.

Figure 12-4: Add Standalone Snap-in dialog

Once the certificates snap-in has been added to MMC, it is possible to import the certificate into the ISA Firewall’s Machine Certificate Store. One of the tasks available in the MMC certificates snap-in is to import a pre-existing certificate into the Certificate Store.

To import the certificate, open the Personal Certificate Store, right-click the Certificates node, and select Import. On the “File to Import” window, browse to the exported certificate, and enter in the relevant password you set previously to import the certificate. Once the certificate is placed within the Personal Certificate Store, it can then be moved to the Trusted Root Certification Authorities by cutting and pasting the certificate from the Personal container to the Trusted Root Certification Authorities container.

Once the certificate is placed within the Trusted Root Certification Authorities Store, the next step is to construct the appropriate Web Publishing Rule that will assimilate the certificate that was just imported into the Trusted Root Certification Authorities Store through the use of a Web Listener. Fortunately, generating these objects to securely publish your SharePoint server can be done with functionality provided by ISA Server through the use of the SharePoint Publishing Rule Wizard.

Creating a Publishing Rule through the SharePoint Publishing Wizard

Creating a Publishing Rule for a SharePoint server has never been easier with the introduction of the SharePoint Publishing Wizard. A Publishing Rule in essence is meant to define whether an allowance or denial rule should be executed when handling attempted user connections. This will become increasingly evident when modifying the properties of the Publishing Rule that the SharePoint Publishing Rule Wizard provisions out through the ISA Management Console. This is because, within the ISA Management Console, there is the option to Allow or Deny connections being established.

1. Open the Microsoft Internet Security and Acceleration Server 2006 management console.

2. Expand Arrays, and expand the relevant SharePoint Array.

3. Select the Firewall Policy node.

4. Select the Tasks tab.

5. Select Publish SharePoint Sites.

6. On the Welcome to the SharePoint Publishing Rule Wizard page (Figure 12-5), enter a friendly name in the rule name textbox.

Figure 12-5: SharePoint Publishing Rule Wizard page

Once the friendly name is entered for the SharePoint rule that you want to create, ISA Server will want to know whether you want to “Publish a single Web site or load balancer,” “Publish a server farm of load balanced Web servers,” or “Publish multiple Web sites.” Which option to choose depends on your SharePoint implementation.

The most frequently used of these is to “Publish a single Web site or load balancer,” because it is common that an organization pushes a single SharePoint portal instance through the ISA firewall. ISA Server does provide facilities for server farms that allow proper load balancing using session affinity or IP affinity, server health status supervision that couples with the related balancing algorithms, and draining of servers so that requests currently handled by a server can continue to be served while future connections are ignored.

For a simple SSL bridging scenario to secure a single SharePoint instance, the first option, “Publish a single Web site or load balancer,” is the option that you should select, as shown in Figure 12-6. Click Next.

On the following window, you must make ISA Server aware of how encryption should happen for the communication layer. Because it is desirable to use SSL bridging to ensure that credentials are never forwarded in clear text (when ISA receives or forwards a request), select “Use SSL to connect to the published Web server or server farm,” as shown in Figure 12-7. Click Next.

On the Internal Publishing Details window (Figure 12-8), you must supply the details for how the internal SharePoint site is going to be resolved through the ISA server proxy (see Figure 12-7). If you are publishing the SharePoint site by using the internal site name, it is best to verify that ISA can resolve this name by doing a simple ECHO request by executing a ping command from the ISA Server machine to the SharePoint machine. Ensure that, if doing an ECHO request, the internal interface is being called from the SharePoint machine as well; otherwise, communication will fail between the two servers. If ISA cannot resolve using the internal name, the “Use a computer name or IP address to connect to the published server” option must be checked. The entries that you place on this page must match the Common Name that is placed on the certificate bound to the SharePoint site on the SharePoint front-end Web server. Click Next.

Figure 12-6: Selecting “Publish a single Web site or load balancer”

Figure 12-7: Selecting “Use SSL to connect to the published Web server or server farm”

Next, you must specify the Public Name Details that the Web Publishing Rule requires to contact the back-end SharePoint server (Figure 12-9). When applying this setting, you are allowed to accept requests for either a specified domain or for any domain. By very careful when selecting the “any domain name” option because this option promotes a low level of security.

Figure 12-8: Internal Publishing Details window

Figure 12-9: Public Name Details window

The reason that this is a very poor security option is that the Web Publishing Rule will accept incoming requests using any IP address or FQDN that can reach the IP address used by the Web listener for the Web Publishing Rule. All requests will be believed to be valid requests, thereby increasing the playing field for attacks. Limiting the requests to a specific domain greatly restricts the names that a user can request against the ISA Server for resolution. It is very important that the friendly name that users use in order to access the SharePoint instance be used in this textbox corresponding to its relevant DNS A record, and that the entry match the Common Name that is appended to the certificate being used. Enter the relevant domain name and click Next.

The next option in the SharePoint Publishing Wizard is to select a Web listener to use with the publishing rule that you are creating. A Web listener is a programmatic asset that essentially provides the relevant network objects (such as IP addresses, port information, and SSL settings) that will listen for requests as they are intercepted by the ISA Server on any number of interfaces. For a SharePoint server, if an extranet implementation is being resolved to www.sharepointmvp.com, then a Web listener is required to translate the relevant IP address and port number to the friendly name www.sharepointmvp.com.

If a Web listener is already defined, you can edit the properties of the listener from this window. If you haven’t previously created a Web listener (as is the current case), you are afforded the option of creating one to correspond to your SharePoint Web Publishing Rule, which will allow the binding of a new Web listener to the certificate you imported.

To create a new Web listener, on the “Welcome to the New Web Listener Wizard” window (Figure 12-10), define a friendly name for the Web listener for systems administrators and architects to use. It is best to put the internal name of the machine that you are publishing in this textbox, along with the port name, supplementing it with any other information that may assist other administrators if they have to perform troubleshooting or leverage the specific Web listener that you are creating.

Figure 12-10: “Welcome to the New Web Listener Wizard” window

Once the Web listener has a friendly name, on the Client Connection Security window (Figure 12-11), ISA needs to know whether the listener requires SSL to communicate with requesting clients. Because a certificate has already been installed on the machine to supplement the listener with this option, check “Require SSL secured connections with clients.” Using the other option of “Do Not Require SSL secured connections with clients” is very atypical, because the external interface will be allowed to establish lines that may transmit plain text, and this is generally only explored when using a uni-homed firewall for branch offices.

On the Web Listener IP Addresses window (Figure 12-12), ISA must be responsive to the requests that should be listened for. Generally, when placing an ISA Server in front of SharePoint, you are facing the external network to the world. Therefore, the External adapter should be selected. If there are specific IPs that should only be listening for requests on the External adapter (which houses multiple IP addresses), you can select the relevant IP addresses for the specific adapter in the Select IP Addresses window.

Figure 12-11: Client Connection Security window

Figure 12-12: Web Listener IP Addresses window

On this same page, remember to keep “ISA Server will compress content sent to clients through this Web Listener if the clients requesting the content support compression” checked, which will allow HTTP compression to work hand-in-hand with the ISA Server cache features. Although the caching features are not discussed here, the inherent ISA caching functions and Content Download Jobs can greatly increase SharePoint speed-to-reception time. If you want both internal and external users to have access to the SharePoint instance, both of the adapters should be selected in this window. Select the relevant adapter and IP addresses, and then click Next.

Because, in the Client Connection Security window (Figure 12-11), SSL was chosen as being required, the certificate to use with the listener must be defined. If the certificate was brought over using the Certificates MMC snap-in, it can be chosen on the Listener SSL Certificates screen by using the Select Certificate button, which will allow the display of all the valid certificates that can be bound to the Web listener being created, and that are currently trusted by the ISA machine. If you specified several IP addresses in the interface chosen in the Web Listener IP Addresses screen (Figure 12-12), you can assign a certificate to each of the IP addresses. The certificate interface is also very useful when inspecting whether any certificate you imported is set for expiration soon, whom it was issued by, if it was installed correctly, and other related metadata. Select the certificate that was imported from the SharePoint server and click Next.

Figure 12-13: Listener SSL Certificates screen

In the Authentication Settings window, you are required to inform ISA of how clients requesting SharePoint content will specify the credentials that ISA Server should use, and how those exact credentials will be validated. A variety of options are available here, including the following:

• HTML Form Authentication

• HTTP Authentication

• SSL Client Certificate Authentication

• No Authentication

There are also a variety of ways to validate the credentials that the client is passing, including the following:

• Active Directory—Used if ISA belongs to a domain

• Active Directory via LDAP—Used if ISA does not belong to the domain, but you want ISA Server to tap into Active Directory

• RADIUS (OTP)—Used if you are using a one-time RADIUS password scheme

• RADIUS—Used for remote RADIUS authentication, most commonly found in use by network appliances

• RSA SecurID—Used if you have the relevant two-factor authentication schemes and hardware tokens

For an extranet environment that will have the logins stored within a medium such as Active Directory, the option to choose would be HTML Form Authentication (not be confused with SharePoint 2007 Forms Based Authentication, which is instead provided by the ASP.NET 2.0 pluggable framework) and Active Directory via LDAP.

By using the HTML Form Authentication option, there are many facets that are provided to you, such as the use of ISA Server Single Sign-On (SSO), not to be confused with SharePoint Single Sign On (SSOSrv) provided by MOSS, which is managed from the Services MMC console. However, authentication credentials are not cached, but rather housed within a temporary cookie.

On public computers, this becomes a concern. However, the option for users to select how they are connecting is provided on the ISA login form. The concept of this cookie (which can be found with an ISA* prefix) becomes important with load balancing for a farm when using a cookie scheme as opposed to source-IP based schemes, because the same server in round-robin load balancing will generally continue serving requests based on the GUID presented by the cookie (so that session affinity is maintained).

On the Single Sign On Settings window (Figure 12-14), select “Enable SSO for Web sites published with this Web listener” option and enter the relevant domain. In the provided example, www.sharepointmvp.com is being published, and therefore the sharepointmvp.com domain must be entered. The listener is then created and appended to the Web Publishing Rule. Click Next.

On the Authentication Delegation window (Figure 12-15), you must tell ISA Server how you would like communication to be authenticated with the back-end server. Table 12-5 shows several options, each of which can be leveraged by an organization, depending on corporate security standards and your SharePoint server needs.

Figure 12-14: Single Sign On Settings window

Figure 12-15: Authentication Delegation window

Table 12-5: Authentication Delegation Routines

Process Name	Process
No delegation, and client cannot authenticate directly	Essentially, this means that no credentials will be forwarded past the ISA Server to the SharePoint server that is being published, so the SharePoint content will not be accessible. Only use this if the SharePoint user base is accessing the ISA Server and not the serving SharePoint machine.
No delegation, but client may authenticate directly	The ISA Server will not forward the credentials to the SharePoint server. However, if the client is prompted for credentials for the Web server, the SharePoint machine can consume them.
Basic authentication	The ISA Server will simply forward the credentials to the SharePoint server using the basic authentication routine. If you are using basic authentication, then you must deploy an SSL bridging scenario, because the credentials will be forwarded in plain text to the back-end SharePoint server, along with whatever content is requested off the SharePoint server in the authentication header.
NTLM authentication	If NTLM is used throughout the corporate environment, the credentials can be forwarded using it, which would introduce domain controller verification, bypassing direct contact between the internal ISA interface and the SharePoint machine. If you are using NTLM for your SharePoint authentication as opposed to Kerberos, this is typically the most-used option.
Negotiate (Kerberos/NTLM)	A negotiation can happen where Kerberos or NTLM is used. This is frequently used when the appropriate IIS Metabase objects mirror the same setting.
Kerberos constrained delegation	If Kerberos is set up in the environment, and the ISA machine has been trusted for delegation of credentials (similar to how the SharePoint machine was set up previously for delegation of credentials through the Active Directory MMC), then a user certificate can be presented to authenticate to the SharePoint machine. Optimally, this is the most secure setting. However, it is more complex to set up, because it involves Kerberos authentication.

Given that SSL bridging is being used to authenticate to the SharePoint server, you can simply use basic authentication because the risk of tampering with the communication lines are rather low with an encrypted transmission. The most secure method is generally the use of Kerberos authentication, but, as mentioned, this requires extra configuration. When not using SSL for security, the most common setting is to “No delegation, and client cannot authenticate directly.” Select “Basic authentication” because SSL is being used. Click Next.

On the ensuing Alternate Access Mapping Configuration window (Figure 12-16), you must tell ISA Server whether AAM has already been set up. This was previously accomplished through the use of the STSADM commands addalternatedomain and addzonemap or the WCAM Alternate Access Mappings Web interface. Therefore, select “SharePoint AAM is already configured on the SharePoint server.” Because of how ISA will forward name requests, the appropriate entries must be added in the extranet URL list. Click Next.

On the User Sets page (Figure 12-17), you see the option to bind the rule that is being created to a specific user set. If there are groups that were previously created in Active Directory, you can produce custom groups to add into the user sets to provide a more granular, applied rule for access requests. If this isn’t a particular concern, and you want to simply apply the rule to all users who are passing through the ISA Server, you can just accept the default rule of All Authenticated Users. Select All Authenticated Users and the click Next.

Figure 12-16: Alternate Access Mapping Configuration window

Figure 12-17: User Sets page

The last page on the SharePoint Publishing Rule Wizard is the “Completing the New SharePoint Publishing Rule Wizard” window, which allows confirmation of the edits made through the entire wizard process. If everything is acceptable, click Finish. You will notice that the new SharePoint publishing rule pointing to your SharePoint server is then available under the Firewall Policy Rules repeater within the ISA Server Management Console. To manage the new Publishing Rule, you can bring up the properties of it by right-clicking it and selecting Properties.

Because the additions haven’t been committed to the ISA array, you must select Apply in the upper portion of the ISA Management Console for the relevant changes to take effect. Afterward, the SharePoint publishing configuration can be tested to see if other adjustments to ISA Server are necessary, based on your network configuration.

ISA and Link Translation

One of the principal benefits of using ISA Server in front of SharePoint is the option for link translation. Link translation in ISA Server is facilitated through the use of a filter, known as the Link Translation Filter (LTF), which is essentially an orthodox ISA firewall Web Filter. When you are facing a SharePoint environment externally in a proxy-based Web publishing scenario, oftentimes your sensitive machine names, absolute URLs, or non-standard port assignments commonly become available to your external users (which is mutually puzzling to your users and non-functional from an operational standpoint). This is frequently found in environments that begin to assimilate content from file shares and orphaned Line of Business systems into SharePoint (particularly evident within returned SharePoint search results in the Core Search Results Web Part provisioned in the SharePoint Search Center).

Link translation rides on a Web Publishing Rule, and, when the LTF is implemented, a default dictionary that will take care of HTTP to HTTPS, obscure port, and computer name translation is also provisioned. The first of these is particularly important, because, when using a SSL connection to SharePoint, all subsequent interactions from the user must follow the SSL protocol. Therefore, by default, in the link translation dictionary, the required HTTP to HTTPS entries are provided when one of your users initiates a connection with SSL. All subsequent requests will follow the HTTPS protocol maintained even when your SSL connections use a non-standard port designation.

If the default dictionary does not contain the required entries to properly facilitate your required link translation, or you find skews in the links being translated, it is possible to add custom dictionary entries to granularize how link translation occurs by appending explicit entries.

This is a powerful option to exploit when, after viewing the effective link translation rules that ISA provisions, there are still antiquated links not being parsed correctly at any point throughout the environment.

Because the link translation occurs on a Web Publishing Rule basis, modifying it is done through the properties of the Web Publishing Rule.

1. Select the relevant Web Publishing Rule and select the Tasks tab, which allows the option to Edit Selected Rule.

2. On the Link Translation tab, select “Apply link translation to this rule.”

3. Select Configure and click the Add option.

4. In the Locally Defined Mappings dialog box (Figure 12-18), enter in the “Replace this text” entry the name of the string you want replaced in returned links, which corresponds to the explicit string that was erroneous before. Enter the value you want to replace the string in the “With this text” entry.

5. Click OK.

If, at some point, you want to verify the Global Site Mappings that have been implemented on the ISA machine, you can use the configuration box to build out a friendly report for records management purposes. This can be done by expanding the Configuration node and, under the General tab, selecting Global Link Translation. Because each array will maintain a store of the URLs that are being translated through within a relevant Web Publishing Rule, under the Global Mappings tab, all of the implicit and explicit dictionary entries can be examined, as shown in Figure 12-19. Because various arrays can exist throughout an enterprise that is using ISA Server, you should be aware that link translation can be spread across all arrays. Therefore, arrays can share link translation information in order to maintain conformity across ISA Server farms.

Figure 12-18: Locally Defined Mappings dialog box

Figure 12-19: Implicit and explicit dictionary entries

Creating Connection Verification for SharePoint Server Health Monitoring

Within ISA Server, you can constantly validate the connections being established between a SharePoint site and the internal ISA interface to gauge your relevant uptime, and to ensure that your required SharePoint content is available to users. This is done through an ISA asset called connectivity verifiers, which will allow a variety of protocols to be used to verify connectivity. The following three connectivity verifiers are provided by default:

• Internet Control Message Protocol (ICMP) ECHO_REQUEST (Ping)

• TCP connection attempts

• HTTP GETs

Also available are varieties of groups that you can place a SharePoint connectivity verifier in (such as DNS, DHCP, and Active Directory) in order to organize the connectivity verifiers that you create.

The first step for you to establish the monitoring of connectivity is to create the actual connectivity verifier. Because this is considered in the ISA Management Console as a Monitoring Activity (because you are monitoring the SharePoint server health), select the Monitoring node. Once you are in the Monitoring interface, select the Connectivity tab and under the Tasks tab, select Create New Connectivity Verifier. When creating a new verifier, the SharePoint site must be presented as an argument. In the address textbox on the Connectivity Verification Details window, place the FQDN of the SharePoint site, because the verifier will exist to service the internal interface, as shown in Figure 12-20.

For this connectivity verifier, you are simply going to check whether the ISA Server sees the SharePoint instance as alive. This can be done by simply using an ECHO request. In the method used to verify the connection, select “Send a Ping request,” and select the “Web (Internet)” group. If you would like to specify a time-out value to use, you can specify that count in milliseconds, and ISA can optionally send you an alert when this threshold is met. The connectivity verifier will generally run every 30 seconds while sending the request, and will wait for 5 additional seconds before responding by directing requests to a subsequent machine (based on the load-balancing algorithm).

Figure 12-20: Connectivity Verification Details window

When creating a connectivity verifier that conflicts in communication with a publishing rule, you will be informed that a new rule must be created in order for the ISA interface to send the request. By doing this, there will be the creation of a system policy rule that must be enabled for the connectivity verifier to function correctly. Click the Apply button in the ISA Server Management Console, as shown in Figure 12-21.

Figure 12-21: Clicking the Apply button in the ISA Server Management Console

After the connectivity rule has been implemented, there are a variety of interactions that can be performed with it. It is possible to modify, disable, delete, import, or export connectivity verifiers from this window in the ISA Server Management Console. In the monitoring dashboard view, the connectivity verifier will show relevant metrics in the Status column in order to report if something wrong does occur.

Managing ISA through Scripts

Though it is feasible for you to manage and administer an ISA instance providing SharePoint through the use of the ISA Management Console, in the spirit of creating reusable assets to use throughout your environment, it is sometimes helpful to instead place ISA routines within reclaimable scripts and applications. Besides automating repetitive, dull administrative tasks, you can position frequently called, difficult, complex tasks into scripts that allow you quick execution of assignments that would otherwise prove to be complicated and lengthy.

The ISA Server Administration Object Model allows quick programmatic access to the necessary ISA objects that can be used to vastly extend and ease the available ISA administration options, automating tasks that would otherwise prove to be very complicated to reproduce and execute several times. Several of the objects are even SharePoint-specific, such as the FpcPublishedServerApplication enumerated type (which contains a Publishing Rule flag for a SharePoint) and the AlternateAccessMappingConfigured property (to help to determine whether AAM is configured for a SharePoint server, which as demonstrated previously is important to ISA Server configuration when securely publishing SharePoint).

By using the Component Object Model (COM) objects, it is possible to tap into and control any other ISA Server arrays that may affect your SharePoint environment. Typically, ISA administration scripts are written in Visual Basic Scripting Edition (VBScript), because they can quickly be constructed within Notepad. However, you can also use a variety of languages such as Visual C++ or Microsoft Visual Basic (VB) to complete the same types of tasks within familiar development environments such as Microsoft Visual Studio .NET. Later in this chapter, you will see how to use a managed language (VB.NET) to perform tasks against the ISA Server as well to build client applications.

To use scripts to make any changes to ISA Server, you must first tap into the root FPC object, which will allow you the use of children FPC objects that are in the remaining object hierarchy. Before doing any pertinent scripting logic, you must create and set the root object. Because the script being developed is using VBScript, you can create the root object by using the CreateObject method. Once the root object is created, you can subsequently tap into the ISA Server Object Model. For example, you could perform something as simple as getting the current ISA Server Name by using the GetContainingServer method, as shown here:

Function ReturnTheIsaServerName()
    Dim FPCobject   
    Set FPCobject = CreateObject("FPC.Root")
    GetIsaServerName = FPCobject.GetContainingServer.Name
End Function

Then, you could push the output from the function using WScript with an Echo method and calling the function name, as shown here:

WScript.Echo ReturnTheIsaServerName()

To further understand how you can utilize VBScript to automate generally repetitive, complex tasks for an ISA instance, consider one of the most common tasks that you may perform if you are responsible for maintaining the ISA environment: modifying existing rules that are associated with your SharePoint environment (either by enabling ones that are already created, or disabling ones that are currently in effect).

For example, an experimental ISA environment may experience frequent problems with an implemented Web Publishing Rule preventing access to your SharePoint environment. Because it is a development environment, a batch file to repeatedly execute rule management would be preferred over manual intervention, since adding a rule string into a script is much quicker than having to navigate through the ISA Management Console interface.

When you are creating more complicated scripts (such as one that taps into rule functionality), it is best to first test whether the object has already been created (as opposed to just directly creating the root object). Then, if the object hasn’t been created, you can subsequently create and set the root object for tapping into other ISA children objects.

Set FPCobject = CreateObject("FPC.Root")
If Not IsObject(FPCobject) Then Set FPCobject = CreateObject("FPC.Root")

Once you have created the root object, you can begin to do more relevant ISA actions. When you are working with Web Publishing Rules, you must pass in a string parameter into the function specifying the rule name—in this example, RuleNamestring. Then, you can use the FPCPolicyRules collection to get the related rule name before activating or deactivating the rule.

Set PolicyRuleobject = 
FPCobject.GetContainingArray.ArrayPolicy.PolicyRules.Item(RuleNamestring)

The FPCPolicyRule object has a property that allows the setting of whether or not a rule is enabled. You can use this to test whether a rule is currently enabled, and the stringAction parameter can be used to either enable or disable the relevant rule.

If Left(LCase(Actionstring),1) = "e" Then Stateboolean = True Else 
Stateboolean = False
If PolicyRuleobject.Enabled = Stateboolean Then EnableorDisable = True
Exit Function
PolicyRuleobject.Enabled = Stateboolean
PolicyRuleobject.Save

Although managing Web Publishing Rules is a powerful option to use through scripts, a variety of other ISA administration objects can be tapped into to construct powerful administrative scripts. Let’s consider another example.

ISA Server plays very heavily into subnets using private network IDs, and you can also manage subnets through the use of scripts by using FPCRuleElements, which has a Subnets property that allows the return of all the subnets within the ISA network or array.

For example, because the Subnets property allows the return of a collection of all subnets that are defined in an array, by declaring the root FPC object, the array, and the FPCsubnet object and collection, you could accomplish something such as simply displaying a list of subnets that are available on a specific ISA array, as shown here:

Dim FPCobject
Dim IsaArrayobject
Dim Subnetscollection
Dim Subnetobject   
Set FPCobject = CreateObject("FPC.Root")
Set IsaArrayobject = FPCobject.GetContainingArray
Set Subnetscollection = IsaArrayobject.RuleElements.Subnets

Once Subnetscollection has the appropriate values, you can loop through the returned values by using a For Each loop on each Subnetobject in the Subnetscollection and parse out the variable subnets within a window using WScript. You can extend this concept further for tasks such as adding or deleting a specific subnet on an array.

Deleting a subnet can be accomplished by declaring a new DeletePassedSubnet() function and passing in the subnet parameter. You can then use the Remove() method out of the FPCSubnets collection to delete the specified subnet.

Function DeletePassedSubnet(SubnetNamestring)
    Dim FPCobject
    Dim IsaArrayobject
    Dim Subnetscollection
    Set FPCobject = CreateObject("FPC.Root")
    Set IsaArrayobject = FPCobject.GetContainingArray
    Set Subnetscollection = IsaArrayobject.RuleElements.Subnets
    Subnetscollection.Remove(SubnetNamestring)
    Subnetscollection.Save    
End Function

You could also delete all the relevant subnets by introducing a For Each loop with the Remove() method.

For Each Subnetobject In Subnetscollection
        Subnetscollection.Remove(Subnetobject.Name)        
    Next

Using a Managed Language with ISA Server Development

If you are a .NET developer you may find the use of scripts to be rather frustrating, because they are often constructed in text editors that don’t offer the rich feature set of the Visual Studio integrated development environment (IDE). It is possible, however, to use managed .NET code against an ISA array to perform intuitive administration and management tasks. You will find this option to be very useful when writing WinForm client applications that provide functions like reporting and monitoring your ISA instance.

The main thing you must do when setting up your Visual Studio project is reference the FPClib object, because it provides all the methods of interaction that are required to interact with ISA Server. The FPClib object is located on your ISA Server in msfpccom.dll in C:\Program Files\Microsoft ISA Server\. Once this reference has been made, you can call the FPClib object by creating an imports directive for FPClib at the top of the relevant class file. Because most of the frequently created code for ISA Server at this level is in Visual C++ or Visual Basic for Applications (VBA), the following code examples are provided in VB.NET. Therefore, the similarities to those provided in the previous discussion on scripting should be relatively consistent.

Previously, you learned how to programmatically work with the rules that ISA Server is using to control access to the SharePoint server. This same type of functionality can be achieved in VB.NET. Most of the methods being called are very similar to those that were introduced in VBScript. By implementing such code, this method (frequently placed in a WinForms custom management console or Console Application) would be able to provide the capability to quickly add access rules to the ISA array by binding it as an event handler to something such as a button control.

The overall strategy can be accomplished by using the FPCPolicyRules collection and the AddAccessRule method to create a new FPCPolicyRule object, which will allow the creation of the relevant access rule. By doing a complex task such as adding an access rule, different concepts are introduced that would otherwise require user interaction to harvest the relevant information (such as using the AccessProperties and SourceSelectionIPs properties of the IFPCPolicyRule object to supply the necessary metadata to create the new rule). These don’t necessarily have to be set to static values, however. They can be expanded to include user-entered information.

You can see that these set properties are being applied to the rule because the FpcIncludeStatus enumerated type is being set to fpcinclude so that the reference is established. The FpcPolicyRuleActions enumerated type is being used to say that the rule that is being created is going to deny the request (because rules, as discussed earlier, will either allow or deny access to the relevant SharePoint resources) by using the fpcPolicyActionDeny property.

Dim array As FPCArray
Dim fpcob As FPC = New FPCClass
Dim rules As FPCPolicyRules = array.ArrayPolicy.PolicyRules
Dim rule As FPCPolicyRule = rules.AddAccessRule()                    
rule.AccessProperties.DestinationDomainNameSets.Add(Conversions.ToString(),
FpcIncludeStatus.fpcInclude)
rule.AccessProperties.UserSets.Add("All Users", FpcIncludeStatus.fpcInclude)
rule.SourceSelectionIPs.Networks.Add("Internal", FpcIncludeStatus.fpcInclude)
rule.Action = FpcPolicyRuleActions.fpcPolicyRuleActionDeny
rule.Enabled = True
rules.Save(False, -1)

Along the same lines, you can add or modify other ISA network objects. For example, you could select a domain set by using the DomainNameSets property to get a FPCDomainNameSets collection, and use the Add() method to add a select domain set. This is a powerful option if the network that ISA is riding upon is frequently changing and subject to domain shifts.

Dim array As FPCArray
Dim fpcobj As FPC = New FPCClass
Dim rules As FPCPolicyRules = array.ArrayPolicy.PolicyRules
Dim sets As FPCDomainNameSets = array.RuleElements.DomainNameSets
Dim num As Integer = sets.Count
sets.Add()
sets.Save(False, -1)
sets.Refresh()

By introducing managed code into your ISA Server development environment you can greatly extend the possibilities when quickly developing client ISA tools to manage the overall SharePoint security infrastructure using a development environment that is familiar to .NET developers. Developers can interact with a development environment that they are familiar with, and tap into the ISA Administrative Object Model to quickly construct powerful methods to automate and extend the overall functionality of ISA.

Summary

The sphere of concepts that SharePoint security entails are exceptionally expansive. Starting at the foundational communication layer and extending to construction of intuitive and insightful applications and scripts that facilitate analysis, reporting, and managing security objects, there are several security considerations for you to take into account. Furthermore, because the realm of SharePoint security extends to all parties involved in your SharePoint environment (from system architects who will set up communication and architecture security, to the developer who is responsible for building both secure applications and security-related tools), each piece of your organization plays an intrinsic role in the overall security program.

A majority of the tools that are required for an appropriate implementation of SharePoint security are built directly into SharePoint, or into the Windows Server 2003 platform. Communication-layer concepts such as IPSec for inter-server communication and SSL for providing client-line security don’t require the introduction of sister server platforms into the environment. To enhance security of SharePoint with more enhanced security attributes, using software appliances such as ISA Server allow the use of advanced security concepts (such as secure Web application publishing) and provide stateful packet inspection of SharePoint traffic.

The security concepts introduced in this chapter can promote a high level of reusability through the use of scripts, batch files, or managed code. Through proper exploitation of things such as the ISA Administrative Object Model, advanced management functionality can be procured, which will vastly enhance the security options that are available for an arbitrary organization, and will ultimately lead to a collaboration environment that people can trust.