Perguntas frequentes sobre o proxy de aplicativo Microsoft Entra

Não, os seguintes itens de configuração estão sendo usados pelo proxy de aplicativo e não devem ser alterados ou excluídos:

• Habilitar/desabilitar "Permitir fluxos de clientes públicos".
• CWAP_AuthSecret (Segredos do cliente).
• Permissões da API. A modificação de qualquer um dos itens de configuração acima na página Registro de aplicativo interrompe a pré-autenticação do Proxy de Aplicativo do Microsoft Entra.

Não, você deve excluir um aplicativo proxy de aplicativo da área de Aplicativos empresariais do Centro de administração do Microsoft Entra. Se você excluir o aplicativo de proxy de aplicativo da área de Registros de aplicativo do Centro de administração do Microsoft Entra, poderá ter problemas.

Para usar o proxy de aplicativo do Microsoft Entra, você deve ter uma licença Microsoft Entra ID P1 ou P2. Para obter mais informações sobre licenciamento, confira Preços do Microsoft Entra

Se sua licença expirar, o proxy de aplicativo será desabilitado automaticamente. As suas informações de aplicativo são salvas por até um ano.

Certifique-se de ter, pelo menos, uma licença P1 ou P2 do Microsoft Entra e um conector do rede privada do Microsoft Entra instalado. Depois que você instalar o primeiro conector com êxito, o serviço de proxy de aplicativo do Microsoft Entra será habilitado automaticamente.

O uso de um utilitário de verificação de porta em pontos de extremidade públicos de proxy de aplicativo (msappproxy.net ou personalizados) pode mostrar que as portas TCP 10200 e 10201 estão abertas, além das portas 80 e/ou 443. Essas portas são usadas para fins de monitoramento de integridade do serviço interno. Nenhum dado do cliente pode ser acessado por essas portas e os serviços por trás delas não processam nenhuma informação; eles simplesmente respondem com "OK".

Sim, o conector de rede privada do Microsoft Entra é usado pelo proxy de aplicativo e pelo Acesso Privado do Microsoft Entra. Para saber mais sobre o conector, consulte Conector de rede privada do Microsoft Entra. Para solucionar problemas de configuração do conector, consulte solucionar problemas de conectores.

Embora esses sufixos apareçam na lista de sufixos, você não deve usá-los. Esses sufixos de domínio não devem ser usados com o proxy de aplicativo do Microsoft Entra. Se você usar esses sufixos de domínio, o aplicativo do proxy de aplicativo do Microsoft Entra criado não funcionará. Você pode usar o sufixo msappproxy.net de domínio padrão ou um domínio personalizado.

O Microsoft Entra ID tem um serviço de proxy de aplicativo que permite que os usuários acessem aplicativos locais entrando com suas contas do Microsoft Entra. Se você tiver instalado conectores em regiões diferentes, poderá otimizar o tráfego selecionando a região do serviço de nuvem do proxy de aplicativo mais próxima a ser usada com cada grupo de conectores. Confira Otimizar o fluxo de tráfego com o proxy de aplicativo do Microsoft Entra.

Depois de carregar o certificado SSL, você receberá a mensagem "certificado inválido, possível senha incorreta" no portal.

Aqui estão algumas dicas para solucionar esse erro:

• Verifique se há problemas com o certificado. Instale-o no seu computador local. A ausência de problemas, significa que o certificado é bom.
• Verifique se a senha não contém nenhum caractere especial. A senha deve conter apenas os caracteres 0-9, A-Z e a-z.
• Se o certificado tiver sido criado com o provedor de armazenamento de chaves de software da Microsoft, o algoritmo RSA deverá ser usado.

O comprimento padrão é de 85 segundos. A configuração "longa" é de 180 segundos. O limite do tempo limite não pode ser estendido.

Não, não há suporte para esse recurso no momento.

O segredo do cliente, também chamado de CWAP_AuthSecret, é adicionado automaticamente ao objeto do aplicativo (registro do aplicativo) quando o aplicativo do proxy de aplicativo do Microsoft Entra é criado.

O segredo do cliente é válido por um ano. Um novo segredo do cliente de um ano é criado automaticamente antes que o atual segredo do cliente válido expire. Três segredos do cliente CWAP_AuthSecret são sempre mantidos no objeto do aplicativo.

Não, você deve usar o domínio de fallback original.

Artigo mencionado em questão: Adicionar e substituir domínio de fallback onmicrosoft.com no Microsoft 365

Na página registros de aplicativo, é possível alterar a URL da home page para a URL externa desejada da página de aterrissagem. A página especificada é carregada quando o aplicativo é inicializado em Meus Aplicativos ou no portal do Office 365. Para obter as etapas de configuração, confira Definir uma página inicial personalizada para aplicativos publicados usando o proxy de aplicativo do Microsoft Entra

Se a pré-autenticação do Microsoft Entra estiver configurada e a URL do aplicativo contiver um caractere "#", ao tentar acessar o aplicativo pela primeira vez, você será redirecionado ao Microsoft Entra ID (login.microsoftonline.com) para a autenticação. Depois de concluir a autenticação, você será redirecionado para a parte de URL antes do caractere "#" e tudo o que vem após o "#" parece ser ignorado/removido. Por exemplo, se a URL for https://www.contoso.com/#/home/index.html, assim que a autenticação do Microsoft Entra for concluída, o usuário será redirecionado para https://www.contoso.com/. Esse comportamento ocorre por design devido ao modo como o caractere “#” é tratado pelo navegador.

Possíveis soluções/alternativas:

• Configurar um redirecionamento de https://www.contoso.com para https://contoso.com/#/home/index.html. Primeiro, o usuário precisa acessar https://www.contoso.com.
• A URL usada para a primeira tentativa de acesso precisa incluir o caractere “#” na forma codificada (%23). O servidor publicado pode não aceitar isso.
• Configurar o tipo de pré-autenticação de passagem (não recomendado).

Não, não há nenhum requisito do IIS para aplicativos publicados. É possível publicar aplicativos Web em execução em servidores diferentes do Windows Server. No entanto, você pode não conseguir usar a pré-autenticação com um servidor não Windows, dependendo se o servidor Web dá suporte ao Negotiate (autenticação Kerberos). O IIS não é necessário no servidor onde o conector está instalado.

O proxy de aplicativo não adiciona automaticamente o cabeçalho HTTP Strict-Transport-Security às respostas HTTPS, mas mantém o cabeçalho se ele estiver na resposta original enviada pelo aplicativo publicado. Provar uma configuração para habilitar essa funcionalidade está no roteiro.

Não, se o protocolo http for configurado na URL externa, o ponto de extremidade do proxy de aplicativo do Microsoft Entra aceitará solicitações de entrada na porta TCP 80; se o protocolo for https, na porta TCP 443.

Sim. Alguns exemplos de URLs internas, inclusive portas: http://app.contoso.local:8888/, https://app.contoso.local:8080/, https://app.contoso.local:8081/test/.

Algumas respostas enviadas pelos aplicativos Web publicados podem conter URLs embutidas em código. Nesse caso, deve-se assegurar, com o uso de uma solução de conversão de link, que o cliente sempre use a URL correta. As soluções de conversão de link podem ser complexas e talvez não funcionem em todos os cenários. Veja aqui nossas soluções documentadas para conversão de link.

Como prática recomendada, é recomendável usar URLs externas e internas idênticas. As URLs externas e internas são consideradas idênticas, se as protocol://hostname:port/path/ em ambas forem idênticas.

Isso pode ser feito usando-se o recurso de Domínios Personalizados.

Exemplos:

Idênticas:

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

Não idênticas:

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

Não é possível tornar as URLs externas e internas idênticas se a URL interna contiver uma porta não padrão (diferente de TCP 80/443).

Em algumas situações, devem ser feitas alterações na configuração do aplicativo Web.

O método PrincipalsAllowedToDelegateToAccount é usado quando servidores do conector estão em um domínio diferente da conta de serviço de aplicativo Web. Ele requer o uso da delegação restrita baseada em recursos. Se os servidores do conector e a conta de serviço de aplicativo Web estiverem no mesmo domínio, será possível usar usuários e computadores do Active Directory para configurar as definições de delegação em cada uma das contas do computador do conector, permitindo que elas deleguem ao SPN de destino.

Se os servidores do conector e a conta de serviço de aplicativo Web estiverem em domínios diferentes, será usada a delegação baseada em recursos. As permissões de delegação são configuradas no servidor Web de destino e na conta de serviço de aplicativo Web. Esse método de delegação restrita é relativamente novo. O método foi introduzido no Windows Server 2012, que dá suporte à delegação entre domínios, permitindo que o proprietário do recurso (serviço Web) controle quais contas de computador e serviço podem delegar a ele. Não existe interface do usuário para ajudar nessa configuração, portanto, é necessário usar o PowerShell. Para obter mais informações, consulte o whitepaper Noções básicas sobre a delegação restrita de Kerberos com o proxy de aplicativo.

A autenticação NTLM não pode ser usada como um método de pré-autenticação ou de logon único. A autenticação NTLM só pode ser usada quando puder ser negociada diretamente entre o cliente e o aplicativo Web publicado. Usar a autenticação NTLM geralmente faz com que uma solicitação de entrada apareça no navegador.

Não, isso não funcionará, pois um usuário convidado no Microsoft Entra ID não tem o atributo exigido por nenhuma das identidades de entrada mencionadas acima.

Nesse caso, há um fallback para "Nome de entidade de usuário". Para obter mais detalhes sobre o cenário B2B, leia Conceder aos usuários B2B no Microsoft Entra ID acesso aos seus aplicativos locais.

As políticas de acesso condicional só são impostas para usuários pré-autenticados com êxito no Microsoft Entra ID. A autenticação de passagem não aciona a autenticação do Microsoft Entra, portanto, as políticas de acesso condicional não podem ser aplicadas. Com a autenticação de passagem, as políticas de MFA devem ser implementadas no servidor local, se possível, ou ao habilitar a pré-autenticação do Microsoft Entra ID com o proxy de aplicativo do Microsoft Entra.

Não, não há suporte para esse cenário porque o proxy de aplicativo encerra o tráfego TLS.

Consulte Publicar a Área de Trabalho Remota com o proxy de aplicativo do Microsoft Entra.

Não, não há suporte para esse cenário.

Sim, é esperado. O cenário de pré-autenticação exige um controle ActiveX, que não tem suporte em navegadores de terceiros.

Sim, esse cenário está atualmente em visualização pública. Consulte Publicar a Área de Trabalho Remota com o proxy de aplicativo do Microsoft Entra.

Sim, é esperado. Se o computador do usuário estiver associado ao Microsoft Entra, o usuário entrará automaticamente no Microsoft Entra ID. O usuário precisa fornecer suas credenciais somente no formulário de entrada do RDWeb.

Essa opção permite que o usuário baixe o arquivo rdp e o use por outro cliente RDP (fora do Cliente Web da Área de Trabalho Remota). Normalmente, outros clientes RDP (como o Cliente de Área de Trabalho Remota da Microsoft) não podem lidar com a pré-autenticação nativamente. Por isso esse cenário não funciona.

Consulte Habilitar o acesso remoto ao SharePoint com o proxy de aplicativo do Microsoft Entra.

O aplicativo móvel do SharePoint não dá suporte à pré-autenticação do Microsoft Entra no momento.

Não, o proxy de aplicativo do Microsoft Entra foi projetado para funcionar com o Microsoft Entra ID e não atende aos requisitos para atuar como um proxy do AD FS.

Não há suporte para isso.

Os aplicativos que usam o protocolo WebSocket, por exemplo, QlikSense e Área de Trabalho Remota Web Client (HTML5), agora têm suporte. Veja a seguir as limitações conhecidas:

• O proxy de aplicativo descarta o cookie definido na resposta do servidor ao abrir a conexão WebSocket.
• Não há nenhum SSO aplicado à solicitação WebSocket.
• Os recursos (Eventlogs, PowerShell e Serviços de Área de Trabalho Remota) no WAC (Centro de Administração do Windows) não funcionam por meio do proxy de aplicativo do Microsoft Entra.

O aplicativo WebSocket não tem nenhum requisito de publicação exclusivo e pode ser publicado da mesma forma que todos os seus outros aplicativos do proxy de aplicativo.

Sim. A translação de links afeta o desempenho. O serviço do proxy de aplicativo examina o aplicativo em busca de links embutidos em código e os substitui por suas respectivas URLs externas publicadas antes de apresentá-las ao usuário.

Para obter o melhor desempenho, é recomendável usar URLs internas e externas idênticas configurando domínios personalizados. Se o uso de domínios personalizados não for possível, será possível melhorar o desempenho da translação de links usando a extensão de entrada segura de Meus Aplicativos ou o navegador Microsoft Edge em dispositivos móveis. Confira Redirecionar links codificados para aplicativos publicados com o proxy de aplicativo do Microsoft Entra.

Não há suporte direto para esse cenário. As opções para esse cenário são:

1. Publique as URLs HTTP e HTTPS como aplicativos separados com um curinga, mas forneça a cada uma delas um domínio personalizado diferente. Essa configuração funciona se elas tiverem URLS externas diferentes.

2. Publique a URL HTTPS por meio de um aplicativo curinga. Publicar os aplicativos HTTP separadamente usando estes cmdlets do PowerShell do proxy de aplicativo:

   • Gerenciamento de aplicativos do proxy de aplicativo
   • gerenciamento do conector de rede privada