Configuring Microsoft Office Live Communications Server 2003 Standard Edition, with ISA Server 2004

The Microsoft® Office Live Communications Server 2003 Standard Edition is a real-time, enterprise communications server. It provides an extensible platform to deliver presence capabilities and instant messaging to connect people, information, and processes to enable better decisions faster without the constraints of geography or time zones.

Microsoft Internet Security and Acceleration (ISA) Server 2004 is the advanced application-layer firewall, virtual private network (VPN), and Web cache solution that enables customers to easily maximize existing information technology (IT) investments by improving network security and performance. ISA Server 2004 provides advanced protection, ease of use, and fast and secure access for all types of networks.

Although it is expected that most outside clients will connect over a virtual private network (VPN) to gain access to a computer running Live Communications Server, a VPN might not be available or practical for some deployments.

This document details an alternative to using VPN and describes how Live Communications Server can be deployed to enable outside users to connect using Transport Layer Security (TLS) securely through ISA Server. When properly configured, users will have access to presence and instant messaging from the public network. This document introduces a new server role, the Live Communications Server Proxy, that is deployed in the corporate perimeter network (also known as DMZ, demilitarized zone, and screened subnet) to enable this scenario.

Server Publishing in ISA Server

ISA Server uses server publishing to process incoming requests to internal servers, such as File Transfer Protocol (FTP) servers, Structured Query Language (SQL) servers, Live Communications Server computers, and others. Requests are forwarded downstream to an internal server, located behind the ISA Server computer.

Server publishing allows virtually any computer on your Internal network to publish to the Internet. Security is not compromised because all incoming requests and outgoing responses pass through ISA Server. When a server is published by an ISA Server computer, the IP addresses that are published are actually the IP addresses of the ISA Server computer. Users who request objects assume that they are communicating with the ISA Server computer—whose name or IP address they specify when requesting the object—while they are actually requesting the information from the publishing server. This is true when the network on which the published server is located has a network address translation (NAT) relationship from the network on which the clients accessing the published server are located. When you configure a routed network relationship, the clients use the actual IP address of the published server to access it.

Server publishing rules determine how server publishing functions, essentially filtering all incoming and outgoing requests through the ISA Server computer. Server publishing rules map incoming requests to the appropriate servers behind the ISA Server computer. These rules will grant access dynamically, as specified, from Internet users to the specific publishing server.

The published server is a SecureNAT client. Therefore, no special configuration of the published server is required after you create the server publishing rule on the ISA Server computer. Note that ISA Server must be configured as the default gateway on the published server.

Note

When you use ISA Server 2004 with Live Communications Server, only presence and instant messaging will be enabled for outside users. Scenarios involving features such as audio and video, data collaboration, and file transfer are not supported.This document primarily describes a deployment of multiple Live Communications Server computers, a Live Communications Server Proxy, and a back-to-back ISA Server configuration. If you have installed a single Live Communications Server computer and have a single ISA Server computer between it and the Internet, you can publish the Live Communications Server to the Internet following the procedures in Configuring the Internal ISA Server Computer.

Deployment Considerations

This section presents some of the aspects the information technology (IT) administrator should consider before enabling the outside user scenario.

Note

To ensure you have the latest information about Live Communications Server 2003, download the most recent version of the “Live Communications Server 2003 Document: Release Notes” (https://go.microsoft.com/fwlink/?linkid=20547).

Existing Applications

The scenarios presented in this document rely on the deployment of a Live Communications Server Proxy. Deployment of that proxy affects the way session initiation protocol (SIP) messages are routed in your deployment. This in turn may impact applications you have deployed on computers running Live Communications Server.

Before enabling the scenarios presented in this document, carefully read the section Impact on Existing Applications later in this document.

Configuring Automatic Clients

In automatic configuration mode, the client queries the DNS to locate a Live Communications Server computer. To have outside clients automatically connect to the corporate Live Communications Server computer over TLS, publish the DNS SRV records into the public namespace.

If you choose to not use automatic configuration, the client must be manually configured to communicate with any given server.

Authenticating Clients

The first Live Communications Server front-end server or home server (HS) that outside clients connect to must be configured for NTLM authentication only. Kerberos authentication is not available for outside user scenarios as described in this document because the Key Distribution Center (KDC) is not accessible from outside the corporate network.

Performance Considerations

To maintain optimal performance, deploy one Live Communications Server Proxy for every 10,000 users connecting from the outside. For every proxy server with 10,000 connected users, deploy one front-end server.

Installing a Live Communications Server Proxy Inside the Perimeter Network

To securely enable the outside user scenario, deployment of a Live Communications Server Proxy in the perimeter network is required. You will need two 100-megabits per second (Mbps) network adapters, one for the public connection and one for the private connection.

For the placement of various key components to support this configuration, see Figure 1.

Note

A company might have security policies that require chained servers within the perimeter network. Installations of chained Live Communications Server Proxy servers are unsupported, and the configuration, setup, and management of a chained configuration is beyond the scope of this document.

Cc713340.4645ba32-3657-4274-ab92-a223d9abc778(en-us,TechNet.10).gif

Figure 1   Live Communications Server Proxy located in a Live Communications Server deployment

Setup and Configuration Information

This section covers the required configuration changes for the sample topology to properly enable the outside user scenario.

The Live Communications Server Proxy is a SIP proxy that runs under the network service account. It does not require access to the Active Directory® directory service and can be installed in the corporate perimeter network.

Adding Hardware

Live Communications Server Proxy will perform properly on the standard configuration for Microsoft Windows Server™ 2003. For complete hardware recommendations, see the "Live Communications Server 2003 Document: Deployment Guide" (https://go.microsoft.com/fwlink/?linkid=20547). We recommend following the same hardware recommendations for the proxy as for a home server.

You will need two 100-megabits per second (Mbps) network adapters, one for the public connection and one for the private connection.

Installing Software

Installing the Live Communications Server Proxy is supported by command-line tools only.

  1. Log on to the computer running Windows Server 2003, where you will install the Live Communications Server Proxy. You must log on using an account with server administrator credentials.
  2. Insert the Live Communications Server CD.
  3. Click Start, click Run, and type the following in the Open box:
    <drive letter>* *:\setup\i386\setup\rtcsrv.msi SERVER=RTC Where <drive letter> is the drive designation for the CD drive.
  4. Press ENTER.
  5. When the Setup Wizard appears, click Next.
  6. After reading and accepting the license agreement, click Next.
  7. Enter the Product key and then click Next twice.
  8. Choose an install location and then click Next.
  9. Click Install.
  10. On the Setup Wizard Completed page, click Finish.

Configuring the Server

In this document, the default port 5061 is used. If your installation uses port numbers that differ from the example numbers, use your port numbers.

For information about home server and front-end server installation and configuration, see the "Live Communications Server 2003 Document: Deployment Guide" (https://go.microsoft.com/fwlink/?linkid=20544).

Home Server

If your deployment does not include front-end servers for use by outside users, you must configure the home server as described in the following front-end server section.

Front-End Server

By default, front-end servers are configured for Kerberos authentication. For the external user, Kerberos will not be available. The first server that an external user can connect to must be configured to use NTLM only.

This section details the changes needed on front-end servers that receive connections from the server that is hosting external users.

To change the authentication setting to NTLM, perform the following steps:

  1. From the Live Communications Server console, expand the Servers folder and right-click the front-end server (or home server in single server deployments) and select Properties. The Live Communications Server Properties dialog box appears.

  2. Click the Authentication tab.

  3. Verify that the setting for Authentication scheme in use is set to NTLM.

  4. Click OK.

Configuring Live Communications Server Proxy

This section details the configuration setting for the Live Communications Server Proxy as shown in the example topology in Figure 1. Contoso.com is a fictitious domain name. Use your organization’s domain in its place. For more information about ports, routing, and certificate configurations, see the "Live Communications Server 2003 Document: Deployment Guide" (https://go.microsoft.com/fwlink/?linkid=20544).

To view and modify the Live Communications Server Proxy configuration, perform the following steps:

  1. Open the Computer Management console.

  2. Expand the Services and Applications node.

  3. Right-click Live Communications Server and select Properties. The Live Communications Server Properties dialog box appears.

Use the following instructions to change the settings in this dialog box.

Connections Tab

Configure the Live Communications Server Proxy to listen on Port 5061, using TLS, listening only on the outside edge of the proxy. Also configure and install a certificate for this connection, For details, see the "Live Communications Server 2003 Document: Deployment Guide" (https://go.microsoft.com/fwlink/?linkid=20544).

Note

Unlike Live Communications Server Home Servers, the Proxy does not need to be configured to listen on MTLS.

Use the following steps to listen using TLS:

  1. From the Connections tab, select any existing connections and click Remove. Repeat this step until there are no more connections.

  2. Click Add.

  3. In the Add Connection dialog box, select This IP address and choose the IP address that represents the outside edge of the Live Communications Server Proxy from the list.

  4. Select TLS in the Transport type list.

  5. Clear the Authenticate remote server check box.

  6. Type 5061 in the Listen on this port box. If you use a different port, enter it instead.

  7. Click Change Certificate, and in the Select Certificate dialog box, select the proper certificate for this connection.

    Note

    The certificate chosen must have an Issued to value that matches the fully qualified domain name (FQDN) that the clients will connect to. Additionally, this FQDN must be in the format: sip.contoso.com where contoso.com represents your SIP domain. Also, the clients must trust the certificate authority that issued the chosen certificate. You can ignore any warnings given about your FQDN not matching if you ensure that the previous requirements are met.

  8. Click OK twice.

Routing Tab

Add the following entry in the routing table of the proxy, for example:

  • All traffic for *@contoso.com is sent to FE.Contoso.com, port 5061.

    Note

    The next hop specified in the routing table needs to be in the form of a fully qualified domain name (FQDN). An IP address will not work for creating a Transport Layer Security (MTLS) session. Make sure that this FQDN can be resolved to an IP address (either by adding an entry in DNS or adding the information in the host file on the proxy). If the inside firewall uses network address translation (NAT), the FQDN of the front-end server needs to resolve to the external IP address of the inside firewall. Note that the entry in the host file must match the certificate name used on the front-end server.

  • Configure and install a certificate for this connection. The proxy and the front-end server need to trust the root certification authority (CA) that has issued the certificate that is used for this connection.

Use the following steps to configure and install a route:

  1. From the Routing tab, click Add.

  2. In the Add Static Route dialog box, specify * for User and contoso.com for domain where contoso.com is your SIP domain.

  3. Type the FQDN of the next hop in Fully qualified domain name. For more information about this value, see the previous note.

  4. Select TLS from the Transport list.

  5. Type 5061 in the Port box. If you use a different port, enter it instead.

  6. Click Change Certificate, and in the Select Certificate dialog box, select the proper certificate for this connection. Click OK. For more information about certificates, see the "Live Communications Server 2003 Document: Deployment Guide" (https://go.microsoft.com/fwlink/?linkid=20544).

  7. You can ignore any warnings related to your FQDN not matching the certificate only in this step. If a warning appears, click Yes.

  8. Click OK.

Authentication Tab

The forwarding proxy does not authenticate user connections. Authentication settings are ignored for this configuration.

  • Click OK to save the changes made in the Live Communications Server Properties dialog box.

Configuring ISA Server

The ISA Server computers in your deployment must be configured to allow TCP (TLS) packets on Port 5061 and to send this traffic to a Live Communications Server computer.

Note

If you have installed a single Live Communications Server computer and have a single ISA Server computer between it and the Internet, you can publish the Live Communications Server computer to the Internet following the procedures in Configuring the Internal ISA Server Computer, and skip the information regarding configuring the external ISA Server computer.

Configuring the Internal ISA Server Computer

The following procedures are performed on the private firewall (FW-2 in this scenario).

To create a protocol definition for the SIPS protocol, perform the following steps:

  1. Click Start, point to All Programs, point to Microsoft ISA Server, and then click ISA Server Management to open ISA Server Management.

  2. In the ISA Server Management console, select Firewall Policy.

  3. In the task pane, select the Toolbox tab, and click Protocols.

  4. Under Protocols, click New, and then click Protocol to open the New Protocol Definition Wizard.

    Cc713340.6bbccddc-80d3-455a-8f72-990ca23b4de1(en-us,TechNet.10).gif

  5. On the New Protocol Definition Wizard Welcome page, in the Protocol definition name box, type SIPS, and then click Next.

  6. On the Primary Connection Information page, click New

  7. In the New/Edit Protocol Connection dialog box, in the Protocol type list, select TCP.

  8. In Direction, select Inbound.

  9. In From and To, type 5061.

    Cc713340.e35cde7a-6ab9-4208-9b0f-9780f4cae4d6(en-us,TechNet.10).gif

  10. Click OK to close the New/Edit Protocol Connection dialog box.

    Cc713340.71457111-bcb8-4ce1-96e3-361d01b5d737(en-us,TechNet.10).gif

  11. On the Primary Connection Information page, click Next.

    Cc713340.d1ff2b27-0dac-4fd4-a4d5-540ef01b7e94(en-us,TechNet.10).gif

  12. On the Secondary Connections page, in Do you want to use secondary connections, select No, and then click Next.

  13. Click Finish to close the New Protocol Definition Wizard. Notice that the SIPS protocol definition is listed under the User-Defined folder under the Protocols menu.

    Cc713340.be14bc11-489d-47f5-bceb-a7f9d9a114bf(en-us,TechNet.10).gif

The next step is to create a server publishing rule to allow inbound requests to the Live Communications Server front-end server from the Live Communications Server Proxy.

To create the publishing rule, follow these steps:

  1. In ISA Server Management, select Firewall Policy.

    Cc713340.ac7d060e-653c-4877-b0d5-94bf0c552d57(en-us,TechNet.10).gif

  2. In the task pane, on the Tasks tab, click Create New Server Publishing Rule to open the New Server Publishing Rule Wizard.

  3. On the New Server Publishing Rule Wizard Welcome page, provide a name for the rule, such as Publish SIPS for Live Communications Server, and then click Next.

    Cc713340.0c62406f-a91c-4da0-b0d0-7f1e60679f6e(en-us,TechNet.10).gif

  4. On the Select Server page, in Server IP address, type the IP address of your computer that is running Live Communications Server, and then click Next.

    Cc713340.5f5d1918-5fa4-433f-9d31-3fb93d42a91f(en-us,TechNet.10).gif

  5. On the Select Protocol page, from the Selected protocol drop-down list, select the SIPS user-defined protocol, and then click Next.

    Cc713340.1a28749b-52a7-477d-a645-d0cb1141582f(en-us,TechNet.10).gif

  6. On the IP Addresses page, under Listen for requests from these networks, select External, because the Live Communications Server Proxy server is on the External network adapter of the ISA Server computer FW-2.

    Note

    You can select specific IP addresses that ISA Server will listen on. To do this, click the Address button, and then for the selected network, specify the IP addresses that ISA Server will listen on.

  7. Click Next.

  8. Click Finish to close the New Server Publishing Rule Wizard. Notice that in the ISA Server Management console, in the details pane, on the Firewall Policy tab, the new rule is listed.

    Cc713340.e80f63e1-b431-4d26-82b4-743189e6efb5(en-us,TechNet.10).gif

  9. Optional. On the Firewall Policy tab, under the Name column, double-click the Publish SIPS for Live Communications Server rule to open its properties.

    Note

    On the To tab, under Requests for the published server, there is an option Requests appear to come from the ISA Server computer. This option can be used when you have not configured ISA Server as the default gateway on the published server. The disadvantage of this approach is that the published server will be unaware of the address of the client, which is a problem for server applications that use the client address for logging or for policy decisions.

  10. In the details pane, click the Apply button to apply the changes you made.

Configuring the External ISA Server Computer

The following procedures are performed on the external firewall (FW-1 in this scenario).

To create a protocol definition for the SIPS protocol, perform the following steps:

  1. Click Start, point to All Programs, point to Microsoft ISA Server, and then click ISA Server Management to open ISA Server Management.

  2. In the ISA Server Management console, select Firewall Policy.

  3. In the task pane, select the Toolbox tab, and click Protocols.

  4. Under Protocols, click New, and then click Protocol to open the New Protocol Definition Wizard.

  5. On the New Protocol Definition Wizard Welcome page, in the Protocol definition name box, type SIPS, and then click Next.

  6. On the Primary Connection Information page, click New.

  7. In the New/Edit Protocol Connection dialog box, in the Protocol type list, select TCP.

  8. In Direction, select Inbound.

  9. In From and To, type 5061.

  10. Click OK to close the New/Edit Protocol Connection dialog box.

  11. On the Primary Connection Information page, click Next.

  12. On the Secondary Connections page, in Do you want to use secondary connections, select No, and then click Next.

  13. Click Finish to close the New Protocol Definition Wizard. Notice that the SIPS protocol definition is listed under the User-Defined folder under the Protocols menu.

Next, create a publishing rule to allow inbound requests to the Live Communications Server Proxy server from Internet clients.

To create the publishing rule, follow these steps:

  1. In ISA Server Management, select Firewall Policy.

  2. In the task pane, on the Tasks tab, click Create New Server Publishing Rule to open the New Server Publishing Rule Wizard.

  3. On the New Server Publishing Rule Wizard Welcome page, provide a name for the rule, such as Publish SIPS for Live Communications Server Proxy, and then click Next.

  4. On the Select Server page, in Server IP address, type the IP address of your computer that is running Live Communications Server, and then click Next.

  5. On the Select Protocol page, from the Selected protocol drop-down list, select the SIPS user-defined protocol, and then click Next.

  6. On the IP Addresses page, under Listen for requests from these networks, select External, because you want to receive requests from the Internet.

    Note

    You can select specific IP addresses that ISA Server will listen on. To do this, click the Address button, and then for the selected network, specify the IP addresses that ISA Server will listen on.

  7. Click Next.

  8. Click Finish to close the New Server Publishing Rule Wizard. Notice that in the ISA Server Management console, in the details pane, on the Firewall Policy tab, the new rule is listed.

  9. On the Firewall Policy tab, under the Name column, double-click the Publish SIPS for Live Communications Server Proxy rule to open its properties.

    Note

    On the To tab, under Requests for the published server, there is an option Requests appear to come from the ISA Server computer. This option can be used when you have not configured ISA Server as the default gateway on the published server. The disadvantage of this approach is that the published server will be unaware of the address of the client, which is a problem for server applications that use the client address for logging or for policy decisions.

  10. In the details pane, click the Apply button to apply the changes you made.

Configuring the DNS Server

If the client configuration will be supported through automatic configuration, an SRV record must be added in the public DNS namespace, for example: _sip._TLS.contoso.com. The SRV record should point to an A record which is sip.contoso.com (where contoso.com is your SIP domain) on port 5061. If your public (world) firewall is a NAT, this A record should point to the IP address of the firewall. Otherwise, the A record should point to the external IP address of the Live Communications Server Proxy.

The following tables are an example of the SRV record and A record needed to support the sample deployment in Figure 1.

Table 1   SRV record for Figure 1 sample deployment

Name Priority Port Target

_sip._tls.contoso.com

0

5061

sip.contoso.com

Table 2   A record for Figure 1 sample deployment

Name Target

sip.contoso.com

If FW1 is a NAT:

    IP address of FW1.contoso.com

Otherwise:

    IP address of Proxy

Impact on Existing Applications

The routing characteristics of SIP messages are different when users connect from outside the corporate network over TLS from when these users connect from within the corporate network.

This, in turn, can impact applications you have deployed on computers running Live Communications Server in your deployment.

This section illustrates these differences with a simple example.

Cc713340.911b3084-82c0-4897-a551-9865da6b6666(en-us,TechNet.10).gif

Figure 2   Routing behavior in the outside user scenario

Routing Behavior from Within the Corporate Network

In this example, Jane and Sharon are two users located in the corporate network. Both are assigned to different Live Communications Home Servers (HS1 and HS3 respectively) and are logged on to their server. Jane and Sharon are in different departments at Contoso. Jane is in the legal department and all her communications need to be archived. Therefore, the administrator has deployed the archiving agent on Jane’s home server (HS1) and has homed the entire legal department on that server.

Sharon’s conversations do not need to be archived. Therefore, the administrator did not deploy the archiving agent on Sharon’s home server.

Jane is sending a message to Sharon. The message first is sent to her own home server, which then sends it to Sharon’s home server. (Jane’s home server parses the To field in the message, and identifies that it is destined to Sharon, and that Sharon is assigned to another server.) In the same way, all messages that Sharon sends to Jane go through Jane’s home server and will be archived as desired by the administrator.

In this deployment, all SIP messages that are from or destined to a user get routed through the user’s home server.

Routing Behavior from Outside the Corporate Network

Tom is also in the legal department and all his conversations should get archived. He is connecting from outside of the corporate network and is logged on to HS1, the same server as Jane.

Tom is sending a message to Sharon. The message goes through the proxy and then reaches the front-end server, which parses the To field and routes it directly to HS3, Sharon’s home server.

In this example, the message sent by Tom does not get archived.

In scenarios where users connect to the corporate network from outside, characteristics of routing are different.

Important

If you have applications deployed on computers running Live Communications Server in your deployment, you need to be aware that these applications may not receive the SIP messages the same way as when users are connecting from within the corporate network.

Troubleshooting

This section focuses on two areas for testing: certificates and setup.

Certification Authority

Make sure your clients and servers trust the certification authority (CA) that issued the server certificates:

  • Use the Client Certificate Microsoft Management Console (MMC) snap-in to verify that clients trust the issuing CA.
  • If a client can connect to a Web site the first time without errors with a certificate issued by the same CA, the CA is trusted.
  • If the client receives an "Unknown certificate — would you like to trust" error message the first time connecting to the Web site, the certificate was manually installed as trusted. Verify this by looking at the client certificate stores to see if it explicitly trusted the Web server certificate.
  • If the client does not already trust your CA, provide the services to allow the client to install the CA certificate manually.
  • Certificate principle names must always match FQDNs when connecting over MTLS.
  • There must be a Hosts entry on the proxy or private DNS in the perimeter network when the inside firewall is a NAT relationship and the port is forwarded to the inside. This is to allow the FQDN to match the certificate returned.

Testing Your Setup

Test these areas of your setup: connection to the host address, log on with a client, and credentials.

Testing the Connection to the Host Address

Test Telnet to 5061 on the host address. If the connection is not successful, the possible failures can be:

  • A firewall between your computers might not have allowed the port to pass through to the server.
  • The server is not listening on the port you specified, or it failed to start. (Verify that a client on the same machine is able to log on.)

Attempting to Log On With a Client

If you are prompted for a user name and password, this confirms the physical connection worked, and the certificate is validated properly. If you are not prompted, check the following:

  • The server certificate might not be trusted by the client. Check the local certificate store to verify that the CA is trusted.
  • The server certificate common name or subject name might not match the name the client resolved to when it made its request. The certificate common name or subject name has to match the FQDN on every Live Communications Server computer in the topology.
  • The firewall may be configured incorrectly. Check the configuration on your firewalls.
  • The proxy server may be misconfigured. Check the configuration on the proxy.

Enter Credentials

If you are able to log on, it indicates that the logon credentials were validated and a TLS has been properly established. If you are not able to log on, the possible reasons can be:

  • The server was unable to reach the client to send presence notifications.
  • Kerberos authentication is enabled, and the client was unable to reach the key distribution center to get a Kerberos ticket. The server must be configured for NTLM only.
  • The credentials you provided may have been invalid.

Do you have comments about this document? Send feedback.