• Article

Authorization and Authentication

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

The Communicator Web Access server performs both authorization and authentication on clients that attempt to access it. Communicator Web Access confirms that the SIP URI of the client matches the credentials of the user and ensures that the user has been authorized to use Office Communications Server 2007. If the user is attempting to connect remotely, Communicator Web Access also confirms that the user has been granted remote access to Office Communications Server 2007.

The authentication request must be made before any other requests in a session.

Important

To improve the security of your Communicator Web Access deployment, we strongly recommend that you use HTTP with Secure Sockets Layer (HTTPS) as the connection protocol. HTTPS is required on the Web listener for the external interface of the reverse proxy, but you should also use it when you create a virtual server and when you configure the Web publishing rule for the reverse proxy.

Authentication

Communicator Web Access requires that clients be authenticated by one of the three mechanisms:

  • Forms-based authentication

  • Integrated Windows authentication

  • Custom authentication

These authentication methods are described in detail in the following sections.

Forms-based authentication and integrated Windows authentication are built into Communicator Web Access.

If you use more than one authentication mechanism, each method requires a unique URL. For example, if Contoso Corporation uses forms-based authentication, integrated Windows authentication, and single sign-on, depending on user scenario, it might publish the following Web sites:

  • Forms-based authentication: https://myserver.contoso.com/forms/signin.html

  • Windows authentication: https://myserver.contoso.com/iwa/signin.html

  • Single sign-on: https://myserver.contoso.com/sso/signin.html

If an authentication request succeeds, the server creates an authentication ticket and passes it to the client, which caches it for the life of the Communicator Web Access session. This ticket expires when one of the following events occur:

  • The user signs out of Communicator Web Access.

  • The user closes the browser.

  • The user leaves the Web page with the Communicator Web Access Contact list to go to another site.

  • A server-specified time period has elapsed.

Forms-Based Authentication

With forms-based authentication, a user who attempts to sign in to Communications Web Access is presented with a form in which to enter a valid domain, user name, and password. Because the user enters credentials in plain text, it is critical that the Web site use HTTP with secure Sockets layer (HTTPS), in addition to certificates, so that the credential will be encrypted.

Forms-based authentication can be used by virtual servers that are accessed by internal users who cannot use the Internet Explorer browser (for example, those who are using an operating system other than Microsoft Windows) and for those who are using a browser that does not support integrated Windows authentication. Virtual servers that are accessed by external users must use either forms-based authentication or custom authentication.

Integrated Windows Authentication

Integrated Windows authentication uses Kerberos Version 5 network authentication, which is available only to internal users. Kerberos is used by default for internal users who sign in by using the Internet Explorer® Internet browser, who are signed in with domain credentials, and whose computer is running a supported version of Windows; the NTLM challenge/response authentication protocol is used when computers are not domain members or when Kerberos is not available.

When you use integrated Windows authentication, Communicator Web Access users can be authenticated by using quick sign-in. After configuring the necessary security settings in Internet Explorer, the user signs in to Communicator Web Access by entering a URI such as the following: https://server.contoso.com/quicksignin.

The domain user account that the user is logged on to on the local computer is used for quick sign-in.

When the user is already authenticated through integrated Windows authentication, Communicator Web Access will open immediately with no further authentication requests. This behavior is beneficial to frequent users, who can bookmark Communicator Web Access with the quick sign-in URI.

Note

If Internet Explorer users are challenged for their credentials when they attempt to sign in to Communicator Web Access from within the internal network, you can configure Internet Explorer to bypass the proxy server for the Communicator Web Access site. If a user has already been authenticated, this configuration allows the user to sign in without having to reenter credentials.
In order to configure Internet Explorer to bypass the proxy server for all users, edit the Internet Explorer group policy to include a proxy server exception for the Communicator Web Access site (for example, im.contoso.com).

For remote users and for users of supported browsers that cannot use integrated Windows authentication, the forms-based authentication window will appear.

Note

Using a quick sign-in URI programmatically from another Web application is not supported and may result in unexpected behavior.

Custom Authentication

If the authentication mechanisms that are built into Communicator Web Access do not meet your needs, you can implement a custom solution. Communicator Web Access (2007 release) supports the following custom authentication solutions:

  • Single sign-on (SSO)

  • Third-party authentication, such as an ISAPI filter that is developed by an ISV (independent software vendor) or two-factor authentication

Custom authentication solutions normally require that you deploy a reverse proxy or other authentication server in the perimeter network. This can be a reverse proxy that you have already deployed in your environment.

If you use custom authentication, you can specify the URL of a sign-out page when you install Communicator Web Access. When users sign out of Communicator Web Access, they are redirected to the sign-out page, and the reverse proxy clears the users authentication cookie from the client computer. For details about creating a sign-out page, see the white paper "Secure Logoff from Published Web Sites" at https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=ISAlogoff.

  • Single Sign-On

    If users of Communicator Web Access use the same credentials to sign in to other services that use the same reverse proxy, such as the Microsoft Office SharePoint® services or Microsoft Office Outlook® Web Access, an automatic sign-in mechanism, such as single sign-on (SSO), can be a great convenience to the user. If the same user tries to connect to any other supported service, the reverse proxy automatically authenticates the user to the service without prompting the user for credentials again.

    SSO credentials typically expire after a specified period of user inactivity, which can be individually set for each service. Setting the timeout period for each service to the same value minimizes user uncertainty and results in a more predictable user experience.

  • Third-Party Authentication

    You can install a third-party authentication mechanism in Windows IIS (Internet Information Services) as an ISAPI filter DLL. For details on installing an ISAPI filter, see the Microsoft Knowledge Base article "How to Install an ISAPI Filter Dynamic-Link Library" at https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=kb150312. See also the Microsoft Unified Communications AJAX SDK.

  • Two-Factor Authentication

    Two-factor authentication requires that in order to be authenticated a user have a valid user name and password, but also, as a second authentication factor, some sort of token or certificate, such as the information that is stored on a smart card. Your reverse proxy must support two-factor authentication.

Authorization

A user can sign in to Communicator Web Access (2007 release) only if the user is enabled for enhanced presence. When Communicator Web Access performs authorization, it checks the Active Directory User object to determine if enhanced presence is enabled for the corresponding user.

For users for whom enhanced presence is not enabled, you can redirect the client browser to a Communicator Web Access (2005 release) service, or you can let the connection attempt fail. For details about enabling enhanced presence, see the Microsoft Office Communications Server 2007 Administrators Guide. For details about redirecting users to an earlier version of Communicator Web Access, see Interoperability later in this guide.

Pop-up Blockers

The Communicator Web Access server uses pop-ups for both internal users and remote users. For example, pop-ups are used to display incoming instant message desktop alerts and new conversation windows. Therefore, users must allow pop-ups on the Communicator Web Access site.

For users of supported versions of Firefox, Mozilla, and the Netscape browser, the number of windows that are open at any one time is limited in order to help safeguard against sites that abuse pop-ups. When accessing Communicator Web Access from these clients, users can reach this limit if several conversation windows or desktop alerts are open at the same time. In this case, the client browser will prevent any new windows from opening, which can result in missed conversations or notifications. To prevent this issue, the user can change or remove the limit on the number of allowable open windows as described in the browser documentation.

Cookies

Cookies are issued to the client by the Communicator Web Access server after successful authentication by both internal users and remote users. Therefore, clients must accept cookies from the Communicator Web Access server in order to function correctly.

Users of single sign-on can, but are not required to, set their Internet browser to accept persistent cookies from the Communicator Web Access virtual server and from all other services that are supported by the same reverse proxy. This setting can be used for custom authentication solutions that recognize persistent cookies.