Problemas comuns de entrada e descoberta

Tópico modificado em: 2009-07-20

Na solução de problemas de entrada, uma das primeiras coisas a serem determinadas é se o usuário está inserindo as informações corretas. Em seguida, verifique se a conta do usuário é uma conta ativa habilitada para o Office Communications Server. Caso as informações do usuário não sejam um problema, investigue a configuração do servidor. Ao investigar a entrada do lado do servidor, determine primeiro se as definições de conexão do cliente estão ajustadas para configuração automática ou manual. Esta seção descreve alguns problemas comuns encontrados durante a entrada, do ponto de vista do usuário e do servidor.

Informações do usuário incorretas

Os cenários a seguir ilustram alguns problemas de entrada comuns relacionados à conta do usuário ou às informações que ele tenta utilizar ao entrar.

Endereço de entrada incorreto

Ao tentar entrar no Communicator, um usuário pode receber a mensagem “Não é possível entrar no Communicator. Talvez o endereço de entrada, nome de usuário ou a senha estejam incorretos, ou talvez o serviço de autenticação não seja compatível com esta versão do programa.”

Com frequência, o usuário estará tentando entrar com um endereço que não corresponde ao URI do SIP especificado nas propriedades do usuário no Active Directory. O formato do URI do SIP é determinado pelo administrador ao habilitar usuários para o Office Communications Server. A URL do SIP pode ser gerada com base no endereço de email, no nome UPN, no nome completo ou na conta do SAM (Gerenciador de Contas de Segurança) (o nome de logon usado em versões mais antigas do sistema operacional Windows) do usuário. O usuário deverá tentar entrar novamente usando o formato correto do URI do SIP.

Conta do usuário não habilitada para o Office Communications Server

Se o usuário estiver inserindo o formato correto do URI do SIP, mas ainda assim não conseguir entrar, o administrador da rede deverá verificar se a conta do usuário está habilitada, se o usuário está habilitado para o Office Communications Server e se a senha da conta não expirou ou foi redefinida.

Para obter informações sobre como habilitar contas de usuários, consulte a Biblioteca Técnica do Microsoft Office Communications Server 2007 R2 em https://go.microsoft.com/fwlink/?Linkid=144479, no tópico Operações > Administrando o Office Communications Server 2007 R2 > Gerenciando contas de usuários.

O usuário não tem permissões sobre a pasta de perfil

Caso um usuário individual receba uma mensagem de erro informando que o servidor não está disponível, ative o log de eventos do Windows referente ao Communicator e verifique o log de rastreamento de eventos do Windows. É possível que os logs mostrem um erro de “acesso negado” durante a criação da pasta do Communicator em C:\Documents and Settings\<nome do usuário>\Configurações Locais\Dados de Aplicativos\Microsoft. Para resolver esse problema, você pode conceder os direitos apropriados ao usuário sobre a pasta do Communicator.

Falhas na entrada com a configuração manual

Com a configuração manual, os problemas de entrada costumam derivar de entradas de nomes de servidor incorretas nas Configurações Avançadas de Conexão do cliente. No Visualizador de Eventos do cliente, poderá ser exibida a mensagem “O Communicator não pôde se conectar ao servidor 192.168.0.2 (192.168.0.2) na porta 5060 devido ao erro 10061”, que faz referência ao endereço IP de um servidor ao qual o cliente não conseguiu se conectar. Ou, então, poderão ser exibidas referências indicando que o servidor apresentado pelo servidor não correspondeu ao nome de host esperado. Em geral, esses erros ocorrem porque um endereço IP de servidor é inserido na caixa de diálogo Configurações Avançadas de Conexão do cliente.

Em vez de inserir o endereço IP do servidor ou um nome NetBIOS nas Configurações Avançadas de Conexão, insira o FQDN do servidor.

Ao usar a configuração manual nas definições de conexão, você também precisará saber se o protocolo TLS é necessário para as conexões entre os clientes e o Office Communications Server. Se ele for necessário, a opção TLS deverá ser selecionada nas Configurações Avançadas de Conexão, e o FQDN do servidor deverá ser especificado (em vez do endereço IP do servidor ou do nome NetBIOS), de forma que o nome do servidor corresponda aos certificados que estão em vigor.

Caso as conexões com o servidor utilizem o protocolo TCP, verifique se as propriedades do pool do Office Communications Server estão definidas como a porta de escuta TCP 5060.

Falhas na entrada com a configuração automática

Com a configuração automática, poderão ocorrer problemas com a configuração do DNS, os certificados ou a nomenclatura do servidor.

Configuração do DNS

Se você estiver usando a configuração automática, verifique se o nome do servidor publicado no DNS tem suporte do certificado do servidor. Para obter informações sobre a necessidade de criação de registros DNS que habilitem a descoberta de clientes e servidores, além de suporte à entrada automática de clientes (caso sua organização deseje oferecer suporte a essa função), consulte o artigo “Requisitos de DNS (Sistema de Nomes de Domínio)” do Microsoft Office Communications Server 2007 R2 em https://go.microsoft.com/fwlink/?linkid=146936.

Quando os clientes forem configurados para entrar automaticamente, verifique a existência do registro SRV de DNS apropriado. Quando usar uma conexão TLS, adicione o registro SRV a seguir e mapeie-o para o registro de host do servidor:

_sipinternaltls._tcp.<domínio> através da porta 5061.

Observação:
Caso o domínio SIP seja diferente do domínio do Office Communications Server, recomenda-se a criação de um registro de host sip.<domínio> em vez do registro de host do Office Communications Server.

Quando usar uma conexão TCP, adicione o registro SRV a seguir e mapeie-o para o registro de host do servidor:

_sipinternal._tcp.<domínio> através da porta 5060.

Verificação de nome restrito

Se os clientes utilizarem a configuração automática para entrar e o TLS for necessário, às vezes as falhas na conexão poderão ser associadas à definição da diretiva EnableStrictDNSNaming. Quando o Communicator estiver configurado para conexão automática e o TLS for imposto, essa diretiva permitirá que o Office Communicator envie e receba mensagens instantâneas com segurança durante o uso do SIP Communications Service. Essa diretiva não afeta os serviços do Windows .NET ou do Microsoft Exchange Server. Boa parte da confusão em torno da diretiva EnableStrictDNSNaming resulta de uma descrição pouco clara da diretiva. Sua configuração incorreta poderá provocar problemas inesperados na negociação do TLS e na entrada do cliente. A explicação correta dessa diretiva é apresentada a seguir.

Se você definir a diretiva EnableStrictDNSNaming como Enabled, os clientes do Communicator só poderão se conectar a um servidor se o nome dele coincidir com o domínio do URI do SIP do usuário, ou se seu FQDN for sip.<domínio do URI>. Por exemplo, se o URI do SIP do usuário for nome@contoso.com, o Communicator só conseguirá se conectar aos seguintes servidores:

• contoso.com
• sip.contoso.com

Se você não configurar essa diretiva ou se a definir como Disabled, os clientes do Communicator poderão se comunicar com qualquer servidor SIP cujo FQDN termine com a parte de domínio do URI do SIP do usuário. Por exemplo, o Communicator conseguirá se comunicar com os servidores denominados sip.division.contoso.com ou lc.contoso.com. A desvantagem é que um invasor poderá responder à consulta DNS inicial com um nome de servidor, por exemplo, invasor.contoso.com. Ao deixar de configurar essa diretiva ou desabilitá-la, você poderá ficar mais vulnerável a ataques “man-in-the-middle”.

Uma razão para não habilitar essa diretiva será quando a organização tiver vários subdomínios e, ao configurar certificados, você precise da flexibilidade de permitir o uso de nomes de servidor não restritos.

Para habilitar a diretiva, verifique se o FQDN do servidor SIP corresponde a um dos formatos de nomenclatura restrita.

Observação:
Você pode configurar essa definição de diretiva em Configuração do Computador e em Configuração do Usuário, mas a definição de Configuração do Computador tem precedência.

Usuários externos impossibilitados de entrar

Se os usuários internos conseguirem entrar, mas os externos tiverem problemas para isso, é possível que haja um problema no modo de configuração dos protocolos de autenticação, com as portas especificadas durante a entrada ou com as configurações de criptografia do servidor.

Definir o protocolo de autenticação como NTLM e Kerberos

O Office Communications Server 2007 R2 usa os protocolos de autenticação Kerberos ou NTLM, dependendo do local do usuário. O protocolo Kerberos, que requer conectividade de cliente com o Active Directory, é utilizado para usuários internos com credenciais do Active Directory. Os usuários externos com credenciais do Active Directory, mas que se conectam de fora do firewall corporativo, utilizam NTLM.

Se os usuários externos não puderem fazer a autenticação, verifique se o protocolo de autenticação está definido como NTLM e Kerberos nas propriedades do servidor front-end do Office Communications Server.

Entrada manual do cliente na porta 5061, escuta da Borda de Acesso na 443

Os clientes que se conectam de fora do firewall corporativo usam a porta 443 para a comunicação SIP com Servidores de Borda. Às vezes, os clientes são configurados para se conectarem ao servidor usando configuração manual, mas o servidor externo é configurado com a porta incorreta. Por exemplo, se um cliente estiver configurado manualmente para se conectar a um servidor na porta 5061 enquanto o Servidor de Borda de Acesso estiver escutando na porta 443, haverá falha na conexão. Verifique as Configurações Avançadas de Conexão do cliente em Nome do Servidor Externo ou Endereço IP e confirme se a entrada especifica a porta 443; por exemplo, sip.domain.com:443.

Além disso, defina a porta 443 se usar a Diretiva de Grupo para especificar o nome do servidor externo.

Incompatibilidade entre NTLMMINCLIENTSEC e NTLMMINSERVERSEC

As organizações podem usar diretivas locais e de grupo para definir configurações de segurança específicas nos domínios do Windows Server a fim de reforçar a segurança. Uma configuração desse tipo é a configuração de autenticação NTLMv2, que pode ser definida para exigir criptografia na comunicação entre servidores e clientes. Caso as configurações do lado do cliente e do lado do servidor não coincidam, não será possível estabelecer comunicação.

As configurações para a autenticação NTLMv2 estão localizadas no Registro da seguinte maneira:

HKey_Local_Machine\System\CurrentControlSet\Control\Lsa\MSV1_0ntlmminclientsec

HKey_Local_Machine\System\CurrentControlSet\Control\Lsa\MSV1_ ntlmminserversec

Às vezes, o servidor estará configurado para exigir criptografia e o cliente não estará. Nesse caso, a solicitação NTLM do cliente não será passada pelo servidor front-end. Essa situação afeta principalmente os usuários externos, pois o NTLM é o único protocolo de autenticação que os clientes externos podem usar como entrada. Por exemplo, caso a chave do servidor esteja configurada para ter o valor 0x20080030, que especifica a criptografia de 128 bits, mas os clientes não estejam, os clientes não conseguirão entrar. Certifique-se de que essa chave no cliente esteja definida de modo a coincidir com a configuração do servidor.

Para obter mais informações, consulte o artigo 823659 da Base de Dados de Conhecimento Microsoft, “Incompatibilidades de cliente, de serviço e de programa que podem ocorrer ao modificar as configurações de segurança e as atribuições dos direitos de usuário”, em https://go.microsoft.com/fwlink/?linkid=147230.