Solucionar problemas do AD FS no Azure Active Directory e o Office 365

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: 3079872
Este artigo descreve o fluxo de trabalho de solução de problemas para problemas de autenticação para usuários federados no Azure Active Directory ou do Office 365.
Sintomas
  • Os usuários federados não podem fazer logon no Office 365 ou Microsoft Azure Embora usuários somente nuvem gerenciados que têm um sufixo UPN de domainxx.onmicrosoft.com podem fazer logon sem nenhum problema.
  • Redirecionamento para os serviços de Federação do Active Directory (AD FS) ou STS não ocorrer para um usuário federado. Ou, um erro "A página não pode ser exibida" é acionado.
  • Você receberá um aviso relacionadas a certificados em um navegador quando você tentar autenticar com o AD FS. Isso indica que a validação do certificado falhará ou o certificado não é confiável.
  • Erro de "Método de autenticação desconhecido" ou erros indicando que não há suporte para AuthnContext. Além disso, erros no nível do AD FS ou STS quando você é redirecionado do Office 365.
  • O AD FS gera um erro "Acesso negado".
  • O AD FS gera um erro informando que há um problema ao acessar o site. Isso inclui um número de ID de referência.
  • O usuário é repetidas solicitações de credenciais no nível do AD FS.
  • Os usuários federados não podem autenticar em uma rede externa ou quando eles utilizarem um aplicativo que utiliza a rota de rede externa (por exemplo, Outlook).
  • Os usuários federados não podem fazer logon após um certificado de assinatura de token é alterado no AD FS.
  • Um erro "Sorry, mas estamos conseguindo sessão" é acionado quando um usuário federado entra no Office 365 no Microsoft Azure. Este erro inclui códigos de erro como C de 8004786, 80041034, 80041317, 80043431, 80048163, 80045C 06, solicitação 8004789A ou incorreta.

Solução de problemas de fluxo de trabalho
  1. Acesso https://login.microsoftonline.come então digite (de nome de login do usuário federadoalguém@exemplo.com). Depois que você pressionar Tab para remover o foco da caixa de logon, verifique se o status da página altera para "Redirecionamento" e, em seguida, você será redirecionado para a federação serviço do Active Directory (AD FS) para entrar.

    Quando ocorre o redirecionamento, consulte a seguinte página:

    Captura de tela da etapa 1
    1. Se nenhum redirecionamento ocorrerá e você será solicitado a digitar uma senha na mesma página, isso significa que Azure do Active Directory (AD) ou Office 365 não reconhece o usuário ou o domínio do usuário seja federado. Para verificar se há uma relação de confiança de federação entre Azure AD ou executar o Office 365 e o servidor do AD FS, o Get-msoldomain cmdlet do PowerShell do Azure AD. Se um domínio estiver agrupado, sua propriedade de autenticação será exibida como "Agrupados", como na seguinte imagem capturada:

      Etapa sobre domínio agrupados
    2. Se o redirecionamento ocorrerá, mas você não serão redirecionados para o servidor do AD FS para entrar, verifique se o nome de serviço do AD FS resolve para o correto IP e se ele pode se conectar a esse IP na porta TCP 443.

      Se o domínio é exibido como "Agrupados", obter informações sobre a relação de confiança de federação, executando os seguintes comandos:
      Get-MsolFederationProperty -DomainName <domain>
      Get-MsolDomainFederationSettings -DomainName <domain>
      Verifique o URI, o URL e o certificado do parceiro de federação que é configurado pelo Office 365 ou AD Azure.
  2. Depois que você será redirecionado para o AD FS, o navegador pode lança um erro relacionado a relação de confiança de certificado e para alguns clientes e dispositivos não permite que você estabeleça uma sessão SSL com o AD FS. Para resolver esse problema, execute as seguintes etapas:
    1. Certifique-se de que o certificado de comunicação de serviço do AD FS é apresentado para o cliente é o mesmo que esteja configurado no AD FS.

      A screen shot sobre A etapa

      Idealmente, o certificado de comunicação de serviço do AD FS deve ser o mesmo que o certificado SSL apresentado para o cliente quando ele tenta estabelecer um túnel SSL com o serviço do AD FS.

      No AD FS 2.0:

      • Vincule o certificado ao IIS-> primeiro site padrão.
      • Use o snap-in do AD FS para adicionar o mesmo certificado que o certificado de comunicação do serviço.

      No AD FS 2012 R2:

      • Use o snap-in do AD FS ou o Adicionar adfscertificate comando para adicionar um certificado de comunicação do serviço.
      • Use o Conjunto de adfssslcertificate comando para definir o mesmo certificado para ligação de SSL.

    2. Verifique se que esse certificado de comunicação de serviço do AD FS é confiável para o cliente.
    3. Se clientes não SNI – suporte estiver tentando estabelecer uma sessão SSL com o AD FS ou WAP R2 de 2 a 12, poderá falhar a tentativa. Nesse caso, considere a adição de uma entrada de Fallback nos servidores do AD FS ou WAP para oferecer suporte a clientes não SNI. Para obter mais informações, consulte o seguinte blog postar:
  3. Você pode encontrar um erro de "Método de autenticação desconhecido" ou erros informando que AuthnContext não é suportado no nível do AD FS ou STS quando você é redirecionado do Office 365. Isso é mais comum quando o Office 365 e AD Azure redireciona para o AD FS ou STS usando um parâmetro que impõe um método de autenticação. Para aplicar um método de autenticação, use um dos seguintes métodos:
    • De WS-Federation, use uma seqüência de caracteres de consulta WAUTH para forçar um método preferencial de autenticação.
    • Para SAML2.0, use o seguinte:
      <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext>
    Quando o método de autenticação imposta é enviado com um valor incorreto ou se esse método de autenticação não é compatível com o AD FS ou STS, você receberá uma mensagem de erro antes de ser autenticado.

    A tabela a seguir mostra o tipo de autenticação URIs são reconhecidos pelo AD FS para WS-Federation autenticação de passiva.
    Método de autenticação desejadowauth URI
    Autenticação de nome e senha de usuáriourn: oasis: nomes: tc: SAML:1.0:am:password
    Autenticação de cliente SSLurn: ietf:rfc:2246
    Autenticação integrada do Windowsurn: Federação: autenticação: windows

    Suporte SAML classes de contexto de autenticação

    Método de autenticação Classe de contexto de autenticação URI
    Nome de usuário e senhaurn: oasis: nomes: tc: SAML:2.0:ac:classes:Password
    Transporte protegido por senhaurn: oasis: nomes: tc: SAML:2.0:ac:classes:PasswordProtectedTransport
    Cliente do Transport Layer Security (TLS)urn: oasis: nomes: tc: SAML:2.0:ac:classes:TLSClient
    Certificado x. 509urn: oasis: nomes: tc: SAML:2.0:ac:classes:X 509
    Autenticação integrada do Windowsurn: Federação: autenticação: windows
    Kerberosurn: oasis: nomes: tc: SAML:2.0:ac:classes:Kerberos

    Para certificar-se de que o método de autenticação é suportado no nível do AD FS, verifique o seguinte.

    O AD FS 2.0

    Em baixo /ADFS/ls/Web.config, certifique-se de que a entrada para o tipo de autenticação estiver presente.

    <microsoft.identityServer.web></microsoft.identityServer.web>
    <localAuthenticationTypes></localAuthenticationTypes>
    Adicionar nome = "Forms" page="FormsSignIn.aspx" / >
    <add name="Integrated" page="auth/integrated/"></add>
    <add name="TlsClient" page="auth/sslclient/"></add>
    <add name="Basic" page="auth/basic/"></add>


    O AD FS 2.0: Como alterar o tipo de autenticação local

    AD FS 2012 R2

    Em baixo Gerenciamento do AD FS, clique em Políticas de autenticação no snap-in do AD FS.

    Na Autenticação primária seção, clique em Editar lado a lado Configurações globais. Você pode também clique com botão direito Políticas de autenticação e, em seguida, selecione Editar autenticação primária Global. Ou, além de Ações painel, selecione Editar autenticação primária Global.

    Na Editar diretiva de autenticação Global janela, diante do Principal guia, você pode definir configurações como parte da diretiva de autenticação global. Por exemplo, para autenticação primária, você pode selecionar métodos de autenticação disponíveis em Extranet e Intranet.

    * * Verifique se a caixa de seleção do método de autenticação necessário está selecionada.
  4. Se familiarize-se com o AD FS e insira as credenciais a você, mas você não poderá ser autenticada, verifique os seguintes problemas.
    1. Problema de replicação do Active Directory

      Se a replicação do AD for interrompida, as alterações feitas ao usuário ou grupo não poderão sincronizadas entre controladores de domínio. Entre controladores de domínio, pode haver uma senha, UPN, GroupMembership, ou Proxyaddress incompatibilidade que afeta a resposta do AD FS (autenticação e declarações). Você deve começar a examinar os controladores de domínio no mesmo site do AD FS. Executando um repadmin /showreps ou um DCdiag /v comando deve revelar se há um problema nos controladores de domínio do AD FS é mais provável de contato.

      Você também pode coletar um resumo de replicação do AD para certificar-se de AD alterações estão sendo replicadas corretamente em todos os controladores de domínio. O Repadmin /showrepl * /csv > Showrepl a saída é útil para verificar o status da replicação. Para obter mais informações, consulte Solucionando problemas de replicação do Active Directory.
    2. Conta bloqueada ou desativada no Active Directory

      Quando um usuário final é autenticado por meio do AD FS, ele ou ela não receberá uma mensagem de erro informando que a conta é bloqueada ou desativada. O AD FS e a auditoria de Logon, você deve ser capaz de determinar se a autenticação falhou devido a uma senha incorreta se a conta está desabilitada ou bloqueada e assim por diante.

      Para habilitar o AD FS e auditoria sobre o AD FS, servidores de Logon, execute as seguintes etapas:
      1. Use diretiva local ou de domínio para ativar o sucesso e falha para as diretivas a seguir:
        • Auditoria de eventos de logon, localizado em configuração do computador \ Configurações de segurança setting\Local política de Policy\Audit"
        • Auditoria de acesso a objetos, localizada em configuração do computador \ Configurações de segurança setting\Local política de Policy\Audit"
        A screen shot sobre políticas
      2. Desative a diretiva a seguir:

        Auditoria: Configurações de subcategorias de diretivas forçar auditoria (Windows Vista ou posterior) para substituir configurações de categorias de diretiva de auditoria

        Essa diretiva está localizada em configuração do computador \ Configurações de segurança setting\Local opção de diretiva.

        A screen shot sobre política

        Se você deseja configurar isso usando auditoria avançada, clique em aqui.
      3. Configure o AD FS para auditoria:
        1. Abrir o AD FS 2.0 snap-in Gerenciamento.
        2. No painel de ações , clique em Editar propriedades de serviço de Federação.
        3. No Propriedades de serviço de Federação caixa de diálogo, clique o eventos guia.
        4. Selecione o auditorias com êxito e Failure audits caixas de seleção.

          Sceenshot sobre como habilitar a auditoria do AD FS
        5. Executar GPupdate /force no servidor.
    3. Nome Principal de serviço (SPN) é registrado incorretamente

      Pode haver SPNs duplicados ou um SPN registrado em uma conta diferente da conta de serviço do AD FS. Para uma configuração de Farm do AD FS, certifique-se de que SPN HOST/AD FSservicename é adicionado com a conta de serviço que está executando o serviço do AD FS. Para uma instalação autônoma do AD FS, onde o serviço está sendo executado em Serviço de rede, o SPN deve estar sob a conta de computador do servidor que está hospedando o AD FS.

      A screen shot para nome de serviço do AD FS

      Certifique-se de que não existem SPNs duplicados para o serviço do AD FS, pois isso pode causar falhas intermitentes de autenticação com o AD FS. Para listar os SPNs, executar SETSPN-L<ServiceAccount></ServiceAccount>.

      A screen shot sobre lista SPN

      Executar SETSPN ServiceAccount de FSservicename – um HOST/AD Para adicionar o SPN.

      Executar SETSPN-X -F Para verificar se os SPNs duplicados.
    4. UPNs duplicados no Active Directory

      Um usuário pode ser capaz de autenticação por meio do AD FS quando elas estão usando SAMAccountName mas não poderá autenticar ao usar o UPN. Nesse cenário, o Active Directory pode conter dois usuários que têm o mesmo UPN. É possível acabar com dois usuários que tenham o UPN mesmo quando os usuários são adicionados e modificados por meio de scripts (ADSIedit, por exemplo).

      Quando o UPN é usado para a autenticação neste cenário, o usuário é autenticado contra o usuário duplicado. Portanto, as credenciais fornecidas não são validadas.

      Você pode usar consultas como o seguinte para verificar se há vários objetos no AD que têm os mesmos valores para um atributo:
      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

      Certifique-se de que o UPN do usuário duplicado é renomeado, para que a solicitação de autenticação com o UPN é validada em relação os objetos corretos.
    5. Em um cenário onde você está usando o seu endereço de e-mail como o ID de login no Office 365 e digite o mesmo endereço de e-mail quando você é redirecionado para o AD FS para autenticação, a autenticação poderá falhar com um erro de "NO_SUCH_USER" nos logs de auditoria. Para habilitar o AD FS localizar um usuário para a autenticação usando um atributo diferente de UPN ou SAMaccountname, você deve configurar o AD FS para dar suporte a uma identificação de logon alternativo. Para obter mais informações, consulte Configurando a identificação de logon alternativo.

      No AD FS 2012 R2

      1. Instalar o Atualização de 2919355.
      2. Atualizar a configuração do AD FS, executando o seguinte cmdlet do PowerShell em qualquer um dos servidores de federação no farm (se você tiver um farm de trabalho, você deve executar este comando no servidor primário do AD FS no seu farm):

        Conjunto AdfsClaimsProviderTrust - TargetIdentifier "AD AUTHORITY" - AlternateLoginID <attribute>- LookupForests <forest domain=""></forest> </attribute>

        Observação:AlternateLoginID é o nome LDAP do atributo que você deseja usar para fazer logon. E LookupForests é a lista de entradas DNS que seus usuários pertencem a florestas.

        Para habilitar o recurso de ID de logon alternativo, você deve configurar o AlternateLoginID e LookupForests parâmetros com um valor não-nulo, válido.

    6. A conta de serviço do AD FS não tem acesso de leitura no token do AD FS que está assinando a chave particular do certificado. Para adicionar essa permissão, siga estas etapas:
      1. Quando você adiciona um novo certificado de autenticação de Token, você recebe o seguinte aviso: "Certifique-se de que a chave particular para o certificado escolhido está acessível para a conta de serviço para esse serviço de Federação em cada servidor no farm."
      2. Clique em Iniciar, Executar, tipo MMC.exe, e então pressione Enter.
      3. Clique em Arquivo e, em seguida, clique em Adicionar/Remover Snap-in.
      4. Clique duas vezes em certificados.
      5. Selecione a conta de computador em questão e, em seguida, clique em Avançar.
      6. Selecione computador Locale clique em Concluir.
      7. Expanda certificados (computador Local), expanda <b00> </b00>Personal e selecione certificados.
      8. Clique com botão direito o novo certificado de autenticação de token, selecione Todas as tarefase, em seguida, selecione Gerenciar chaves particulares.

        Sceenshot sobre a etapa 8
      9. Adicionar acesso de leitura para a conta de serviço 2.0 do AD FS e, em seguida, clique em OK.
      10. Feche os MMC de certificados.
    7. A opção de Proteção estendida para autenticação do Windows está habilitada para o diretório virtual do AD FS ou LS. Isso pode causar problemas com navegadores específicos. Às vezes, você poderá ver repetidamente pedir credenciais do AD FS, e isso pode estar relacionado à Proteção estendida configuração está ativada para a autenticação do Windows para o aplicativo do AD FS ou LS no IIS.

      Sceenshot sobre a etapa 8
      Quando Proteção estendida autenticação estiver ativado, as solicitações de autenticação são vinculadas a ambos os nomes principais de serviço (SPNs) do servidor para que o cliente tenta se conectar e o canal de segurança de camada de transporte (TLS) externa na qual ocorre a autenticação integrada do Windows. Proteção estendida aprimora a funcionalidade de autenticação do Windows existente para atenuar as retransmissões de autenticação ou ataques de "homem no meio". No entanto, alguns navegadores não funcionam com o Proteção estendida configuração; em vez disso, eles repetidamente solicitam credenciais e negam o acesso. Desativando Proteção estendida Ajuda é nesse cenário.

      Para obter mais informações, consulte O AD FS 2.0: Continuamente as credenciais solicitadas ao usar o depurador do Fiddler web.

      No AD FS 2012 R2

      Execute o seguinte cmdlet para desativar Extendedprotection:

      Conjunto ADFSProperties-ExtendedProtectionTokenCheck None

    8. Regras de autorização de emissão na relação de confiança de terceiros contar (RP) podem negar acesso a usuários. Sobre a relação de confiança do AD FS terceira parte, você pode configurar as regras de autorização de emissão que controlam se um usuário autenticado deve ser emitido um token para um interlocutor dependente. Os administradores podem usar as declarações que são emitidas para decidir se deseja negar o acesso de um usuário que seja membro de um grupo que é puxado como uma declaração.

      Se determinados usuários federados não podem autenticar por meio do AD FS, convém verificar as regras de autorização de emissão para o Office 365 RP e ver se o Permitir o acesso a todos os usuários regra é configurada.

      A screen shot sobre regras
      Se esta regra não é definir, examinar as regras de autorização personalizada para verificar se a condição na regra avalia "true" para o usuário afetado. Para obter mais informações, consulte os seguintes recursos:
      Se você pode autenticar a partir de uma intranet quando você acessar o servidor do AD FS diretamente, mas você não pode autenticar quando você acessar o AD FS por meio de um proxy do AD FS, verifique os seguintes problemas:
      • Problema de sincronização de tempo no servidor do AD FS e proxy do AD FS

        Verifique se a hora no servidor do AD FS e a hora no proxy estão em sincronia. Quando o tempo do servidor do AD FS está desativado por mais de cinco minutos do horário nos controladores de domínio, ocorrem falhas de autenticação. Quando o tempo no proxy do AD FS não é sincronizado com o AD FS, a relação de confiança de proxy é afetada e quebrada. Portanto, não uma solicitação que vem através do proxy do AD FS.
      • Verifique se o proxy do AD FS confiança com o serviço AD FS está funcionando corretamente. Execute novamente a configuração do proxy se você suspeitar que a relação de confiança de proxy está quebrada.
  5. Depois que o AD FS emite um token, o Azure AD ou Office 365 gera um erro. Nessa situação, verifique os seguintes problemas:
    • As declarações emitidas pelo AD FS no token devem coincidir com os respectivos atributos do usuário no AD Azure. No símbolo para AD Azure ou Office 365, as declarações a seguintes são necessárias.

      WSFED:
      UPN: O valor desta declaração deve corresponder o UPN dos usuários no AD Azure.
      ImmutableID: O valor desta declaração deve coincidir com a sourceAnchor ou ImmutableID do usuário no Azure AD.

      Para obter o valor do atributo de usuário no AD Azure, execute a seguinte linha de comando: Get-MsolUser – UserPrincipalName<UPN></UPN>

      SAML 2.0:
      IDPEmail: O valor desta declaração deve corresponder o nome principal de usuário dos usuários no AD Azure.
      NAMEID: O valor desta declaração deve coincidir com a sourceAnchor ou ImmutableID do usuário no Azure AD.

      Para obter mais informações, consulte Use um provedor de identidade SAML 2.0 para implementar o serviço single sign-on.

      Exemplos:
      Esse problema pode ocorrer quando o UPN do usuário sincronizado é alterado no AD, mas sem atualizar o diretório on-line. Nesse cenário, você pode corrigir UPN do usuário no AD (para corresponder ao nome de logon do usuário relacionados) ou execute o seguinte cmdlet para alterar o nome de logon do usuário relacionado no diretório on-line:

      Conjunto MsolUserPrincipalName - UserPrincipalName [ExistingUPN] - NewUserPrincipalName [DomainUPN-AD]

      Pode ser também que você está usando AADsync para sincronização Enviar como UPN e EMPID como SourceAnchor, mas o parceiro dependente de declaração de regras no nível do AD FS não foram atualizadas para enviar Enviar como UPN e EMPID como ImmutableID.
    • Há uma incompatibilidade de certificado de autenticação de token entre o AD FS e o Office 365.

      Esse é um dos problemas mais comuns. O AD FS usa o certificado de autenticação de tokens para assinar o token é enviado para o usuário ou aplicativo. A relação de confiança entre o Office 365 e o AD FS é uma relação de confiança federada com base em certificado de autenticação de token (por exemplo, Office 365 verifica que o token recebido é assinado com um certificado de autenticação de token do provedor de declarações [o serviço AD FS] que ele confia).

      Se o certificado de autenticação de token no AD FS é alterado devido à sobreposição de certificado automático ou por intervenção do administrador (depois ou antes da expiração do certificado), os detalhes sobre o novo certificado deve ser atualizado no inquilino do Office 365 para o domínio federado.

      Office 365 ou Azure AD tentará chegar ao serviço do AD FS, fornecido acessível da rede pública. Podemos tentar sondar os metadados de Federação do ADFS em intervalos regulares, para receber alterações de configuração no ADFS, principalmente o certificado de assinatura de token. Se esse processo não estiver funcionando, o Administrador Global verá uma notificação no portal do Office 365, avisando sobre a expiração do certificado de autenticação de Token e com as ações a serem tomadas para atualizá-lo.

      Você pode usar Get-MsolFederationProperty - DomainName<domain></domain> para despejar a propriedade federação no AD FS e o Office 365. Aqui você pode comparar a impressão digital de TokenSigningCertificate para verificar se a configuração de Inquilino do Office 365 para seu domínio federado está em sincronia com o AD FS. Se você encontrar uma incompatibilidade na configuração de certificado de autenticação de tokens, execute o seguinte comando para atualizá-lo:
      Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
      Você também pode executar a seguinte ferramenta para agendar uma tarefa no servidor do AD FS que irá monitorar para a revisão automática de certificados de autenticação de token certificado de atualização Office 365 inquilinos automaticamente.

      Ferramenta de instalação de automação do Microsoft Office 365 federação atualização de metadados

      Verificar e gerenciar o serviço single sign-on com o AD FS
    • Regras de declaração de transformação de emissão para o Office 365 RP não estão configuradas corretamente.

      Em um cenário em que várias TLDs (domínios de nível superior), você poderá ter problemas de logon se o Supportmultipledomain opção não foi usada quando a relação de confiança RP foi criada e atualizada. Para obter mais informações, clique em aqui.
    • Certifique-se de que a criptografia token é não sendo usados pelo AD FS ou STS quando é emitido um token para o Azure AD ou para o Office 365.
  6. Há credenciais armazenadas em cache obsoletas no Gerenciador de credenciais do Windows.

    Às vezes, durante o logon em uma estação de trabalho no Portal (ou ao usar o Outlook), quando o usuário será solicitado a fornecer credenciais, as credenciais podem ser salvos para o destino (serviço Office 365 ou AD FS) no Gerenciador de credenciais do Windows (Gerenciador de controle de Accounts\Credential do Panel\User). Isso ajuda a evitar o prompt de credenciais por algum tempo, mas ele pode causar um problema após a senha do usuário foi alterada e o Gerenciador de credenciais não é atualizado. Nesse cenário, obsoletas credenciais são enviadas para o serviço do AD FS e, portanto, a autenticação falhará. Pode ajudar a remover ou atualizar as credenciais armazenadas no Gerenciador de credenciais do Windows.
  7. Certifique-se de que o algoritmo de Hash seguro que está configurada em contar parte de confiança para o Office 365 é definido como SHA1.

    Quando a relação de confiança entre o STS para o AD FS e o Azure AD/Office 365 usando o protocolo SAML 2.0, o algoritmo de Hash seguro configurado para assinatura digital devem ser SHA1.
  8. Se nenhuma das causas anteriores se aplique à sua situação, criar um caso de suporte com a Microsoft e peça-lhe para verificar se a conta de usuário consistente aparece sob o inquilino do Office 365. Para obter mais informações, consulte os seguintes recursos:

    Mensagem de erro do AD FS 2.0 quando um usuário federado entra no Office 365: "Ocorreu um problema ao acessar o site"

    Um usuário federado é repetidas solicitações de credenciais quando ele se conecta ao ponto de extremidade de serviço 2.0 do AD FS durante a entrada do Office 365
  9. Dependendo de qual serviço de nuvem (integrado ao AD Azure), você está acessando, a solicitação de autenticação é enviada para o AD FS pode variar. Por exemplo: determinadas solicitações podem incluir parâmetros adicionais, como Wauth ou Wfresh, e esses parâmetros podem causar comportamento diferente no nível do AD FS.

    Recomendamos que os binários do AD FS ser mantidas sempre atualizadas para incluir as correções para problemas conhecidos. Para obter mais informações sobre as atualizações mais recentes, consulte a tabela a seguir.

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 3079872 - Última Revisão: 08/11/2015 20:21:00 - Revisão: 2.0

Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Foundation, Windows Server 2008 Standard, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Foundation, Windows Server 2008 R2 Standard, Windows Server 2012 Foundation, Windows Server 2012 Essentials, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 Foundation, Windows Server 2012 R2 Standard

  • kbmt KB3079872 KbMtpt
Comentários