Planear a implementação do Proxy de Aplicações Microsoft Entra

O proxy de aplicativo Microsoft Entra é uma solução de acesso remoto 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 é proxy de aplicativo.

O proxy de aplicativo é recomendado para dar aos usuários remotos 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. Não se destina a utilizadores que estão na rede empresarial. 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 Microsoft Entra.

Planear a 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

Tem de cumprir os 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: Os conectores são agentes leves que se podem implementar em:

  • Hardware físico nas instalações
  • Uma máquina virtual (VM) hospedada em qualquer solução de hipervisor
  • Uma VM hospedada no Azure para habilitar a conexão de saída com o serviço de proxy de aplicativo.

• Consulte Compreender os conectores de rede privada do Microsoft Entra para obter uma visão geral mais detalhada.

  • As máquinas conectoras devem estar habilitadas para Transport Layer Security (TLS) 1.2 antes de instalar os conectores.

  • Se possível, implante conectores na mesma rede e segmento que os servidores de aplicações web de back-end. É melhor implantar conectores depois de concluir uma deteção de aplicações.

  • Recomendamos que cada grupo de conectores tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ideal para a manutenção de uma máquina em qualquer ponto. Analise a tabela de capacidade do conector para ajudar a decidir o tipo de máquina para o conector.

• Configurações de acesso à rede: os conectores de rede privada do Microsoft Entra se conectam ao Azure via HTTPS (Porta TCP (Transmission Control Protocol) 443) e HTTP (Porta TCP 80).

  • Terminar o tráfego TLS do conector não é suportado e impede que os conectores estabeleçam um canal seguro com os respetivos endpoints de proxy de aplicação do Microsoft Entra.

  • Evite todas as formas de inspeção em linha nas 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, como tal, não é recomendada.

  • O balanceamento de carga dos próprios conectores também não é suportado, ou mesmo necessário.

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

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

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

• Requisitos de acesso condicional: não recomendamos o uso de proxy de aplicativo para acesso à intranet porque ele adiciona latência que afeta os usuários. Recomendamos o uso de proxy de aplicativo com pré-autenticação e políticas de 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 o Microsoft Entra ID.

• Limites de serviço: para proteger contra o consumo excessivo de recursos por locatários individuais, há limites de limitação definidos por aplicativo e locatário. Para ver esses limites, consulte Limites e restrições de serviço do Microsoft Entra. Esses limites de restrição são baseados numa referência que excede o volume de uso típico e fornecem um amplo buffer para a maioria das implantações.

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

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

• Registos 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 de proxy de aplicativo predefinido. A falha ao criar um registro CNAME para um aplicativo que usa um domínio personalizado impede que os 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 de conector devem ser capazes de resolver a URL interna dos aplicativos que estão sendo publicados.

• Direitos e funções administrativas

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

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

• 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 aplicativos

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

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

Definir requisitos organizacionais

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

Acesso

• Os utilizadores remotos com dispositivos vinculados a um domínio ou ao Microsoft Entra podem aceder a aplicações publicadas de forma segura, com autenticação única contínua (SSO).

• Os utilizadores remotos com dispositivos pessoais aprovados podem aceder com segurança a aplicações publicadas, desde que estejam inscritos no MFA e registados a aplicação Microsoft Authenticator no seu telemóvel como método de autenticação.

Governação

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

Segurança

• Apenas os utilizadores atribuídos a aplicações através da adesão a grupos ou individualmente podem aceder a essas aplicações.

Desempenho

• Não há degradação do desempenho do aplicativo em comparação com o acesso ao 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 um piloto

Determine a quantidade de tempo e esforço necessários para comissionar totalmente um único aplicativo para acesso remoto com logon único (SSO). Faça isso executando um piloto que considere a descoberta inicial, a publicação e os testes de modo geral. Usar um aplicativo Web simples baseado em IIS que já esteja pré-configurado para autenticação integrada do Windows (IWA) ajudaria a estabelecer uma linha de base, já que a configuração requer um esforço mínimo para pilotar com êxito o acesso remoto e o SSO.

Os seguintes elementos de design devem aumentar o sucesso de sua implementação piloto diretamente em um locatário de produção.

Gestão de conectores:

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 em produção. Os aplicativos testados com êxito podem ser movidos para grupos de conectores de produção.

Gestão de aplicações:

É mais provável que sua força de trabalho se lembre de que um URL externo é familiar e relevante. Evite publicar a sua aplicação usando os nossos sufixos predefinidos msappproxy.net ou onmicrosoft.com. 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 do portal MyApps do Azure. Quando estiver pronto para produção, você pode definir o escopo do aplicativo para seu respetivo público-alvo, seja no mesmo locatário de pré-produção ou também publicando 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 resolvidas com antecedência. O processo inclui hosts de conector que ingressam no domínio para executar SSO usando Delegação Restrita de Kerberos (KCD) e tratar de outras atividades que consomem tempo.

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

Implemente incrementalmente 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 for bem-sucedida, 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. Teste e valide o acesso.

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, consulte o guia de solução de problemas .

Implemente a sua solução

Implantar proxy de aplicativo

As etapas para implantar seu 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 de proxy de aplicativo.

Publicar aplicações através de proxy de aplicações

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

Também pode publicar aplicações com o PowerShell.

Práticas recomendadas a serem seguidas ao publicar um aplicativo:

• Usar grupos de conectores: atribua um grupo de conectores designado para publicar cada aplicação respetiva. Recomendamos que cada grupo de conectores tenha pelo menos dois conectores para fornecer alta disponibilidade e escala. Ter três conectores é ideal no caso de você precisar fazer a manutenção de uma máquina a qualquer momento. Além disso, consulte Compreender os 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 local.

• 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. O front-end envia a consulta para seu servidor de banco de dados back-end e aguarda uma resposta, mas quando recebe uma resposta, o lado cliente da conversa expira. Definir o tempo limite como Longo fornece 180 segundos para que transações mais longas sejam concluídas.

• Usar tipos de cookies apropriados

  • HTTP-Only Cookie: Fornece segurança extra ao fazer com que o proxy do aplicativo inclua o sinalizador HTTPOnly nos cabeçalhos de resposta HTTP set-cookie. A configuração ajuda a mitigar ataques como o cross-site scripting (XSS). Deixe definido como Não para clientes/agentes de usuário que exigem acesso ao cookie de sessão. Por exemplo, cliente RDP/MTSC conectando-se a um gateway de área de trabalho remota publicado via proxy de aplicativo.

  • Cookie Seguro: Quando um cookie é definido com o atributo Secure, o agente do usuário (aplicativo do lado do cliente) só inclui o cookie em solicitações HTTP se a solicitação for transmitida por um canal seguro TLS. A configuração ajuda a mitigar o risco de um cookie ser comprometido em canais de texto não criptografado, portanto, deve ser ativada.

  • Cookie persistente: Permite que o cookie de sessão do proxy de aplicativo persista entre os fechamentos do navegador, permanecendo válido até expirar ou ser excluído. Usado para cenários em que um aplicativo avançado, como o Office, acessa um documento dentro de um aplicativo Web publicado, sem que o usuário seja solicitado novamente para autenticação. No entanto, ative 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 só deve ser usada para aplicativos mais antigos que não podem 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 encaminhamento do tráfego real e o FQDN na URL externa como cabeçalho do host. Na maioria das situações, a alternativa deve permitir que a aplicação funcione normalmente quando acessada remotamente, mas os seus utilizadores perdem os benefícios de ter uma correspondência nas URLs interna e externa.

• Traduzir URLs no Corpo do Aplicativo: Ativar a tradução de links do Corpo do Aplicativo para um aplicativo quando pretender que os links desse aplicativo sejam traduzidos nas respostas enviadas de volta ao cliente. Se habilitada, a função fornece uma tentativa de melhor esforço para traduzir todos os links internos que o proxy do aplicativo encontra nas respostas HTML e CSS que estão sendo retornadas aos clientes. É útil ao publicar aplicativos que contenham links absolutos codificados ou links de nome curto NetBIOS no conteúdo ou aplicativos com conteúdo vinculado a outros aplicativos locais.

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

Por exemplo, suponha que você tenha três aplicativos publicados por meio do proxy do aplicativo que se vinculam uns aos outros: Benefícios, Despesas e Viagens, além de um quarto aplicativo, Comentários que não são publicados por meio do proxy do aplicativo.

Quando a tradução de links 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 as acessem. No entanto, os links de Despesas e Viagem para Benefícios não funcionam, a menos que a tradução de links também esteja ativada para esses aplicativos. O link do aplicativo Comentários não é redirecionado porque não possui uma URL externa, impedindo que usuários externos o acessem por meio do aplicativo Benefícios. Para obter mais informações, consulte Opções de tradução e redirecionamento de links.

Aceda à sua candidatura

Gerencie o acesso aos recursos publicados do proxy de aplicativo selecionando a abordagem que melhor se adapta ao seu cenário e aos requisitos de 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 no 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 seu aplicativo publicado e atribuir diretamente grupos ou indivíduos.

Você também pode permitir que os usuários acessem seu aplicativo de autoatendimento atribuindo um grupo do qual eles não são membros no momento e configurando as opções de autoatendimento.

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

Os usuários convidados também podem ser convidados a acessar aplicativos internos publicados via proxy de aplicativo através 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 Microsoft Entra sem permissões, portanto, use com cuidado.

Uma vez que seu aplicativo é publicado, ele deve ser acessível digitando seu URL externo em um navegador ou por seu ícone em https://myapps.microsoft.com.

Ativar pré-autenticação

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

1. Navegue até Entra ID>Enterprise apps>Todos os aplicativos e escolha o aplicativo que você deseja gerenciar.

2. Selecione o proxy do 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, o Microsoft Entra ID primeiro autentica os usuários. Se o logon único estiver configurado, o aplicativo 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 que inicialmente use HTTP agora opere sobre HTTPS.

Ativar o início de sessão único

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

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

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

Leia Início de Sessão Único para Aplicações no Microsoft Entra ID para o(a) ajudar a escolher o método SSO mais apropriado ao configurar as suas aplicações.

Trabalhar com outros tipos de aplicações

O proxy de aplicativo Microsoft Entra oferece suporte a aplicativos criados com a Microsoft Authentication Library (MSAL). Ele lida com 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 de proxy de aplicativo. Leia a publicação de aplicativos cliente nativos e móveis e aplicativos baseados em declarações.

Reforçar a segurança com o Acesso Condicional

A segurança de aplicativos requer um conjunto avançado de recursos de segurança que possam proteger e responder a ameaças complexas no local e na nuvem. Use políticas de Acesso Condicional para controlar o acesso aos seus aplicativos com base em muitas 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 seguintes recursos podem ser usados para oferecer suporte ao proxy de aplicativo Microsoft Entra:

• Acesso condicional baseado no usuário e na localização: 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: certifique-se de que apenas dispositivos registrados, aprovados e compatíveis possam 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. Proteja o acesso à nuvem corporativa e aos aplicativos locais e mantenha 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 todos os usuários, seja no local ou na nuvem.

• Microsoft Entra My Apps: Com seu serviço de proxy de aplicativo implantado e 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.

Gerencie sua implementação

Funções necessárias

A Microsoft defende o princípio de conceder o menor privilégio possível para executar as tarefas necessárias com o Microsoft Entra ID. Analise 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 afetar inadvertidamente um recurso sensível.

Para gerenciar o acesso administrativo de forma eficaz e garantir a auditoria adequada, recomendamos o uso do acesso just-in-time (JIT) 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 monitorização

O Microsoft Entra ID fornece mais informações sobre o uso do aplicativo e a integridade operacional da sua organização por meio de logs e relatórios de auditoria. O proxy de aplicativo também facilita o monitoramento de conectores do centro de administração do Microsoft Entra e dos logs de eventos do Windows.

Registos de auditoria de aplicação

Esses logs fornecem informações detalhadas sobre logins em aplicativos configurados com 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, relatórios de uso e insights também estão disponíveis para seu aplicativo.

Monitoramento de conector de rede privada

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

Logs de eventos e contadores de desempenho do Windows

Os conectores têm registos de administração e de sessão. Os logs de administração incluem eventos-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 Compreender os conectores de rede privada do Microsoft Entra. Siga o tutorial para configurar fontes de dados do 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 sua organização de suporte.

• Solucionar problemas de links na página do aplicativo que não funcionam
• Abrir portas para a minha aplicação
• Configurar a autenticação única
• Configurar Delegação Restrita de Kerberos
• Configurar com o PingAccess
• Solucionar problemas de erro do Access the Corporate Application
• Solucionar problemas de instalação do proxy de aplicativo Agent Connector
• Resolver problemas de início de sessão