Diseño de referencia validado del módulo de tráfico AAA

Resumen de Citrix ADC

Citrix ADC es un Delivery Controller de aplicaciones todo en uno que hace que las aplicaciones se ejecuten hasta cinco veces mejor, reduce los costes de propiedad de las aplicaciones, optimiza la experiencia del usuario y garantiza que las aplicaciones estén siempre disponibles mediante:

• Gestión de tráfico y equilibrio de carga avanzada L4-7

• Aceleración comprobada de aplicaciones, como compresión HTTP y almacenamiento en caché

• Un firewall de aplicaciones integrado para la seguridad de las aplicaciones

• Descarga de servidores para reducir significativamente los costes y consolidar servidores

Como líder indiscutible en la prestación de servicios y aplicaciones, Citrix ADC se implementa en miles de redes de todo el mundo para optimizar, proteger y controlar la prestación de todos los servicios empresariales y en la nube. Implementado directamente frente a servidores web y bases de datos, Citrix ADC combina equilibrio de carga de alta velocidad y conmutación de contenido, compresión http, almacenamiento en caché de contenido, aceleración SSL, visibilidad de flujo de aplicaciones y un potente firewall de aplicaciones en una plataforma integrada y fácil de usar. El cumplimiento de los SLA se simplifica enormemente con la supervisión integral que transforma los datos de red en inteligencia empresarial procesable. Citrix ADC permite definir y administrar directivas mediante un simple motor de directivas declarativas sin necesidad de experiencia en programación.

Módulo AAA-TM de Citrix ADC

Gestión del tráfico

AAA proporciona seguridad para un entorno de Internet distribuido al permitir que cualquier cliente con las credenciales adecuadas se conecte de forma segura a servidores de aplicaciones protegidos desde cualquier lugar de Internet. Esta función incorpora las tres funciones de seguridad de autenticación, autorización y auditoría. La autenticación permite a Citrix ADC verificar las credenciales del cliente, ya sea localmente o con un servidor de autenticación de terceros. Permite que solo los usuarios aprobados accedan a servidores protegidos. La autorización permite al ADC verificar qué contenido de un servidor protegido debe permitir a cada usuario acceder. La auditoría permite al ADC mantener un registro de la actividad de cada usuario en un servidor protegido.

Citrix Gateway

Las empresas ahora pueden lograr la federación y Single Sign-On en aplicaciones y escritorios virtuales de empresa, web, SaaS y locales a través de Citrix Gateway. Citrix Gateway aprovecha sus funciones de autenticación, autorización y auditoría (AAA) con el cambio de contenido para permitir a los usuarios acceder a todas sus aplicaciones empresariales autorizadas a través de una única puerta de enlace y URL. Las organizaciones que implementan Citrix ADC hoy en día para su infraestructura de aplicaciones y escritorios virtuales pueden ampliar fácilmente su funcionalidad para Single Sign-On único en aplicaciones de nube heredadas de empresa, web, virtuales, públicas, privadas e híbridas. Los clientes que utilizan puertas de enlace y soluciones de terceros con Single Sign-On y de entrega de aplicaciones pueden implementar una única solución para todas sus necesidades de Single Sign-On al consolidarse en Citrix Gateway.

Los mecanismos de autenticación incluyen LDAP, RADIUS, SAML, Kerberos, autenticación basada en certificados y más.

Cualquier mecanismo de autenticación que esté configurado en un servidor virtual de Citrix Gateway antes de utilizar la actualización automáticamente cuando el servidor virtual Citrix Gateway se coloca detrás del servidor virtual de Unified Gateway.

No hay pasos de configuración adicionales que no sean la asignación de una dirección IP no direccionable (0.0.0.0) al servidor virtual de Citrix Gateway.

Introducción a la autenticación

Para comprender cómo funciona AAA en un entorno distribuido, considere una organización con una intranet a la que tienen acceso sus empleados en la oficina, en el hogar y durante el viaje. El contenido de la intranet es confidencial y requiere acceso seguro. Cualquier usuario que desee acceder a la intranet debe tener un nombre de usuario y una contraseña válidos. Para cumplir estos requisitos, el ADC hace lo siguiente:

• Redirige al usuario a la página de inicio de sesión si el usuario accede a la intranet sin haber iniciado sesión.

• Recopila las credenciales del usuario, las entrega al servidor de autenticación y las almacena en caché en un directorio al que se puede acceder a través de LDAP.

• Comprueba que el usuario está autorizado a acceder a contenido de intranet específico antes de entregar la solicitud del usuario al servidor de aplicaciones.

• Mantiene un tiempo de espera de sesión después del cual los usuarios deben autenticarse de nuevo para recuperar el acceso a la intranet. (Puede configurar el tiempo de espera).

• Registra los accesos del usuario, incluidos los intentos de inicio de sesión no válidos, en un registro de auditoría.

La autenticación requiere que varias entidades: el cliente, el dispositivo Citrix ADC, el servidor de autenticación externo si se utiliza una, y el servidor de aplicaciones, respondan entre sí cuando se le solicite realizando una serie compleja de tareas en el orden correcto.

Cuando un cliente autenticado solicita un recurso, el ADC, antes de enviar la solicitud al servidor de aplicaciones, comprueba las directivas de usuario y grupo asociadas a la cuenta de cliente, para comprobar que el cliente está autorizado a acceder a ese recurso. El ADC maneja toda la autorización en servidores de aplicaciones protegidas. No es necesario realizar ninguna configuración especial de los servidores de aplicaciones protegidos.

Cambios de contraseña

AAA-TM controla los cambios de contraseña para los usuarios mediante el método específico del protocolo para el servidor de autenticación. Para la mayoría de los protocolos, ni el usuario ni el administrador necesitan hacer nada diferente de lo que harían sin AAA-TM. Incluso cuando un servidor de autenticación LDAP está en uso y ese servidor forma parte de una red distribuida de servidores LDAP con un único servidor de administración de dominio designado, los cambios de contraseña generalmente se manejan sin problemas. Cuando un cliente autenticado de un servidor LDAP cambia su contraseña, el cliente envía una solicitud de modificación de credenciales a AAA-TM, que la reenvía al servidor LDAP. Si el servidor LDAP del usuario es también el servidor de administración de dominio, ese servidor responde adecuadamente y, a continuación, AAA-TM realiza el cambio de contraseña solicitado. De lo contrario, el servidor LDAP envía AAA-TM una respuesta LDAP_REFERRAL al servidor de administración del dominio. AAA-TM sigue la referencia al servidor de administración de dominio indicado, se autentica en ese servidor y realiza el cambio de contraseña en ese servidor.

Nota:

Al configurar AAA-TM con un servidor de autenticación LDAP, el administrador del sistema debe tener en cuenta las siguientes condiciones y limitaciones:

• AAA-TM asume que el servidor de administración de dominio en la referencia acepta las mismas credenciales de enlace que el servidor original.
• AAA-TM solo sigue las referencias LDAP para las operaciones de cambio de contraseña. En otros casos, AAA-TM se niega a seguir la referencia.
• AAA-TM solo sigue un nivel de referencias LDAP. Si el segundo servidor LDAP también devuelve una referencia, AAA- TM se niega a seguir la segunda referencia.

Soporte de auditoría/registro

El ADC admite la auditoría de todos los estados y la información de estado, por lo que puede ver los detalles de lo que cada usuario hizo mientras inició sesión, en orden cronológico. Para proporcionar esta información, el dispositivo registra cada evento, tal como ocurre, en un archivo de registro de auditoría designado en el dispositivo o en un servidor syslog. La auditoría requiere configurar el dispositivo y cualquier servidor syslog que utilice.

Limitaciones y directrices de uso

Matriz de autenticación:

Una IP pública para implementaciones AAA-TM en Citrix ADC

Citrix ADC admite el marco AAA para servidores virtuales de administración de tráfico (TM) (en adelante denominado vserver) mediante el aprovechamiento de varias funciones AAA admitidas por el subsistema de autenticación. El servidor utilizado para la autenticación se denomina “authentication vserver” o AAA vserver.

Citrix ADC puede consolidar la imagen anterior en un extremo público al tener la diapositiva vserver de autenticación adyacente a TM vserver para que haya un punto final público y, a su vez, un certificado. Esto se muestra en el siguiente diagrama:

Aplicaciones alojadas en Windows por Citrix Virtual Apps and Desktops

Puede implementar Citrix Gateway en el perímetro de la red interna (o intranet) de la organización para proporcionar un único punto de acceso seguro a los servidores, aplicaciones y otros recursos de red que residen en la red interna. Todos los usuarios remotos deben conectarse a Citrix Gateway para poder acceder a los recursos de la red interna.

Citrix Gateway se instala con mayor frecuencia en las siguientes ubicaciones de una red:

• En la red DMZ

• En una red segura que no tiene una DMZ

También puede implementar Citrix Gateway con Citrix Virtual Apps, Virtual Desktops, StoreFront y Endpoint Management Server a los usuarios para acceder a sus aplicaciones Windows, web, móviles y SaaS.

Si su implementación incluye Citrix Virtual Apps, StoreFront o Virtual Desktops, puede implementar Citrix Gateway en una configuración DMZ de un salto o de dos saltos. No se admite una implementación de doble salto con versiones anteriores de escritorios virtuales o aplicaciones virtuales.

Aplicaciones SaaS SAML 2.0

Security Assertion Markup Language (SAML) es un mecanismo de autenticación basado en XML que proporciona capacidad de Single Sign-On y está definido por el Comité Técnico de Servicios de Seguridad de OASIS.

¿Por qué SAML? Considere un escenario en el que un proveedor de servicios (LargeProvider) aloja varias aplicaciones para un cliente (BigCompany). BigCompany tiene usuarios que deben acceder sin problemas a estas aplicaciones. En una configuración tradicional, LargeProvider necesitaría mantener una base de datos de usuarios de BigCompany. Esto plantea algunas preocupaciones para cada una de las siguientes partes interesadas:

• LargeProvider debe garantizar la seguridad de los datos del usuario.

• BigCompany debe validar a los usuarios y mantener los datos del usuario actualizados, no solo en su propia base de datos, sino también en la base de datos de usuarios mantenida por LargeProvider. Por ejemplo, un usuario eliminado de la base de datos BigCompany también debe eliminarse de la base de datos LargeProvider.

• Un usuario tiene que iniciar sesión individualmente en cada una de las aplicaciones alojadas.

El mecanismo de autenticación SAML proporciona un enfoque alternativo. El siguiente diagrama de implementación muestra cómo funciona SAML:

Las preocupaciones planteadas por los mecanismos tradicionales de autenticación se resuelven de la siguiente manera:

• LargeProvider no tiene que mantener una base de datos para los usuarios de BigCompany. Liberado de la administración de identidades, Large Provider puede concentrarse en ofrecer mejores servicios.

• BigCompany no soporta la carga de asegurarse de que la base de datos de usuarios LargeProvider se mantenga sincronizada con su propia base de datos de usuarios.

• Un usuario puede iniciar sesión una vez, en una aplicación alojada en LargeProvider, y iniciar sesión automáticamente en las otras aplicaciones que están alojadas allí.

El dispositivo Citrix ADC se puede implementar como proveedor de servicios SAML (SP) y proveedor de identidades SAML (IdP). Lea los temas relevantes para comprender las configuraciones que deben realizarse en el dispositivo Citrix ADC.

Integración de la nube híbrida ADFS

AD FS es un servicio basado en estándares que permite compartir de forma segura la información de identidad entre socios comerciales de confianza (conocidos como federación) a través de una extranet. Cuando un usuario necesita acceder a una aplicación web desde uno de sus socios de federación, la propia organización del usuario es responsable de autenticar al usuario y proporcionar información de identidad en forma de “afirmaciones” al socio que aloja la aplicación web. El socio de alojamiento utiliza su directiva de confianza para asignar los reclamos entrantes a los reclamos que son entendidos por su aplicación web, que utiliza los reclamos para tomar decisiones de autorización.

Los Servicios de federación de Active Directory (AD FS) permiten que los usuarios locales y los usuarios federados utilicen Single Sign-On (SSO) basado en notificaciones en sitios web y servicios. Puede usar AD FS para permitir que la organización colabore de forma segura en dominios de Active Directory con otras organizaciones externas mediante la federación de identidades. Esto reduce la necesidad de cuentas duplicadas, administración de varios inicios de sesión y otros problemas de administración de credenciales que pueden producirse al establecer confianzas entre organizaciones.

Modo de proxy ADFS

El proxy de AD FS 2.0 es un servicio que facilita una conexión entre usuarios externos y el servidor interno de AD FS 2.0. Actúa como un proxy inverso y normalmente reside en la red perimetral de su organización (también conocida como DMZ). En lo que respecta a los usuarios, no saben que están hablando con un servidor proxy de AD FS, ya que los servicios de federación son accedidos por las mismas URL. El servidor proxy maneja tres funciones principales.

• Proveedor de aserción: el proxy acepta solicitudes de token de los usuarios y pasa la información a través de SSL (puerto predeterminado 443) al servidor interno de AD FS. Recibe el token del servidor interno de AD FS y lo devuelve al usuario.

• Consumidor de aserción: el proxy acepta tokens de los usuarios y los pasa a través de SSL (puerto predeterminado 443) al servidor interno de AD FS para su procesamiento.

• Proveedor de metadatos: el proxy también responderá a las solicitudes de metadatos de federación.

El proxy de AD FS 2.0 no es un requisito para usar AD FS. Es una función adicional. La razón por la que instalaría un proxy de AD FS 2.0 es que no desea exponer el servidor real de AD FS 2.0 a Internet. Los servidores de AD FS 2.0 son recursos unidos a un dominio, mientras que el proxy de AD FS 2.0 no tiene ese requisito. Si todos los usuarios y aplicaciones son internos de la red, no es necesario utilizar un proxy de AD FS 2.0. Si hay un requisito para exponer el servicio de federación a Internet, se recomienda utilizar un proxy de AD FS 2.0.

Consulte el siguiente enlace para obtener más información sobreDescripción del proxy de AD FS 2.0.

Modo IDP ADFS

El proveedor de identidad (IP) del socio federado envía notificaciones que reflejan la identidad, los grupos y los datos de atributos de sus usuarios. Por lo tanto, la organización ya no necesita revocar, cambiar o restablecer las credenciales de los usuarios del asociado, ya que las credenciales son administradas por la organización asociada. Además, si una asociación necesita ser terminada, se puede realizar con un único cambio de directiva de confianza. Sin AD FS, las cuentas individuales de cada usuario asociado tendrían que ser desactivadas. Configurar como proveedor de identidad permite reutilizar cuentas existentes administradas por objetos de Active Directory existentes para la autenticación. Elimina la necesidad de crear mecanismos complejos de sincronización de cuentas o desarrollar código personalizado que realice las tareas de aceptar credenciales de usuario final, validarlas contra el almacén de credenciales y administrar las identidades.

Autenticación de Citrix ADC nFactor (Multifactor)

nFactor proporciona una nueva perspectiva de la autenticación, optimiza el flujo de autenticación y proporciona una gran flexibilidad durante la autenticación.

La autenticación multifactor mejora la seguridad de una aplicación al requerir a los usuarios que proporcionen múltiples pruebas de identificación para obtener acceso. El dispositivo Citrix ADC proporciona un enfoque extensible y flexible para configurar la autenticación multifactor. Este enfoque se denomina autenticación nFactor.

Con la autenticación nFactor puede:

• Configure cualquier número de factores de autenticación.

• Basar la selección del siguiente factor en el resultado de ejecutar el factor anterior.

• Personalice la interfaz de inicio de sesión. Por ejemplo, puede personalizar los nombres de las etiquetas, los mensajes de error y el texto de ayudad. o Extraer información del grupo de usuarios sin realizar la autenticación.

• Configure PassThrough para un factor de autenticación. Esto significa que no se requiere ninguna interacción explícita de inicio de sesión para ese factor.

• Configure el orden en el que se aplican los diferentes tipos de autenticación. Cualquiera de los mecanismos de autenticación compatibles con el dispositivo Citrix ADC se puede configurar como cualquier factor de la configuración de autenticación nFactor.

Estos factores se ejecutan en el orden en que se configuran.

• Configure Citrix ADC para que continúe con un factor de autenticación que debe ejecutarse cuando se produzca un error en la autenticación.

Para ello, configure otra directiva de autenticación con la misma condición exacta, pero con la siguiente prioridad más alta y con la acción establecida en “NO_AUTH”.

También debe configurar el siguiente factor, que debe especificar el mecanismo de autenticación alternativo que se aplicará.

Aplicaciones empresariales del cliente

Autenticación Multi-Factor Adaptable (MFA) para una seguridad más estricta

Las empresas tienen varias partes interesadas que utilizan sus aplicaciones y datos. Empleados asociados, proveedores y varios otros que necesitan acceder a aplicaciones y datos desde varias ubicaciones y utilizando varios dispositivos. Las empresas necesitaban una forma de autenticar diferentes grupos de usuarios de diferentes maneras. Si bien diferentes Gateways se pueden utilizar para diferentes grupos de usuarios, el mantenimiento y la coherencia de la experiencia se verán afectados con este enfoque.

• SSO: Citrix ADC admite todos los protocolos SSO: SAML, Kerberos, KCD, basado en formularios, 401/NTLM. Citrix ADC admite el protocolo SAML y puede jugar el rol de IDP SAML (caso de uso 1. anterior) así como el rol SAML SP (caso de uso 2. anterior).

• Perfil de host: Citrix ADC admite la función de análisis de extremos (EPA) que se utiliza para la comprobación de perfiles de host. EPA se puede utilizar para conceder acceso en cuarentena en caso de que el usuario no esté cumpliendo las comprobaciones de seguridad necesarias para el acceso completo.

• Auditoría de conformidad: Citrix ADC admite una amplia gama de mecanismos de auditoría como Appflow, Syslog y registro definido por el usuario.

Pasos de configuración

Citrix Gateway para aplicaciones de Windows alojadas

Arquitecturas de red

Al implementar Citrix Gateway en la DMZ, las conexiones de usuario deben atravesar el primer firewall para conectarse a Citrix Gateway. De forma predeterminada, las conexiones de usuario utilizan SSL en el puerto 443 para establecer esta conexión. Para permitir que las conexiones de usuario lleguen a la red interna, debe permitir SSL en el puerto 443 a través del primer firewall.

Citrix Gateway descifra las conexiones SSL desde el dispositivo de usuario y establece una conexión en nombre del usuario a los recursos de red detrás del segundo firewall. Los puertos que deben estar abiertos a través del segundo firewall dependen de los recursos de red a los que se autoriza el acceso de usuarios externos.

Por ejemplo, si autoriza a usuarios externos a tener acceso a un servidor web de la red interna y este servidor escucha las conexiones HTTP en el puerto 80, debe permitir HTTP en el puerto 80 a través del segundo firewall. Citrix Gateway establece la conexión a través del segundo firewall con el servidor HTTP de la red interna en nombre de los dispositivos de usuario externos.

Citrix Gateway implementado en la red segura

Cuando implemente Citrix Gateway en la red segura, conecte una interfaz de Citrix Gateway a Internet y la otra a los servidores que se ejecutan en la red segura. Poner Citrix Gateway en la red segura proporciona acceso a usuarios locales y remotos. Esta configuración solo tiene un firewall. Sin embargo, hace que la implementación sea menos segura para los usuarios que se conectan desde una ubicación remota. Aunque Citrix Gateway intercepta el tráfico de Internet, el tráfico entra en la red segura antes de autenticar a los usuarios. Cuando Citrix Gateway se implementa en una DMZ, los usuarios se autentican antes de que el tráfico de red llegue a la red segura.

Cuando Citrix Gateway se implementa en la red segura, las conexiones de Citrix Gateway Plug-in deben atravesar el firewall para conectarse a Citrix Gateway. De forma predeterminada, las conexiones de usuario utilizan el protocolo SSL en el puerto 443 para establecer esta conexión. Para admitir esta conectividad, debe abrir el puerto 443 en el firewall.

Modo Proveedor de identidades SAML (IdP)

El IdP SAML (proveedor de identidad) es una entidad SAML que se implementa en la red del cliente. El IdP recibe solicitudes del SP SAML y redirige a los usuarios a una página de inicio de sesión, donde deben introducir sus credenciales. El IdP autentica estas credenciales con el directorio de usuario (servidor de autenticación externo, como LDAP) y, a continuación, genera una aserción SAML que se envía al SP.

El SP valida el token y el usuario obtiene acceso a la aplicación protegida solicitada.

Cuando el dispositivo Citrix ADC está configurado como IdP, todas las solicitudes son recibidas por un servidor virtual de autenticación asociado con el perfil de IdP SAML relevante

Nota: Un dispositivo Citrix ADC se puede utilizar como IdP en una implementación donde el SP SAML está configurado en el dispositivo o en cualquier SAML externo

Cuando se utiliza como proveedor de identidades SAML, un dispositivo Citrix ADC:

• Admite todos los métodos de autenticación que admite para los inicios de sesión tradicionales.

• Firma digitalmente afirmaciones. La compatibilidad con el algoritmo SHA256 se introduce en Citrix ADC 11.0 Build 55.x.

• Admite autenticación de un solo factor y de dos factores. SAML no debe configurarse como el mecanismo de autenticación secundario.

• Puede cifrar afirmaciones utilizando la clave pública del SP SAML. Esto se recomienda cuando la aserción incluye información sensible. Soporte introducido en Citrix ADC 11.0 Build 55.x.

• Puede configurarse para aceptar solo solicitudes firmadas digitalmente desde SAML SP. Compatibilidad introducida en Citrix ADC 11.0 Build 55.x

• Puede iniciar sesión en el IdP SAML mediante los siguientes mecanismos de autenticación basados en 401: Negotiate, NTLM y Certificado. Soporte introducido en Citrix ADC 11.0 Build 55.x.

• Se puede configurar para enviar 16 atributos además del atributo NameID. Los atributos deben extraerse del servidor de autenticación apropiado. Para cada uno de ellos, puede especificar el nombre, la expresión, el formato y un nombre descriptivo en el perfil de IdP SAML. Soporte introducido en Citrix ADC 11.0 Build 55.x.

• Si el dispositivo Citrix ADC está configurado como un IdP SAML para varios SP SAML, un usuario puede obtener acceso a las aplicaciones de los distintos SPs sin autenticarse explícitamente cada vez. El dispositivo Citrix ADC crea una cookie de sesión para la primera autenticación y cada solicitud posterior utiliza esta cookie para la autenticación. Soporte introducido en Citrix ADC 11.0 Build 55.x.

• Puede enviar atributos multivalor en una aserción SAML. Compatibilidad introducida en Citrix ADC 11.0 Build 64.x.

• Soporta enlaces de publicación y redirección. La compatibilidad con enlaces de redirección se introduce en Citrix ADC 11.0 Build 64.x. o

Si la hora del sistema en Citrix ADC SAML IdP y el SP SAML del mismo nivel no está sincronizada, los mensajes pueden ser invalidados por cualquiera de las partes. Para evitar estos casos, ahora puede configurar la duración de tiempo para la que las afirmaciones serán válidas.

Esta duración, denominada “tiempo de sesgo”, especifica el número de minutos para los que debe aceptarse el mensaje.

El tiempo de sesgo se puede configurar en el SP SAML y el IdP SAML.

Nota:Se introdujo

soporte en Citrix ADC 11.0 Build 64.x.

• Se puede configurar para servir aserciones solo a SPs SAML preconfigurados en o de confianza por el IdP. Para esta configuración, el IdP SAML debe tener el ID del proveedor de servicios (o el nombre del emisor) de los SPs SAML pertinentes. Compatibilidad introducida en Citrix ADC 11.0 Build 64.x.

Configuración del modo proxy ADFS

Configuración

Para configurar Citrix ADC como un proxy ADFS, las siguientes funciones deben estar habilitadas en el sistema Citrix ADC: Equilibrio de carga, Descarga SSL de conmutación de contenido. La configuración de Citrix ADC como un proxy ADFS implica los siguientes pasos:

1. Configurar un servidor virtual de conmutación de contenido. Esta es la VIP proxy ADFS, la dirección IP de este servidor virtual es la IP que se utilizará como reemplazo de la IP del servidor ADFS.
2. Cree cuatro servidores virtuales de equilibrio de carga: uno para autenticación activa y pasiva, uno para acceso a metadatos y otro para reescribir la URL de solicitud.
3. Cree y vincule las directivas de cambio de contenido necesarias al servidor vCS. Estos consistirán en lo siguiente:
   • Dos directivas para analizar solicitudes de autenticación activas y pasivas, con autenticación previa activada/inhabilitada (inhabilitada si se prefiere la autenticación en el servidor ADFS)
   • Una directiva para analizar las solicitudes de metadatos, que no están autenticadas y tienen la autenticación previa inhabilitada.
   • Una directiva para reescribir la URL de solicitud de /adfs/services/trust a /adfs/services/trust/proxymex.
4. Crear un servidor vserver AAA, autenticación LDAP y negociar y directivas de sesión para la autenticación de solicitudes en Nets-Caler y realizar la suplantación de personación/KCD de Kerberos (delegación restringida Kerberos) en el servidor ADFS back-end.

Para obtener más información, consulte laguía de implementación para el proxy ADFS de Citrix ADC.

Flujo de paquetes

Flujo de paquetes para Citrix ADC como proxy ADFS con acceso interno o externo de usuario:

1. ADFS habilita el acceso de usuario interno o externo a Office 365.

2. El usuario se redirige al servicio de federación aplicable para la autenticación.

3. El usuario se redirige al servicio de federación interna de la empresa.

4. El usuario interno se equilibra la carga a la comunidad de ADFS.

5. El usuario externo se conecta a la página de inicio de sesión de Citrix ADC AAA-TM.

6. El usuario se autentica contra Active Directory o un servicio de autenticación similar.

7. Después de la autenticación, Citrix ADC realiza SSO (Kerberos/NTLM) en la comunidad de ADFS.

8. El servidor ADFS valida las credenciales de SSO y devuelve el token STS.

9. El usuario externo se conecta al servicio de federación donde se verifican el token y las notificaciones.

10. En función de la validación, el servicio de federación proporciona al usuario un nuevo token de seguridad.

11. El usuario externo proporciona cookie de autorización con token de seguridad al recurso para el acceso.

Beneficios de usar Citrix ADC como proxy ADFS

1. Atiende tanto a las necesidades de equilibrio de carga como de proxy ADFS

2. Funciona con escenarios de acceso de usuarios internos y externos

3. Admite varios métodos para la autenticación previa y habilita la autenticación multifactor

4. Proporciona una experiencia SSO para los usuarios finales

5. Soporta protocolos activos y pasivos
   • Ejemplos de aplicaciones de protocolo activas: Outlook, Lync

6. Ejemplos de aplicaciones de protocolo pasivo: aplicación web de Outlook, navegadores

7. Citrix ADC es un dispositivo reforzado para la implementación basada en DMZ

8. Agrega valor con funciones principales de ADC adicionales
   • Cambio de contenido
   • Descarga SSL
   • Reescribir
   • Respondedor
   • Límite de tasa
   • Seguridad (AAA-TM, Gateway, Firewall de aplicaciones)