Common Issues with Sign-in and Discovery
Topic Last Modified: 2009-07-20
When troubleshooting issues with sign-in, one of the first things to determine is whether the user is entering the correct information. Next, ensure that the user’s account is an active account that is enabled for Office Communications Server. If the user information is not an issue, investigate the server-side configuration. When investigating sign-in from the server side, first determine whether the client connection settings are set to automatic configuration or manual configuration. This section describes some common issues encountered during sign-in from both the user and server perspective.
The following scenarios illustrate some common sign-in issues related to the user’s account or the information that the user is trying to use during sign in.
Incorrect Sign-In Address
When attempting to sign in to Communicator, a user may see the message, “Cannot sign in to Communicator. You may have entered your sign-in address, user name, or password incorrectly, or the authentication service may be incompatible with the version of the program.”
Frequently, the user is trying to sign in with a sign-in address that does not match the SIP URI that is specified in the user’s Active Directory properties. The format for the SIP URI is determined by the administrator when enabling users for Office Communications Server. The SIP URL can be generated from the user’s e-mail address, user principal name, full name, or Security Accounts Manager (SAM) account (the logon name used in older versions of the Windows operating system). The user should try to sign in again by using the correct SIP URI format.
User Account Not Enabled for Office Communications Server
If the user is entering the correct SIP URI format and sign-in continues to fail, the network administrator should verify that the user account is enabled, that the user is enabled for Office Communications Server, and that the password for the account hasn't expired or been reset.
For information about how to enable user accounts, see Managing User Accounts in the Administering Office Communications Server 2007 R2 documentation.
User Does Not Have Permissions on Profile Folder
If an individual user receives an error saying that the server is unavailable, turn on Windows event logging for Communicator and check the Windows event trace log. The logs may show an “access denied” error while creating the Communicator folder under C:\Documents and Settings\<user name>\Local Settings\Application Data\Microsoft. To resolve this issue, you can give the user the appropriate rights on the Communicator folder.
With manual configuration, sign-in issues usually stem from incorrect server name entries in the Advanced Connection Settings on the client. In the Event Viewer for the client, you may see “Communicator failed to connect to server 192.168.0.2 (192.168.0.2) on port 5060 due to error 10061,” which references the IP address of a server to which the client could not connect. Or, you will see references stating that the server presented by the server did not match the expected host name. Often these errors occur because a server IP address is entered in the client’s Advanced Connection Settings dialog box.
Instead of entering the server IP address or a NetBIOS name in the Advanced Connection Settings, enter the server’s FQDN.
When using manual configuration in connection settings, you also need to know whether TLS is required for connections between clients and Office Communications Server. If TLS is required, the TLS option must be selected in the Advanced Connection Settings, and the server’s FQDN must be specified (instead of the server IP address or NetBIOS name) so that server name matches the certificates that are in place.
If connections to the server use TCP, ensure that the Office Communications Server pool properties are set to the TCP listening port 5060.
With automatic configuration, there may be issues with DNS configuration, certificates, or server naming.
If you are using automatic configuration, make sure that the published server name in DNS is supported by the server certificate. For information about required creation of DNS records that enable discovery of clients and servers, as well as support for automatic client sign-in (if your organization wants to support it), see the Microsoft Office Communications Server 2007 R2 article, “Domain Name System (DNS) Requirements,” at http://go.microsoft.com/fwlink/?linkid=146936.
When clients are configured to sign in automatically, make sure that the appropriate DNS SRV record exists. When using a TLS connection, add the following SRV record and map it to the host record of the server:
_sipinternaltls._tcp.<domain> over port 5061.
|If the SIP domain differs from the Office Communications Server domain, we recommend that you create a host record sip.<domain> instead of the Office Communications Server host record.|
When using a TCP connection, add the following SRV record and map it to the host record of the server:
_sipinternal._tcp.<domain> over port 5060
Strict Name Checking
If clients use automatic configuration to sign in and TLS is required, connection failures can sometimes be traced to the EnableStrictDNSNaming policy setting. When Communicator is configured for automatic connection and TLS is enforced, this policy enables Office Communicator to send and receive instant messages securely when using the SIP Communications Service. This policy does not affect Windows .NET or Microsoft Exchange Server services. Much of the confusion surrounding the EnableStrictDNSNaming policy stems from unclear policy description. Setting this policy incorrectly can cause unexpected problems with TLS negotiation and client sign-in. The correct explanation for this policy is as follows.
If you set the EnableStrictDNSNaming policy to Enabled, Communicator clients can only connect to a server if its name matches the user’s SIP URI domain, or if its FQDN is sip.<URI domain>. For example, if the user’s SIP URI is firstname.lastname@example.org, Communicator will be able to connect only to the following servers:
If you do not configure this policy or you set it to Disabled, Communicator clients can communicate with any SIP server that has an FQDN that ends with the domain part of the user's SIP URI. For example, Communicator will be able to communicate with servers named sip.division.contoso.com or lc.contoso.com. The downside is that an attacker can respond to the initial DNS query with a server name such as attacker.contoso.com. By not configuring this policy or disabling it, you may be more open to man-in-the-middle attacks.
One reason for not enabling this policy is if your organization has multiple subdomains and, when setting up certificates, you need the flexibility of allowing non-strict server names.
To enable this policy, make sure that your SIP server’s FQDN matches one of the strict naming formats.
|You can configure this policy setting under both Computer Configuration and User Configuration, but the policy setting under Computer Configuration takes precedence.|
If internal users can sign in but external users are encountering issues, there may be an issue with the way authentication protocols are configured, the ports specified during sign-in, or server-side encryption settings.
Set the Authentication Protocol to Both NTLM and Kerberos
Office Communications Server 2007 R2 uses Kerberos or NTLM authentication protocols, depending on the location of the user. Kerberos protocol, which requires client connectivity to Active Directory, is used for internal users with Active Directory credentials. External users who have Active Directory credentials but who are connecting from outside the corporate firewall use NTLM.
If external users cannot authenticate, ensure that the authentication protocol in the Office Communications Server front-end server properties is set to Both NTLM and Kerberos.
Client Manual Sign-In on 5061, Access Edge Listening on 443
Clients that connect from outside the corporate firewall use port 443 for SIP communications with Edge servers. Sometimes clients are configured to connect to the server by using manual configuration, but external server is configured with the incorrect port. For example, if a client is manually configured to connect to a server on port 5061 while Access Edge Server is listening on port 443, the connection will fail. Check the client’s Advanced Connection Settings under External Server Name or IP Address, and ensure that the entry specifies port 443, for example sip.domain.com:443.
Also, specify port 443 if you use Group Policy to specify the external server name,
Mismatch between NTLMMINCLIENTSEC and NTLMMINSERVERSEC
Organizations may use local policies and group policies to configure specific security settings in Windows Server domains to help tighten security. One such setting is the NTLMv2 authentication setting, which can be configured to require encryption on communication between servers and clients. If the settings on the client side and the server side do not match, communication cannot be established.
The settings are for NTLMv2 authentication are located in registry as follows:
Sometimes the server will be configured to require encryption, and the client will not. In this case, the client NTLM request is not passed on by the front-end server. This situation primarily affects external users, because NTLM is the only authentication protocol that external clients can use to sign in. For example, if the server key is configured to have a value of 0x20080030, which specifies 128-bit encryption, and clients are not, clients will be unable to sign in. You should ensure that this key on the client is configured to match the server’s setting.
For more information, see Microsoft Knowledge Base article 823659, “Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments,” at http://go.microsoft.com/fwlink/?linkid=147230.