Editar

Expandir o AD FS no local para o Azure

Microsoft Entra ID
Microsoft Entra
Azure Load Balancer

Esta arquitetura de referência implementa uma rede híbrida segura que expande a sua rede no local para o Azure e utiliza os Serviços de Federação do Active Directory (AD FS) para proceder à autenticação federada e à autorização dos componentes em execução no Azure.

Arquitetura

Diagram showing an example of a secure hybrid network architecture with Active Directory Federation Services.

Transfira um ficheiro do Visio desta arquitetura.

Nota

O arquivo do Visio inclui 4 guias de diagramas. Selecione a guia AD FS para ver o diagrama de arquitetura relevante para este artigo.

Fluxo de trabalho

  • Sub-rede do AD DS. Os servidores do AD DS estão contidos na sua própria sub-rede com regras do grupo de segurança da rede (NSG) que atuam como uma firewall.

  • Servidores do AD DS. Os controladores de domínio em execução como VMs no Azure. Estes servidores fornecem a autenticação de identidades locais dentro do domínio.

  • Sub-rede do AD FS. Os servidores do AD FS estão localizados na sua própria sub-rede com as regras NSG a funcionarem como uma firewall.

  • Servidores do AD FS. Os servidores do AD FS fornecem autenticação e autorização federadas. Nesta arquitetura, podem realizar as seguintes tarefas:

    • Receber tokens de segurança que contêm afirmações realizadas por um servidor de federação parceiro em nome de um utilizador parceiro. O AD FS verifica se os tokens são válidos antes de transmitir as afirmações para a aplicação Web em execução no Azure para autorizar os pedidos.

      O aplicativo em execução no Azure é a terceira parte confiável. O servidor de federação parceiro tem de emitir afirmações que devem ser compreendidas pela aplicação Web. Os servidores de federação parceiros são referidos como parceiros de conta, uma vez que enviam pedidos de acesso em nome de contas autenticadas na organização parceira. Os servidores do AD FS são denominados parceiros de recursos, pois fornecem acesso aos recursos (a aplicação Web).

    • Autenticar e autorizar pedidos recebidos de utilizadores externos a executar um browser ou dispositivo que precisa de acesso às aplicações Web, com o AD DS e o Serviço do Registo de Dispositivos do Azure Active Directory.

    Os servidores do AD FS são configurados como um farm acedido através de um balanceador de carga do Azure. Esta implementação melhora a disponibilidade e a escalabilidade. Os servidores AD FS não são expostos diretamente à Internet. Todo o tráfego de Internet é filtrado através dos servidores proxy da aplicação Web do AD FS e de uma DMZ (também referida como uma rede de perímetro).

    Para obter mais informações sobre como funciona o AD FS, veja Descrição Geral dos Serviços de Federação do Active Directory. Além disso, o artigo Implementação do AD FS no Azure contém uma introdução passo a passo detalhada para a implementação.

  • Sub-rede de proxy do AD FS. Os servidores proxy do AD FS podem ser contidos dentro da sua própria sub-rede, com as regras NSG a fornecer proteção. Os servidores nesta sub-rede estão expostos à Internet através de um conjunto de aplicações virtuais de rede que fornecem uma firewall entre a rede virtual do Azure e a Internet.

  • Servidores proxy de aplicação Web (WAP) do AD FS. Estas VMs funcionam como servidores do AD FS para pedidos recebidos de organizações parceiras e de dispositivos externos. Os servidores WAP atuam como um filtro e protegem os servidores do AD FS do acesso direto da Internet. Tal como acontece com os servidores do AD FS, a implementação dos servidores WAP num farm com balanceamento de carga dá-lhe maior disponibilidade e escalabilidade do que a implementação de uma coleção de servidores autónomos.

    Nota

    Para obter informações detalhadas sobre a instalação de servidores WAP, veja Install and Configure the Web Application Proxy Server (Instalar e Configurar o Servidor Proxy de Aplicações Web).

  • Organização parceira. Uma organização parceira a executar uma aplicação Web que solicita acesso a uma aplicação Web em execução no Azure. O servidor de federação na organização parceira autentica os pedidos localmente e envia tokens de segurança que contêm afirmações para o AD FS em execução no Azure. O AD FS no Azure valida os tokens de segurança e, se válidos, pode transmitir as afirmações para a aplicação Web em execução no Azure para os autorizar.

    Nota

    Também pode configurar um túnel VPN com o gateway do Azure para fornecer acesso direto ao AD FS para os parceiros fidedignos. Os pedidos recebidos destes parceiros não são transmitidos através dos servidores WAP.

Componentes

Esta arquitetura expande a implementação descrita em Expandir o AD DS para o Azure. Ele contém os seguintes componentes.

Detalhes do cenário

O AD FS pode ser hospedado localmente, mas se seu aplicativo for um híbrido no qual algumas partes são implementadas no Azure, pode ser mais eficiente replicar o AD FS na nuvem.

O diagrama anterior mostra os seguintes cenários:

  • O código da aplicação de uma organização parceira acede a uma aplicação Web alojada na sua VNet do Azure.
  • Um utilizador externo registado com credenciais armazenadas no Active Directory Domain Services (AD DS) acede a uma aplicação Web alojada na sua VNet do Azure.
  • Um utilizador ligado à VNet com um dispositivo autorizado executa uma aplicação Web alojada na sua VNet do Azure.

Esta arquitetura de referência centra-se na federação passiva, na qual os servidores de federação decidem como e quando autenticar um utilizador. O utilizador fornece as informações de início de sessão quando a aplicação é iniciada. Este mecanismo é utilizado frequentemente por browsers e envolve um protocolo que redireciona o browser para um site onde o utilizador é autenticado. O AD FS também suporta a federação ativa, em que uma aplicação assume a responsabilidade de fornecer credenciais sem a necessidade de interação do utilizador. Mas, esse cenário está fora do âmbito desta arquitetura.

Para obter outras considerações, consulte Escolher uma solução para integrar o Ative Directory local com o Azure.

Potenciais casos de utilização

Utilizações típicas desta arquitetura:

  • Aplicações híbridas onde as cargas de trabalho são executadas parcialmente no local e parcialmente no Azure.
  • Soluções que utilizam a autorização federada para expor as aplicações Web às organizações parceiras.
  • Sistemas que suportam o acesso em browsers em execução fora da firewall da organização.
  • Sistemas que permitem aos utilizadores aceder a aplicações Web através da ligação de dispositivos externos autorizados, como computadores remotos, notebooks e outros dispositivos móveis.

Recomendações

As recomendações seguintes aplicam-se à maioria dos cenários. Siga-as, a não ser que tenha requisitos específicos que as anulem.

Recomendações de redes

Configure a interface de rede para cada uma das VMs que aloja o AD FS e os servidores WAP com endereços IP privados estáticos.

Não forneça aos endereços IP públicos das VMs do AD FS. Para obter mais informações, consulte a seção Considerações de segurança.

Defina o endereço IP dos servidores do serviço de nomes de domínio (DNS) primário e secundário das interfaces de rede para cada VM do AD FS e WAP para referenciar as VMs dos Serviços de Diretório do Active Directory. As VMs DS do Ative Directory devem estar executando o DNS. Este passo é necessário para permitir que cada VM adira ao domínio.

Instalação do AD FS

O artigo Implementar um Farm de Servidores de Federação fornece instruções detalhadas para instalar e configurar o AD FS. Execute as seguintes tarefas antes de configurar o primeiro servidor do AD FS no farm:

  1. Obtenha um certificado publicamente fidedigno para realizar a autenticação do servidor. O nome do requerente tem de conter o nome que os clientes utilizam para aceder ao serviço de federação. Este pode ser o nome DNS registado para o balanceador de carga, por exemplo, adfs.contoso.com (evite utilizar nomes com carateres universais, tal como *.contoso.com, por motivos de segurança). Utilize o mesmo certificado em todas as VMs do servidor do AD FS. Pode comprar um certificado de uma autoridade de certificação fidedigna. Porém, se a sua organização utilizar os Serviços de Certificados do Active Directory, poderá criar os seus próprios.

    O nome alternativo do requerente é utilizado pelo serviço de registo de dispositivos (DRS) para ativar o acesso a partir de dispositivos externos. Este deve ter o formato enterpriseregistration.contoso.com.

    Para obter mais informações, veja Obtain and Configure a Secure Sockets Layer (SSL) Certificate for AD FS (Obter e Configurar um Certificado SSL (Secure Sockets Layer) para o AD FS).

  2. No controlador de domínio, gere uma nova chave de raiz para o Serviço de Distribuição de Chaves. Defina o tempo efetivo para a hora atual, com menos 10 horas (esta configuração reduz o atraso que pode ocorrer na distribuição e na sincronização das chaves no domínio). Este passo é necessário para suportar a criação da conta de serviço de grupo, que é utilizada para executar o serviço do AD FS. O comando PowerShell seguinte mostra um exemplo sobre como fazê-lo:

    Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
    
  3. Adicione cada VM do servidor do AD FS ao domínio.

Nota

Para instalar o AD FS, o controlador de domínio a executar a função FSMO (Flexible Single Master Operation) do emulador do controlador de domínio primário (PDC) para o domínio deve estar em execução e acessível nas VMs do AD FS.

Confiança do AD FS

Estabeleça a confiança da federação entre a sua instalação do AD FS e os servidores de federação de todas as organizações parceiras. Configure o mapeamento e a filtragem de afirmações necessários.

  • A equipa do DevOps em cada organização parceira tem de adicionar uma confiança da entidade confiadora para as aplicações Web acessíveis através de servidores do AD FS.
  • A equipa do DevOps na sua organização tem de configurar a confiança do fornecedor de afirmações para permitir que os servidores do AD FS confiem nas afirmações fornecidas pelas organizações parceiras.
  • A equipa do DevOps na sua organização também tem de configurar o AD FS para transmitir afirmações para as aplicações Web da sua organização.

Para obter mais informações, veja Establishing Federation Trust (Estabelecer Confiança da Federação).

Publique as aplicações Web da sua organização e disponibilize-as aos parceiros externos com a pré-autenticação através dos servidores WAP. Para obter mais informações, veja Publish Applications using AD FS Preauthentication (Publicar Aplicações com a Pré-autenticação do AD FS).

O AD FS suporta a transformação e o aumento de tokens. O Microsoft Entra ID não fornece esse recurso. Com o AD FS, quando configura as relações de confiança, pode:

  • Configurar transformações de afirmação para as regras de autorização. Por exemplo, você pode mapear a segurança do grupo de uma representação usada por uma organização parceira que não seja da Microsoft para algo que o Ative Directory DS possa autorizar em sua organização.
  • Converter as afirmações de um formato para outro. Por exemplo, poderá mapear a partir de SAML 2.0 para SAML 1.1 se a sua aplicação suportar apenas afirmações de SAML 1.1.

Monitorização do AD FS

O Pacote de Gestão do Microsoft System Center dos Serviços de Federação do Active Directory 2012 R2 fornece uma monitorização proativa e reativa da implementação do AD FS para o servidor de federação. Este pacote de gestão monitoriza:

  • Eventos que o serviço do AD FS guarda nos registos de eventos.
  • Os dados de desempenho que os contadores de desempenho do AD FS recolhem.
  • O estado de funcionamento geral dos sistemas do AD FS e das aplicações Web (entidades confiadoras) e fornece alertas para problemas e avisos críticos.

Outra opção é monitorar o AD FS usando o Microsoft Entra Connect Health. O Microsoft Entra Connect Health fornece monitoramento robusto de sua infraestrutura de identidade local. Ele permite que você mantenha uma conexão confiável com o Microsoft 365 e o Microsoft Online Services. Essa confiabilidade é alcançada fornecendo recursos de monitoramento para seus principais componentes de identidade. Além disso, torna os principais pontos de dados sobre esses componentes facilmente acessíveis.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

As considerações seguintes, resumidas do artigo Plan your AD FS deployment (Planear a Implementação do AD FS), apresentam um ponto de partida para o dimensionamento de farms do AD FS:

  • Se você tiver menos de 1000 usuários, não crie servidores dedicados, mas instale o AD FS em cada um dos servidores DS do Ative Directory na nuvem. Confirme que tem, pelo menos, dois servidores do Diretório do Active Directory para manter a disponibilidade. Crie um único servidor WAP.
  • Se você tiver entre 1000 e 15.000 usuários, crie dois servidores AD FS dedicados e dois servidores WAP dedicados.
  • Se você tiver entre 15.000 e 60.000 usuários, crie entre três e cinco servidores AD FS dedicados e pelo menos dois servidores WAP dedicados.

Essas considerações pressupõem que você esteja usando tamanhos duplos de VM quad-core (Standard D4_v2 ou superior) no Azure.

Se você estiver usando o Banco de Dados Interno do Windows para armazenar dados de configuração do AD FS, estará limitado a oito servidores AD FS no farm. Se você prevê que precisará de mais no futuro, use o SQL Server. Para obter mais informações, veja The Role of the AD FS Configuration Database (A Função da Base de Dados de Configuração do AD FS).

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.

Crie um farm do AD FS com, pelo menos, dois servidores para aumentar a disponibilidade do serviço. Utilize contas de armazenamento diferentes para cada VM do AD FS no farm. Essa abordagem ajuda a garantir que uma falha em uma única conta de armazenamento não torne todo o farm inacessível.

Crie conjuntos de disponibilidade do Azure separados para as VMs do AD FS e WAP. Confirme se existem, pelo menos, duas VMs em cada conjunto. Cada conjunto de disponibilidade tem de ter, pelo menos, dois domínios de atualização e dois domínios de falhas.

Configure os balanceadores de carga para as VMs do AD FS e WAP da seguinte forma:

  • Utilize um balanceador de carga do Azure para fornecer acesso às VMs WAP e um balanceador de carga interno para distribuir a carga entre os servidores do AD FS no farm.

  • Transmita apenas tráfego presente na porta 443 (HTTPS) para os servidores do AD FS/WAP.

  • Atribua um endereço IP estático ao balanceador de carga.

  • Crie uma investigação de integridade usando HTTP contra /adfs/probe. Para obter mais informações, consulte Verificações de integridade do balanceador de carga de hardware e Proxy de aplicativo Web / AD FS 2012 R2.

    Nota

    Os servidores do AD FS utilizam o protocolo de Indicação do Nome de Servidor (SNI), por isso, se tentar sondar com um ponto final HTTPS a partir do Balanceador de carga, este falhará.

  • Adicione um registo A DNS ao domínio para o balanceador de carga do AD FS. Especifique o endereço IP do balanceador de carga e escolha um nome no domínio (por exemplo, adfs.contoso.com). Este é nome que os clientes e os servidores do WAP utilizam para aceder ao farm de servidores do AD FS.

Pode utilizar o SQL Server ou a Base de Dados Interna do Windows para conter as informações de configuração do AD FS. A Base de Dados Interna do Windows fornece uma redundância básica. As alterações são escritas diretamente apenas numa das bases de dados do AD FS no cluster do AD FS, enquanto os outros servidores utilizam a replicação por solicitação para manter as bases de dados atualizadas. A utilização do SQL Server pode fornecer uma redundância de base de dados completa e uma elevada disponibilidade com clustering de ativação pós-falha ou espelhamento.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

O AD FS usa HTTPS, portanto, certifique-se de que as regras NSG para a sub-rede que contém as VMs da camada da Web permitam solicitações HTTPS. Estes pedidos podem ter origem na rede no local, nas sub-redes que contêm a camada Web, na camada Business, na camada de dados, na DMZ privada, na DMZ pública e na sub-rede que contém os servidores do AD FS.

Impeça a exposição direta dos servidores do AD FS à Internet. Os servidores do AD FS são computadores associados a domínios que têm autorização total para conceder tokens de segurança. Se um servidor for comprometido, um utilizador mal-intencionado poderá emitir tokens de acesso total para todas as aplicações Web e para todos os servidores de federação protegidos pelo AD FS. Se o sistema tiver de processar pedidos de utilizadores externos não ligados a partir de sites de parceiros fidedignos, utilize os servidores WAP para processar estes pedidos. Para obter mais informações, veja Where to Place a Federation Server Proxy (Onde Colocar um Proxy de Servidor de Federação).

Coloque os servidores AD FS e os servidores WAP em sub-redes separadas com as suas próprias firewalls. Pode utilizar as regras NSG para definir regras de firewall. Todas as firewalls devem permitir o tráfego na porta 443 (HTTPS).

Restrinja o acesso de início de sessão direto aos servidores do AD FS e WAP. Apenas a equipa do DevOps deve poder estabelecer ligação. Não associe os servidores WAP ao domínio.

Considere a utilização de um conjunto de aplicações virtuais de rede para registar as informações detalhadas do tráfego que atravessa o limite da sua rede virtual para fins de auditoria.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

Aqui estão considerações de custo para os serviços usados nessa arquitetura.

Serviços de Domínio do AD

Considere ter o Active Directory Domain Services como um serviço partilhado que é consumido por várias cargas de trabalho para reduzir os custos. Para obter mais informações, consulte Preços dos Serviços de Domínio Ative Directory.

Serviços de Federação do Active Directory (AD FS)

Para obter informações sobre as edições oferecidas pelo Microsoft Entra ID, consulte Preços do Microsoft Entra. O recurso Serviços de Federação do AD está disponível em todas as edições.

Excelência Operacional

A equipa do DevOps deve estar preparada para realizar as seguintes tarefas:

  • Gerencie os servidores de federação, incluindo o gerenciamento do farm do AD FS, o gerenciamento da política de confiança nos servidores de federação e o gerenciamento dos certificados usados pelos serviços de federação.
  • Gerencie os servidores WAP, incluindo o gerenciamento do farm WAP e dos certificados.
  • Gerencie aplicativos Web, incluindo a configuração de partes confiáveis, métodos de autenticação e mapeamentos de declarações.
  • Faça backup dos componentes do AD FS.

Para obter outras considerações sobre DevOps, consulte DevOps: estendendo os Serviços de Domínio Ative Directory (AD DS) para o Azure.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

  • Sarah Parkes - Brasil | Arquiteto de Soluções Cloud Sênior

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Passos Seguintes