Resolver problemas de AD FS no Azure Active Directory e do Office 365

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 3079872
Este artigo aborda o fluxo de trabalho de resolução de problemas de autenticação para os utilizadores federados acedam Azure Active Directory ou do Office 365.
Sintomas
  • Os utilizadores federados não é possível iniciar sessão no Office 365 ou Microsoft Azure apesar geridos nuvem só os utilizadores que têm um sufixo UPN de domainxx.onmicrosoft.com sessão sem problemas.
  • Redireccionamento de serviços de Federação do Active Directory (AD FS) ou STS não ocorrer devido a um utilizador federado. Ou, é accionado um erro "Não é possível apresentar a página".
  • Recebe um aviso de relacionados com certificados num browser quando tenta autenticar com o AD FS. Indica que a validação do certificado falha ou se o certificado não é fidedigno.
  • Erro de "Método de autenticação desconhecido" ou erros indicando que o AuthnContext não é suportada. Além disso, os erros ao nível do AD FS ou STS quando são redireccionados do Office 365.
  • O AD FS lança um erro "Acesso negado".
  • O AD FS lança um erro a indicar que existe um problema ao aceder ao site; Isto inclui um número de ID de referência.
  • O utilizador é-lhe pedido repetidamente credenciais ao nível do AD FS.
  • Não é possível autenticar os utilizadores federados da rede externa ou quando utilizam uma aplicação que suporte a rota de rede externa (Outlook, por exemplo).
  • Os utilizadores federados não é possível iniciar sessão depois de um certificado de assinatura de tokens é alterado no AD FS.
  • Um erro ", mas estiver com dificuldades em iniciar sessão" é accionado quando um utilizador federado inicia sessão no Office 365 no Microsoft Azure. Este erro inclui códigos de erro, tal como C de 8004786, 80041034, 80041317, 80043431, 80048163, 06 de 80045C, 8004789A ou mau pedido.

Resolução de problemas de fluxo de trabalho
  1. Acesso https://login.microsoftonline.come, em seguida, introduza (de nome de início de sessão do utilizador federadoalguém@exemplo.com). Depois de premir Tab para remover o foco da caixa de início de sessão, verifique se o estado da página é alterado para "Redireccionar" e, em seguida, em está redireccionado para o serviço Active Directory Federation (AD FS) para início de sessão.

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

    Captura de ecrã para o passo 1
    1. Se nenhum redireccionamento ocorre e lhe for pedido para introduzir uma palavra-passe na mesma página, isso significa que Azure do Active Directory (AD) ou do Office 365 não reconhecer o utilizador ou o domínio do utilizador ser federada. Para verificar se existe uma fidedignidade de Federação entre Azure AD ou executar o Office 365 e o servidor de AD FS, o Get-msoldomain cmdlets do PowerShell de AD Azure. Se um domínio é federado, a propriedade de autenticação será apresentada como "Federados," como no seguinte captura de ecrã:

      Passo sobre como domínio federados
    2. Se o redireccionamento ocorre mas não são redireccionadas para o servidor de AD FS para início de sessão, verificar se resolve o nome de serviço do AD FS para a correcta de IP e se pode ligar a esse IP na porta TCP 443.

      Se o domínio é apresentado como "Federados", obter informações sobre a fidedignidade da 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 esteja configurado pelo Office 365 ou Azure AD.
  2. Depois de é redireccionado para AD FS, o browser poderá lança um erro de relacionados com a fidedignidade do certificado e para alguns clientes e dispositivos pode não permitir-lhe estabelecer uma sessão SSL com o AD FS. Para resolver este problema, siga estes passos:
    1. Certifique-se de que o certificado de comunicação do serviço de AD FS que é apresentado para o cliente é igual ao que está configurado no AD FS.

      Captura de ecrã sobre passo A

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

      No AD FS 2.0:

      • Vincular o certificado ao IIS-> site primeiro predefinido.
      • Utilize o snap-in AD FS para adicionar o mesmo certificado como o certificado de comunicação do serviço.

      No AD FS 2012 R2:

      • Utilizar o snap-in AD FS ou o Adfscertificate adicionar comando para adicionar um certificado de comunicação do serviço.
      • Utilizar o Conjunto-adfssslcertificate comandos para definir o mesmo certificado para a ligação SSL.

    2. Certifique-se que esse certificado de comunicação de serviço do AD FS é considerado fidedigno pelo cliente.
    3. Se não SNI – com capacidade de clientes estão a tentar estabelecer uma sessão SSL com o AD FS ou WAP R2 de 2-12, a tentativa poderá falhar. Neste caso, considere adicionar uma entrada de contingência nos servidores para suportar clientes de não SNI o AD FS ou WAP. Para mais informações, consulte a seguinte mensagem no blogue:
  3. Poderá encontrar um erro de "Método de autenticação desconhecido" ou erros indicando que o AuthnContext não é suportada ao nível do AD FS ou STS quando são redireccionados do Office 365. Isto é mais comum quando Office 365 e Azure AD redirecciona para o AD FS ou STS utilizando um parâmetro que impõe um método de autenticação. Para impor um método de autenticação, utilize um dos seguintes métodos:
    • Para WS-Federation, utilize uma cadeia de consulta WAUTH para forçar um método de autenticação preferido.
    • Para SAML2.0, utilize 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 forçada é enviado com um valor incorrecto ou se esse método de autenticação não é suportado no AD FS ou STS, receberá uma mensagem de erro antes de é autenticado.

    A tabela seguinte mostra o tipo de autenticação URIs que são reconhecidos pelo AD FS para WS-Federation autenticação de passiva.
    Método de autenticação que pretendiawauth URI
    Autenticação de nome e palavra-passe de utilizadorurn: oasis: nomes: tc: SAML:1.0:am:password
    Autenticação de cliente SSLurn: ietf:rfc:2246
    Autenticação integrada do Windowsurn: federation: autenticação: o windows

    Suportado SAML classes de contexto de autenticação

    Método de autenticação Classe de contexto de autenticação URI
    Nome de utilizador e palavra-passeurn: oasis: nomes: tc: SAML:2.0:ac:classes:Password
    Transporte de palavra-passe protegidaurn: 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: federation: autenticação: o windows
    Kerberosurn: oasis: nomes: tc: SAML:2.0:ac:classes:Kerberos

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

    O AD FS 2.0

    Em /adfs/ls/Web.config, certifique-se de que a entrada para o tipo de autenticação está presente.

    <microsoft.identityServer.web></microsoft.identityServer.web>
    <localAuthenticationTypes></localAuthenticationTypes>
    Adicionar nome = "Formulários" 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 de locais

    R2 DE 2012 DO AD FS

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

    Do Autenticação primário secção, clique em Editar junto a Definições globais. Pode também com o botão direito Políticas de autenticação e, em seguida, seleccione Editar autenticação primário Global. Ou, do Acções painel, seleccione Editar autenticação primário Global.

    Do Editar política de autenticação Global janela, do Primário separador, pode configurar definições como parte da política de autenticação global. Por exemplo, para autenticação principal, pode seleccionar métodos de autenticação disponíveis em Extranet e Intranet.

    * * Certifique-se de que a caixa de verificação do método de autenticação necessário.
  4. Se obtiver para o AD FS e introduza as credenciais mas não pode ser autenticado, verifique os seguintes problemas.
    1. Problema de replicação do Active Directory

      Se a replicação do AD for interrompida, as alterações efectuadas ao utilizador ou grupo não podem ser sincronizadas através dos controladores de domínio. Entre controladores de domínio, pode existir uma palavra-passe, UPN, GroupMembership, ou Proxyaddress Erro de correspondência que afecta a resposta de AD FS (autenticação e afirmações). Deve iniciar a olhar para os controladores de domínio no mesmo local que o AD FS. Executar uma repadmin /showreps ou um DCdiag /v comando deve revelar se existe um problema nos controladores de domínio que o AD FS é mais provável contactar.

      Também pode recolher um resumo de replicação do AD para se certificar de que AD alterações estão a ser correctamente replicadas em todos os controladores de domínio. O repadmin /showrepl * /csv > Showrepl saída é útil para verificar o estado de replicação. Para mais informações, consulte Resolução de problemas de replicação do Active Directory.
    2. Conta bloqueada ou desactivada no Active Directory

      Quando um utilizador final é autenticado através do AD FS, ele ou ela não irá receber uma mensagem de erro a indicar que a conta está bloqueada ou desactivada. O AD FS e de início de sessão de auditoria, deverá ser capaz de determinar se a autenticação falhou devido a uma palavra-passe incorrecta, se a conta estiver desactivada ou bloqueada e assim sucessivamente.

      Para activar o AD FS e início de sessão de auditoria no suporte de AD FS servidores, siga estes passos:
      1. Utilize a política local ou de domínio para activar ou sem êxito de políticas que se seguem:
        • Auditar eventos de início de sessão, localizado em configuração do computador Definições setting\Local política política"
        • Auditar acesso a objectos, localizada em configuração do computador Definições setting\Local política política"
        O captura sobre as políticas de ecrã
      2. Desactive a seguinte política:

        Auditoria: Forçar definições de subcategoria de política de auditoria (Windows Vista ou posterior) para substituir definições de categoria de política de auditoria

        Esta política está localizada em configuração do computador Definições setting\Local Policy\Security opção.

        O captura sobre a política de ecrã

        Se pretender configurar esta utilizar a auditoria avançadas, clique em Aqui.
      3. Configure o AD FS para auditoria:
        1. Abrir o AD FS 2.0 snap-in de gestão.
        2. No painel de Acções , clique em Editar propriedades do serviço de Federação.
        3. Do Propriedades do serviço de Federação caixa de diálogo, faça clique sobre o eventos separador.
        4. Seleccione o auditorias com e auditorias de falha de caixas de verificação.

          O sceenshot sobre como activar a auditoria de AD FS
        5. Executar GPupdate /force no servidor.
    3. Nome Principal de serviço (SPN) está incorrectamente registado

      Poderão existir SPNs duplicados ou um SPN registado numa conta diferente da conta de serviço do AD FS. Para uma configuração de farm de servidores do AD FS, certifique-se de que SPN HOST/AD FSservicename é adicionada sob a conta de serviço que está a executar o serviço do AD FS. Para uma configuração autónoma de AD FS, onde o serviço está a ser executado Serviço de rede, o SPN tem de estar sob a conta de computador do servidor que hospeda o AD FS.

      Captura de ecrã para o nome de serviço do AD FS

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

      O captura acerca da lista de SPN de ecrã

      Executar SETSPN – um anfitrião/AD FSservicename ContaServiço Para adicionar o SPN.

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

      Um utilizador poderá conseguir autenticar através do AD FS quando eles estão a utilizar SAMAccountName mas não é possível autenticar quando utilizar o UPN. Neste cenário, o Active Directory pode conter dois utilizadores que tenham o mesmo UPN. É possível acabar com dois utilizadores que tenham o UPN mesmo quando os utilizadores são adicionados ou modificados através de scripts (ADSIedit, por exemplo).

      Quando o UPN é utilizado para autenticação neste cenário, o utilizador é autenticado relativamente ao utilizador duplicado. Por conseguinte, as credenciais fornecidas não são validadas.

      Pode utilizar consultas a seguinte para verificar se existem vários objectos no AD que tenham os mesmos valores para um atributo:
      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

      Certifique-se de que é mudado o UPN de utilizador duplicado, para que o pedido de autenticação com o UPN é validado contra os objectos correctos.
    5. Num cenário, quando estiver a utilizar o seu endereço de correio electrónico como o ID de início de sessão no Office 365 e introduzir o mesmo endereço de correio electrónico quando são redireccionados para o AD FS para autenticação, a autenticação poderá falhar com um erro de "NO_SUCH_USER" nos registos de auditoria. Para activar o AD FS localizar um utilizador para a autenticação utilizando um atributo que não o UPN ou SAMaccountname, tem de configurar o AD FS para suportar um ID de início de sessão alternativo. Para mais informações, consulte Configurar o ID de início de sessão alternativo.

      No AD FS 2012 R2

      1. Instalar Actualização 2919355.
      2. Actualizar a configuração do AD FS executando o cmdlet seguinte do PowerShell em qualquer um dos servidores de Federação no farm (se tiver um farm WID, tem de executar este comando no servidor de AD FS principal no farm):

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

        NotaAlternateLoginID é o nome LDAP do atributo que pretende utilizar para início de sessão. E LookupForests é a lista das florestas entradas de DNS que os utilizadores pertencem.

        Para activar a funcionalidade de ID de início de sessão alternativo, tem de configurar tanto o AlternateLoginID e LookupForests parâmetros com um valor não nulo e válido.

    6. A conta de serviço do AD FS não tem acesso de leitura para o token de AD FS que é a chave privada do certificado de assinatura. Para adicionar esta permissão, siga estes passos:
      1. Quando adiciona um novo certificado de assinatura de tokens, recebe a seguinte advertência: "Certifique-se de que a chave privada para o certificado escolhido está acessível para a conta de serviço para este serviço de Federação em cada servidor no farm."
      2. Clique em Iniciar, clique em Executar, tipo MMC.exe, e, em seguida, prima Enter.
      3. Clique em ficheiroe, em seguida, clique em Adicionar/Remover Snap-in.
      4. Faça duplo clique em certificados.
      5. Seleccione a conta de computador em questão e, em seguida, clique em seguinte.
      6. Seleccione o Computador Locale clique em Concluir.
      7. Expanda certificados (computador Local), expanda <b00> </b00>Personal e, em seguida, seleccione certificados.
      8. O novo certificado de assinatura de tokens de contexto, seleccione Todas as tarefase, em seguida, seleccione Gerir chaves privadas.

        O sceenshot sobre o passo 8
      9. Adicionar acesso de leitura para a conta de serviço 2.0 de AD FS e, em seguida, clique em OK.
      10. Feche os certificados da MMC.
    7. A opção de Protecção expandido para a autenticação do Windows está activada para o directório virtual do AD FS ou LS. Isto pode causar problemas com determinados browsers. Por vezes, poderá ver o AD FS repetidamente pedir credenciais e esta poderá estar relacionada com o Protecção adicional definição está activada para a autenticação Windows para a aplicação de AD FS ou LS no IIS.

      O sceenshot sobre o passo 8
      Quando Protecção adicional para autenticação estiver activada, os pedidos de autenticação estão vinculados a ambos os nomes do Principal do serviço (SPN) do servidor para que o cliente tenta estabelecer ligação e para o canal de Transport Layer Security (TLS) exterior através da qual ocorre a autenticação integrada do Windows. Protecção adicional melhora a funcionalidade de autenticação do Windows existente para atenuar os relés de autenticação ou ataques de "intromissão". No entanto, alguns browsers não funcionam com o Protecção adicional definição; em vez disso repetidamente pedir credenciais e, em seguida, negar o acesso. Desactivar Protecção adicional ajuda-o a é neste cenário.

      Para mais informações, consulte O AD FS 2.0: Continuamente solicitadas credenciais ao utilizar o depurador de web Fiddler.

      Para o AD FS 2012 R2

      Execute o cmdlet seguinte para desactivar a Extendedprotection:

      Conjunto-ADFSProperties – ExtendedProtectionTokenCheck nenhum

    8. Regras de autorização de emissão na fidedignidade partes confiem (RP) podem negar o acesso aos utilizadores. Numa fidedignidade o interlocutor dependente AD FS, pode configurar as regras de autorização de emissão que controlam se um utilizador autenticado deve ser emitido um token para um interlocutor. Os administradores podem utilizar as afirmações que são emitidas para decidir se pretende negar acesso a um utilizador que é um membro de um grupo que está ser puxado para cima como uma afirmação.

      Se determinados utilizadores federados não podem ser autenticados através do AD FS, poderá pretender verificar as regras de autorização de emissão RP de 365 Office e ver se o Permitir o acesso a todos os utilizadores regra é configurada.

      O captura sobre as regras de ecrã
      Se esta regra não está a configurar, observe as regras de autorização personalizado para verifique se a condição da regra avalia "true" para o utilizador afectado. Para mais informações, consulte os seguintes recursos:
      Se pode autenticar partir de uma intranet quando aceder ao servidor de AD FS directamente, mas não podem ser autenticados quando acede a AD FS através de um proxy do AD FS, verifique os seguintes problemas:
      • Problema de sincronização de hora no servidor de AD FS e do proxy do AD FS

        Certifique-se de que a hora do servidor de AD FS e a hora a proxy são sincronizados. Quando a hora do servidor de AD FS está desactivada por mais de cinco minutos a partir do momento em controladores de domínio, ocorrem falhas de autenticação. Quando a hora no proxy do AD FS não está sincronizada com o AD FS, a fidedignidade de proxy é afectada e quebrada. Por conseguinte, um pedido que é fornecido através do proxy do AD FS falha.
      • Verifique se o proxy do AD FS fidedignidade com o serviço do AD FS está a funcionar correctamente. Volte a executar a configuração do proxy se suspeitar que a fidedignidade de proxy é interrompida.
  5. Depois do AD FS emite um token, Azure AD ou Office 365 lança um erro. Nesta situação, verifique os seguintes problemas:
    • As afirmações que são emitidas pelo AD FS num token devem corresponder aos respectivos atributos do utilizador no Azure AD. O token para o AD Azure ou Office 365. o, as seguintes afirmações são necessárias.

      WSFED:
      UPN: O valor desta afirmação deve corresponder o UPN dos utilizadores no Azure AD.
      ImmutableID: O valor desta afirmação deverá corresponder ao sourceAnchor ou ImmutableID do utilizador no Azure AD.

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

      SAML 2.0:
      IDPEmail: O valor desta afirmação deve corresponder o nome principal de utilizador dos utilizadores no Azure AD.
      NAMEID: O valor desta afirmação deverá corresponder ao sourceAnchor ou ImmutableID do utilizador no Azure AD.

      Para mais informações, consulte Utilize um fornecedor de identidade de SAML 2.0 para implementar o início de sessão único.

      Exemplos:
      Este problema pode ocorrer quando o UPN de um utilizador sincronizado é alterado no AD mas sem actualizar o directório online. Neste cenário, pode corrigir o UPN de utilizador AD (para corresponder ao nome de início de sessão do utilizador relacionadas) ou executar o cmdlet seguinte para alterar o nome de início de sessão do utilizador relacionado no directório Online:

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

      Também pode ser o que está a utilizar AADsync para sincronizar Enviar como UPN e EMPID como SourceAnchor, mas o interlocutor dependente reclamar regras ao nível do AD FS não tenham sido actualizadas para enviar Enviar como UPN e EMPID como ImmutableID.
    • Existe uma discrepância de certificado de assinatura de tokens entre o AD FS e Office 365.

      Este é um dos problemas mais comuns. O AD FS utiliza o certificado de assinatura de tokens para assinar o token enviado para o utilizador ou aplicação. A fidedignidade entre o AD FS e Office 365 é uma fidedignidade federada que se baseia este certificado de assinatura de tokens (por exemplo, Office 365 verifica que o token recebido for assinado utilizando um certificado de assinatura de tokens do fornecedor de afirmações [o serviço do AD FS] que confia).

      Se o certificado de assinatura de tokens AD FS é alterado devido a sobreposição de certificado automática ou pela intervenção de um administrador (após ou antes da expiração do certificado), os detalhes do novo certificado deve ser actualizado no inquilino do Office 365 para o domínio federado.

      Office 365 ou Azure AD tentará para lidar com o serviço do AD FS, desde sua acessíveis a partir da rede pública. Vamos tentar consultar os metadados de Federação ADFS a intervalos regulares, para obter quaisquer alterações de configuração no ADFS, principalmente o certificado de assinatura de tokens. Se este processo não está a funcionar, o Administrador Global deverá ver uma notificação no portal Office 365, aviso sobre a expiração de certificado de assinatura de tokens e com acções a tomar, actualizá-lo.

      Pode utilizar Get-MsolFederationProperty - NomeDomínio<domain></domain> Para copiar a propriedade de Federação de AD FS e Office 365. Aqui pode comparar o thumbprint de TokenSigningCertificate, para verificar se a configuração de Tenants do Office 365 para o domínio federada é sincronizada com o AD FS. Se encontrar um erro de correspondência na configuração do certificado de assinatura de tokens, execute o seguinte comando para actualizá-lo:
      Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
      Também pode executar a seguinte ferramenta para agendar uma tarefa no servidor de AD FS que irá monitorizar o rollover de certificado automática da assinatura de tokens certificado e actualização do Office 365 tenant automaticamente.

      Ferramenta de instalação de automatização do Microsoft Office 365 Federação actualização de metadados

      Verificar e gerir serviço single sign-on com AD FS
    • Regras de pedido de transformação de emissão de RP de 365 Office não estiverem correctamente configuradas.

      Num cenário em que tenha vários TLDs (domínios de nível superior), poderá ter problemas de início de sessão se a Supportmultipledomain parâmetro não foi utilizado quando a fidedignidade RP foi criada e actualizada. Para mais informações, clique em Aqui.
    • Certifique-se de que a encriptação token é não a ser utilizada pelo AD FS ou STS quando um token emitido Azure AD ou Office 365.
  6. Existem credenciais em cache obsoletas no Gestor de credenciais do Windows.

    Por vezes, durante o início de sessão numa estação de trabalho para o portal (ou ao utilizar o Outlook), quando é pedido ao utilizador as credenciais, as credenciais poderão ser guardadas para o destino (serviço Office 365 ou o AD FS) no Gestor de credenciais do Windows (Gestor de Accounts\Credential de Panel\User de controlo). Isto ajuda a impedir que um pedido de credenciais durante algum tempo, mas poderá provocar um problema depois da palavra-passe de utilizador foi alterado e o Gestor de credenciais não está actualizado. Nesse cenário, obsoletas credenciais são enviadas para o serviço do AD FS e, por conseguinte, a autenticação falha. Pode ajudar a remover ou actualizar as credenciais em cache, no Gestor de credenciais do Windows.
  7. Certifique-se de que o algoritmo Hash seguro, que está configurada no depender das partes de fidedignidade para o Office 365 está definido como SHA1.

    Quando a fidedignidade entre o STS/AD FS e Azure AD/Office 365 estiver a utilizar o protocolo de SAML 2.0, o algoritmo Hash seguro configurado para assinatura digital deverá ser SHA1.
  8. Se nenhuma das causas anteriores se aplicarem à sua situação, crie um incidente de suporte com a Microsoft e peça-lhe para verificar se a conta de utilizador é apresentado consistentemente no inquilino do Office 365. Para mais informações, consulte os seguintes recursos:

    Mensagem de erro do AD FS 2.0 quando um utilizador federado inicia sessão no Office 365: "Ocorreu um problema ao aceder ao site"

    Um utilizador federado está-lhe pedido repetidamente credenciais quando ele ou ela estabelece ligação com o ponto final de serviço 2.0 de AD FS durante o início de sessão no Office 365
  9. Dependendo de qual o serviço nuvem (integrado com Azure AD) que está a aceder, o pedido de autenticação que é enviado para o AD FS pode variar. Por exemplo: certos pedidos podem incluir parâmetros adicionais tais como Wauth ou Wfresh, e estes parâmetros podem causar um comportamento diferente ao nível do AD FS.

    Recomendamos que os binários de AD FS sempre ser mantida actualizada para incluir as correcções para problemas conhecidos. Para mais informações sobre as actualizações mais recentes, consulte a tabela seguinte.

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 3079872 - Última Revisão: 08/11/2015 20:23: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