Compreender os conectores do Proxy de Aplicações do Azure Active Directory

Os conectores são o que torna Azure AD Proxy de Aplicações possível. São simples, fáceis de implementar e manter, e super poderosos. Este artigo discute o que são os conectores, como funcionam e algumas sugestões de como otimizar a sua implementação.

O que é um conector Proxy de Aplicações?

Os conectores são agentes leves que se sentam no local e facilitam a ligação de saída ao serviço Proxy de Aplicações. Os conectores devem ser instalados num Servidor do Windows que tenha acesso à aplicação backend. Pode organizar conectores em grupos de conector, com cada grupo a manusear o tráfego para aplicações específicas. Para obter mais informações sobre o proxy da aplicação e uma representação diagramática da arquitetura de procuração de aplicações consulte utilizar Azure AD Proxy de Aplicações para publicar apps no local para utilizadores remotos

Requisitos e implantação

Para implementar Proxy de Aplicações com sucesso, precisa de pelo menos um conector, mas recomendamos dois ou mais para uma maior resiliência. Instale o conector numa máquina em funcionamento Windows Server 2012 R2 ou posteriormente. O conector precisa de comunicar com o serviço Proxy de Aplicações e com as aplicações no local que publica.

Windows Server

Precisa de um servidor a funcionar Windows Server 2012 R2 ou mais tarde no qual pode instalar o conector Proxy de Aplicações. O servidor precisa de se ligar aos serviços Proxy de Aplicações em Azure e às aplicações no local que está a publicar.

O servidor precisa de ter o TLS 1.2 ativado antes de instalar o conector Proxy de Aplicações. Para ativar o TLS 1.2 no servidor:

  1. Definir as seguintes chaves de registo:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001
    
  2. Reiniciar o servidor

Para obter mais informações sobre os requisitos de rede para o servidor do conector, consulte Começar com Proxy de Aplicações e instalar um conector.

Manutenção

Os conectores e o serviço cuidam de todas as tarefas de alta disponibilidade. Podem ser adicionados ou removidos dinamicamente. Cada vez que um novo pedido chega é encaminhado para um dos conectores que está atualmente disponível. Se um conector não estiver temporariamente disponível, não responde a este tráfego.

Os conectores são apátridas e não têm dados de configuração na máquina. Os únicos dados que armazenam são as definições para a ligação do serviço e o seu certificado de autenticação. Quando se ligam ao serviço, retiram todos os dados de configuração necessários e atualizam-no a cada dois minutos.

Os conectores também pesquisam o servidor para saber se existe uma versão mais recente do conector. Se um for encontrado, os conectores atualizam-se sozinhos.

Pode monitorizar os seus conectores a partir da máquina em que estão a funcionar, utilizando os registos de eventos e os contadores de desempenho. Ou pode ver o seu estado na página Proxy de Aplicações do portal do Azure:

Exemplo: conectores Azure AD Proxy de Aplicações

Não é preciso eliminar manualmente os conectores que não estão a ser reutilizados. Quando um conector está em funcionamento, permanece ativo à medida que se liga ao serviço. Os conectores não reutilizados são marcados como inativos e são removidos após 10 dias de inatividade. No entanto, se pretender desinstalar um conector, desinstale o serviço Desinsector e o serviço Updater a partir do servidor. Reinicie o computador para remover completamente o serviço.

Atualizações automáticas

Azure AD fornece atualizações automáticas para todos os conectores que implementa. Enquanto o serviço Proxy de Aplicações Connect updater estiver a funcionar, os seus conectores atualizam-se automaticamente com a versão principal do conector. Se não vir o serviço de Atualização do Conector no seu servidor, tem de reinstalar o seu conector para obter quaisquer atualizações.

Se não quiser esperar que uma atualização automática chegue ao seu conector, pode fazer uma atualização manual. Aceda à página de descarregamento do conector no servidor onde o seu conector está localizado e selecione Download. Este processo inicia uma atualização para o conector local.

Para os inquilinos com vários conectores, as atualizações automáticas visam um conector de cada grupo para evitar tempo de inatividade no seu ambiente.

Poderá experimentar tempo de inatividade quando o seu conector atualizar se:

  • Tem apenas um conector que recomendamos instalar um segundo conector e criar um grupo de conector. Isto evitará o tempo de inatividade e proporcionará uma maior disponibilidade.
  • Um conector estava no meio de uma transação quando a atualização começou. Embora a transação inicial esteja perdida, o seu navegador deve repetir automaticamente a operação ou pode atualizar a sua página. Quando o pedido é ressentido, o tráfego é encaminhado para um conector de reserva.

Para ver informações sobre versões previamente lançadas e que alterações incluem, consulte Proxy de Aplicações-Version Release History.

Criação de grupos de conector

Os grupos de conector permitem-lhe atribuir conectores específicos para servir aplicações específicas. Pode agrupar muitos conectores e, em seguida, atribuir cada aplicação a um grupo.

Os grupos de conector facilitam a gestão de grandes implementações. Também melhoram a latência para inquilinos que têm aplicações hospedadas em diferentes regiões, porque você pode criar grupos de conector baseados em localização para servir apenas aplicações locais.

Para saber mais sobre os grupos de conectores, consulte publicar aplicações em redes e locais separados utilizando grupos de conector.

Planeamento de capacidade

É importante certificar-se de que planeou capacidade suficiente entre os conectores para lidar com o volume de tráfego esperado. Recomendamos que cada grupo de conector tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ótimo no caso de precisar de servir uma máquina em qualquer ponto.

Em geral, quanto mais utilizadores tiveres, maior é a máquina de que precisas. Abaixo está uma tabela que dá um esboço do volume e da latência esperada que diferentes máquinas podem manusear. Note que tudo se baseia em Transações esperadas por Segundo (TPS) e não pelo utilizador, uma vez que os padrões de utilização variam e não podem ser usados para prever a carga. Haverá também algumas diferenças com base no tamanho das respostas e no tempo de resposta da aplicação backend - tamanhos de resposta maiores e tempos de resposta mais lentos resultarão num Max TPS mais baixo. Recomendamos também que se disponibilizem máquinas adicionais para que a carga distribuída através das máquinas forneça sempre um tampão amplo. A capacidade extra irá garantir que você tem alta disponibilidade e resiliência.

Núcleos RAM Latência esperada (MS)-P99 Max TPS
2 8 325 586
4 16 320 1150
8 32 270 1190
16 64 245 1200*

* Esta máquina utilizou uma definição personalizada para elevar alguns dos limites de ligação predefinidos para além das definições recomendadas .NET. Recomendamos que faça um teste com as definições predefinidoras antes de contactar o suporte para que este limite seja alterado para o seu inquilino.

Nota

Não há muita diferença no TPS máximo entre 4, 8 e 16 máquinas nucleares. A principal diferença entre estes é a latência esperada.

Esta tabela também se centra no desempenho esperado de um conector baseado no tipo de máquina em que está instalada. Isto é separado dos limites de estrangulamento do serviço Proxy de Aplicações, ver limites de serviço e restrições.

Segurança e networking

Os conectores podem ser instalados em qualquer lugar da rede que lhes permita enviar pedidos para o serviço Proxy de Aplicações. O importante é que o computador que executa o conector também tenha acesso às suas apps. Pode instalar conectores dentro da sua rede corporativa ou numa máquina virtual que funciona na nuvem. Os conectores podem funcionar dentro de uma rede de perímetro, também conhecida como uma zona desmilitarizada (DMZ), mas não é necessário porque todo o tráfego está de saída para que a sua rede permaneça segura.

Os conectores só enviam pedidos de saída. O tráfego de saída é enviado para o serviço Proxy de Aplicações e para as aplicações publicadas. Não é preciso abrir portas de entrada porque o tráfego flui para os dois lados uma vez que uma sessão é estabelecida. Também não tem de configurar o acesso à entrada através das suas firewalls.

Para obter mais informações sobre a configuração das regras de firewall de saída, consulte Work with existing proxy servers.

Desempenho e escalabilidade

A escala para o serviço Proxy de Aplicações é transparente, mas a escala é um fator para os conectores. Precisa de conectores suficientes para lidar com o tráfego máximo. Uma vez que os conectores são apátridas, não são afetados pelo número de utilizadores ou sessões. Em vez disso, respondem ao número de pedidos e ao seu tamanho de carga útil. Com o tráfego web padrão, uma máquina média pode lidar com alguns milhares de pedidos por segundo. A capacidade específica depende das características exatas da máquina.

O desempenho do conector está ligado por CPU e networking. O desempenho do CPU é necessário para encriptação e desencriptação TLS, enquanto o networking é importante para obter uma conectividade rápida com as aplicações e o serviço online em Azure.

Em contraste, a memória é menos um problema para os conectores. O serviço online cuida de grande parte do processamento e de todo o tráfego não autenticado. Tudo o que pode ser feito na nuvem é feito na nuvem.

Se, por qualquer motivo, o conector ou a máquina não estiverem disponíveis, o tráfego começará a ir para outro conector do grupo. Esta resiliência é também a razão pela qual recomendamos ter múltiplos conectores.

Outro fator que afeta o desempenho é a qualidade da ligação em rede entre os conectores, incluindo:

  • O serviço online: As ligações lentas ou de alta latência ao serviço Proxy de Aplicações em Azure influenciam o desempenho do conector. Para obter o melhor desempenho, ligue a sua organização ao Azure com a Rota Expressa. Caso contrário, certifique-se de que as ligações com o Azure são manuseadas da forma mais eficiente possível.
  • As aplicações de backend: Em alguns casos, existem proxies adicionais entre o conector e as aplicações de backend que podem retardar ou impedir ligações. Para resolver este cenário, abra um navegador a partir do servidor de conector e tente aceder à aplicação. Se executar os conectores em Azure mas as aplicações estão no local, a experiência pode não ser o que os seus utilizadores esperam.
  • Os controladores de domínio: Se os conectores executarem um único sinal de inserção (SSO) utilizando a Delegação Restrita Kerberos, eles contactam os controladores de domínio antes de enviar o pedido para o backend. Os conectores têm uma cache de bilhetes Kerberos, mas num ambiente movimentado a capacidade de resposta dos controladores de domínio pode afetar o desempenho. Esta questão é mais comum para conectores que funcionam em Azure mas comunicam com controladores de domínio que estão no local.

Para obter mais informações sobre a otimização da sua rede, consulte considerações de topologia da Rede ao utilizar o Azure Ative Directory Proxy de Aplicações.

Adesão de domínio

Os conectores podem funcionar numa máquina que não esteja ligada ao domínio. No entanto, se pretender um único sinal de entrada (SSO) para aplicações que utilizem a autenticação integrada do Windows (IWA), precisa de uma máquina de união de domínios. Neste caso, as máquinas de conector devem ser unidas a um domínio que possa efetuar a Delegação Constrangida kerberos em nome dos utilizadores para as aplicações publicadas.

Os conectores também podem ser unidos a domínios em florestas que têm uma confiança parcial, ou a controladores de domínio apenas de leitura.

Implantações de conector em ambientes endurecidos

Normalmente, a colocação do conector é simples e não requer uma configuração especial. No entanto, existem algumas condições únicas que devem ser consideradas:

  • As organizações que limitam o tráfego de saída devem abrir os portos necessários.
  • As máquinas compatíveis com o FIPS podem ser necessárias para alterar a sua configuração para permitir que os processos do conector gerem e armazenem um certificado.
  • As organizações que bloqueiam o seu ambiente com base nos processos que emitem os pedidos de networking têm de se certificar de que ambos os serviços de conector estão habilitados a aceder a todas as portas e IPs necessários.
  • Em alguns casos, os proxies avançados de saída podem quebrar a autenticação de certificado bidirecional e fazer com que a comunicação falhe.

Autenticação do conector

Para fornecer um serviço seguro, os conectores têm de autenticar em direção ao serviço, e o serviço tem de autenticar em direção ao conector. Esta autenticação é feita utilizando certificados de cliente e servidor quando os conectores iniciam a ligação. Desta forma, o nome de utilizador e a palavra-passe do administrador não são armazenados na máquina de conector.

Os certificados utilizados são específicos ao serviço do Proxy de Aplicações. Estes são criados durante o registo inicial e são renovados automaticamente pelos conectores a cada dois meses.

Após a primeira renovação bem-sucedida do certificado, o serviço do Conector do Proxy de Aplicações do Azure Active Directory (Serviço de Rede) não tem permissão para remover o certificado antigo do arquivo de máquinas local. Se o certificado tiver expirado ou não for mais utilizado pelo serviço, poderá eliminá-lo em segurança.

Para evitar problemas com a renovação do certificado, confirme que a comunicação de rede a partir do conector para os destinos documentados está ativada.

Se um conector não estiver ligado ao serviço durante vários meses, os seus certificados podem estar desatualizados. Neste caso, desinstale e volte a instalar o conector para acionar o registo. Pode executar os seguintes comandos PowerShell:

Import-module AppProxyPSModule
Register-AppProxyConnector -EnvironmentName "AzureCloud"

Para o governo, use -EnvironmentName "AzureUSGovernment". Para mais detalhes, consulte o Agente de Instalação para a nuvem Azure Government.

Para saber mais sobre como verificar o certificado e problemas de resolução de problemas consulte o suporte de componentes de Verificação da Máquina e de backend para Proxy de Aplicações certificado fiduciário.

Os bastidores

Os conectores são baseados em Proxy de Aplicações Web do Windows Server, por isso têm a maioria das mesmas ferramentas de gestão, incluindo Registos de Eventos do Windows

Gerir registos de eventos com o Visualizador de Eventos

e contadores de desempenho do Windows.

Adicione contadores ao conector com o Monitor de Desempenho

Os conectores têm registos Administração e session. O registo Administração inclui eventos-chave e os seus erros. O registo session inclui todas as transações e os seus dados de processamento.

Para ver os registos, abra Visualizador de Eventos e vá a Applications and Services Logs>Microsoft>AadApplicationProxy>Connector. Para tornar visível o registo de Sessão no menu Ver , selecione 'Registar Registos Analíticos e Debug'. O registo de Sessão é normalmente utilizado para a resolução de problemas e é desativado por padrão. Permita-o começar a recolher eventos e desativá-lo quando já não for necessário.

Pode examinar o estado do serviço na janela dos Serviços. O conector é composto por dois Serviços Windows: o conector real e o atualizador. Ambos devem correr a toda a hora.

Exemplo: Janela de serviços mostrando Azure AD serviços locais

Passos seguintes