Implementaciones de tarjeta inteligente
Los siguientes tipos de implementaciones de tarjeta inteligente se admiten en esta versión del producto y en entornos mixtos que contengan esta versión. Hay otras configuraciones que pueden funcionar, pero no se admiten.
| Tipo | Conectividad con StoreFront |
|---|---|
| Equipos unidos a un dominio local | Conectados directamente |
| Acceso remoto desde equipos unidos a un dominio | Conectados a través de NetScaler Gateway |
| Equipos no unidos a dominio | Conectados directamente |
| Acceso remoto desde equipos no unidos a un dominio | Conectados a través de NetScaler Gateway |
| Clientes ligeros y equipos que no pertenecen a un dominio y acceden a un sitio de Desktop Appliance | Conectados a través de sitios de Desktop Appliance |
| Clientes ligeros y equipos que pertenecen a un dominio y acceden a StoreFront con una URL de Servicios XenApp | Conectados a través de direcciones URL de Servicios XenApp |
Los tipos de implementación se definen por las funciones del dispositivo del usuario al que está conectado el lector de tarjetas inteligentes:
- Si el dispositivo está unido a un dominio o no.
- Cómo se conecta el dispositivo con StoreFront.
- Qué software se usa para ver las aplicaciones y los escritorios virtuales.
Además, las aplicaciones habilitadas para tarjeta inteligente, tales como Microsoft Word y Microsoft Excel, también se pueden utilizar en estas implementaciones. Esas aplicaciones permiten a los usuarios firmar o cifrar documentos digitalmente.
Autenticación bimodal
Cuando es posible en cada una de estas implementaciones, Receiver admite la autenticación bimodal, que ofrece al usuario la posibilidad de elegir si quiere autenticarse con tarjeta inteligente o con nombre de usuario y contraseña. Esto resulta útil cuando no se puede usar la tarjeta inteligente por alguna razón (por ejemplo, si el usuario la olvidó en casa o el certificado de inicio de sesión caducó).
Como los usuarios de dispositivos que no pertenecen a un dominio inician sesión en Receiver para Windows directamente, puede permitir que los usuarios recurran a la autenticación explícita. Si configura la autenticación bimodal, a los usuarios se les solicita que inicien sesión con una tarjeta inteligente y su PIN, pero tienen la opción de seleccionar la autenticación explícita si tienen problemas con las tarjetas inteligentes.
Si implementa NetScaler Gateway, los usuarios inician sesión en sus dispositivos y Receiver para Windows les pedirá autenticarse en NetScaler Gateway. Esto se aplica a dispositivos unidos a un dominio y a dispositivos que no pertenecen a ningún dominio. Los usuarios pueden iniciar sesión en NetScaler Gateway con su tarjeta inteligente y su PIN o con credenciales explícitas. Esto permite ofrecer a los usuarios la autenticación bimodal para los inicios de sesión de NetScaler Gateway. Configure la autenticación PassThrough de NetScaler Gateway a StoreFront y delegue la validación de las credenciales a NetScaler Gateway para los usuarios de tarjeta inteligente de modo que los usuarios se autentiquen silenciosamente en StoreFront.
Consideraciones cuando hay varios bosques de Active Directory
En un entorno Citrix, se admite el uso de tarjetas inteligentes dentro de un único bosque. Los inicios de sesión con tarjeta inteligente que abarcan varios bosques requieren una relación de confianza bidireccional de bosques en todas las cuentas de usuario. Las implementaciones más complejas de tarjeta inteligente con varios bosques (es decir, donde las relaciones de confianza son unidireccionales o de diferentes tipos) no se admiten.
Se puede usar tarjetas inteligentes en entornos Citrix que incluyen escritorios remotos. Esta función se puede instalar localmente (en el dispositivo de usuario al que está conectada la tarjeta inteligente) o de forma remota (en el escritorio remoto al que se conecta el dispositivo del usuario).
Directiva de extracción de tarjetas inteligentes
La directiva de extracción de tarjetas inteligentes definida en el producto determina el comportamiento al extraer la tarjeta inteligente del lector durante una sesión. El sistema operativo Windows configura y controla esta directiva de extracción.
| Configuración de directiva | Comportamiento del escritorio |
|---|---|
| Ninguna acción | Ninguna acción. |
| Bloquear estación de trabajo | La sesión de escritorio se desconecta y el escritorio virtual queda bloqueado. |
| Forzar cierre de sesión | El usuario se ve forzado a cerrar la sesión. Si se pierde la conexión de red y esta configuración está habilitada, es posible que se cierre la sesión y el usuario pierda ciertos datos. |
| Desconectar si es una sesión remota de Terminal Services | La sesión se desconecta y el escritorio virtual queda bloqueado. |
Comprobar la revocación de certificados
Si la comprobación de revocación de certificados está habilitada y un usuario introduce una tarjeta inteligente con un certificado no válido en el lector de tarjetas, el usuario no se puede autenticar ni acceder al escritorio o a la aplicación relacionados con el certificado. Por ejemplo, si el certificado no válido se usa para el proceso de descifrado de correo electrónico, el correo electrónico seguirá cifrado. Si hay otros certificados en la tarjeta, tales como los utilizados para la autenticación, que aún son válidos, sus funciones permanecen activas.
Ejemplo de implementación: equipos que pertenecen a un dominio
Esta implementación contiene dispositivos de usuario que están unidos a un dominio, y que ejecutan Desktop Viewer y se conectan directamente a StoreFront.
El usuario inicia sesión en un dispositivo mediante una tarjeta inteligente y un PIN. Receiver autentica al usuario en un servidor de StoreFront mediante la autenticación integrada de Windows (IWA). StoreFront pasa los identificadores de seguridad del usuario (SID) a XenApp o XenDesktop. Cuando el usuario inicia una aplicación o un escritorio virtual, no se vuelve a solicitar el PIN al usuario porque la función de Single Sign-On está configurada en Receiver.
Esta implementación se puede ampliar a una configuración de doble salto con la incorporación de un segundo servidor de StoreFront y un servidor que aloja aplicaciones. Un Receiver desde el escritorio virtual se autentica en el segundo servidor de StoreFront. Con esta segunda conexión se puede usar cualquier método de autenticación. La configuración que se muestra para el primer salto se puede volver a utilizar en el segundo salto o usarse en el segundo salto solamente.
Ejemplo de implementación: acceso remoto desde equipos unidos a un dominio
Esta implementación contiene dispositivos de usuario que están unidos a un dominio, y que ejecutan Desktop Viewer y se conectan a StoreFront a través de NetScaler Gateway/Access Gateway.
El usuario inicia una sesión en un dispositivo usando una tarjeta inteligente y un PIN y, a continuación, inicia otra sesión en NetScaler Gateway/Access Gateway. Este segundo inicio de sesión puede realizarse con la tarjeta inteligente y el PIN, o con un nombre de usuario y una contraseña, porque Receiver permite la autenticación bimodal en esta implementación.
El usuario inicia sesión automáticamente en StoreFront, el cual pasa los identificadores de seguridad (SID) del usuario a XenApp o XenDesktop. Cuando el usuario inicia una aplicación o un escritorio virtual, no se vuelve a solicitar el PIN al usuario porque la función de Single Sign-On está configurada en Receiver.
Esta implementación se puede ampliar a una configuración de doble salto con la incorporación de un segundo servidor de StoreFront y un servidor que aloja aplicaciones. Un Receiver desde el escritorio virtual se autentica en el segundo servidor de StoreFront. Con esta segunda conexión se puede usar cualquier método de autenticación. La configuración que se muestra para el primer salto se puede volver a utilizar en el segundo salto o usarse en el segundo salto solamente.
Ejemplo de implementación: equipos que no pertenecen a un dominio
Esta implementación contiene dispositivos de usuario que no están unidos a un dominio, y que ejecutan Desktop Viewer y se conectan directamente a StoreFront.
El usuario inicia la sesión en un dispositivo. Por lo general, el usuario introduce un nombre de usuario y una contraseña pero, como el dispositivo no está unido a un dominio, las credenciales de inicio de sesión son optativas. Como la autenticación bimodal es posible en esta implementación, Receiver pide al usuario una tarjeta inteligente y un PIN, o un nombre de usuario y una contraseña. A continuación, Receiver se autentica en StoreFront.
StoreFront pasa los identificadores de seguridad del usuario (SID) a XenApp o XenDesktop. Cuando el usuario inicia una aplicación o un escritorio virtual, se solicita un PIN al usuario de nuevo porque la función de Single Sign-On no está disponible en esta implementación.
Esta implementación se puede ampliar a una configuración de doble salto con la incorporación de un segundo servidor de StoreFront y un servidor que aloja aplicaciones. Un Receiver desde el escritorio virtual se autentica en el segundo servidor de StoreFront. Con esta segunda conexión se puede usar cualquier método de autenticación. La configuración que se muestra para el primer salto se puede volver a utilizar en el segundo salto o usarse en el segundo salto solamente.
Ejemplo de implementación: acceso remoto desde equipos que no están unidos a un dominio
Esta implementación contiene dispositivos de usuario que no están unidos a un dominio, y que ejecutan Desktop Viewer y se conectan directamente a StoreFront.
El usuario inicia la sesión en un dispositivo. Por lo general, el usuario introduce un nombre de usuario y una contraseña pero, como el dispositivo no está unido a un dominio, las credenciales de inicio de sesión son optativas. Como la autenticación bimodal es posible en esta implementación, Receiver pide al usuario una tarjeta inteligente y un PIN, o un nombre de usuario y una contraseña. A continuación, Receiver se autentica en StoreFront.
StoreFront pasa los identificadores de seguridad del usuario (SID) a XenApp o XenDesktop. Cuando el usuario inicia una aplicación o un escritorio virtual, se solicita un PIN al usuario de nuevo porque la función de Single Sign-On no está disponible en esta implementación.
Esta implementación se puede ampliar a una configuración de doble salto con la incorporación de un segundo servidor de StoreFront y un servidor que aloja aplicaciones. Un Receiver desde el escritorio virtual se autentica en el segundo servidor de StoreFront. Con esta segunda conexión se puede usar cualquier método de autenticación. La configuración que se muestra para el primer salto se puede volver a utilizar en el segundo salto o usarse en el segundo salto solamente.
Ejemplo de implementación: acceso al sitio de Desktop Appliance desde clientes ligeros y equipos que no pertenecen a un dominio
Esta implementación contiene dispositivos de usuario que no están unidos a un dominio que pueden ejecutar Desktop Lock y se conectan a StoreFront a través de sitios de Desktop Appliance.
Desktop Lock es un componente separado que se ha publicado con XenApp, XenDesktop y VDI-in-a-Box. Es una alternativa a Desktop Viewer que se ha diseñado principalmente para equipos Windows reasignados y clientes ligeros Windows. Desktop Lock reemplaza el shell y el Administrador de tareas de Windows en los dispositivos de los usuarios, lo que impide que los usuarios accedan al dispositivo subyacente. Con Desktop Lock, los usuarios pueden acceder a los escritorios de máquinas de servidor Windows y a escritorios de máquinas de escritorio Windows. La instalación de Desktop Lock es optativa.
El usuario inicia una sesión en un dispositivo mediante una tarjeta inteligente. Si Desktop Lock se está ejecutando en el dispositivo, el dispositivo está configurado para iniciar el sitio de Desktop Appliance a través de Internet Explorer ejecutado en modo quiosco (pantalla completa). Un control ActiveX en el sitio solicita el PIN al usuario y lo envía a StoreFront. StoreFront pasa los identificadores de seguridad del usuario (SID) a XenApp o XenDesktop. Se iniciará el primer escritorio que esté disponible en la lista alfabética del grupo de escritorios asignado.
Esta implementación se puede ampliar a una configuración de doble salto con la incorporación de un segundo servidor de StoreFront y un servidor que aloja aplicaciones. Un Receiver desde el escritorio virtual se autentica en el segundo servidor de StoreFront. Con esta segunda conexión se puede usar cualquier método de autenticación. La configuración que se muestra para el primer salto se puede volver a utilizar en el segundo salto o usarse en el segundo salto solamente.
Ejemplo de implementación: implementación de clientes ligeros y equipos que pertenecen a un dominio y acceden a StoreFront a través de la URL de servicios XenApp
Esta implementación contiene dispositivos de usuario que están unidos a un dominio y que ejecutan Desktop Lock y se conectan a StoreFront a través de direcciones URL de Servicios XenApp.
Desktop Lock es un componente separado que se ha publicado con XenApp, XenDesktop y VDI-in-a-Box. Es una alternativa a Desktop Viewer que se ha diseñado principalmente para equipos Windows reasignados y clientes ligeros Windows. Desktop Lock reemplaza el shell y el Administrador de tareas de Windows en los dispositivos de los usuarios, lo que impide que los usuarios accedan al dispositivo subyacente. Con Desktop Lock, los usuarios pueden acceder a los escritorios de máquinas de servidor Windows y a escritorios de máquinas de escritorio Windows. La instalación de Desktop Lock es optativa.
El usuario inicia sesión en un dispositivo mediante una tarjeta inteligente y un PIN. Si Desktop Lock se está ejecutando en el dispositivo, autentica al usuario en un servidor de StoreFront mediante la autenticación integrada de Windows (IWA). StoreFront pasa los identificadores de seguridad del usuario (SID) a XenApp o XenDesktop. Cuando el usuario inicia un escritorio virtual, no se vuelve a solicitar el PIN al usuario porque la función de Single Sign-On está configurada en Receiver.
Esta implementación se puede ampliar a una configuración de doble salto con la incorporación de un segundo servidor de StoreFront y un servidor que aloja aplicaciones. Un Receiver desde el escritorio virtual se autentica en el segundo servidor de StoreFront. Con esta segunda conexión se puede usar cualquier método de autenticación. La configuración que se muestra para el primer salto se puede volver a utilizar en el segundo salto o usarse en el segundo salto solamente.
En este artículo
- Autenticación bimodal
- Consideraciones cuando hay varios bosques de Active Directory
- Directiva de extracción de tarjetas inteligentes
- Comprobar la revocación de certificados
- Ejemplo de implementación: equipos que pertenecen a un dominio
- Ejemplo de implementación: acceso remoto desde equipos unidos a un dominio
- Ejemplo de implementación: equipos que no pertenecen a un dominio
- Ejemplo de implementación: acceso remoto desde equipos que no están unidos a un dominio
- Ejemplo de implementación: acceso al sitio de Desktop Appliance desde clientes ligeros y equipos que no pertenecen a un dominio
- Ejemplo de implementación: implementación de clientes ligeros y equipos que pertenecen a un dominio y acceden a StoreFront a través de la URL de servicios XenApp