Office Communicator must determine which server it should log on to by using the user’s URI (for example, firstname.lastname@example.org) and any manual settings configured on the client. If manual settings were provided, the server to use is clear. However, if the URI was the only indicator provided, some discovery is required.
Communicator discovery varies based on configuration. After the client discovers the server to connect to, it tries to connect by using TCP or TLS over TCP. If TLS is used, the server provides a certificate to authenticate itself to the client. The client must validate the certificate before it continues. The client might negotiate compression (if using TLS over TCP), and then it initiates a SIP registration.
Next, the client sends a SIP REGISTER message to the server without any credentials. This prompts Office Communications Server to challenge for user credentials, and specifies to the Communicator client the authentication protocols that it accepts.
When it comes to providing credentials, Communicator has two options. Communicator can use the user’s current Windows credentials to log on, or it can prompt the user for credentials.
|The credentials manager in Windows can also be used to manage
credentials. More information about the credentials manager is in
the Microsoft TechNet article Windows XP Resource Kit:
Understanding Logon and Authentication at
Authentication failures can occur during the first part of logon processing. This can occur when credentials are not already saved or when the desktop credentials do not match the account that Communicator is trying to use. This can also occur when the SIP URI, account name, or password is typed incorrectly or when credentials and the SIP URI do not match. An example of this is if Jeremy tries to log on with the URI sip:email@example.com, but he uses the user account and password for CONTOSO\vadim instead of the account owner’s own credentials, CONTOSO\jeremy.
Understanding Client Automatic Configuration and DNS Discovery
For organizations that plan to use automatic configuration, one of the requirements during server deployment is to create an internal DNS SRV record that maps one of the following records to the fully qualified domain name (FQDN) of the Enterprise pool or Standard Edition server that handles client sign-in requests:
- _sipinternaltls._tcp.<domain> (for internal TLS
- _sipinternal._tcp. <domain> (for internal TCP
connections, performed only if TCP is allowed)
When the client is set to use automatic configuration, it uses the SIP URI that is provided by the user to discover which server it should sign in to. Communicator does this by using DNS SRV records published for the domain part of the SIP URI.
For example, if the user enters a URI of sip:firstname.lastname@example.org, Communicator uses contoso.comto discover a SIP server that uses DNS. Communicator looks for the following SRV records in its search for an appropriate server:
If these records do not exist, Communicator queries for host (A) records:
The first query looks for an internal server in the contoso.com domain that offers ports supporting TLS over TCP for clients. The second query seeks to discover an internal server in the contoso.com domain that offers TCP ports for clients. Finally, the third query looks for an Internet-reachable server for the contoso.com domain that offers ports supporting TLS over TCP for clients. Communicator never looks for an Internet-reachable server that supports TCP, because use of clear-text SIP on the Internet does not make sense from a security standpoint. In other words, Communicator is not aware whether the network that is being used is internal or external. Communicator queries for all DNS SRV records. However, it tries TLS over TCP connections first. TLS over TCP is forced through an Edge Server (no option to allow for unsecured TCP connections).
Finally, if all the DNS SRV records do not exist (not if they are not valid; only if they do not exist at all), the client falls back to sipinternal.< URI domain> and tries to resolve that host name. If the host name resolves to an IP address, Communicator tries to connect by using TLS over TCP, TCP, or both, depending on what the policy allows for. If this fails, it will try one last time with sipexternal.< URI domain>.
Communicator policies can be put in place to prevent TCP from being used, and this prevents the second query from being issued. The EnableStrictDNSNaming policy can also be specified, which requires strict names for the computers discovered. In this case, Communicator is allowed to connect to servers only if the name is a match with the domain in the domain part of the user’s SIP URI or if the FQDN is sip.< URI domain >. If this policy is not enabled, any server name of the form <servername>.<URI domain> is allowed. As an example, for sip:email@example.com, the host sip.contoso.com is always allowed (strict policy or not). Server77.contoso.com, sipfed.contoso.com, and ap.contoso.com are all also allowed if strict naming policy is not enabled. The following server names are never allowed because they do not tightly fit the domain that the user’s URI specified. Therefore, the client does not trust these servers as valid logon points: sip.eng.contoso.com, sip.contoso.net, sip.com, sip.contoso.com.cpandl.com, and so on.
This tight validation between the host name and the URI is done specifically because the only configuration with which the client is provided is the SIP URI. Because of this, the client must be very careful not to allow DNS attacks to allow it to connect to any man-in-the-middle, who could thereby watch Communicator’s traffic. By having a tight tie between the URI and the host names allowed for logon, Communicator has better certainty that the certificate the user is validating actually has authority for the domain to which he is trying to log on to.
After the host name is identified, Communicator also resolves the host name to an IP address. This usually occurs as the result of the DNS SRV request, but until the IP address is resolved, Communicator cannot connect. This can be a problem during logon also.
The latest version of Communicator enables the ability to manually specify bothan internal and external server to log on against. Communicator always attempts to connect to the internal server if it is available, but it falls back to the external server. Previously, Communicator had only a single manual entry, which created problems for mobile workers. With the ability to specify an internal and external server, it is now easier for administrators to configure and enable laptop configurations that work across internal and external networks. This increased functionality is also important for companies where the domain in the user’s URI differs from their SIP enterprise server’s domain. Because the administrator can configure Communicator (on a laptop, for example) once, the user does not need to remember the internal or external servers and administrators do not have to publish DNS SRV records for all the domains they want to support for remote access users.
The Office Communicator client enables the user to automatically connect to the appropriate Office Communications Server without actually putting in the server name. Regardless of whether the client is inside the internal network or is working externally, this feature redirects the client and allows it to authenticate and connect to its own Office Communications Server (in the case of Standard Edition) or home pool (in the case of Enterprise Edition). This feature has a significant DNS dependency. For this to work successfully, the appropriate SRV records should be published both internally and externally.
When the Office Communicator client first starts and the user tries to connect, Office Communicator always tries to connect to the server or home pool in its same domain, or by using the same SIP URI as in the sign-in address. For example, if the sign-in name that is used is firstname.lastname@example.org, Office Communicator looks for the home pool or Office Communications Server in the same DNS namespace, which is fabrikam.com. This process is made easier by the usage of DNS SRV records, which ultimately points the client to the FQDN of the home pool or server in the correct domain. The process works the same whether the client is in an internal or external network.
The client starts querying SRV records and, by default, it always tries to use TLS for authentication. If TLS fails, then and only then will it fall back to Transmission Control Protocol (TCP).
Either of these first two DNS records should be published and available in the internal DNS namespace. So, if by now the client gets the host name back, it directly connects to the home pool or the Office Communications Server. Or else, it continues its query process, knowing that it is currently not in the internal network.
If either of these queries is a success, the client is redirected to the external edge of Access Edge Server and subsequently to the internal home pool or the Office Communications Server. However, if it still fails, in a final attempt it tries to look up the host records directly as in the following two examples. If this attempt to configure its settings automatically fails, the Office Communicator will fail and require manual intervention.