When you create a virtual server you will need to specify values for a number of key properties, beginning with the authentication mechanism. Communicator Web Access provides several authentication options.

Integrated (NTLM/Kerberos) password authentication

This is the most secure type of authentication and the option that requires the least amount of effort. With integrated password authentication, users do not have to enter a user name and password. Instead, they are authenticated using the same credentials they used when they logged on to their computer.

However, there are two drawbacks to integrated password authentication. First, this type of authentication can only be used with internal virtual servers; external users always have to supply credentials, which means that sites that handle external logon requests must used either forms-based or custom authentication.

Second, integrated password authentication can only be used by people who: log on from a computer running Microsoft Windows, and are using a Web browser that supports NTLM or Kerberos authentication. If all of your users are internal users running Internet Explorer and Microsoft Windows, then you can use integrated password authentication as your sole authentication mechanism. Otherwise, you will need to use both integrated password authentication and forms-based authentication, or you will need to use a custom authentication method.

Note:
If you use both integrated password authentication and forms-based authentication, Communicator Web Access will first try to log a user on using integrated password authentication. If that fails, the user will then be given the chance to log on using forms-based authentication.

Forms-based authentication

With forms-based authentication, a user attempting to access a Communicator Web Access virtual server is presented within a logon dialog box. The user must be then present his or her credentials (that is, domain, user name, and password) before he or she can be authenticated and be able to access the site. Forms-based authentication enables you to provide support for:

• Macintosh and Linux users
  
  
• Users who are not running Internet Explorer
  
  
• External users (that is, users logging on from outside the organization’s firewall)
  
  

The downside to forms-based authentication is that it is not a very secure mechanism. For example, user credentials are passed to the server in plain-text format. Because of that, it is highly recommended that you employ HTTPS connectivity for any virtual server that allows forms-based authentication.

Custom authentication

In addition to the authentication mechanisms built into the Windows operating system, Communicator Web Access also supports custom or third-party authentication methods. For example, Communicator Web Access supports the use of two-factor authentication, in which two pieces of identification (typically a smart card and a Personal Identification Number (PIN)) must be presented before a user can be authenticated.

Communicator Web Access also supports single sign-on authentication, although only with Microsoft Internet Security and Acceleration Server (ISA) 2006. With single sign-on, a user can log on once and be granted access to multiple applications. For example, a user can log on to Microsoft Outlook Web Access and automatically be logged on to Communicator Web Access as well (or vice-versa).

Note:
If you use single sign-on you should specify the option Sign-Out URL, a URL that the user will be taken to whenever he or she signs out from Communicator Web Access. By visiting this page, the user can be assured that any authentication cookies stored on their computer will be deleted. For details, see the documentation for your custom authentication method.

After specifying the authentication mechanism you need to specify the connectivity type. Communicator Web Access supports two different connectivity protocols: HTTP and HTTPS. Of the two, HTTPS is preferred because it is the more secure protocol. Among other things, HTTPS encrypts all the traffic between the server and the browser. If you decide to use HTTPS (the recommended protocol), you need to assign this connection a certificate. For details, see Preparing Certificates for Communicator Web Access.

Note:
The HTTPS protocol is required if you intend to implement desktop sharing. If you log on to a Communicator Web Access Web site that uses the HTTP protocol the desktop sharing button will be disabled. If you hold the mouse over the button a tooltip will appear stating that, “Desktop sharing requires a secure connection (HTTPS). Contact your system administrator.”

You must also assign each virtual server an IP address and port. Virtual servers can share IP addresses, but virtual servers cannot share ports: each virtual server must have its own port, a port not used by any other application. By default, Setup suggests using port 443 for HTTPS connections and port 80 for HTTP connections. Because these are also the ports used by the Default Web Site in Internet Information Services (IIS) you will need to shut down that site before those ports can be assigned to Communicator Web Access.

As noted, when you create a virtual server you must specify a port to be used by that server. If the specified port is already in use by another application the Setup program will inform you that the port has already been reserved, and will ask you to select a different port number. For example, port 443 is used by the Default Web Site in IIS. If you have not disabled this Web site Setup will not allow you to use port 443 as a virtual server port.

However, Communicator Web Access does not always recognize ports that are currently in use by a Windows system component. For example, suppose you select port 137 when creating a virtual server. Setup will allow you to use that port number, and will create the virtual server for you. However, you will not be able to start this new virtual server. That is because this port is used by File and Printer Sharing. If this happens, you will need to use the Communicator Web Access snap-in to change the port number.

Finally, you will need to assign the virtual server a “next hop server.” When a user participates in a conference, messages need to be passed between the Communicator Web Access server and the user’s home server. Anonymous users (that is, users who do not have an account in your Active Directory domain or the domain of a federated partner) can participate in conferences. However, because anonymous users do not have a home server there is no place for Communicator Web Access to relay messages.

Because of this you must assign each virtual server a “next hop” server, a server (or pool of servers) that can act as a home server for anonymous users. A next hop server can be any computer in the forest that is running Office Communications Server 2007 R2.

When you assign a next hop server, make sure that the next hop server is up and running. Do not assign a next hop server that is currently offline or is going to be taken offline. If the next hop server fails, Communicator Web Access will fail as well. Because of this, it is recommended that you use a server pool as your next hop server. That way, the failure of a single server will not cause Communicator Web Access to fail.

Again, note that the Setup wizard only lets you create one virtual server per Communicator Web Access computer. If you want to create a second virtual server on this same computer (for example, so that one Communicator Web Access server can support both internal and external users), you need to create the second server using the Communicator Web Access snap-in. For details, see Creating a Communicator Web Access Virtual Server By Using Communicator Web Access Snap-in.