Configuring Servers for Secure Mobile Access to SharePoint Data

After the design phase is over and the servers have been deployed into their respective places on the physical network, it is time to configure the servers to support the delivery of SharePoint data to mobile employees. Much as the design phase takes planning and consideration, the configuration phase requires careful considerations. Moving into implementation, you will need to answer questions such as:

• Do I have a single SharePoint site? Or an entire server farm?

• Is my SharePoint data accessed internally and externally?

• Do I need to use HTTPS? If so, do I have the appropriate certificates?

• What is the server information that we need to publish: IP address? Full qualified domain name (FQDN)?

• What type of authentication do I require? LDAP? Forms-based? Basic? None?

Having the answers to each of these questions will make the ISA configuration wizard much easier and will help ensure a smooth deployment. Since SharePoint is a Web-based service provided to the end user, it is most common to see users accessing information using fully qualified domain names like http://intranet.contoso.com. Alternate Access Mapping (AAM) is a feature of Windows SharePoint Services 3.0 (and thus Office SharePoint Server 2007) that provides users of multiple domains and even multiple networks to access the same set of content using unique URLs. SharePoint identifies the source of a request and matches that to a defined network (URL). This allows SharePoint to return a URL consistent to the FQDN provided by the user. For example, an external user referencing content from the URL http://companyweb.contoso.com should not receive a return URL of http://intranet.contoso.com. SharePoint uses zones as a means of managing URLs and authentication providers when accessing the same content from different networks. Figure 19-7 illustrates the use of alternate access mappings for SharePoint data.

Figure 19-7: Example of alternate access mappings for SharePoint

The configuration in the diagram would allow users to access the content from multiple URLs including:

• http://moss01.contoso.com individual server name, defined on the Intranet zone

• http://moss02.contoso.com individual server name, defined on the Intranet zone

• http://moss03.contoso.com individual server name, defined on the Intranet zone

• http://intranet.contoso.com NLB cluster name for farm, defined on the Intranet zone

• http://companyweb.contoso.com Alternate Access Mapping to reference the NLB farm, defined on the Internet zone

When the SharePoint server receives a request for http://intranet.contoso.com, it assumes that the request is coming from a computer that is on the Intranet zone and will return the same URL. When the server receives a request for http://extranet.contoso.com, it assumes that the request is coming from the Internet zone and will return the same URL.

Note 

To support the scenario provided, DNS records would need to be created accordingly. The records for each server will most likely exist by default as a result of DNS Dynamic Update. The required Host (A) records for the intranet and company Web host names should be created manually.

Alternate Access Mappings are configured from the Global Configuration section of the Operations page in SharePoint 3.0 Central Administration, shown in Figure 19-8.

Figure 19-8: Alternate Access Mappings link in Central Administration

All currently configured URLs are listed on the Alternate Access Mapping page, as shown in Figure 19-9.

Figure 19-9: Alternate Access Mappings in SharePoint

New mappings can be defined by providing a URL and the appropriate security zone for the URL. The zone chosen is dependent upon the level of security required for the delivery of the data. In situations where information should be delivered to the requesting general public as part an Internet accessible site, the Internet zone would be best if Anonymous authentication is enabled. For scenarios where company employees need access to the data that perhaps is still the Internet zone but with a stronger security, a mechanism like Windows Integrated authentication would be in order.

With the Alternate Access Mapping in place, it will be possible for external user to access data using the http://companyweb.contoso.com URL. SharePoint is configured by default to allow mobile device access to the content using the http://companyweb.contoso.com/m URL (shown in Figure 19-9). Using the /m at the end of the URL identifies to SharePoint to return the less graphically intensive version of a SharePoint site.

Figure 19-10: SharePoint mobile URL with the /m switch

Since we are dealing here with providing access to external users, it is critical that we consider the need for the encryption of traffic for connections between external mobile users and the SharePoint server. To configure SSL for the SharePoint site is similar to enabling SSL for any other Web site. A certificate must be obtained and installed on the SharePoint server. The certificate installed on the SharePoint server, and inevitably on the ISA server, can be obtained from either a certification authority (CA) on an existing internal Public Key Infrastructure (PKI) or it can be obtained from a publicly trusted certification authority. There will be some extra work involved to use an internal PKI as the devices running Windows Mobile will need to establish trust to the internal root server. On the other hand, there will be some extra money involved if a certificate is obtained from a publicly trusted PKI.

As shown in Figure 19-11, ISA supports two types of SSL deployments: SSL tunneling and SSL bridging. ISA server configured to perform SSL tunneling simply passes HTTPS information through to the Web front-end server itself. SSL bridging allows ISA to perform a stateful inspection of the traffic because the traffic is decrypted at the ISA server and re-encrypted as ISA makes the request to the SharePoint server.

Figure 19-11: ISA Server 2006 and SSL tunneling

To configure the more secure SSL bridging option, two certificates are required. One certificate will be installed on the SharePoint server and one certificate on the ISA server. The certificate installed on the SharePoint server should have a common name equal to that of the server (for example, moss1.contoso.com). The second certificate will be installed on the ISA server and should have a common name that reflects the name of the site that users are connecting to (for example, companyweb.contoso.com). It is best practice to obtain the Web server certificate used on the ISA server from a trusted public certification authority since this is the server that users will directly query. Using a public certification authority prevents errors or warnings on the client system. For each URL that is accessed using SSL, you'll need a separate certificate installed on the ISA server and another certificate installed on the SharePoint server. The certificate stored on the SharePoint server can be obtained from an internal certification authority if one exists. However, the ISA server needs to be configured to trust the root certificate for the PKI that issued the Web server certificate to the SharePoint server.

Before purchasing a certificate from a public certification authority, review the list of certificates in the Trusted Root Certification Authorities on the mobile devices, shown in Figure 19-12.

Figure 19-12: Trusted CAs on a mobile device

Once the certificates are in place, the ISA server can be configured with a Web listener and a publishing rule. A Web listener, as its name suggests, is an object that is created to specify a specific IP address and port to listen on. In addition, it defines the SSL requirements and the authentication mechanisms available to requesting clients that meet the outlined criteria. Web listeners can be created from the ISA toolbox.

Note 

Web listeners can be created during the Web Publishing wizard as well.

For providing access to SharePoint data, you will need to perform the follow steps to create a Web listener:

1. Configure the Web listener to use the Require SSL Secured Connection With Clients option, as shown in Figure 19-13.

2. Assign an IP address to the Web listener. You can assign the entire pool of addresses from the External network or you can specify an individual IP address, as shown in Figure 19-14. If a single IP address is specified, you can provide unique certificates for each IP address.

3. Select an authentication mechanism for the Web listener. Figure 19-15 shows a typical configuration for Web listener authentication when publishing SharePoint data through ISA.

Figure 19-13: Illustration of the three available authentication methods

Figure 19-14: Configuring Web listeners for a specific network

Figure 19-15: Selecting an authentication mechanism

The HTML Form Authentication option shown here will allow ISA to present a default HTML form to request authentication credentials. Clients could also provide credentials to ISA via SSL client certificates or they can use HTTP authentication types of Basic, Digest, or Windows Integrated. For situations in which no authentication is required, the Web listener can be set to allow no authentication.

Validating credentials involves determining how ISA will check the credentials provided through one of the methods mentioned in the previous paragraph. ISA provides several options including:

q	Windows (Active Directory) Validates credentials against a Windows Active Directory domain. The ISA server must be a member of the domain.
q	LDAP (Active Directory) Validates credentials against a Windows Active Directory domain. However, the ISA server does not have to be a member of the domain.
q	RADIUS ISA can be configured as a RADIUS client that redirects requests to any RADIUS server specified.
q	RADIUS OTP A RADIUS solution where password changes occur based on time or an authentication request counter, thereby a creating one-time-password (OTP).
q	RSA SecurID An integration with the RSA SecurID authentication technology.

Choosing authentication servers is required when the authentication type that is selected requires validation against another server. Figure 19-16 shows the selection of validation servers for the LDAP (Active Directory) authentication method selected in the previous step.

Figure 19-16: Selecting the LDAP authentication method

Using Active Directory, RADIUS, or RSA SecurID will all require the configuration of the back-end servers that will perform the validation of the user credentials.

Once the Web listener is created, a publishing rule can be configured. The publishing rule, as noted earlier, is the core component to making resources available to the external network. Figure 19-17 shows the ISA Tasks option for easily instantiating a wizard to walk through the publishing of a SharePoint site.

Figure 19-17: ISA Tasks options

The Publish SharePoint Sites wizard involves several steps in which you specify much of the existing configuration and how it is going to be referenced by external requests. Once you have provided a name for the new publishing rule, you will need to provide information on the infrastructure that is being published. Figure 19-18 shows the options available at the beginning of the wizard.

Figure 19-18: Publishing Wizard options

Creating the Web listener establishes the connection type that should exist between the ISA server and the clients. In our example above, we chose to use a secure SSL connection between Web listener and clients. Remember that the certificate with a common name for the Web site was added during the creation of the Web listener. This was to ensure the security of the data transmitted between the ISA server and the external client systems. However, the wizard that is used to publish the SharePoint site establishes the connection type that should exist between the ISA server and the SharePoint server hosting the site. Figure 19-19 displays the two options available for the connection type between the ISA server and the SharePoint server.

Figure 19-19: Server Connection Security page in the New SharePoint Publishing Rule Wizard

Using the SSL option to secure communication between the ISA server and the SharePoint server requires a certificate to be installed on the SharePoint server and that the ISA server trust the root CA that issued the certificate. If there are multiple SharePoint servers in a farm that is being published, the certificate must be installed on each server in the farm. It is not uncommon to use an internal Public Key Infrastructure to issue a certificate to the SharePoint server or servers. However, if this is the case, the ISA server will not have a native trust for this certificate. The ISA server will need to have the root CA certificate imported into the list of Trusted Root Certification Authorities. In a normal Internet scenario, if there is a lack of trust for a certificate, then the end user is prompted to accept the lack of trust and proceed with the request. Since this side of the publishing scenario involves two servers and no end users, there is no opportunity to accept the lack of trust. Therefore, the ISA server must be configured to trust the certificate.

Some network engineers might argue that using SSL for the communication between the ISA server and the SharePoint server is not even required. The argument for this case being that the communication between these two computers happens on a portion of the network that is not as vulnerable to attack. In situations where the ISA server is an edge firewall, a multi-homed, or the back-end firewall of a back-to-back scenario, the communication with the SharePoint server all takes place over the internal corporate network. Therefore the need to use SSL to encrypt data is not as significant unless you are in a highly secured environment. The decision to make between using HTTPS or HTTP for the ISA server is based solely on the desire for additional security since the performance hit on the Web front-end SharePoint servers is not significant.

The next step in the wizard, shown in Figure 19-20, is to provide information on the location of the internal site that needs to be proxied by the ISA server. There are a couple of important things to consider as you provide this information. The name of the internal Web site must match the common name on the certificate that was installed, if using HTTPS communication between the ISA server and the SharePoint server. The ISA server must be able to resolve the name of the internal Web site. This presents a problem in scenarios where the ISA server is not a member of the Active Directory domain and is not configured to use an internal DNS server. The wizard provides an additional text box to enter a computer name or IP address that the ISA server will be able to resolve.

Figure 19-20: Internal Publishing Details page of the New SharePoint Publishing Rule Wizard

For security measures, it is most common not to include the ISA server in the Active Directory domain unless it is the back-end firewall in a back-to-back firewall scenario. Therefore it is important to specify the IP address of the internal SharePoint server that hosts the Web site.

Publishing a Web site by using ISA allows for the defining of the name of the public site that users type, as shown in Figure 19-21. An IP address can also be used, however, this is common only when name resolution methods are not available for a period of time or when testing the publishing of a site. The name that is specified must be resolvable on the Internet by having a Host (A) record created in the DNS zone database that is authoritative for your external domain.

Figure 19-21: Public Name Details page of the New SharePoint Site Publishing Wizard

Next in the Publish SharePoint Site wizard is the configuration of the appropriate Web listener. Figure 19-22 shows the option for choosing an existing Web listener or creating a new one. Remember that a Web listener defines where the ISA server is listening and how authentication occurs.

Figure 19-22: Select Web Listener page in the New SharePoint Publishing Rule Wizard

Since the ISA server needs to establish a connection to the internal SharePoint server, an authentication method must be configured, shown in Figure 19-23. The easiest selection to make for authentication of the ISA server to the SharePoint server is the option for NTLM authentication. NT LAN Manager authentication, or NTLM, is supported by all systems that are Windows Server 2003 operating systems and even some earlier versions of Windows. NTLM is used, in particular, to provide authentication between two Windows Server 2003 servers that are not part of the same domain. As we have noted on several occasions, here it is common to find that the ISA server is not, in fact, part of the Active Directory domain. It is more often a stand-alone server that belongs to a workgroup.

Figure 19-23: Authentication Delegation page in the New SharePoint Site Publishing Wizard

The ISA server needs to be configured to authenticate the client to the SharePoint server in order to retrieve content for the requesting user. The wizard provides several other options including:

• No Delegation, And Client Cannot Authenticate Directly

• No Delegation, But Client Can Authenticate Directly

• Basic Authentication

• Negotiate (Kerberos/NTLM)

• Kerberos Constrained Delegation

If the ISA server were a member of the internal Active Directory domain, it would be possible to select and configure the options that deal with Kerberos authentication. Using Kerberos for authentication requires some additional configuration steps. A service principal name (SPN) must be created to be used by the ISA server for the Kerberos authentication process. The Web server must be configured to accept Kerberos authentication and be configured to use Integrated Windows authentication in Internet Information Services (IIS).

The Kerberos Constrained Delegation option also requires that the ISA server be trusted for delegation. The Negotiate (Kerberos/NTLM) authentication option will try to use Kerberos as the first authentication method but will fall back to NTLM if and when the Kerberos authentication attempt fails.

As a true sign that this wizard is for SharePoint and not just any Web site, the next step in the wizard, shown in Figure 19-24, requires the acknowledgement that Alternate Access Mappings have been configured on the SharePoint server. Remember that Alternate Access Mappings allow the SharePoint site to be referenced by using multiple URLs.

Figure 19-24: Alternate Access Mappings in the New SharePoint Site Publishing Wizard

The integration of ISA Server with SharePoint is undisputed when the a new wizard exists and that wizard request information particular to the SharePoint deployment.

The final step in publishing a SharePoint site to the Internet is to define the user set that this rule is applied to. Any SharePoint group can be added and removed at will. For situations in which all users should not have access to the published data, user-created groups can be used.

Note 

Any changes to the ISA Server 2006 firewall policy or the system policy requires you to click the Apply button to complete the changes.

After completing the Publish SharePoint Site Wizard, the rule will be displayed in the Firewall Policy list.