Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Esse conteúdo é relevante para a versão local do Proxy de Aplicativo Web. Para habilitar o acesso seguro a aplicações no local pela nuvem, consulte o conteúdo sobre proxy da aplicação do Microsoft Entra .
Este tópico descreve as tarefas necessárias para publicar o SharePoint Server, o Exchange Server ou o Gateway de Área de Trabalho Remota (RDP) por meio do Proxy de Aplicativo Web.
Note
Esta informação é fornecida as-is. Os Serviços de Área de Trabalho Remota dão suporte e recomendam o uso do Proxy de Aplicativo do Azure para fornecer acesso remoto seguro a aplicativos locais.
Publicar o SharePoint Server
Você pode publicar um site do SharePoint por meio do Proxy de Aplicativo Web quando o site do SharePoint estiver configurado para autenticação baseada em declarações ou autenticação integrada do Windows. Se desejar usar os Serviços de Federação do Active Directory (AD FS) para pré-autenticação, deverá configurar uma entidade confiável usando um dos assistentes.
Se o site do SharePoint usar autenticação baseada em declarações, você deverá usar o Assistente para Adicionar Confiança de Terceira Parte Confiável para configurar a confiança da terceira parte confiável para o aplicativo.
Se o site do SharePoint usar a autenticação integrada do Windows, você deverá usar o Assistente para Adicionar Confiança de Terceira Parte Confiável Não Baseada em Declarações para configurar a confiança da terceira parte confiável para o aplicativo. Você pode usar o IWA com um aplicativo Web baseado em declarações, desde que configure o KDC.
Para permitir que os usuários se autentiquem usando a autenticação integrada do Windows, o servidor Proxy de aplicativo Web deve ser associado a um domínio.
Você deve configurar a aplicação para oferecer suporte à delegação restrita de Kerberos. Você pode fazer isso no controlador de domínio para qualquer aplicativo. Você também pode configurar o aplicativo diretamente no servidor back-end se ele estiver sendo executado no Windows Server 2012 R2 ou no Windows Server 2012. Para obter mais informações, consulte O que há de novo na autenticação Kerberos. Você também deve assegurar-se de que os servidores Proxy de Aplicativo Web sejam configurados para a delegação aos nomes principais de serviço dos servidores back-end. Para obter um passo a passo de como configurar o Proxy de Aplicativo Web para publicar um aplicativo usando a autenticação integrada do Windows, consulte Configurar um site para usar a autenticação integrada do Windows.
Se o seu site do SharePoint estiver configurado usando mapeamentos de acesso alternativo (AAM) ou conjuntos de sites nomeados pelo host, você poderá usar diferentes URLs de servidor externo e back-end para publicar seu aplicativo. No entanto, se você não configurar seu site do SharePoint usando AAM ou conjuntos de sites nomeados pelo host, deverá usar as mesmas URLs de servidor externo e de back-end.
Publicar o Exchange Server
A tabela a seguir descreve os serviços do Exchange que você pode publicar por meio do Proxy de Aplicativo Web e a pré-autenticação com suporte para esses serviços:
| Serviço de troca | Pre-authentication | Notes |
|---|---|---|
| Outlook Aplicação Web | - AD FS usando autenticação não baseada em declarações - Passagem - AD FS usando autenticação baseada em reclamações para Exchange 2013 Service Pack 1 (SP1) on-premises |
Para obter mais informações, consulte: Usando a autenticação baseada em declarações do AD FS com o Outlook Web App e o EAC |
| Painel de Controle do Exchange | Pass-through | |
| Outlook em Qualquer Lugar | Pass-through | Você deve publicar URLs adicionais para que o Outlook em Qualquer Lugar funcione corretamente: - O URL da descoberta automática, do EWS e do OAB (no caso do modo de cache do Outlook). |
| Exchange ActiveSync | Pass-through AD FS usando o protocolo de autorização HTTP Basic |
|
| Serviços Web do Exchange | Pass-through | |
| Autodiscover | Pass-through | |
| Catálogo de Endereços Offline | Pass-through |
Para publicar o Outlook Web App usando a autenticação integrada do Windows, você deve usar o Assistente para Adicionar Confiança de Terceira Parte Confiável Não Baseada em Declarações para configurar a confiança da terceira parte confiável para o aplicativo.
Para permitir que os usuários se autentiquem usando a delegação restrita de Kerberos, o servidor Proxy de Aplicativo Web deve ser associado a um domínio.
Você deve configurar o aplicativo para oferecer suporte à autenticação Kerberos. Além disso, você precisa registrar um SPN (nome da entidade de serviço) na conta na qual o serviço Web está sendo executado. Você pode fazer isso no controlador de domínio ou nos servidores back-end. Em um ambiente Exchange com balanceamento de carga, isso exigiria o uso da Conta de Serviço Alternativa, consulte Configurando a autenticação Kerberos para servidores de Acesso para Cliente com balanceamento de carga
Você também pode configurar o aplicativo diretamente no servidor back-end se ele estiver sendo executado no Windows Server 2012 R2 ou no Windows Server 2012. Para obter mais informações, consulte O que há de novo na autenticação Kerberos. Você também deve assegurar-se de que os servidores Proxy de Aplicativo Web sejam configurados para a delegação aos nomes principais de serviço dos servidores back-end.
Publicação do Gateway de Área de Trabalho Remota através do Proxy de Aplicações Web
Se quiser restringir o acesso ao seu Gateway de Acesso Remoto e adicionar pré-autenticação para acesso remoto, você pode implantá-lo por meio do Proxy de Aplicativo Web. Esta é uma excelente forma de garantir que se possa ter um sistema de pré-autenticação completo para RDG, incluindo MFA. Publicar sem pré-autenticação também é uma opção e fornece um único ponto de entrada em seus sistemas.
Como publicar uma aplicação no RDG usando a autenticação de passagem direta do Proxy de Aplicações Web
A instalação será diferente dependendo se as funções de Acesso via Web RD (/rdweb) e Gateway RD (rpc) estão no mesmo servidor ou em servidores diferentes.
Se os papéis RD Web Access e RD Gateway estiverem alojados no mesmo servidor RDG, pode simplesmente publicar o FQDN raiz em Proxy de Aplicação Web, como
https://rdg.contoso.com/.Você também pode publicar os dois diretórios virtuais individualmente, por exemplo,https://rdg.contoso.com/rdweb/ e
https://rdg.contoso.com/rpc/.Se o Acesso via Web RD e o Gateway RD estiverem hospedados em servidores RDG separados, será necessário publicar os dois diretórios virtuais individualmente. Pode usar os mesmos ou diferentes FQDNs externos, por exemplo,
https://rdweb.contoso.com/rdweb/ehttps://gateway.contoso.com/rpc/.Se os FQDNs Externo e Interno forem diferentes, não deve desativar a tradução de cabeçalhos de pedidos na regra de publicação do RDWeb. Isso pode ser feito executando o seguinte script do PowerShell no servidor Proxy de Aplicativo Web, mas ele deve ser habilitado por padrão.
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$falseNote
Se você precisar oferecer suporte a clientes avançados, como Conexões de RemoteApp e Área de Trabalho ou conexões de Área de Trabalho Remota do iOS, elas não oferecem suporte à pré-autenticação, portanto, você precisa publicar RDG usando autenticação de passagem.
Como publicar um aplicativo no RDG usando o Proxy de Aplicativo Web com pré-autenticação
A pré-autenticação do Proxy de Aplicativo Web com RDG funciona ao transmitir o cookie de pré-autenticação obtido pelo Internet Explorer para o cliente de Conexão de Área de Trabalho Remota (mstsc.exe). Isso é usado pelo cliente de Conexão de Área de Trabalho Remota (mstsc.exe). Isso é usado pelo cliente de Conexão de Área de Trabalho Remota como prova de autenticação.
O procedimento a seguir instrui o servidor de Collection a incluir as propriedades RDP personalizadas necessárias nos ficheiros RDP do Remote App que são enviados aos clientes. Estes indicam ao cliente que é necessária a pré-autenticação e para passar os cookies do endereço do servidor de pré-autenticação ao cliente de Conexão de Ambiente de Trabalho Remoto (mstsc.exe). Em conjunto com a desativação do recurso HttpOnly no aplicativo Web Application Proxy, isso permite que o cliente de Conexão de Área de Trabalho Remota (mstsc.exe) utilize o cookie Web Application Proxy obtido através do navegador.
A autenticação no servidor RD Web Access ainda usará o logon do formulário RD Web Access. Isso fornece o menor número de solicitações de autenticação do utilizador, pois o formulário de logon do RD Web Access cria um repositório de credenciais no lado do cliente que pode então ser usado pelo cliente de Conexão de Área de Trabalho Remota (mstsc.exe) para qualquer lançamento subsequente de Aplicação Remota.
Primeiro, crie uma Confiança de Terceiro Confiável manual no AD FS como se estivesse publicando um aplicativo reconhecedor de declarações. Isso significa que você precisa criar uma confiança de terceira parte confiável fictícia que está lá para impor a pré-autenticação, para que você obtenha a pré-autenticação sem a Delegação Restrita de Kerberos para o servidor publicado. Depois que um utilizador é autenticado, todo o restante é processado.
Warning
Pode parecer que o uso da delegação é preferível, mas não resolve totalmente os requisitos de Single Sign-On (SSO) do mstsc, e há problemas ao delegar para o diretório /rpc, porque o cliente espera manipular a autenticação do Gateway RD por si próprio.
Para criar uma Confiança de Terceira Parte Confiável manual, siga as etapas no Console de Gerenciamento do AD FS:
Usar o assistente Adicionar Confiança de Terceira Parte
Selecione Inserir dados sobre a parte confiável manualmente.
Aceite todas as configurações padrão.
Para o identificador de Confiança da Parte Confiável, insira o FQDN externo que o (a) utilizador(a) usará para o acesso RDG, por exemplo
https://rdg.contoso.com/.Esta é a confiança de terceira parte confiável que você usará ao publicar o aplicativo no Proxy de Aplicativo Web.
Publique a raiz do site (por exemplo,
https://rdg.contoso.com/) no Proxy de Aplicativo Web. Defina a pré-autenticação como AD FS e use a confiança de terceira parte confiável criada acima. Isso permitirá que /rdweb e /rpc usem o mesmo cookie de autenticação de Proxy de Aplicativo Web.É possível publicar /rdweb e /rpc como aplicações separadas e até mesmo usar diferentes servidores publicados. Você só precisa garantir que publique ambos usando a mesma Relação de Confiança de Terceiros, pois o token de Proxy de Aplicativo Web é emitido para esta relação e, portanto, é válido entre aplicativos publicados com a mesma Relação de Confiança de Terceiros.
Se os FQDNs Externo e Interno forem diferentes, não deve desativar a tradução dos cabeçalhos de requisição na regra de publicação do RDWeb. Isso pode ser feito executando o seguinte script do PowerShell no servidor Proxy de Aplicativo Web, mas ele deve ser habilitado por padrão:
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$trueDesative a propriedade de cookie HttpOnly no Proxy de Aplicações Web na aplicação RDG publicada. Para permitir que o controlo ActiveX do RDG aceda ao cookie de autenticação do Web Application Proxy, é necessário desativar a propriedade HttpOnly no cookie do Web Application Proxy.
Isso requer que você instale o pacote cumulativo de atualizações de novembro de 2014 para Windows RT 8.1, Windows 8.1 e Windows Server 2012 R2 (KB3000850).
Depois de instalar o hotfix, execute o seguinte script do PowerShell no servidor Proxy de Aplicativo Web especificando o nome do aplicativo relevante:
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableHttpOnlyCookieProtection:$trueA desativação de HttpOnly permite que o controle ActiveX RDG acesse o cookie de autenticação do Proxy de Aplicativo Web.
Configure a coleção RDG relevante no servidor de Coleção para permitir que o cliente de Ligação de Ambiente de Trabalho Remoto (mstsc.exe) saiba que a pré-autenticação é necessária no arquivo rdp.
No Windows Server 2012 e no Windows Server 2012 R2, isso pode ser feito executando o seguinte cmdlet do PowerShell no servidor da Coleção RDG:
Set-RDSessionCollectionConfiguration -CollectionName "<yourcollectionname>" -CustomRdpProperty "pre-authentication server address:s: <https://externalfqdn/rdweb/>`nrequire pre-authentication:i:1"Certifique-se de remover os < colchetes e > quando substituir por seus próprios valores, por exemplo:
Set-RDSessionCollectionConfiguration -CollectionName "MyAppCollection" -CustomRdpProperty "pre-authentication server address:s: https://rdg.contoso.com/rdweb/`nrequire pre-authentication:i:1"No Windows Server 2008 R2:
Inicie sessão no Terminal Server com uma conta que tenha privilégios de Administrador.
Vá para Iniciar>Ferramentas Administrativas>, Serviços de> Terminal,TS RemoteApp Manager.
No painel de Visão Geral do TS RemoteApp Manager, ao lado de Definições RDP, selecione Alterar.
Na guia Configurações de RDP personalizadas , digite as seguintes configurações de RDP na caixa Configurações de RDP personalizadas:
pre-authentication server address: s: https://externalfqdn/rdweb/require pre-authentication:i:1Quando terminar, selecione Candidatar-se.
Isso instrui o servidor da Coleção a incluir as propriedades RDP personalizadas nos arquivos RDP que são enviados aos clientes. Estes informam o cliente de que é necessária a pré-autenticação e que deve passar os cookies do endereço do servidor de pré-autenticação para o cliente de Conexão de Ambiente de Trabalho Remoto (mstsc.exe). Isso, em conjunto com a desativação de HttpOnly no aplicativo Web Application Proxy, permite que o cliente de Conexão de Área de Trabalho Remota (mstsc.exe) utilize o cookie de autenticação de Proxy de Aplicativo Web obtido através do navegador.
Para obter mais informações sobre RDP, consulte Configurando o cenário OTP do Gateway TS.