Guia de federação do AD FS com o Entra ID

By Mirko Peters · 2026-04-30 · Updated 2026-09-13

Entenda a federação do AD FS, o SSO, as relações de confiança e a segurança, depois explore a migração do AD FS para o Microsoft Entra ID e os problemas comuns de solução de problemas.

Automatically translated with AI from the original post. Read the English original

A federação com o Active Directory Federation Services (AD FS) tem um papel central na forma como as organizações modernas gerenciam identidades digitais e o logon único (SSO). À medida que as empresas crescem e suas necessidades evoluem, especialmente com a expansão dos aplicativos em nuvem e das plataformas de colaboração, entender o AD FS se torna mais importante do que nunca. Este guia explica o que o AD FS faz, como ele se encaixa no ecossistema maior da Microsoft e por que a migração para soluções avançadas como o Entra ID e o Azure AD está transformando o cenário de autenticação corporativa.

Desde conceitos fundamentais, como identidade federada, até estratégias detalhadas de migração e práticas recomendadas de segurança, você terá uma visão abrangente de como o AD FS funciona, além do que precisa saber ao planejar uma transição para a identidade moderna em nuvem. Seja você alguém que está solucionando problemas em ambientes já existentes ou desenhando uma nova abordagem, este conteúdo foi feito para ajudar você a tomar decisões bem informadas e manter sua autenticação sempre sólida.

Fundamentos do Active Directory Federation Services

O Active Directory Federation Services (AD FS) está no centro de como muitas organizações integram diferentes sistemas de autenticação, especialmente quando há uma combinação complexa de recursos locais e serviços em nuvem. O conceito central é simples: a identidade federada permite que os usuários acessem aplicativos fora do seu ambiente de origem usando as credenciais que já conhecem. Trata-se de derrubar as barreiras digitais entre organizações e serviços, tornando o acesso mais seguro e fluido para todos os envolvidos.

Imagine que você tenha parceiros, fornecedores ou equipes remotas que precisam trabalhar nos seus sistemas, mas você não quer distribuir um monte de nomes de usuário e senhas extras. O AD FS entra em cena criando "pontes de confiança", para que esses usuários façam login como se estivessem no próprio ambiente. É a resposta da Microsoft à velha pergunta "como compartilhar recursos sem abrir mão da segurança?", apoiada em padrões técnicos robustos como SAML e OAuth.

Se você está apenas começando no mundo da federação de identidades, ou se já gerencia relações de confiança entre domínios há anos, esta próxima seção estabelece a base. Vamos ver o que o AD FS realmente faz, por que ele ainda é relevante e como evoluiu junto com a realidade dos ambientes em nuvem e híbridos. Os detalhes virão nas próximas partes, mas, por enquanto, saiba que o AD FS é o seu ponto de partida para uma autenticação segura e transfronteiriça em ambientes fortemente baseados na Microsoft.

O que é a federação do Active Directory e como ela funciona?

O Active Directory Federation Services (AD FS) é uma ferramenta desenvolvida pela Microsoft para possibilitar uma autenticação segura e contínua entre limites organizacionais e de domínio. Em sua essência, o AD FS implementa a "identidade federada", o que significa que seus usuários podem acessar sistemas, aplicativos ou serviços que não são controlados pelo seu domínio, sempre usando as credenciais normais. Assim, ninguém precisa memorizar uma dúzia de senhas ou alternar entre vários logins só para fazer o trabalho.

Como isso funciona? O AD FS utiliza protocolos padronizados do setor, como SAML (Security Assertion Markup Language) e OAuth, para estabelecer relações de confiança, frequentemente chamadas de "confianças federadas", entre a sua organização (o provedor de identidade) e quaisquer aplicativos externos ou parceiros (as partes confiáveis). O diferencial está na autenticação baseada em declarações: depois de verificar o usuário, o AD FS emite um "token de segurança" contendo declarações (basicamente, detalhes sobre a identidade e os direitos do usuário). O aplicativo de destino valida o token e libera o acesso se tudo estiver em ordem.

Historicamente, o AD FS ajudou grandes empresas a oferecer logon único (SSO) tanto para aplicativos locais quanto para recursos em nuvem, como o Office 365. Naquela época, antes de diretórios nativos da nuvem como o Entra ID se tornarem comuns, o AD FS era a ponte que mantinha a autenticação fluida, mesmo entre os limites da empresa. Hoje, ele continua sendo um componente fundamental em cenários híbridos, embora muitas organizações já estejam traçando seu caminho rumo a soluções de identidade em nuvem para ganhar mais flexibilidade e segurança.

Componentes principais da arquitetura do AD FS

• Servidor de federação: O mecanismo principal do AD FS, que autentica usuários, emite tokens baseados em declarações e gerencia as relações de confiança com as partes confiáveis.
• Web Application Proxy (WAP): Atua como um gateway, oferecendo acesso proxy seguro para usuários externos e protegendo os servidores de federação contra exposição direta à internet.
• Claims Provider: Fornece os dados de identidade do usuário, muitas vezes extraídos do Active Directory, para alimentar a geração de tokens e a emissão de claims.
• Relying Party Trust: Representa os aplicativos ou sistemas externos que consomem e validam os tokens do AD FS; define como os claims são transformados e quais usuários estão autorizados.
• Domain Controller: Autentica os usuários no Active Directory, confirmando as credenciais antes da emissão do token.

Fluxos de autenticação do ADFS e confiança federada explicados

Quando se trata de single sign-on e acesso seguro, o AD FS se destaca por tornar a autenticação simples para o usuário final, mesmo quando a infraestrutura por trás é tudo, menos simples. A base disso está na forma como o AD FS lida com os fluxos de autenticação e a confiança federada. Tudo gira em torno de movimentar credenciais, tokens e claims de forma segura e eficiente, desde o momento em que o usuário tenta fazer login até o momento em que ele chega ao aplicativo ou recurso de destino.

É aqui que os detalhes dos protocolos (como SAML, WS-Federation e OAuth) realmente mostram seu valor. O processo acontece rapidamente: validação das credenciais do usuário, emissão de claims, transformação de atributos e envio dos tokens corretos para os sistemas certos. Ao longo do caminho, os relacionamentos de confiança federada garantem que as organizações dos dois lados da negociação possam ter confiança em quem está passando pela porta digital.

Em seguida, vamos mapear passo a passo a jornada típica de autenticação do AD FS e, depois, detalhar como a confiança federada é configurada para que duas organizações completamente separadas possam permitir acesso seguro entre empresas sem preocupações. Entender esses conceitos prepara profissionais de TI e equipes de segurança para tudo, desde construir uma federação segura até solucionar problemas persistentes de acesso ou de claims mais adiante.

Entendendo os fluxos de autenticação do ADFS

1. Usuário acessa o aplicativo: O usuário tenta abrir um aplicativo federado. Se for um acesso externo, a requisição passa primeiro pelo Web Application Proxy; requisições internas vão direto para o AD FS.
2. Solicitação de autenticação enviada: A relying party do aplicativo redireciona o navegador do usuário para o servidor AD FS com uma solicitação de autenticação, incluindo o recurso que o usuário deseja acessar.
3. Validação de credenciais: O AD FS solicita que o usuário faça login (usando credenciais do Windows, formulários, MFA ou certificado) e verifica esses dados com o controlador de domínio do Active Directory.
4. Criação de claims: Após a validação, o AD FS cria um token baseado em claims. Esse token inclui atributos sobre o usuário, como nome de usuário, associação a grupos ou e-mail, com base em regras pré-configuradas.
5. Emissão do token: O token de claims é assinado com segurança pelo AD FS e devolvido ao navegador do usuário.
6. Aplicativo valida o token: O navegador envia o token para o aplicativo de destino, que verifica sua autenticidade usando a parte pública do certificado do AD FS.
7. Acesso concedido: Se o token, os claims e as regras estiverem todos corretos, o aplicativo finalmente libera o usuário, sem pedir outra senha.

Esse fluxo passo a passo funciona para o SSO típico, seja para usuários internos ou para acessos vindos de um parceiro federado. A mesma lógica se aplica ao OAuth (muito usado em aplicativos SaaS), o que dá ao AD FS flexibilidade para lidar com uma ampla gama de cenários e protocolos de autenticação.

Estabelecendo confiança federada entre organizações

Configurar uma confiança federada no AD FS significa criar um relacionamento em que duas organizações concordam em aceitar os tokens de autenticação uma da outra. Tecnicamente, isso envolve configurar cada lado para reconhecer o outro como um claims provider confiável ou uma relying party. Certificados SSL são trocados para proteger a comunicação, e políticas de confiança personalizadas são definidas para determinar quais claims são aceitos e como as identidades dos usuários são mapeadas.

Uma configuração correta de confiança sustenta um SSO seguro e sem atritos para parceiros de negócios, fornecedores ou subsidiárias, entregando colaboração sem reduzir os padrões de segurança da organização.

Considerações de segurança e melhores práticas para a implantação do AD FS

Sempre que o assunto for federação e SSO, a segurança passa a ser prioridade máxima. Afinal, uma única violação ou uma confiança mal configurada pode se espalhar rapidamente. Com o AD FS, o foco está em proteger todo o pipeline de emissão de tokens, garantir que somente as pessoas certas consigam se autenticar e manter os invasores longe dos seus recursos mais valiosos.

O cenário de ameaças inclui desde phishing de credenciais e roubo de tokens até ataques de negação de serviço e tentativas de força bruta. Você precisa de defesas sólidas em cada etapa: desde políticas de autenticação rigorosas e fluxos de tokens criptografados até a aplicação regular de patches e o monitoramento em tempo real. Esse tipo de segurança em camadas não apenas impede a entrada de invasores, como também ajuda as organizações a atender aos requisitos de auditoria e governança.

Nas próximas seções, vamos detalhar defesas práticas para o AD FS, destacar os vetores de ataque mais comuns e suas estratégias de mitigação, e resumir as melhores práticas comprovadas para configuração segura, auditoria contínua e integração com programas mais amplos de segurança e governança. Se você busca estratégias práticas para reduzir riscos, incluindo lições aprendidas nos ambientes Entra ID e Azure da Microsoft, continue lendo. E, se você quer entender como identidade, acesso condicional e governança funcionam juntos na nuvem, confira este episódio sobre estratégia de segurança de identidade para insights mais aprofundados.

Protegendo a emissão de tokens e a autenticação no AD FS

• Aplique políticas rigorosas de senha e de credenciais: Configure senhas complexas e regras de expiração estritas para reduzir a exposição de credenciais fracas.
• Habilite a autenticação multifator (MFA): Adicione uma segunda etapa de verificação (como um código no celular ou um token de hardware) para bloquear logins não autorizados, mesmo que a senha tenha sido comprometida.
• Use canais de token seguros e criptografados: Exija SSL/TLS em todas as trocas de tokens e garanta que os tokens sejam assinados e criptografados para evitar adulteração ou interceptação.
• Restrinja a vida útil dos tokens: Use tokens de curta duração para limitar a janela de ataque caso um token seja roubado ou reutilizado.

Para mais contexto sobre como prevenir ataques que contornam até mesmo o MFA, como o abuso de consentimento do OAuth, veja estes controles essenciais para proteger o Entra ID.

Principais considerações de segurança e mitigação de ameaças

• Phishing de credenciais: Treine os usuários para identificar phishing e exija MFA para proteger o momento do login.
• Replay e roubo de tokens: Use tokens de vida curta e validação contínua de tokens para limitar os danos causados por tokens interceptados.
• Ataques de negação de serviço (DoS): Implante servidores AD FS e de proxy em configurações de alta disponibilidade e limite a exposição a redes não confiáveis.
• Gerenciamento de patches: Atualize regularmente o AD FS e todos os sistemas dependentes para corrigir vulnerabilidades antes que os atacantes as explorem.
• Auditoria e monitoramento: Implemente registro (logging) e monitoramento robustos para detectar atividades suspeitas cedo; para uma abordagem mais ampla de zero trust, veja este episódio do podcast sobre Zero Trust.

Melhores práticas para implantação e monitoramento do AD FS

• Redundância e balanceamento de carga: Implante múltiplos servidores de federação e de proxy para eliminar pontos únicos de falha e suportar grandes volumes de usuários.
• Monitoramento contínuo: Use logs de auditoria, monitoramento de eventos e alertas em tempo real para sinalizar rapidamente padrões suspeitos.
• Auditorias de segurança regulares: Revise configurações e relações de confiança em busca de desvios ou lacunas, e acompanhe as mudanças nas melhores práticas.
• Integração com plataformas de segurança em nuvem: Conecte os logs e eventos do AD FS a ferramentas SIEM, como o Microsoft Sentinel, ou ao Microsoft Purview Audit, para detecção unificada de riscos e relatórios de conformidade.
• Gerenciamento do ciclo de vida: Atualize regularmente tokens, certificados e configurações de política para minimizar a "dívida de identidade" e o risco técnico.

Limitações do ADFS e problemas de solução de problemas em organizações modernas

Embora o AD FS tenha ajudado muitas organizações a conectar sistemas e usuários no passado, não é segredo que a tecnologia traz uma série de dores de cabeça modernas. Se você já administrou uma infraestrutura de AD FS, conhece bem a rotina: há custos de manutenção, configurações de confiança complexas e atualizações que aparecem justamente quando você menos espera. Somando a isso ambientes de nuvem que crescem rapidamente, os métodos antigos podem começar a parecer bastante frágeis.

As limitações não são apenas técnicas; elas podem se transformar em riscos para o negócio. Pense na confiabilidade da autenticação, na facilidade de escalar e na rapidez com que você consegue se adaptar quando surge o próximo requisito de SaaS. São esses os pontos críticos que levam mais equipes a considerar identidades baseadas na nuvem, como o Entra ID. Mas, antes de qualquer mudança grande, é fundamental saber o que observar e o que fazer quando algo quebra no seu ambiente de AD FS.

A seguir, vamos detalhar as principais limitações que impedem o AD FS de atender às necessidades das empresas de hoje e apresentar passos práticos de solução de problemas para os incidentes que mais provavelmente chegarão à sua central de suporte. Dominar esses fundamentos pode lhe dar tempo e confiança preciosos, seja para manter a operação funcionando ou para se preparar para a migração.

Principais limitações do AD FS para autenticação corporativa

• Alta sobrecarga de manutenção: As implantações de AD FS exigem aplicação contínua de patches, monitoramento e manutenção de hardware, o que aumenta os custos operacionais.
• Integração limitada com a nuvem: O AD FS legado não consegue igualar as integrações nativas e profundas com SaaS ou com a segurança nativa da nuvem que existem no Entra ID ou no Azure AD.
• Configuração complexa: Configurar cenários com múltiplas florestas ou entre domínios introduz mais componentes em movimento e mais oportunidades de configuração incorreta.
• Desafios de escalabilidade: Bases de usuários em crescimento ou necessidades de acesso global costumam exigir servidores adicionais e configurações de rede sofisticadas.

Solução de problemas comuns do AD FS

1. Falhas de autenticação: Verifique as permissões da conta de serviço, a conectividade com os controladores de domínio e as tentativas de logon com falha nos logs de eventos do AD FS (o Event ID 364 indica problemas na emissão de tokens).
2. Erros na emissão de tokens: Revise as regras de declarações e as configurações de certificados; certificados incompatíveis ou expirados costumam causar falhas.
3. Partes confiáveis mal configuradas: Verifique os endpoints, as relações de confiança e as transformações de declarações para garantir o mapeamento correto entre os sistemas.
4. Bloqueios de conta ou problemas de senha: Garanta que a sincronização de senhas e as políticas de conta estejam consistentes entre florestas e domínios.
5. Monitore os logs do AD FS: Use os Event IDs relevantes (como o 100, para emissão de token bem-sucedida, ou a série 300, para problemas de configuração) para identificar rapidamente as causas raiz.

Migração do AD FS para o Entra ID e o futuro da federação

Para as organizações que ainda mantêm um pé no AD FS legado e o outro entrando na nuvem, o caminho à frente está ficando mais claro. Soluções de identidade baseadas na nuvem, como o Azure AD e o Entra ID, oferecem autenticação robusta, flexível e mais segura para cargas de trabalho modernas, inclusive para aquelas aplicações antigas e difíceis que antes dependiam exclusivamente do AD FS. O setor está caminhando nessa direção por bons motivos: menos sobrecarga de hardware, modelos de confiança mais simples e posturas de segurança preparadas para ameaças em evolução e exigências de conformidade.

Mas migrar do AD FS não é uma troca de chave da noite para o dia. Migrar para o Entra ID (a nova marca guarda-chuva para os serviços de identidade da Microsoft) significa reavaliar as relações de confiança, a integração de aplicações e como políticas como o acesso condicional e a governança vão funcionar no novo cenário. Feita da forma certa, a migração proporciona maior satisfação dos usuários e controles mais fortes e consistentes entre sistemas na nuvem e locais.

A seguir, você encontra uma comparação direta entre o AD FS e a identidade em nuvem, além de estratégias comprovadas para uma transição gradual e tranquila, que não afete os usuários nem abra novas brechas de segurança. Se você quer uma amostra dos desafios de risco e governança que acompanham o acesso condicional no Entra ID, este mergulho profundo sobre loops de segurança de identidade também é um bom ponto de partida.

AD FS versus identidade baseada na nuvem com Azure AD e Entra ID

• Limitações do AD FS: Requisitos de hardware local, aplicação de patches, gerenciamento complexo de relações de confiança e regras de declarações, integração nativa limitada com nuvem e SaaS e resposta mais lenta a ameaças de segurança emergentes.
• Vantagens do Azure AD e do Entra ID: integração nativa com o Microsoft 365, configuração mais simples, acesso condicional integrado, onboarding rápido de SaaS, aplicação consistente de políticas e proteção de identidade reforçada para cargas de trabalho na nuvem.
• Principais motivadores estratégicos da migração: menor sobrecarga de manutenção, gerenciamento simplificado, acesso escalável e modelos de segurança orientados por políticas que acompanham o crescimento da organização.

Para entender como exceções e autorizações acumuladas geram uma “dívida de identidade” e como a governança adequada no Entra ID transforma a segurança das identidades na nuvem, confira este podcast sobre identidade como plano de controle.

Estratégias de migração para uma transição sem interrupções do AD FS para o Entra ID

• Descoberta: faça o inventário de todas as relying party trusts, regras de declarações e aplicações integradas ao AD FS; mapeie as dependências e identifique as cargas de trabalho prontas para migração.
• Planejamento: projete um plano de migração em fases, configure o Entra ID e valide os conectores de nuvem para coexistência híbrida, se necessário.
• Coexistência: execute o AD FS em paralelo com o Entra ID, movendo gradualmente as aplicações para autenticação no Azure AD e monitorando a experiência do usuário e os logs de acesso.
• Transição final: migre os usuários e as cargas de trabalho restantes para o Entra ID, remova as trusts legadas e as regras personalizadas e desative a infraestrutura local do AD FS quando a validação estiver concluída.
• Ajustes pós-migração: revise as políticas de acesso condicional, o provisionamento de usuários e os relatórios no Entra ID para fechar o ciclo e preparar suas práticas de identidade para o futuro.

Ouça também

Se você está pesquisando federação ADFS com o Entra ID, estes episódios trazem contexto prático sobre arquitetura, segurança, governança e implementação:

• Microsoft AI Agent Harness – Simply Explained — Entenda orquestração, guardrails, avaliação e fluxos de trabalho de IA confiáveis.
• Microsoft Defender XDR – Simply Explained — Conecte decisões de identidade e de IA ao monitoramento e à resposta de segurança.
• Microsoft Teams Governance – The Illusion of Control — Saiba como governança, propriedade e políticas reduzem o risco operacional.
• Azure Virtual Network – Simply Explained — Entenda o contexto de arquitetura por trás da conectividade na nuvem.