Planejar uma implantação de proxy de aplicativo do Microsoft Entra

O proxy de aplicativo do Microsoft Entra é uma solução de acesso remoto simples, segura e econômica para aplicativos locais. Ele fornece um caminho de transição imediato para as organizações "Cloud First" gerenciarem o acesso a aplicativos locais herdados que ainda não são capazes de usar protocolos modernos. Para obter mais informações introdutórias, consulte o que é o proxy de aplicativo.

O proxy de aplicativo é recomendado para conceder aos usuários remotos o acesso a recursos internos. O proxy de aplicativo substitui a necessidade de uma VPN ou proxy reverso para esses casos de uso de acesso remoto. Ele não se destina aos usuários que estão na rede corporativa. Esses usuários que usam o proxy de aplicativo para acesso à intranet podem enfrentar problemas de desempenho indesejáveis.

Este artigo inclui os recursos necessários para planejar, operar e gerenciar o proxy de aplicativo do Microsoft Entra.

Planejar sua implementação

A seção a seguir fornece uma visão ampla dos principais elementos de planejamento que configuram você para uma experiência de implantação eficiente.

Pré-requisitos

Você precisa atender aos seguintes pré-requisitos antes de iniciar a implementação. Você pode ver mais informações sobre como configurar seu ambiente, incluindo esses pré-requisitos, no tutorial.

• Conectores: Conectores são agentes leves que você pode implantar em:

  • Hardware físico local
  • Uma VM (Máquina Virtual) hospedada em qualquer solução de hipervisor
  • Uma VM hospedada no Azure para habilitar a conexão de saída com o serviço do proxy de aplicativo.

• Confira Noções básicas sobre conectores de rede privada do Microsoft Entra para obter uma visão geral mais detalhada.

  • Os computadores conectores devem ser habilitados para o TLS (Transport Layer Security) 1.2 antes de instalar os conectores.

  • Se possível, implante conectores na mesma rede e segmento que os servidores de aplicativos Web de back-end. É melhor implantar conectores depois de concluir uma descoberta de aplicativos.

  • Recomendamos que cada grupo de conectores tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ideal para atender um computador a qualquer momento. Examine a tabela de capacidade do conector para ajudar a decidir o tipo de computador para o conector.

• Configurações de acesso à rede: os conectores de rede privada do Microsoft Entra se conectam ao Azure por meio da PORTA HTTPS (Protocolo de Controle de Transmissão (TCP) 443) e HTTP (Porta TCP 80).

  • Não é suportado o término do tráfego TLS do conector, o que impede os conectores de estabelecerem um canal seguro com seus respectivos endpoints de proxy de aplicativo do Microsoft Entra.

  • Evite todas as formas de inspeção embutida em comunicações TLS de saída entre conectores e o Azure. A inspeção interna entre um conector e aplicativos de back-end é possível, mas pode degradar a experiência do usuário e, por isso, não é recomendada.

  • O balanceamento de carga dos conectores em si também não tem suporte ou nem mesmo é necessário.

Considerações importantes antes de configurar o proxy de aplicativo do Microsoft Entra

Os requisitos principais a seguir devem ser atendidos para configurar e implementar o proxy de aplicativo do Microsoft Entra.

• Integração do Azure: antes de implantar o proxy de aplicativo, as identidades de usuário devem ser sincronizadas de um diretório local ou criadas diretamente em seus locatários do Microsoft Entra. A sincronização de identidade permite que a ID do Microsoft Entra pré-autenticar os usuários antes de conceder-lhes acesso a aplicativos publicados por proxy de aplicativo e ter as informações necessárias do identificador de usuário para executar o SSO (logon único).

• Requisitos de acesso condicional: não recomendamos usar o proxy de aplicativo para acesso à intranet porque ele adiciona latência que afeta os usuários. É recomendável usar o proxy de aplicativo com políticas de pré-autenticação e acesso condicional para acesso remoto da Internet. Uma abordagem para fornecer Acesso Condicional para uso na intranet é modernizar os aplicativos para que eles possam se autenticar diretamente com o Microsoft Entra ID. Para obter mais informações, consulte Recursos para migrar aplicativos para a ID do Microsoft Entra.

• Limites de serviço: para proteger contra o excesso de uso de recursos por locatários individuais, há limites de controle definidos por aplicativo e locatário. Para ver esses limites, consulte os limites e restrições de serviço do Microsoft Entra. Esses limites de controle são baseados em uma referência superior ao volume de uso típico e oferecem uma margem ampla para a maioria das implementações.

• Certificado público: se você estiver usando nomes de domínio personalizados, deverá adquirir um certificado TLS. Dependendo dos requisitos organizacionais, obter um certificado pode levar algum tempo e recomendamos que inicie o processo o quanto antes. O proxy de aplicativo do Azure dá suporte a certificados padrão, curinga ou baseados em SAN. Para obter mais informações, consulte Configurar domínios personalizados com o proxy de aplicativo do Microsoft Entra.

• Requisitos de domínio: Para usar o Kerberos Constrained Delegation (KCD) para logon único, verifique se tanto o servidor conector quanto o servidor de aplicativos estão unidos a um domínio e se estão no mesmo domínio ou em domínios confiáveis. O serviço do conector é executado na conta do sistema local e não deve usar uma identidade personalizada. Para obter mais informações, consulte KCD para logon único.

• Registros DNS para URLs

  • Antes de usar domínios personalizados no proxy de aplicativo, você deve criar um registro CNAME no DNS (Sistema de Nomes de Domínio público), permitindo que os clientes resolvam a URL externa definida personalizada para o endereço proxy de aplicativo predefinido. Falha ao criar um registro CNAME para um aplicativo que usa um domínio personalizado impede que usuários remotos se conectem ao aplicativo. As etapas necessárias para adicionar registros CNAME podem variar de provedor DNS para provedor, portanto, saiba como gerenciar registros DNS e conjuntos de registros usando o Centro de administração do Microsoft Entra.

  • Da mesma forma, os hosts do conector devem ser capazes de resolver a URL interna dos aplicativos que estão sendo publicados.

• Direitos administrativos e funções

  • A instalação do conector requer direitos de administrador local para o servidor Windows no qual ele está sendo instalado. Ele também requer, no mínimo, uma função de Administrador de Aplicativos para autenticar e registrar a instância do conector no seu locatário do Microsoft Entra.

  • A publicação e a administração do aplicativo exigem a função administrador de aplicativos . Os administradores de aplicativos podem gerenciar todos os aplicativos no diretório, incluindo registros, configurações de SSO, atribuições de usuário e grupo e licenciamento, configurações de proxy de aplicativo e consentimento. Ela não concede a capacidade de gerenciar o Acesso Condicional. A função administrador de aplicativos de nuvem tem todas as habilidades do Administrador de Aplicativos, exceto que ela não permite o gerenciamento de configurações de proxy de aplicativo.

• Licenciamento: o proxy de aplicativo está disponível por meio de uma assinatura do Microsoft Entra ID P1 ou P2. Consulte a página de preços do Microsoft Entra para obter uma lista completa de opções e recursos de licenciamento.

Descoberta de Aplicativo

Compile um inventário de todos os aplicativos no escopo que estão sendo publicados por meio do proxy de aplicativo coletando as seguintes informações:

Você pode baixar a planilha de inventário de aplicativos para inventariar seus aplicativos.

Definir requisitos organizacionais

Veja a seguir as áreas para as quais você deve definir os requisitos de negócios de sua organização. Cada área contém exemplos de requisitos

Acesso

• Usuários remotos com dispositivos conectados ao domínio ou ao Microsoft Entra podem acessar aplicativos publicados com segurança com o SSO (logon único) contínuo.

• Usuários remotos com dispositivos pessoais aprovados podem acessar com segurança aplicativos publicados desde que estejam registrados na MFA e registrados no aplicativo Microsoft Authenticator em seu celular como um método de autenticação.

Governança

• Os administradores podem definir e monitorar o ciclo de vida de atribuições de usuário em aplicativos publicados por meio do proxy de aplicativo.

Segurança

• Somente os usuários atribuídos a aplicativos por meio da associação de grupo ou individualmente podem acessar esses aplicativos.

Desempenho

• Não há degradação do desempenho do aplicativo em comparação com o acesso do aplicativo da rede interna.

Experiência do usuário

• Os usuários estão cientes de como acessar seus aplicativos usando URLs familiares da empresa em qualquer plataforma de dispositivo.

Auditoria

• Os administradores podem auditar a atividade de acesso do usuário.

Melhores práticas para obter um piloto

Determine a quantidade de tempo e esforço necessários para encerrar completamente um único aplicativo para acesso remoto com SSO (logon único). Faça isso executando um piloto que considere sua descoberta inicial, publicação e teste geral. Usar um aplicativo web simples baseado em IIS que já está pré-configurado para autenticação integrada do Windows (IWA) ajudaria a estabelecer um ponto de referência, pois a configuração requer um esforço mínimo para implantar o acesso remoto e SSO com sucesso.

Os elementos de design a seguir devem aumentar o sucesso da implementação do piloto diretamente em um locatário de produção.

Gerenciamento do conector:

Os conectores desempenham um papel fundamental no fornecimento do canal local para seus aplicativos. O uso do grupo de conectores padrão é adequado para testes piloto iniciais de aplicativos publicados antes de comissioná-los para produção. Os aplicativos testados com êxito podem ser movidos para grupos de conectores de produção.

Gerenciamento de aplicativos:

É mais provável que sua força de trabalho lembre se uma URL externa é familiar e relevante. Evite publicar seu aplicativo usando nossos sufixos msappproxy.net ou onmicrosoft.com predefinidos. Em vez disso, forneça um domínio verificado de nível superior familiar, prefixado com um nome de host lógico, como intranet.<>customers_domain.com.

Restrinja a visibilidade do ícone do aplicativo piloto a um grupo piloto ocultando seu ícone de inicialização no portal do Azure MyApps. Quando estiver pronto para produção, você poderá definir o escopo do aplicativo para seu respectivo público-alvo, seja no mesmo locatário de pré-produção ou publicando também o aplicativo em seu locatário de produção.

Configurações de logon único: algumas configurações de SSO têm dependências específicas que podem levar tempo para serem configuradas, portanto, evite atrasos no controle de alterações, garantindo que as dependências sejam tratadas com antecedência. O processo inclui a junção de domínio de hosts conectores para executar o SSO usando a KCD (Delegação Restrita de Kerberos) e cuidar de outras atividades demoradas.

TLS entre o host do conector e o aplicativo de destino: a segurança é primordial, portanto, o TLS entre o host do conector e os aplicativos de destino sempre deve ser usado. Particularmente, se o aplicativo Web for configurado para autenticação baseada em formulários (FBA), como as credenciais do usuário, serão transmitidas efetivamente em texto não criptografado.

Implemente de forma incremental e teste cada etapa. Realize testes funcionais básicos após a publicação de um aplicativo para garantir que todos os requisitos de usuário e de negócios sejam atendidos:

Teste e valide o acesso geral ao aplicativo Web com a pré-autenticação desabilitada. Se tiver êxito, habilite a pré-autenticação e atribua usuários e grupos. Em seguida, teste e valide o acesso. Em seguida, adicione o método SSO para seu aplicativo e teste novamente para validar o acesso. Por fim, aplique as políticas de Acesso Condicional e MFA conforme necessário. Testar e validar acessos.

Ferramentas de solução de problemas: inicie a solução de problemas verificando o acesso ao aplicativo publicado diretamente do navegador no host do conector. Verifique se o aplicativo funciona conforme o esperado. Simplifique sua configuração para isolar problemas, como usar um único conector e desabilitar o SSO. Ferramentas como o Fiddler da Telerik podem ajudar a depurar problemas de acesso ou conteúdo rastreando o tráfego, inclusive para plataformas móveis como iOS e Android. Para obter mais informações, confira o guia de solução de problemas.

Implementar Sua Solução

Implantar proxy de aplicativo

As etapas para implantar o proxy de aplicativo são abordadas no tutorial para adicionar um aplicativo local para acesso remoto. Se a instalação não for bem-sucedida, selecione Solucionar problemas de proxy de aplicativo no portal ou use o guia de solução de problemas para problemas com a instalação do conector do agente proxy de aplicativo.

Publicar aplicativos por meio do proxy de aplicativo

A publicação de aplicativos pressupõe que você satisfize todos os pré-requisitos e que tem vários conectores sendo exibidos como registrados e ativos na página proxy do aplicativo.

Você também pode publicar aplicativos usando o PowerShell.

Práticas recomendadas a seguir ao publicar um aplicativo:

• Use grupos de conectores: atribua um grupo de conectores designado para publicar cada aplicativo respectivo. Recomendamos que cada grupo de conectores tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ideal caso você precise atender a um computador a qualquer momento. Além disso, consulte Noções básicas sobre grupos de conectores de rede privada do Microsoft Entra para ver como você também pode usar grupos de conectores para segmentar seus conectores por rede ou localização.

• Definir tempo limite do aplicativo de back-end: a configuração é útil em cenários em que o aplicativo pode exigir mais de 75 segundos para processar uma transação de cliente. Por exemplo, quando um cliente envia uma consulta para um aplicativo Web que atua como um front-end para um banco de dados. A interface envia a consulta para seu servidor de banco de dados back-end e aguarda uma resposta, mas, quando a recebe, a conexão do lado do cliente expira. Definir o tempo limite como Longo fornece 180 segundos para que transações mais longas se concluam.

• Usar tipos de cookie apropriados

  • HTTP-Only Cookie: fornece segurança extra, fazendo com que o proxy de aplicativo inclua o sinalizador HTTPOnly em cabeçalhos de resposta HTTP do set-cookie. A configuração ajuda a mitigar exploits, como o XSS (cross-site scripting). Deixe definido como Não para clientes/agentes de usuário que exigem acesso ao cookie de sessão. Por exemplo, o cliente RDP/MTSC conectando-se a um Gateway de Área de Trabalho Remota publicado por meio do proxy de aplicativo.

  • Cookie Seguro: quando um cookie é definido com o atributo Secure, o agente do usuário (aplicativo do lado do cliente) inclui apenas o cookie em solicitações HTTP se a solicitação é transmitida por um canal protegido do TLS. A configuração ajuda a atenuar o risco de um cookie ser comprometido por canais de texto claros, portanto, deve ser habilitado.

  • Cookie Persistente: permite que o cookie de sessão de proxy de aplicativo persista entre os fechamentos do navegador permanecendo válido até que ele expire ou seja excluído. Usado para cenários em que um aplicativo avançado, como o Office, acessa um documento em um aplicativo Web publicado, sem que o usuário seja reprompido para autenticação. No entanto, habilite com cuidado, pois os cookies persistentes podem, em última análise, deixar um serviço em risco de acesso não autorizado, se não forem usados com outros controles de compensação. Essa configuração deve ser usada somente para aplicativos mais antigos que não conseguem compartilhar cookies entre processos. É melhor atualizar seu aplicativo para lidar com o compartilhamento de cookies entre processos em vez de usar a configuração.

• Traduzir URLs em Cabeçalhos: você habilita a configuração para cenários em que o DNS interno não pode ser configurado para corresponder ao namespace público da organização(também conhecido como DNS Dividido). A menos que seu aplicativo exija o cabeçalho de host original na solicitação do cliente, deixe o valor definido como Sim. A alternativa é fazer com que o conector use o FQDN na URL interna para o roteamento do tráfego real e o FQDN na URL externa, como o cabeçalho do host. Na maioria das circunstâncias, a alternativa deve permitir que o aplicativo funcione normalmente quando acessado remotamente, mas seus usuários perdem os benefícios de ter uma URL igual dentro e fora.

• Traduzir URLs no Corpo do Aplicativo: ative a tradução de URLs no Corpo do Aplicativo para um aplicativo quando quiser que os links desse aplicativo sejam traduzidos nas respostas para o cliente. Se habilitada, a função fornece uma melhor tentativa de esforço para traduzir todos os links internos que o proxy de aplicativo encontra em respostas HTML e CSS retornadas aos clientes. É útil ao publicar aplicativos que contêm links codificados de forma rígida, seja links absolutos ou links de nome curto do NetBIOS, no conteúdo, ou aplicativos com conteúdo que se vincula a outros aplicativos on-premises.

Para cenários em que um aplicativo publicado é vinculado a outros aplicativos publicados, habilite a conversão de link para cada aplicativo para que você tenha controle sobre a experiência do usuário no nível por aplicativo.

Por exemplo, imagine que você tem três aplicativos publicados por meio do proxy de aplicativo, todos vinculados entre si: Benefícios, Despesas e Viagem, além de um quarto aplicativo, Comentários, que não é publicado por meio do proxy de aplicativo.

Quando a tradução de link está habilitada para o aplicativo Benefícios, os links para os aplicativos Despesas e Viagens são redirecionados para suas URLs externas, permitindo que usuários externos os acessem. No entanto, os links de Despesas e Viagens de volta para Benefícios não funcionam, a menos que a tradução de link também esteja habilitada nesses aplicativos. O link do aplicativo Comentários não é redirecionado porque ele não tem uma URL externa, impedindo que usuários externos o acessem por meio do aplicativo Benefícios. Para obter mais informações, consulte as opções de conversão de link e redirecionamento.

Acesse seu aplicativo

Gerencie o acesso aos recursos publicados do proxy de aplicativo selecionando a abordagem que melhor se ajusta aos seus requisitos de cenário e escalabilidade. Os métodos comuns incluem a sincronização de grupos locais por meio do Microsoft Entra Connect, a criação de Grupos Dinâmicos na ID do Microsoft Entra com base em atributos de usuário, a habilitação de grupos de autoatendimento gerenciados por proprietários de recursos ou a combinação dessas estratégias. Explore os recursos vinculados para entender os benefícios de cada método.

A maneira mais direta de atribuir acesso de usuários a um aplicativo é entrar nas opções Usuários e Grupos no painel esquerdo do aplicativo publicado e atribuir diretamente grupos ou indivíduos.

Você também pode permitir que os usuários acessem por autoatendimento em seu aplicativo atribuindo um grupo que atualmente não é membro e configurando as opções de autoatendimento.

Se habilitado, os usuários entrarão no portal do MyApps para solicitar acesso. Eles são automaticamente aprovados e adicionados ao grupo de autoatendimento ou exigem aprovação de um aprovador designado.

Os usuários convidados também podem obter acesso a aplicativos internos publicados por meio do proxy de aplicativo do Microsoft Entra B2B.

Para aplicativos locais que normalmente são acessíveis anonimamente, não exigindo autenticação, convém desabilitar a opção localizada nas Propriedades do aplicativo.

Deixar a opção definida como Não permite que os usuários acessem o aplicativo local por meio do proxy de aplicativo do Microsoft Entra sem permissões, portanto, use com cuidado.

Depois que seu aplicativo for publicado, ele deverá ser acessível digitando sua URL externa em um navegador ou por seu ícone em https://myapps.microsoft.com.

Habilitar a pré-autenticação

Verifique se seu aplicativo está acessível por meio do proxy de aplicativo acessando-o por meio da URL externa.

1. Navegue até Entrar ID>Aplicativos empresariais>Todos os aplicativos e escolha o aplicativo que você deseja gerenciar.

2. Selecione o proxy de aplicativo.

3. No campo Pré-Autenticação, use a lista suspensa para selecionar Microsoft Entra ID e selecione Salvar. Com a pré-autenticação habilitada, a ID do Microsoft Entra autentica primeiro os usuários. Se o logon único estiver configurado, o aplicativo de back-end também verificará o usuário antes de conceder acesso. Alternar o modo de pré-autenticação de Passthrough para Microsoft Entra ID protege a URL externa com HTTPS, garantindo que qualquer aplicativo inicialmente usando HTTP agora funcione com HTTPS.

Habilitar logon único

O SSO melhora a experiência e a segurança do usuário, permitindo que os usuários entrem uma vez com a ID do Microsoft Entra. Após a pré-autenticação, o conector de rede privada entra no aplicativo local do usuário, fazendo com que ele apareça como se o usuário tivesse se conectado diretamente.

Escolher a opção Passagem permite que os usuários acessem o aplicativo publicado sem precisar se autenticar na ID do Microsoft Entra.

Para habilitar o SSO, seu aplicativo deve pré-autenticar usuários com a ID do Microsoft Entra. Sem pré-autenticação, as opções de SSO não estão disponíveis.

Leia SSO em aplicativos no Microsoft Entra ID para ajudar você a escolher o método SSO mais apropriado quando configurar seus aplicativos.

Trabalhando com outros tipos de aplicativos

O proxy de aplicativo do Microsoft Entra dá suporte a aplicativos criados com a MSAL (Biblioteca de Autenticação da Microsoft). Ele manipula aplicativos cliente nativos usando tokens de ID do Microsoft Entra em cabeçalhos de solicitação de cliente para pré-autenticar usuários.

Saiba mais sobre as configurações disponíveis do proxy de aplicativo. Leia a publicação de aplicativos cliente nativos e móveis e aplicativos baseados em declarações.

Fortalecer a segurança com acesso condicional

A segurança do aplicativo requer um conjunto avançado de recursos de segurança que podem proteger e responder a ameaças complexas locais e na nuvem. Use políticas de Acesso Condicional para controlar o acesso a seus aplicativos com base em várias condições, como localização, risco, tipo de dispositivo, conformidade do dispositivo e muito mais. Para obter exemplos de políticas que você pode implantar, consulte o artigo Modelos de Acesso Condicional.

Os recursos a seguir podem ser usados para dar suporte ao proxy de aplicativo do Microsoft Entra:

• Acesso condicional baseado em usuário e local: mantenha os dados confidenciais protegidos limitando o acesso do usuário com base na localização geográfica ou em um endereço IP com políticas de Acesso Condicional baseadas em localização.

• Acesso condicional baseado em dispositivo: verifique se somente dispositivos registrados, aprovados e compatíveis podem acessar dados corporativos com acesso condicional baseado em dispositivo.

• Acesso condicional baseado em aplicativo: o trabalho não precisa parar quando um usuário não está na rede corporativa. Proteger o acesso à nuvem corporativa e aplicativos locais e manter o controle com o Acesso Condicional.

• Acesso condicional baseado em risco: proteja seus dados contra hackers mal-intencionados com uma política de Acesso Condicional baseada em risco que pode ser aplicada a todos os aplicativos e a todos os usuários, seja no local ou na nuvem.

• Meus Aplicativos do Microsoft Entra: com o serviço do proxy de aplicativo implantado e os aplicativos publicados com segurança, ofereça aos usuários um hub simples para descobrir e acessar todos os seus aplicativos. Aumente a produtividade com recursos de autoatendimento, como a capacidade de solicitar acesso a novos aplicativos e grupos ou gerenciar o acesso a esses recursos em nome de outras pessoas, por meio de Meus Aplicativos.

Gerenciar sua implementação

Funções necessárias

A Microsoft defende o princípio de conceder o privilégio mínimo possível para executar as tarefas necessárias com o Microsoft Entra ID. Examine as diferentes funções do Azure disponíveis e escolha a certa para atender às necessidades de cada persona. Algumas funções devem ser aplicadas temporariamente e removidas após a conclusão da implantação.

Minimizar o número de pessoas que têm acesso a informações ou recursos seguros ajuda a reduzir a chance de um ator mal-intencionado obter acesso não autorizado ou um usuário autorizado afetando inadvertidamente um recurso confidencial.

Para gerenciar o acesso administrativo de forma eficaz e garantir a auditoria adequada, recomendamos usar o acesso JIT (just-in-time) com o Privileged Identity Management. Essa abordagem fornece acesso privilegiado sob demanda aos recursos do Azure e à ID do Microsoft Entra somente quando necessário.

Relatórios e monitoramento

A ID do Microsoft Entra fornece mais informações sobre o uso do aplicativo e a integridade operacional da sua organização por meio de logs de auditoria e relatórios. O proxy de aplicativo também facilita o monitoramento de conectores no Centro de Administração do Microsoft Entra e nos Logs de Eventos do Windows.

Logs de auditoria de aplicativo

Esses logs fornecem informações detalhadas sobre logons para aplicativos configurados com o proxy de aplicativo e o dispositivo e o usuário que acessa o aplicativo. Os logs de auditoria estão localizados no Centro de administração do Microsoft Entra e na API de Auditoria para exportação. Além disso, os relatórios de uso e insights também estão disponíveis para seu aplicativo.

Monitoramento do conector de rede privada

Os conectores e o serviço cuidam de todas as tarefas de alta disponibilidade. Você pode monitorar o status dos conectores na página do proxy de aplicativo no centro de administração do Microsoft Entra. Para obter mais informações sobre a manutenção do conector, consulte Noções básicas sobre conectores de rede privada do Microsoft Entra.

Logs de eventos do Windows e contadores de desempenho

Os conectores têm logs de administrador e sessão. Os logs de administrador incluem eventos de chave e seus erros. Os logs de sessão incluem todas as transações e seus detalhes de processamento. Os logs e contadores estão localizados nos Logs de Eventos do Windows. Para obter mais informações, consulte Noções básicas sobre conectores de rede privada do Microsoft Entra. Siga o tutorial para configurar fontes de dados de log de eventos no Azure Monitor.

Guia e etapas de solução de problemas

Saiba mais sobre problemas comuns e como resolvê-los com nosso guia para solucionar problemas de mensagens de erro.

Conteúdo relacionado

Os artigos a seguir abordam cenários comuns que também podem ser usados para criar guias de solução de problemas para a organização do seu suporte.

• Solucionar problemas de links que não estão funcionando na página do aplicativo
• Abrir portas para meu aplicativo
• Configurar logon único
• Configurar delegação restrita do Kerberos
• Configurar com PingAccess
• Solucionar problemas de acesso ao aplicativo corporativo
• Solucionar problemas de instalação do conector do agente proxy de aplicativo
• Solucionar problema de login