Perguntas mais frequentes sobre o proxy de aplicações do Microsoft Entra

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

• Ativar/desativar "Permitir fluxos de clientes públicos".
• CWAP_AuthSecret (Segredos do cliente).
• Permissões da API. Modificar qualquer um dos itens de configuração acima na página de registro do aplicativo quebra a pré-autenticação para o proxy do aplicativo Microsoft Entra.

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

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

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

Verifique se você tem pelo menos uma licença do Microsoft Entra ID P1 ou P2 e um conector de rede privada do Microsoft Entra instalado. Depois de instalar com êxito o primeiro conector, o serviço de proxy de aplicativo Microsoft Entra é ativado automaticamente.

Sim, o conector de rede privada Microsoft Entra é usado pelo proxy de aplicativo e pelo Microsoft Entra Private Access. Para saber mais sobre o conector, consulte Conector de rede privada Microsoft Entra. Para solucionar problemas de configuração de conectores, 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 Microsoft Entra. Se você usar esses sufixos de domínio, o aplicativo proxy de aplicativo 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 sua conta do Microsoft Entra. Se você tiver instalado conectores em regiões diferentes, poderá otimizar o tráfego selecionando a região de serviço de nuvem de proxy de aplicativo mais próxima a ser usada com cada grupo de conectores, consulte Otimizar o fluxo de tráfego com o proxy de aplicativo Microsoft Entra.

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

Eis algumas sugestões para resolver problemas relacionados com este erro:

• Verifique se há problemas com o certificado. Instale-o no computador local. Se não tiver nenhuns problemas, então o certificado está em bom estado de funcionamento.
• Certifique-se de que a palavra-passe não contém caracteres especiais. A senha deve conter apenas os caracteres 0-9, A-Z e a-z.
• Se o certificado tiver sido criado com o Fornecedor de Armazenamento de Chaves de Software da Microsoft, deve ser utilizado o algoritmo de RSA.

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

Não, isso não é suportado no momento.

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

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

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

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

Na página Registros de aplicativos, você pode alterar o URL da página inicial para o URL externo desejado da página de destino. A página especificada é carregada quando o aplicativo é iniciado em Meus Aplicativos ou no Portal do Office 365. Para conhecer as etapas de configuração, consulte Definir uma home page 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 "#" quando você tentar acessar o aplicativo pela primeira vez, será redirecionado para o Microsoft Entra ID (login.microsoftonline.com) para a autenticação. Depois de concluir a autenticação, você será redirecionado para a parte URL antes do caractere "#" e tudo o que vem depois do "#" parece ser ignorado/removido. Por exemplo, se a URL for https://www.contoso.com/#/home/index.html, uma vez que a autenticação do Microsoft Entra é feita, o usuário é redirecionado para https://www.contoso.com/. Esse comportamento é por design devido à forma como o caractere "#" é manipulado pelo navegador.

Soluções/alternativas possíveis:

• Configure um redirecionamento de https://www.contoso.com para https://contoso.com/#/home/index.html. O usuário deve primeiro acessar https://www.contoso.como .
• O URL usado para a primeira tentativa de acesso deve incluir o caractere "#" na forma codificada (%23). O servidor publicado pode não aceitar isso.
• Configure o tipo de pré-autenticação de passagem (não recomendado).

Não, não há nenhum requisito do IIS para aplicativos publicados. Você pode publicar aplicativos Web em execução em servidores diferentes do Windows Server. No entanto, talvez não seja possível usar a pré-autenticação com um servidor que não seja Windows, dependendo se o servidor Web oferece suporte a Negociar (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 estiver configurado na URL externa, o ponto de extremidade do proxy do aplicativo Microsoft Entra aceita a solicitação de entrada na porta TCP 80, se o protocolo https estiver na porta TCP 443.

Sim, alguns exemplos de URLs internas, incluindo 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 codificadas. Neste caso, deve ser assegurado através de uma solução de tradução de links que o cliente utiliza sempre o URL correto. As soluções de tradução de links podem ser complexas e podem não funcionar em todos os cenários. Pode encontrar aqui as nossas soluções documentadas para tradução de links.

Como prática recomendada, é aconselhável usar URLs externos e internos idênticos. Os URLs externos e internos são considerados idênticos, se os protocol://hostname:port/path/ URLs em ambos forem idênticos.

Isso pode ser feito usando o recurso Domínios personalizados .

Exemplos:

Idêntico:

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

Não idêntico:

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/

Tornar os URLs externos e internos idênticos não é possível, se o URL interno contiver uma porta não padrão (diferente de TCP 80 / 443).

Em alguns cenários, as alterações devem ser feitas na configuração do aplicativo Web.

O método PrincipalsAllowedToDelegateToAccount é usado quando os servidores de conector estão em um domínio diferente da conta de serviço de aplicativo Web. Requer o uso da Delegação Restrita baseada em Recursos. Se os servidores de conector e a conta de serviço de aplicativo Web estiverem no mesmo domínio, você poderá usar Usuários e Computadores do Ative Directory para definir as configurações de delegação em cada uma das contas da máquina conectora, permitindo que eles deleguem ao SPN de destino.

Se os servidores de conector e a conta de serviço de aplicativo Web estiverem em domínios diferentes, a delegação baseada em recursos será usada. As permissões de delegação são configuradas no servidor Web de destino e na conta de serviço do aplicativo Web. Este método de delegação restrita é relativamente novo. O método foi introduzido no Windows Server 2012, que oferece suporte à delegação entre domínios, permitindo que o proprietário do recurso (serviço Web) controle quais contas de máquina e serviço podem delegar a ele. Não há interface do usuário para ajudar com essa configuração, então você precisa usar o PowerShell. Para obter mais informações, consulte o whitepaper Understanding Kerberos Constrained Delegation with application proxy.

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

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

Neste caso, há um fallback para "Nome principal do 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 aplicadas para usuários pré-autenticados com êxito na ID do Microsoft Entra. 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 impostas. Com a autenticação de passagem, as políticas de MFA devem ser implementadas no servidor local, se possível, ou habilitando a pré-autenticação com o proxy de aplicativo Microsoft Entra.

Não, esse cenário não é suportado porque o proxy de aplicativo encerra o tráfego TLS.

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

Não, este cenário não é suportado.

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

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

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

Esta opção permite ao usuário baixar o arquivo rdp e usá-lo por outro cliente RDP (fora do cliente Web de Área de Trabalho Remota). Normalmente, outros clientes RDP (como o Microsoft Remote Desktop Client) não podem lidar com a pré-autenticação nativamente. É por isso que o cenário não funciona.

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

Atualmente , o aplicativo móvel do SharePoint não oferece suporte à pré-autenticação do Microsoft Entra.

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

Não, isso não é suportado.

Aplicativos que usam o protocolo WebSocket, por exemplo, QlikSense e Remote Desktop Web Client (HTML5), agora são suportados. As seguintes limitações são conhecidas:

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

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

Sim. A tradução de ligações afeta o desempenho. O serviço de proxy de aplicativo verifica o aplicativo em busca de links codificados e os substitui por suas respetivas URLs externas publicadas antes de apresentá-las ao usuário.

Para obter o melhor desempenho, recomendamos o uso de URLs internas e externas idênticas configurando domínios personalizados. Se não for possível usar domínios personalizados, você poderá melhorar o desempenho da tradução de links usando a Extensão de Logon Seguro de Meus Aplicativos ou o Navegador Microsoft Edge em dispositivos móveis. Consulte Redirecionar links codificados para aplicativos publicados com o proxy de aplicativo Microsoft Entra.

Este cenário não é suportado diretamente. Suas opções para esse cenário são:

1. Publique as URLs HTTP e HTTPS como aplicativos separados com um curinga, mas dê a cada um deles um domínio personalizado diferente. Esta configuração funciona uma vez que têm URLs externos diferentes.

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

   • Gerenciamento de aplicativos de proxy de aplicativo
   • Gestão de Conectores de Rede Privada