Product Documentation

Creación de un nombre de dominio completo (FQDN) para acceder a un almacén de forma interna y externa

Dec 12, 2016
Nota: Para usar esta característica con Receivers nativos de escritorio, se necesitan las versiones siguientes.
  • Receiver para Windows 4.2
  • Receiver para Mac 11.9

Puede proporcionar acceso a los recursos desde la red corporativa o desde Internet a través de NetScaler Gateway y simplificar la experiencia de los usuarios mediante la creación de un único nombre de dominio completo para clientes internos y clientes externos móviles.

La creación de un único nombre de dominio completo es útil para los usuarios que configuren cualquiera de los Receiver nativos. Solo necesitan recordar una sola dirección URL y si se han conectado a una red interna o a una red pública.

Balizas de StoreFront para Receivers nativos

Citrix Receiver intenta comunicarse con las balizas y usa las respuestas para determinar si los usuarios están conectados a redes locales o públicas. Cuando un usuario accede a un escritorio o aplicación, la información de ubicación se transfiere al servidor que proporciona el recurso para que se puedan devolver a Citrix Receiver los correspondientes datos de conexión. Esto garantiza que a los usuarios no se les solicitará que inicien sesión de nuevo cuando accedan a un escritorio o aplicación. Para obtener información sobre la configuración de balizas, consulte Configuración de balizas.

Configuración del certificado de SSL y del servidor virtual de NetScaler Gateway

El nombre de dominio completo se resuelve en la dirección IP del enrutador de un firewall externo o en la dirección IP del servidor virtual de NetScaler Gateway de la zona desmilitarizada (DMZ) cuando los clientes externos intentan acceder a recursos desde fuera de la red corporativa. Compruebe que los campos Nombre común y Nombre alternativo del firmante del certificado SSL contengan el nombre de dominio completo compartido que se utilizará para acceder al almacén de forma externa. Al emplear una entidad de certificación (CA) raíz externa como Verisign en lugar de una entidad de certificación empresarial para firmar el certificado de la puerta de enlace, cualquier cliente externo confía automáticamente en el certificado enlazado al servidor virtual de puerta de enlace. Si emplea una CA raíz externa como Verisign, no se necesita importar más certificados de CA raíz en los clientes externos.

Para implementar un único certificado con el nombre común del nombre de dominio completo compartido en NetScaler Gateway y en el servidor StoreFront, tenga en cuenta si quiere que respalden la detección remota. Si es que sí, compruebe que el certificado cumple con las especificaciones de los nombres alternativos del firmante.

Certificado de ejemplo de un servidor virtual de NetScaler Gateway: storefront.example.com
  1. Compruebe que el nombre de dominio completo compartido, la URL de respuesta y la URL de alias de cuenta se incluyen en el campo DNS como nombre alternativo del sujeto (SAN - Subject Alternative Name).
  2. Compruebe también que la clave privada se puede exportar para que el certificado y la clave se puedan importar en NetScaler Gateway.
  3. Asegúrese de que Autorización predeterminada tenga el valor Permitir.
  4. Firme el certificado mediante una entidad de certificación externa como Verisign o mediante una entidad de certificación empresarial de la organización.

Ejemplos de nombres SAN de grupos de servidores de dos nodos:

storefront.ejemplo.com (obligatorio)

storefrontcb.ejemplo.com (obligatorio)

cuentas.ejemplo.example.com (obligatorio)

storefrontserver1.ejemplo.com (optativo)

storefrontserver2.ejemplo.com (optativo)

Firma del certificado SSL del servidor virtual de NetScaler Gateway con una entidad de certificación (CA)

Según sus requisitos, tiene dos opciones para elegir el tipo de certificado firmado por una entidad de certificación.

  • Opción 1: Certificado firmado por una entidad de certificación externa. Si el certificado enlazado al servidor virtual de NetScaler Gateway está firmado por una entidad externa de confianza, es muy posible que los clientes externos NO necesiten copiar certificados de CA raíz en sus almacenes de certificados de CA raíz de confianza. Los clientes de Windows se incluyen en los certificados de CA raíz de las agencias de firma más comunes. Se pueden emplear entidades externas y comerciales de certificación como DigiCert, Thawte y Verisign. Tenga en cuenta que los dispositivos móviles como iPhones, iPads y los teléfonos y las tablets Android aún podrían requerir que la entidad de certificación raíz se copie al dispositivo para confiar en el servidor virtual de NetScaler Gateway.
  • Opción 2: Certificado firmado por una CA raíz empresarial. Si elige esta opción, todos los clientes externos requieren que el certificado de CA raíz empresarial se copie en sus almacenes de certificados de CA raíz de confianza. Si se usan dispositivos portátiles con un Receiver nativo instalado, como un iPhone o un iPad, cree un perfil de seguridad en dichos dispositivos.

Importación del certificado raíz en dispositivos portátiles

  • Los dispositivos iOS pueden importar archivos de certificado X.509 .CER mediante datos adjuntos de correo electrónico porque normalmente no se puede acceder al almacenamiento local de los dispositivos iOS.
  • Los dispositivos Android también necesitan el formato X.509 .CER. El certificado se puede importar desde el almacenamiento local del dispositivo o desde los datos adjuntos de un correo electrónico.

DNS externo: storefront.example.com

Compruebe que la resolución de DNS proporcionada por el proveedor de servicios de Internet de la organización se resuelve en la dirección IP del enrutador del firewall que apunta al exterior en el borde exterior de la DMZ o a la dirección IP virtual del servidor virtual de NetScaler Gateway.

DNS partido

  • Cuando el DNS partido (Split-view DNS) se configura correctamente, la dirección de origen de la solicitud DNS debe enviar el cliente al registro A de DNS correcto.
  • Cuando los clientes se mueven entre redes públicas y empresariales, sus direcciones IP deben cambiar. Dependiendo de la red a la que estén conectados en ese momento, deben recibir el registro A correcto cuando hacen una consulta a storefront.ejemplo.com.

Importación de certificados emitidos por una entidad de certificación de Windows en NetScaler Gateway

WinSCP es una herramienta externa útil y gratuita para trasladar archivos de una máquina con Windows a un sistema de archivos de NetScaler Gateway. Copie los certificados que quiere importar en la carpeta /nsconfig/ssl/ del sistema de archivos de NetScaler Gateway. Puede usar las herramientas de OpenSSL en NetScaler Gateway para extraer el certificado y la clave de un archivo PKCS12/PFX y, así, crear dos archivos X.509 .CER y .KEY independientes en formato PEM que puede utilizar NetScaler Gateway.

  1. Copie el archivo PFX en /nsconfig/ssl, en el dispositivo NetScaler Gateway o en VPX.
  2. Abra la interfaz de línea de comandos de NetScaler Gateway.
  3. Para cambiar al shell de FreeBSD, escriba Shell para salir de la interfaz de línea de comandos de NetScaler Gateway.
  4. Para cambiar el directorio, use cd/nsconfig/ssl.
  5. Ejecute openssl pkcs12 -in <archivo de certificación importado>.pfx -nokeys -out <nombre del archivo de certificación>.cer y escriba la contraseña del archivo PFX cuando se le solicite.
  6. Ejecute openssl pkcs12 -in <archivo de certificación importado>.pfx -nocerts -out <nombre del archivo de claves>.key
  7. Escriba la contraseña del archivo PFX cuando se le solicite y, a continuación, establezca una frase de contraseña con formato PEM de clave privada para proteger el archivo KEY.
  8. Para comprobar que los archivos .CER y .KEY se han creado correctamente en /nsconfig/ssl/, ejecute ls -al.
  9. Para volver a la interfaz de línea de comandos de NetScaler Gateway, escriba Exit.

Directiva de sesiones de puerta de enlace de Receiver para Mac/Windows nativo

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver && REQ.HTTP.HEADER X-Citrix-Gateway EXISTS

Directiva de sesiones de puerta de enlace de Receiver para Web

REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer EXISTS

Parámetros de cVPN y Smart Access

Si usa el modo de acceso inteligente (Smart Access), habilítelo en la página de propiedades del servidor virtual de NetScaler Gateway. Se necesitan licencias universales para cada usuario concurrente o simultáneo que accede a recursos remotos.

Perfil de Receiver

Configure la URL del servicio de cuentas de perfil de la sesión para que sea https://cuentas.ejemplo.com/Citrix/Roaming/Accounts y NO https://storefront.ejemplo.com/Citrix/Roaming/Accounts.

Agregue también esta URL como entrada de <allowedAudiences> adicional en los archivos web.config de autenticación y movilidad en el servidor StoreFront. Para obtener más información, consulte "Configuración de la URL base del host, la puerta de enlace y el certificado SSL de un servidor StoreFront" en el apartado siguiente.

Perfil de Receiver para Web

Parámetros de proxy ICA y modo Básico

Si usa el proxy de ICA, habilite el modo básico en la página de propiedades del servidor virtual de NetScaler Gateway. Solo se necesita una licencia de plataforma de NetScaler.

Perfil de Receiver

Perfil de Receiver para Web

Configuración de la URL base del host, la puerta de enlace y el certificado SSL de un servidor StoreFront

El mismo nombre de dominio completo compartido que se resuelve en el servidor virtual de NetScaler Gateway también debe resolverse directamente en el equilibrador de carga de StoreFront si se ha creado un clúster de StoreFront o si hay una única dirección IP de StoreFront que aloje el almacén.

DNS interno: Cree tres registros A de DNS.

  • storefront.example.com debe resolverse en el equilibrador de carga de StoreFront o en la dirección IP única del servidor StoreFront.
  • storefrontcb.example.com debe resolverse en la dirección IP virtual del servidor virtual de NetScaler Gateway, de modo que, si existe un firewall entre la DMZ y la red local de la empresa, permita esto.
  • accounts.example.com. Cree un alias de DNS para storefront.example.com. También se resuelve en la dirección IP del equilibrador de carga para el clúster de StoreFront o en la dirección IP única del servidor StoreFront.

Certificado de ejemplo de un servidor StoreFront: storefront.example.com

  1. Cree un certificado adecuado para el servidor o grupo de servidores StoreFront antes de instalar StoreFront.
  2. Agregue el nombre de dominio completo compartido a los campos Nombre común y DNS. Compruebe que coincide con el nombre de dominio completo utilizado en el certificado SSL enlazado al servidor virtual de NetScaler Gateway que ha creado anteriormente o, si no, utilice el mismo certificado enlazado al servidor virtual de NetScaler Gateway.
  3. Agregue el alias de la cuenta (accounts.example.com) al certificado como otro nombre SAN. Tenga en cuenta que el alias de la cuenta utilizado en el nombre alternativo de firmante (SAN) es el que se utiliza en el perfil de sesión de NetScaler Gateway del procedimiento anterior (Perfil y directiva de sesiones de NetScaler Gateway con Receivers nativos).

  4. Compruebe que la clave privada se puede exportar para que el certificado se pueda transferir a otro servidor StoreFront o a varios nodos de un grupo de servidores StoreFront.

  5. Firme el certificado mediante una entidad de certificación (CA) externa como Verisign, o mediante una CA empresarial de la organización, o mediante una CA intermedia.
  6. Exporte el certificado en formato PFX e incluya la clave privada.
  7. Importe el certificado y la clave privada en el servidor StoreFront. Si va a implementar un clúster de StoreFront de Windows sin equilibrio de carga, importe el certificado en todos los nodos. Si utiliza un equilibrador de carga alternativo, como un servidor virtual de NetScaler con equilibrio de carga, importe el certificado ahí en su lugar.
  8. Cree un enlace HTTPS de IIS en el servidor StoreFront y enlácele el certificado SSL importado.

  9. Configure la URL base del host en el servidor StoreFront para que coincida con el nombre de dominio completo compartido que ya ha elegido.
    Nota: StoreFront siempre selecciona automáticamente el último nombre alternativo de firmante (SAN) en la lista de nombres alternativos de firmante del certificado. Esto es una sugerencia de URL base del host para ayudar a los administradores de StoreFront y normalmente es correcta. Puede configurarla manualmente con cualquier dirección HTTPS://<FQDN> válida, siempre que exista en el certificado como un nombre SAN. Ejemplo: https://storefront.example.com
localized image

Configure NetScaler Gateway en el servidor StoreFront: storefront.example.com

1. En el nodo Almacenes, haga clic en Administrar NetScaler Gateways en el panel Acciones.

2. Seleccione la Puerta de enlace en la lista y haga clic en Modificar.

localized image

 

3. En la página Parámetros generales, introduzca el nombre FQDN compartido en el campo NetScaler Gateway URL.

4. Seleccione la ficha Parámetros de autenticación e introduzca el nombre FQDN de respuesta en el campo URL de respuesta.

localized image

5. Seleccione la ficha Secure Ticket Authority y asegúrese de que los servidores Secure Ticket Authority (STA) coinciden con la lista de Delivery Controllers ya configurados en el nodo Almacén

6. Habilite el acceso remoto al almacén.

7. Establezca manualmente la baliza interna para el alias de la cuenta (accounts.example.com) y configúrela de modo que no se pueda resolver desde fuera de la puerta de enlace. El nombre de dominio completo (FQDN) debe ser distinto de la baliza externa que comparten la URL base del host de StoreFront y el servidor virtual de NetScaler Gateway (storefront.example.com). NO utilice el nombre de dominio completo compartido, ya que crea una situación en la que la baliza interna y la baliza externa son idénticas.

8. Si quiere respaldar la detección mediante nombres de dominio completo (FQDN), siga estos pasos. Si la configuración del archivo de aprovisionamiento es suficiente o si solo está utilizando Receiver para Web, puede omitir los pasos siguientes.

Agregue una entrada <allowedAudiences> adicional en C:\inetpub\wwwroot\Citrix\Authentication\web.config. Hay dos entradas <allowedAudiences> en el archivo web.config de autenticación. Solo la primera entrada del archivo requiere agregar una entrada <allowedAudience> más para el productor de tokens de autenticación.

9. Realice una búsqueda de la cadena <allowedAudiences>. Busque la siguiente entrada, agregue la línea que aparece en negrita, guarde y cierre el archivo web.config.

<service id="abd6f54b-7d1c-4a1b-a8d7-14804e6c8c64" displayName="Authentication Token Producer">

..........

..........
               <allowedAudiences>
                     <add name="https-storefront.example.com" audience="https://storefront.example.com/" />
                           <add name="https-accounts.example.com" audience="https://accounts.example.com/" />
                 </allowedAudiences>

9. En C:\inetpub\wwwroot\Citrix\Roaming\web.config. Busque la siguiente entrada, agregue la línea que aparece en negrita, guarde y cierre el archivo web.config.

<tokenManager>
          <services>
                <clear />
..........

..........

                   </trustedIssuers>
                   <allowedAudiences>
                       <add name="https-storefront.example.com" audience="https://storefront.example.com/" />
                               <add name="https-accounts.example.com" audience="https://accounts.example.com/" />
                       </allowedAudiences>
                     </service>
                   </services>
                 </tokenManager>

 

También es posible exportar el archivo .CR de aprovisionamiento del Receiver nativo para el almacén. Así, ya no hay necesidad de la configuración para el primer uso de Receivers nativos. Distribuya este archivo a todos los clientes de Receiver para Windows y Mac.

Si ya hay un Receiver instalado en el cliente, el tipo de archivo .CR se reconoce y, al hacer doble clic en el archivo de aprovisionamiento, este se importa automáticamente.