Preguntas más frecuentes sobre el proxy de aplicación de Microsoft Entra

No, el proxy de aplicación usa los siguientes elementos de configuración y no se deben modificar ni eliminar:

• Habilitación o deshabilitación de "Permitir flujos de clientes públicos".
• CWAP_AuthSecret (secretos de cliente).
• Permisos de API. La modificación de cualquiera de los elementos de configuración anteriores en la página de registro de aplicaciones interrumpe la autenticación previa para el proxy de aplicación de Microsoft Entra.

No, debe eliminar una aplicación de proxy de aplicación del área de aplicaciones empresariales del Centro de administración Microsoft Entra. Si elimina la aplicación de proxy de aplicación de el área registros de aplicaciones del Centro de administración de Microsoft Entra, podría experimentar problemas.

Para usar el proxy de aplicación de Microsoft Entra, debe tener una licencia de Microsoft Entra ID P1 o P2. Para más información sobre las licencias, vea Precios de Microsoft Entra.

Si su licencia caduca, el proxy de aplicación se deshabilita automáticamente. La información de la aplicación se guardará durante un año como máximo.

Asegúrese de que tiene al menos una licencia P1 o P2 de Microsoft Entra ID y un conector de red privada de Microsoft Entra instalado. Después de instalar correctamente su primer conector, el servicio proxy de aplicaciones de Microsoft Entra se habilitará automáticamente.

Sí, el proxy de aplicación y el acceso privado Microsoft Entra usan el conector de red privada de Microsoft Entra. Para obtener más información sobre el conectores, consulte Conector de red privada de Microsoft Entra. Para solucionar problemas de configuración del conector, consulte Solución de problemas de conectores.

Aunque estos sufijos aparecen en la lista de sufijos, no debería usarlos. Estos sufijos de dominio no están diseñados para usarse con el proxy de aplicación de Microsoft Entra. Si usa estos sufijos de dominio, la aplicación creada del proxy de aplicación de Microsoft Entra no funcionará. Puede usar el sufijo de dominio estándar (msappproxy.net) o un dominio personalizado.

Microsoft Entra ID tiene un servicio de proxy de aplicación que permite a los usuarios tener acceso a aplicaciones locales mediante el inicio de sesión con su cuenta de Microsoft Entra. Si instaló conectores en diferentes regiones, puede optimizar el tráfico. Para ello, seleccione la región de servicio en la nube del proxy de aplicación más cercana para usarla con cada grupo de conectores; consulte Optimizar el flujo de tráfico con el proxy de aplicación de Microsoft Entra.

Después de cargar el certificado SSL, recibirá el mensaje "certificado no válido, contraseña posiblemente incorrecta" en el portal.

A continuación se ofrecen algunas sugerencias para solucionar este error:

• Compruebe si el certificado da problemas. Instálelo en su equipo local. Si no experimenta ningún problema, el certificado es correcto.
• Asegúrese de que la contraseña no contiene caracteres especiales. La contraseña solo debe contener los caracteres 0-9, A-Z y a-z.
• Si el certificado se creó con el proveedor de almacenamiento de claves de software de Microsoft, se debe utilizar el algoritmo de RSA.

La duración predeterminada es de 85 segundos. La duración "larga" es de 180 segundos. No se puede extender el límite del tiempo de expiración.

No, actualmente no se admite.

El secreto de cliente, también denominado CWAP_AuthSecret, se agrega automáticamente al objeto de aplicación (registro de aplicaciones) cuando se crea la aplicación del proxy de aplicación de Microsoft Entra.

El secreto de cliente es válido durante un año. Se crea automáticamente un nuevo secreto de cliente de un año antes de que expire el secreto de cliente válido actual. En todo momento se conservan tres secretos de cliente CWAP_AuthSecret en el objeto de aplicación.

No, debe usar el dominio de reserva original.

Artículo mencionado en cuestión: Agregar y reemplazar el dominio de reserva de onmicrosoft.com en Microsoft 365

En la página de registros de aplicaciones puede cambiar la dirección URL de la página principal a la dirección URL externa que quiera ver en la página de aterrizaje. La página especificada se carga cuando la aplicación se inicia desde Mis Aplicaciones o el portal de Office 365. Para obtener los pasos de configuración, consulte Establecer una página principal personalizada para aplicaciones publicadas mediante el proxy de aplicación de Microsoft Entra.

Si se configura la autenticación previa de Microsoft Entra y la dirección URL de la aplicación contiene un carácter "#" al intentar acceder a la aplicación por primera vez, se le redirigirá a Microsoft Entra ID (login.microsoftonline.com) para la autenticación. Una vez completada la autenticación, se le redirigirá a la parte de la dirección URL anterior al carácter "#" y todo lo que viene después de "#" parece omitirse o eliminarse. Por ejemplo, si la dirección URL es https://www.contoso.com/#/home/index.html, una vez realizada la autenticación Microsoft Entra el usuario es redirigido ahttps://www.contoso.com/. Este comportamiento se debe por diseño a la forma en que el explorador considera el carácter "#".

Posibles soluciones o alternativas:

• Configure un redireccionamiento de https://www.contoso.com a https://contoso.com/#/home/index.html. El usuario debe acceder primero a https://www.contoso.com.
• La dirección URL usada para el primer intento de acceso debe incluir el carácter "#" en formato codificado (%23). Es posible que el servidor publicado no lo acepte.
• Configure el tipo de autenticación previa passthrough (no recomendado).

No, no hay ningún requisito de IIS para las aplicaciones que se publican. Puede publicar aplicaciones web que se ejecutan en servidores distintos de Windows Server. Sin embargo, es posible que no pueda usar la autenticación previa con un servidor que no sea Windows, dependiendo de si el servidor web admite Negotiate (autenticación Kerberos). IIS no es necesario en el servidor en el que está instalado el conector.

El proxy de aplicación no agrega automáticamente el encabezado HTTP Strict-Transport-Security a las respuestas HTTPS, pero mantiene el encabezado si está en la respuesta original enviada por la aplicación publicada. La incorporación de una configuración para habilitar esta funcionalidad está en el mapa de ruta.

No, si el protocolo http está configurado en la dirección URL externa, el punto de conexión del proxy de aplicación de Microsoft Entra acepta la solicitud entrante en el puerto TCP 80; y si se trata del protocolo https, se acepta en el puerto TCP 443.

Sí, algunos ejemplos de direcciones URL internas que incluyen puertos son los siguientes: http://app.contoso.local:8888/, https://app.contoso.local:8080/, https://app.contoso.local:8081/test/.

Algunas respuestas enviadas por las aplicaciones web publicadas pueden contener direcciones URL codificadas de forma rígida. En este caso, se debe garantizar que el cliente siempre use la dirección URL correcta mediante una solución de traducción de vínculos. Las soluciones de traducción de vínculos pueden ser complejas y es posible que no funcionen en todos los escenarios. Puede encontrar aquí nuestras soluciones documentadas para la traducción de vínculos.

Como procedimiento recomendado, se recomienda usar direcciones URL externas e internas idénticas. Las direcciones URL externas e internas se consideran idénticas si los valores de protocol://hostname:port/path/ de ambas direcciones URL son idénticos.

Esto se puede lograr mediante la característica de dominios personalizados.

Ejemplos:

Idénticas:

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

No 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/

No es posible hacer que las direcciones URL externas e internas sean idénticas, si la dirección URL interna contiene un puerto no estándar (distinto de TCP 80/443).

En algunos escenarios, los cambios deben realizarse en la configuración de la aplicación web.

El método PrincipalsAllowedToDelegateToAccount se usa cuando los servidores del conector están en un dominio diferente de la cuenta de servicio de la aplicación web. Requiere el uso de la delegación restringida basada en recursos. Si los servidores del conector y la cuenta de servicio de la aplicación web se encuentran en el mismo dominio, puede usar los usuarios y equipos de Active Directory para configurar las opciones de delegación en cada una de las cuentas de equipo del conector, para que así puedan delegar en el SPN de destino.

Si los servidores del conector y la cuenta de servicio de la aplicación web están en dominios diferentes, se usará la delegación basada en recursos. Los permisos de delegación se configuran en el servidor web de destino y la cuenta de servicio de la aplicación web. Tenga en cuenta que este método de delegación restringida es relativamente nuevo. El método se presentó en Windows Server 2012, que admite la delegación entre dominios al permitir que el propietario del recurso (servicio web) controle el equipo y las cuentas de servicio que pueden delegar contenido en él. No hay ninguna interfaz de usuario que le ayude con esta configuración, por lo que tendrá que usar PowerShell. Para obtener más información, consulte las notas del producto Descripción de la delegación restringida de Kerberos con el proxy de aplicación.

No se puede usar la autenticación NTLM como método de autenticación previa o de inicio de sesión único. La autenticación NTLM solo se puede usar cuando se puede negociar directamente entre el cliente y la aplicación web publicada. El uso de la autenticación NTLM normalmente hace que aparezca un mensaje de inicio de sesión en el explorador.

No, esto no funcionará, ya que un usuario invitado de Microsoft Entra ID no tiene el atributo que requieren las identidades de inicio de sesión mencionadas anteriormente.

En este caso, existe una opción alternativa: "Nombre principal de usuario". Para más información sobre el escenario B2B, consulte Conceder a los usuarios B2B en Microsoft Entra ID acceso a las aplicaciones locales.

Las directivas de acceso condicional solo se aplican a los usuarios que hayan realizado correctamente una autenticación previa en Microsoft Entra ID. La autenticación transferida no desencadena la autenticación Microsoft Entra, por lo que no se pueden aplicar las directivas de Acceso condicional. Si se usa la autenticación transferida, las directivas de MFA se deben implementar en el servidor local (si es posible) o se debe habilitar la autenticación previa con el proxy de aplicación de Microsoft Entra.

No, este escenario no se admite porque el proxy de aplicación finaliza el tráfico TLS.

Consulte Publicación del Escritorio Remoto con el proxy de aplicación de Microsoft Entra.

No, este escenario no se admite.

Sí, es normal. El escenario de autenticación previa requiere un control ActiveX, que no se admite en exploradores de terceros.

Sí, este escenario se encuentra actualmente en versión preliminar pública. Consulte Publicación del Escritorio Remoto con el proxy de aplicación de Microsoft Entra.

Sí, es normal. Si el equipo del usuario está unido a Microsoft Entra, el usuario inicia sesión automáticamente en Microsoft Entra ID. El usuario solo tiene que proporcionar sus credenciales en el formulario de inicio de sesión RDWeb.

Esta opción permite al usuario descargar el archivo rdp y que lo use otro cliente RDP (fuera del cliente web del Escritorio remoto). Por lo general, otros clientes RDP (como el cliente de Escritorio remoto de Microsoft) no pueden realizar la autenticación previa de forma nativa. Por eso el escenario no funciona.

Consulte Habilitar el acceso remoto a SharePoint con el proxy de aplicación de Microsoft Entra.

Actualmente, la Aplicación móvil de SharePoint no es compatible con la autenticación previa de Microsoft Entra.

El proxy de aplicación de Microsoft Entra está diseñado para funcionar con Microsoft Entra ID y no cumple los requisitos para funcionar como un proxy de AD FS.

No se admite.

Ahora se admiten las aplicaciones que usan el protocolo WebSocket, por ejemplo QlikSense y cliente web de Escritorio remoto (HTML5). Estas son las limitaciones conocidas:

• El proxy de la aplicación descarta la cookie que se establece en la respuesta del servidor al abrir la conexión WebSocket.
• No hay ningún inicio de sesión único aplicado a la solicitud de WebSocket.
• Las características (EventLogs, PowerShell y Servicios de Escritorio remoto) en Windows Admin Center (WAC) no funcionan actualmente a través del proxy de aplicación de Microsoft Entra.

La aplicación WebSocket no tiene ningún requisito de publicación único y se puede publicar igual que todas las demás aplicaciones de proxy de aplicación.

Sí. El uso de la traducción de vínculos afecta al rendimiento. El servicio de proxy de aplicación examina la aplicación en busca de vínculos codificados y los reemplaza por sus respectivas direcciones URL externas publicadas antes de presentarlas al usuario.

Para obtener el mejor rendimiento, se recomienda usar direcciones URL internas y externas idénticas mediante la configuración de los dominios personalizados. Si no es posible usar dominios personalizados, puede mejorar el rendimiento de la traducción de vínculos mediante la extensión del inicio de sesión seguro de Mis aplicaciones o el explorador Microsoft Edge en dispositivos móviles. Consulte Redirección de los vínculos codificados de manera rígida para las aplicaciones publicadas con el proxy de aplicación de Microsoft Entra.

Este escenario no se admite directamente. Pero tiene varias opciones para el mismo:

1. Puede publicar las direcciones URL HTTP y HTTPS como aplicaciones independientes con un carácter comodín, pero deberá asignarles un dominio personalizado diferente. Esta configuración funciona ya que tienen diferentes direcciones URL externas.

2. Puede publicar la dirección URL HTTPS a través de una aplicación con caracteres comodín. Publique las aplicaciones HTTP por separado mediante estos cmdlets de PowerShell de proxy de aplicación:

   • Administración de aplicaciones de proxy de aplicación
   • administración de conectores de red privada