Enterprise single sign-on usuários no Office 365 não podem entrar no Lync Online de dentro de sua rede corporativa

Traduções deste artigo Traduções deste artigo
ID do artigo: 2839539 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

PROBLEMA

Considere o seguinte cenário:
  • Um Microsoft Office 365 para empresas, o Microsoft Office 365 para educação ou o Microsoft Office 365 para clientes de empresas de médio porte configura o logon único (SSO) nos serviços de Federação do Active Directory (AD FS) 2.0.
  • Os usuários federados que se conectam de dentro de sua rede corporativa não podem entrar no Lync Online do Lync 2013 e recebem a seguinte mensagem de erro:
    Não é possível entrar porque o servidor está temporariamente indisponível.
Observação Esse problema aplica-se somente aos usuários de SSO empresarial que entrar no Microsoft Lync Online usando o Microsoft Lync 2013 de dentro de sua rede corporativa. O problema não se aplica a usuários no Microsoft Lync 2010, os usuários que não estão no Lync Online ou os usuários que se conectam de fora de sua rede corporativa.

SOLUÇÃO

Importante Siga cuidadosamente as etapas nesta seção. Problemas sérios poderão ocorrer se você modificar o Registro incorretamente. Antes de modificá-lo, Faça backup do registro para restauração no caso de ocorrerem problemas.

Como existem várias causas possíveis, é melhor trabalhar por meio de todas as soluções a seguintes e, em seguida, verifique se a configuração.
  1. Quando você implanta um AD FS 2.0 federação Server farm, você deve especificar uma conta de serviço com base em domínio que precisa de um SPN registrado para habilitar a autenticação Kerberos funcione corretamente. Para obter mais informações, consulte o wiki do TechNet a seguir:
    O AD FS 2.0: Como configurar o SPN (servicePrincipalName) para a conta de serviço
    Os motivos pelos quais você talvez precise definir o SPN manualmente na conta do AD FS 2.0 service são as seguintes:
    • Falha no registro do SPN durante a configuração inicial do farm.
    • O nome do serviço de Federação foi alterado.
    • A conta de serviço foi alterada.
  2. Certifique-se de que o AD FS 2.0 service está executando sob a conta de serviço com base em domínio foi mencionada na etapa anterior. Por exemplo, na imagem a seguir, TRLABV3 é o nome de host interno e ADFSSvc é a conta de serviço:

    Recolher esta imagemExpandir esta imagem
    Tomada de tela dos AD FS 2.0 Windows Service Properties, mostrando a conta de domínio

  3. Configurar o AD FS 2.0 server para aceitar cabeçalhos de solicitação são maiores do que 40 KB (Quilobytes). Talvez você precise fazer isso quando o usuário é membro de muitos grupos de usuários de serviços de domínio Active Directory (AD DS). Quando um usuário é membro de muitos grupos do AD DS, aumenta o tamanho do token de autenticação Kerberos para o usuário.

    A solicitação HTTP que o usuário envia para o servidor de serviços de informações da Internet (IIS) contém o token Kerberos no cabeçalho WWW-Authenticate. Portanto, o tamanho do cabeçalho aumenta conforme o aumento do número de grupos. Se o cabeçalho HTTP ou tamanho de pacote aumenta além dos limites que estão configurados no IIS, o IIS pode rejeitar a solicitação e enviar um erro como resposta. Para obter mais informações, consulte o seguinte artigo da Base de Conhecimento Microsoft:
    2020943 Erro "HTTP 400 - Solicitação incorreta (solicitação de cabeçalho muito longo)" no Internet Information Services (IIS)
    Para contornar esse problema, use um dos seguintes métodos:
    1. Diminua o número de grupos de usuários do AD DS que o usuário é membro.
    2. Altere o MaxFieldLength e os valores de registro MaxRequestBytes no servidor que está executando o IIS para que os cabeçalhos de solicitação do usuário não são considerados muito longos. Esses dois valores de registro estão localizadas na seguinte subchave do registro:
      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
  4. Se você implantou várias AD FS 2.0 servidores em um farm e tê-los a carga equilibrada, o cliente do Lync 2013 talvez consiga direcionar a solicitação para o AD FS 2.0 server. Adicionando uma entrada para o AD FS 2.0 server ao arquivo Hosts no cliente que aponta diretamente para o AD FS 2.0 server ignora o IP virtual do balanceador de carga.
  5. Se as soluções anteriores não resolverem o problema e fazer o downgrade para o Lync 2010 não é uma opção, siga estas etapas para solucionar o problema.

    Observação Se uma conta de administrador local não existir no computador, você precisará criar uma para essa solução funcione.
    1. Navegue até o Lync 2013 executável no Windows Explorer:
       C:\Program Files\Microsoft Office 15\root\office15
    2. Mantenha pressionada a tecla Shift e, em seguida, clique com o botão Lync.exe.
    3. Clique em Executar como usuário diferente.
    4. Insira as credenciais para uma conta de administrador local no computador e, em seguida, pressione Enter.

OBTER MAIS INFORMAÇÕES

Esse problema normalmente ocorre devido a um erro de configuração do AD FS 2.0. Outros serviços, como o Microsoft Exchange Online podem funcionar corretamente, apesar dessa configuração. As causas habituais estão listadas aqui:
  • O ServicePrincipalName (SPN) não está configurado corretamente. As razões para isso incluem o seguinte:
    • Falha no registro do SPN durante a configuração inicial do farm.
    • O nome do serviço de Federação foi alterado.
    • A conta de serviço foi alterada.
  • O AD FS 2.0 service não está sendo executado sob a conta do serviço correto.
  • O cabeçalho de solicitação do Lync 2013 é rejeitada pelo IIS e o AD FS 2.0 server porque o cabeçalho é muito grande. Esse problema pode ocorrer porque a conta de usuário é um membro de muitos grupos de usuário do AD DS.
  • O AD FS 2.0 server farm é com balanceamento de carga e a solicitação não está atingindo o AD FS 2.0 server.
Para obter mais ajuda com a implantação do AD FS 2.0 para uso com o SSO no Office 365, consulte o seguinte site do TechNet:
Planejar e implantar o AD FS para uso com o serviço single sign-on
No caso de quando o usuário é um membro de muitos grupos do AD DS, a seguinte entrada é inserida nos logs de rastreamento do Microsoft Online Services Sign-In Assistant (esses logs estão usualmente localizados no C:\ MSOSSPTrace):
##TestHook: URL-

https://<ADFSServer>/adfs/services/trust/2005/windowstransport@transport.cpp_245

.....

.....

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request - Request Too Long</h2>

<hr><p>HTTP Error 400. The size of the request headers is too long.</p>

</BODY></HTML>

Ainda precisa de ajuda? Vá para o Comunidade do Office 365 no site da Web.

Propriedades

ID do artigo: 2839539 - Última revisão: quinta-feira, 26 de junho de 2014 - Revisão: 10.0
A informação contida neste artigo aplica-se a:
  • Microsoft Lync Online
Palavras-chave: 
o365022013 o365 o365e o365a o365m kbgraphxlink kbgraphic kbmt KB2839539 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.
Clique aqui para ver a versão em Inglês deste artigo: 2839539

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com