Você está offline; aguardando reconexão

Enterprise single sign-on usuários no Office 365 não podem entrar no Skype para negócios on-line de dentro de sua rede corporativa

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
PROBLEMA
Considere o seguinte cenário:
  • Um Office 365 para empresas, Office 365 para educação ou 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 Skype para negócios Online(formerly 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 Skype para negócios on-line usando o 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 Skype para negócios on-line 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: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:

    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.
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: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 .

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 2839539 - Última Revisão: 05/01/2015 18:04:00 - Revisão: 11.0

Skype for Business Online

  • o365022013 o365 o365e o365a o365m kbgraphxlink kbgraphic kbmt KB2839539 KbMtpt
Comentários
html>