Planear una implementación de Microsoft Entra Application Proxy

Microsoft Entra Application Proxy es una solución de acceso remoto segura y rentable a todas las aplicaciones locales. Proporciona una ruta de transición inmediata para que las organizaciones "Cloud First" administren el acceso a aplicaciones locales heredadas que aún no son capaces de usar protocolos modernos. Para obtener más información introductoria, consulte ¿Qué es el proxy de aplicación?

Se recomienda el proxy de aplicación para conceder a los usuarios remotos acceso a recursos internos. El proxy de aplicación reemplaza la necesidad de una VPN o proxy inverso para estos casos de uso de acceso remoto. No está pensado para los usuarios que están en la red corporativa. Estos usuarios que usan el proxy de aplicación para el acceso a la intranet pueden experimentar problemas de rendimiento no deseados.

En este artículo se incluyen los recursos que necesita para planificar, operar y administrar Microsoft Entra Application Proxy.

Planeamiento de la implementación

En la sección siguiente se proporciona una vista amplia de los elementos clave de planeación que le configuran para una experiencia de implementación eficaz.

Requisitos previos

Debe cumplir los siguientes requisitos previos antes de iniciar la implementación. Puede ver más información sobre cómo configurar el entorno, incluidos estos requisitos previos, en el tutorial.

• Conectores: Los conectores son agentes ligeros que puede implementar en:

  • Hardware físico en el entorno local
  • Una máquina virtual (VM) hospedada en cualquier solución de hipervisor
  • Una VM hospedada en Azure para habilitar una conexión saliente con el servicio del proxy de aplicación.

• Consulte Descripción de los conectores de red privada de Microsoft Entra para obtener información general más detallada.

  • Las máquinas del conector deben estar habilitadas para la seguridad de la capa de transporte (TLS) 1.2 antes de instalar los conectores.

  • Si es posible, implemente los conectores en la misma red y segmento que los servidores de aplicaciones web de back-end. Es mejor implementar los conectores después de completar una detección de aplicaciones.

  • Se recomienda que cada grupo de conectores tenga al menos dos conectores para proporcionar alta disponibilidad y escala. Tener tres conectores es óptimo para el mantenimiento de una máquina en cualquier momento. Revise la tabla de capacidad del conector para ayudar a decidir el tipo de máquina para el conector.

• Configuración de acceso a la red: los conectores de red privados de Microsoft Entra se conectan a Azure a través del puerto HTTPS (Protocolo de control de transmisión (TCP) 443) y HTTP (puerto TCP 80) .

  • Terminar el tráfico TLS del conector no es compatible, lo que impide que los conectores establezcan un canal seguro con sus respectivos puntos de conexión del proxy de aplicación de Microsoft Entra.

  • Evite todo tipo de inspección insertada en las comunicaciones TLS salientes entre los conectores y Azure. La inspección interna entre un conector y las aplicaciones de back-end es posible, pero podría degradar la experiencia del usuario y, por lo tanto, no se recomienda.

  • Tampoco se admite, ni se necesita, el equilibrio de carga de los propios conectores.

Consideraciones importantes antes de configurar Microsoft Entra Application Proxy

Deben cumplirse los siguientes requisitos principales para configurar e implementar Microsoft Entra Application Proxy.

• Incorporación de Azure: Antes de implementar Application Proxy, debe sincronizar las identidades de usuario desde un directorio local o bien crear directamente desde los inquilinos de Microsoft Entra. La sincronización de identidades permite a Microsoft Entra ID autenticar previamente a los usuarios antes de concederles acceso a las aplicaciones publicadas a través del proxy de aplicaciones, y contar con la información necesaria del identificador de usuario para realizar el inicio de sesión único (SSO).

• Requisitos de acceso condicional: no se recomienda usar el proxy de aplicación para el acceso a la intranet porque agrega latencia que afecta a los usuarios. Se recomienda usar el proxy de aplicación con autenticación previa y directivas de acceso condicional para el acceso remoto desde Internet. Un enfoque para proporcionar acceso condicional para su uso en la intranet es modernizar las aplicaciones para que se puedan autenticar directamente con Microsoft Entra ID. Para obtener más información, consulte Recursos para migrar aplicaciones a Microsoft Entra ID.

• Límites de servicio: para proteger contra el exceso de consumo de recursos por usuarios individuales, se establecen límites de restricción por aplicación y usuario. Para ver estos límites, consulte Restricciones y límites del servicio Microsoft Entra. Estos límites de estrangulamiento se basan en un punto de referencia más allá del volumen de uso típico y proporcionan un amplio margen para la mayoría de las implementaciones.

• Certificado público: si usa nombres de dominio personalizados, debe adquirir un certificado TLS. Según los requisitos de la organización, obtener un certificado puede llevar algún tiempo y se recomienda comenzar el proceso lo antes posible. El proxy de aplicación de Azure admite certificados estándar, comodín o basados en SAN. Para obtener más información, consulte Configuración de dominios personalizados con el proxy de aplicación de Microsoft Entra.

• Requisitos de dominio: para usar la delegación restringida de Kerberos (KCD) para el inicio de sesión único, asegúrese de que el servidor del conector y el servidor de aplicaciones están unidos a un dominio y en el mismo dominio o en dominios de confianza. El servicio del conector se ejecuta en la cuenta del sistema local y no debe usar una identidad personalizada. Para más información, consulte KCD para inicio de sesión único.

• Registros de DNS para direcciones URL

  • Antes de usar dominios personalizados en el proxy de aplicación, debe crear un registro CNAME en el sistema público de nombres de dominio (DNS), permitiendo a los clientes resolver la URL personalizada externa en la dirección predefinida del proxy de aplicación. Si no se crea un registro CNAME para una aplicación que usa un dominio personalizado, se impide que los usuarios remotos se conecten a la aplicación. Los pasos necesarios para agregar registros CNAME pueden variar de un proveedor de DNS a otro, así que aprenda a administrar registros DNS y conjuntos de registros utilizando el Centro de administración de Microsoft Entra.

  • De forma similar, los hosts de conector deben poder resolver la dirección URL interna de las aplicaciones que se publican.

• Derechos y roles administrativos

  • La instalación del conector requiere derechos de administrador local en el servidor Windows en que se instala. También requiere un mínimo de un rol de Administrador de la aplicación para autenticarse y registrar la instancia del conector para su inquilino de Microsoft Entra.

  • La publicación y administración de aplicaciones requiere el rol Administrador de la aplicación. Los administradores de aplicaciones pueden administrar todas las aplicaciones del directorio, incluidos los registros, la configuración de SSO, las asignaciones de usuarios y grupos y las licencias, la configuración del proxy de aplicación y el consentimiento. No concede la capacidad de administrar el acceso condicional. El rol Administrador de aplicaciones en la nube tiene todas las capacidades del administrador de aplicaciones, salvo que no permite la administración de la configuración del proxy de aplicación.

• Licencias: el proxy de aplicación está disponible a través de una suscripción Microsoft Entra ID P1 o P2. Consulte la página precios de Microsoft Entra para obtener una lista completa de características y opciones de licencia.

Detección de aplicaciones

Para compilar un inventario de todas las aplicaciones del ámbito que se están publicando mediante el proxy de aplicación, recopile la siguiente información:

Puede descargar la hoja de cálculo de inventario de aplicaciones para realizar un inventario de las aplicaciones.

Definir los requisitos organizativos

Las siguientes son las áreas para las que debe definir los requisitos empresariales de la organización. Cada área contiene ejemplos de requisitos

Acceder

• Los usuarios remotos con uniones a un dominio o con dispositivos unidos a Microsoft Entra pueden tener acceso a las aplicaciones publicadas de forma segura con inicio de sesión único (SSO) de conexión directa.

• Los usuarios remotos con dispositivos personales aprobados pueden acceder de forma segura a las aplicaciones publicadas siempre que estén inscritos en MFA y registren la aplicación Microsoft Authenticator en su teléfono móvil como método de autenticación.

Gobernanza

• Los administradores pueden definir y supervisar el ciclo de vida de las asignaciones de usuario a las aplicaciones publicadas mediante el proxy de aplicación.

Seguridad

• Solo los usuarios asignados a las aplicaciones a través de la pertenencia a grupos o individualmente pueden acceder a esas aplicaciones.

Rendimiento

• No hay ninguna degradación del rendimiento de la aplicación en comparación con el acceso a la aplicación desde la red interna.

Experiencia del usuario

• Los usuarios saben cómo acceder a sus aplicaciones mediante el uso de direcciones URL de empresa familiares en cualquier plataforma de dispositivo.

Auditoría

• Los administradores pueden auditar la actividad de acceso del usuario.

Procedimientos recomendados para un piloto

Determine la cantidad de tiempo y esfuerzo necesarios para programar completamente una sola aplicación para el acceso remoto con el inicio de sesión único (SSO). Para hacerlo, ejecute un programa piloto que tenga en cuenta su detección inicial, publicación y pruebas generales. El uso de una sencilla aplicación web basada en IIS que ya está preconfigurada para la autenticación integrada de Windows (IWA) ayudaría a establecer una línea base, ya que la configuración requiere un esfuerzo mínimo para pilotar correctamente el acceso remoto y el inicio de sesión único.

Los siguientes elementos de diseño deben aumentar el éxito de su implementación piloto directamente en un inquilino de producción.

Administración del conector:

Los conectores desempeñan un papel clave a la hora de proporcionar un conducto local a las aplicaciones. El uso del grupo de conectores predeterminado es adecuado para la prueba piloto inicial de las aplicaciones publicadas antes de autorizarlas para producción. A continuación, las aplicaciones probadas correctamente se pueden mover a grupos de conectores de producción.

Administración de aplicaciones:

Es probable que el personal recuerde que una URL externa es familiar y pertinente. Evite publicar la aplicación con nuestros sufijos predefinidos msappproxy.net o onmicrosoft.com. En su lugar, proporcione un dominio verificado familiar de nivel superior, con un prefijo de nombre de host lógico, como intranet.<dominio_de_clientes>.com.

Para restringir la visibilidad del icono de la aplicación piloto a un grupo piloto, oculte su forma de icono de inicio del portal Mis aplicaciones de Azure. Cuando esté listo para producción, puede delimitar la aplicación a su audiencia de destino, ya sea en el mismo entorno de preproducción o publicando también la aplicación en el entorno de producción.

Configuración del inicio de sesión único Algunas opciones de SSO tienen dependencias específicas que pueden tardar tiempo en configurarse, así que, para evitar retrasos en el control de cambios, compruebe que las dependencias se abordan con antelación. El proceso incluye unir hosts del conector a un dominio para iniciar sesión única mediante la delegación restringida de Kerberos (KCD) y ocuparse de otras actividades que consumen mucho tiempo.

TLS entre el host de conector y la aplicación de destino: La seguridad es fundamental, por lo que siempre se debe usar TLS entre el host del conector y las aplicaciones de destino. Especialmente si la aplicación web está configurada para la autenticación basada en formularios (FBA), ya que, en ese caso, las credenciales de usuario se transmiten de forma eficaz en texto no cifrado.

Implementar de forma incremental y probar cada paso. Realice pruebas funcionales básicas después de publicar una aplicación para asegurarse de que se cumplen todos los requisitos empresariales y de usuario:

Pruebe y valide el acceso general a la aplicación web con la autenticación previa deshabilitada. Si se ejecuta correctamente, habilite la autenticación previa y asigne usuarios y grupos. A continuación, pruebe y valide el acceso. A continuación, agregue el método SSO para la aplicación y vuelva a probar para validar el acceso. Por último, aplique las directivas de acceso condicional y MFA según sea necesario. Pruebe y valide el acceso.

Herramientas de solución de problemas: empiece a solucionar problemas comprobando el acceso a la aplicación publicada directamente desde el explorador en el host del conector. Asegúrese de que la aplicación funciona según lo previsto. Simplifique la configuración para aislar problemas, como el uso de un único conector y la deshabilitación del inicio de sesión único. Herramientas como Fiddler de Telerik pueden ayudar a depurar problemas de acceso o contenido mediante el seguimiento del tráfico, incluido para plataformas móviles como iOS y Android. Para más información, consulte la guía para la solución de problemas.

Implementación de la solución

Implementar el proxy de aplicación

Los pasos para implementar el proxy de aplicación se tratan en el tutorial para agregar una aplicación local para el acceso remoto. Si no se completa correctamente la instalación, seleccione Solucionar problemas del proxy de aplicación en el portal o use la guía de solución de problemas para los problemas de instalación del conector del agente del proxy de aplicación.

Publicar aplicaciones mediante el proxy de aplicación

La publicación de aplicaciones supone que cumple todos los requisitos previos y que tiene varios conectores que se muestran como registrados y activos en la página del proxy de aplicación.

Para publicar aplicaciones, también puede usar PowerShell.

Procedimientos recomendados que se deben seguir al publicar una aplicación:

• Usar grupos de conectores: asigne un grupo de conectores designado para publicar cada aplicación correspondiente. Se recomienda que cada grupo de conectores tenga al menos dos conectores para proporcionar alta disponibilidad y escala. Tener tres conectores es óptimo en caso de que necesite atender una máquina en cualquier momento. Además, consulte Descripción de los grupos de conectores de red privada de Microsoft Entra para ver cómo puede usar también grupos de conectores para segmentar los conectores por red o ubicación.

• Establecer tiempo de espera de la aplicación back-end: la configuración es útil en escenarios en los que la aplicación puede requerir más de 75 segundos para procesar una transacción de cliente. Por ejemplo, cuando un cliente envía una consulta a una aplicación web que actúa como front-end a una base de datos. El front-end envía la consulta a su servidor de bases de datos back-end y espera una respuesta, pero en el momento en que recibe una respuesta, el lado cliente de la conversación agota el tiempo de espera. Establecer el tiempo de espera en Long proporciona 180 segundos para que se completen las transacciones más largas.

• Use tipos de cookies adecuados

  • HTTP-Only Cookie: proporciona seguridad adicional al hacer que el proxy de aplicación incluya la marca HTTPOnly en los encabezados de respuesta HTTP set-cookie. La configuración ayuda a mitigar vulnerabilidades de seguridad como scripting entre sitios (XSS). Deje establecido en No para los clientes o agentes de usuario que requieren acceso a la cookie de sesión. Por ejemplo, un cliente RDP/MTSC que se conecte a una Puerta de enlace de Escritorio remoto mediante el proxy de aplicaciones.

  • Cookie segura: cuando se establece una cookie con el atributo Secure, el agente de usuario (aplicación del lado cliente) solo incluye la cookie en solicitudes HTTP si la solicitud se transmite a través de un canal seguro TLS. La configuración ayuda a mitigar el riesgo de que una cookie se ponga en peligro en los canales de texto no cifrado, por lo que debe habilitarse.

  • Cookie persistente: permite que la cookie de sesión del proxy de aplicación persista entre los cierres del explorador y siga siendo válida hasta que expire o se elimine. Se usa para escenarios en los que una aplicación enriquecida, como Office, accede a un documento dentro de una aplicación web publicada, sin que se le vuelva a pedir la autenticación. Sin embargo, habilite con precaución, ya que las cookies persistentes pueden dejar un servicio en riesgo de acceso no autorizado, si no se usan con otros controles de compensación. Esta configuración solo debe usarse para las aplicaciones más antiguas que no pueden compartir cookies entre procesos. Es mejor actualizar la aplicación para controlar el uso compartido de cookies entre procesos en lugar de usar la configuración.

• Traducir direcciones URL en encabezados: habilite la configuración para escenarios en los que no se puede configurar DNS interno para que coincida con el espacio de nombres público de la organización (a.k.a Split DNS). A menos que la aplicación requiera el encabezado de host original en la solicitud de cliente, deje el valor establecido en Sí. La alternativa es que el conector use FQDN en la dirección URL interna para el redireccionamiento del tráfico real y el FQDN en la dirección URL externa como encabezado de host. En la mayoría de los casos, la alternativa debe permitir que la aplicación funcione con normalidad cuando se accede a ella de forma remota, pero los usuarios pierden las ventajas de tener una URL coincidente tanto interna como externa.

• Traducir direcciones URL en el cuerpo de la aplicación: Active la traducción de vínculos del cuerpo de la solicitud de una aplicación cuando quiera que los vínculos de la aplicación se traduzcan en las respuestas que se devuelvan al cliente. Si está habilitada, la función proporciona un mejor intento de traducción de todos los vínculos internos que el proxy de aplicación encuentra en las respuestas HTML y CSS que se devuelven a los clientes. Resulta útil al publicar aplicaciones que contienen vínculos absolutos rígidamente codificados o vínculos de nombre corto de NetBIOS en el contenido, o aplicaciones cuyo contenido se vincula a otras aplicaciones locales.

Para los escenarios en que una aplicación publicada vincula a otras aplicaciones publicadas, habilite la traducción de vínculos para cada aplicación de modo que pueda tener control sobre la experiencia del usuario en el nivel de aplicación.

Por ejemplo, imagine que tiene tres aplicaciones publicadas a través del proxy de aplicación que se vinculan entre sí: Beneficios, Gastos y Viajes, además de una cuarta aplicación, Comentarios, que no se publica a través del proxy de aplicación.

Cuando la traducción de vínculos está habilitada para la aplicación Ventajas, los vínculos a las aplicaciones Expenses and Travel se redirigen a sus direcciones URL externas, lo que permite a los usuarios externos acceder a ellos. Sin embargo, los vínculos de Expenses and Travel back to Benefits no funcionan a menos que la traducción de vínculos también esté habilitada para esas aplicaciones. El vínculo de la aplicación Comentarios no se redirige porque carece de una dirección URL externa, lo que impide que los usuarios externos accedan a ella a través de la aplicación Ventajas. Para obtener más información, consulte Opciones de traducción y redirección de vínculos.

Acceso a la aplicación

Administre el acceso a los recursos publicados del proxy de aplicación seleccionando el enfoque que mejor se adapte a sus requisitos de escenario y escalabilidad. Entre los métodos comunes se incluyen la sincronización de grupos locales a través de Microsoft Entra Connect, la creación de grupos dinámicos en el identificador de Microsoft Entra basado en atributos de usuario, la habilitación de grupos de autoservicio administrados por propietarios de recursos o la combinación de estas estrategias. Explore los recursos vinculados para comprender las ventajas de cada método.

La manera más sencilla de asignar acceso a los usuarios para una aplicación es ir a las opciones Usuarios y grupos desde el panel izquierdo de la aplicación publicada y asignar directamente grupos o individuos.

También puede permitir que los usuarios accedan mediante el autoservicio a su aplicación asignando un grupo del que no son miembros y configurando las opciones de autoservicio.

Si está habilitado, los usuarios inician sesión en el portal MyApps para solicitar acceso. Se aprueban automáticamente y se agregan al grupo de autoservicio, o requieren la aprobación de un responsable designado.

También se puede invitar a los usuarios invitados a acceder a las aplicaciones internas publicadas mediante el proxy de aplicación a través de Microsoft Entra B2B.

En el caso de las aplicaciones locales a las que normalmente se puede acceder de forma anónima, sin autenticación, es posible que desee deshabilitar la opción ubicada en las propiedades de la aplicación.

Dejar la opción establecida en No permite a los usuarios acceder a la aplicación local a través del proxy de aplicación de Microsoft Entra sin permisos, por lo que debe usarse con precaución.

Una vez publicada la aplicación, se debe poder acceder a ella escribiendo su URL externa en un explorador o por su icono en https://myapps.microsoft.com.

Habilitación de la autenticación previa

Compruebe que se pueda acceder a la aplicación mediante el proxy de aplicación con la dirección URL externa.

1. Vaya a Entra ID>Aplicaciones empresariales>Todas las aplicaciones y elija la aplicación que quiere administrar.

2. Seleccione Proxy de la aplicación.

3. En el campo Autenticación previa, use la lista desplegable para seleccionar Microsoft Entra ID y seleccione Guardar. Con la autenticación previa habilitada, Microsoft Entra ID autentica primero a los usuarios. Si se configura el inicio de sesión único, la aplicación back-end también comprueba al usuario antes de conceder acceso. Al cambiar el modo de autenticación previa de Passthrough a Microsoft Entra ID, se protege la dirección URL externa con HTTPS, lo que garantiza que cualquier aplicación que use inicialmente HTTP funciona a través de HTTPS.

Habilitar el inicio de sesión único

El inicio de sesión único mejora la experiencia del usuario y la seguridad al permitir que los usuarios inicien sesión una vez con microsoft Entra ID. Después de la autenticación previa, el conector de red privada inicia sesión en la aplicación local para el usuario, lo que hace que aparezca como si el usuario iniciara sesión directamente.

Elegir la opción Acceso directo permite a los usuarios acceder a la aplicación publicada sin tener que autenticarse en Microsoft Entra ID.

Para habilitar el inicio de sesión único, la aplicación debe autenticar previamente a los usuarios con el identificador de Microsoft Entra. Sin autenticación previa, las opciones de SSO no están disponibles.

Lea Inicio de sesión único en aplicaciones de Microsoft Entra ID para que le ayude a elegir el método de SSO más apropiado al configurar las aplicaciones.

Trabajar con otros tipos de aplicaciones

El proxy de aplicación de Microsoft Entra admite aplicaciones compiladas con la Biblioteca de autenticación de Microsoft (MSAL). Gestiona las aplicaciones cliente nativas utilizando tokens de Microsoft Entra ID en los encabezados de solicitud de cliente para preautenticar a los usuarios.

Obtenga información sobre las configuraciones disponibles del proxy de aplicación. Lea la publicación de aplicaciones cliente nativas y móviles y aplicaciones basadas en declaraciones.

Reforzar la seguridad con el acceso condicional

La seguridad de la aplicación requiere un conjunto avanzado de funcionalidades de seguridad que pueden protegerle frente a complejas amenazas locales y en la nube y responder cuando se producen. Use directivas de acceso condicional para controlar el acceso a las aplicaciones en función de muchas condiciones, como la ubicación, el riesgo, el tipo de dispositivo, el cumplimiento de dispositivos, etc. Para obtener ejemplos de directivas que puede implementar, consulte el artículo Plantillas de acceso condicional.

Las siguientes funcionalidades pueden usarse para admitir Microsoft Entra Application Proxy:

• Acceso condicional basado en el usuario y en la ubicación: mantenga protegidos los datos confidenciales limitando el acceso de los usuarios según la geolocalización o una dirección IP con las directivas de acceso condicional basado en la ubicación.

• Acceso condicional basado en dispositivos: asegúrese de que solo los dispositivos inscritos, aprobados y compatibles pueden acceder a datos corporativos con acceso condicional basado en el dispositivo.

• Acceso condicional basado en la aplicación: el trabajo no se tiene que detener cuando un usuario no está en la red corporativa. Proteja el acceso a aplicaciones locales y en la nube corporativas y mantenga el control con el acceso condicional.

• Acceso condicional basado en el riesgo: Proteja sus datos de hackers malintencionados con una directiva de acceso condicional basada en el riesgo.

• Aplicaciones de Microsoft Entra: Con el servicio del proxy de aplicación implementado y las aplicaciones publicadas de forma segura, ofrezca a sus usuarios un centro sencillo para detectar y acceder a todas sus aplicaciones. Aumente la productividad con funcionalidades de autoservicio, como la capacidad para solicitar acceso a nuevas aplicaciones y grupos o para administrar el acceso a estos recursos en nombre de otros mediante Aplicaciones.

Administrar la implementación

Roles necesarios

Microsoft defiende el principio de otorgar el mínimo privilegio posible para realizar las tareas necesarias con Microsoft Entra ID. Revise los distintos roles de Azure disponibles y elija el correcto para las necesidades de cada rol. Algunos roles se deben aplicar temporalmente y quitar una vez completada la implementación.

Minimizar el número de personas que tienen acceso a información segura o recursos ayudan a reducir la posibilidad de que un actor malintencionado obtenga acceso no autorizado o que un usuario autorizado afecte involuntariamente a un recurso confidencial.

Para administrar el acceso administrativo de forma eficaz y garantizar una auditoría adecuada, se recomienda usar el acceso Just-In-Time (JIT) con Privileged Identity Management. Este enfoque proporciona acceso con privilegios a petición a los recursos de Azure y el identificador de Microsoft Entra solo cuando sea necesario.

Creación de informes y supervisión

Microsoft Entra ID proporciona más información sobre el uso de la aplicación de su organización y el estado operativo a través de registros e informes de auditoría. El proxy de aplicación también facilita la supervisión de conectores desde el Centro de administración de Microsoft Entra y los registros de eventos de Windows.

Registros de auditoría de la aplicación

Estos registros proporcionan información detallada sobre los inicios de sesión en las aplicaciones configuradas con el proxy de aplicación y el dispositivo y el usuario que acceden a la aplicación. Los registros de auditoría se encuentran en el Centro de administración de Microsoft Entra y en Audit API para exportación. Además, los informes de uso y de información también están disponibles para la aplicación.

Supervisión del conector de red privada

Los conectores y el servicio se encargan de todas las tareas de alta disponibilidad. Puede supervisar el estado de sus conectores desde la página del proxy de aplicación en el Centro de administración de Microsoft Entra. Para obtener más información sobre el mantenimiento del conector, consulte Descripción de los conectores de red privada de Microsoft Entra.

Contadores de rendimiento y registros de eventos de Windows

Los conectores tienen registros de administración y sesión. Los registros de administración incluyen eventos importantes y sus errores. Los registros de sesión incluyen todas las transacciones y sus detalles de procesamiento. Los registros y contadores se encuentran en los registros de eventos de Windows. Para obtener más información, consulte Descripción de los conectores de red privada de Microsoft Entra. Siga el tutorial para configurar orígenes de datos del registro de eventos en Azure Monitor.

Guía y pasos para la solución de problemas

Más información sobre los problemas comunes y cómo resolverlos con nuestra guía para los mensajes de error de solución de problemas.

Contenido relacionado

Los siguientes artículos cubren escenarios comunes que también se pueden usar para crear guías de solución de problemas para su organización de soporte técnico.

• Solución de problemas de vínculos en la página de la aplicación que no funciona
• Apertura de puertos para mi aplicación
• Configuración del inicio de sesión único
• Configuración de la delegación limitada de Kerberos
• Configuración con PingAccess
• Solución de problemas de acceso a la aplicación corporativa
• Solución de problemas de instalación del conector del agente de proxy de aplicación
• Solución de problemas de inicio de sesión