Entre ruedas y alas

CITRIX: ¿Por que Securizar tu Tráfico entre XML Brocker y WebInterface?

El servidor Citrix XML es un componente de Citrix XenApp y XenDesktop que se utiliza para enumerar y proporcionar entradas seguras para los usuarios que utilizan a la WebInterface o CloudGateway.

El Servicio XML Citrix es un servicio de Windows que forma parte del Citrix XenApp y XenDesktop.

Se utiliza para proporcionar datos enviados tras solicitudes a los componentes XML de Citrix. Esta tecnología se introduce con MetaFrame 1.8 SP2. Hasta XenApp 6.0 cada servidor XenApp puede ser un servidor XML. En XenApp 6.5 se introduce la arquitectura de controlador de trabajo y sólo un servidor con la función de controlador puede ser un server XML. Un servidor con la función de controlador es responsable de la gestión de las explotaciones.

El servicio XML de Citrix es más comúnmente utilizado para proporcionar a los usuarios acceso a sus aplicaciones y escritorios a través de un portal web, aprovechando los servicios de WebInterface, CloudGateway (Storefront) o Access Gateway.

Se recomienda tener varios servidores Citrix XML, lo más cerca posible de los DataCollector (servidores de zona XenApp) y Desktop Delivery Controller (XenDesktop).

El protocolo XML de WebInterface y/o StoreFront utiliza texto plano en el envio de datos. Ello nos hace potencialmente posibles victimas para un ataque realizado internamente.

¿Seguridad?

Mi entorno de laboratorio será la mesa de pruebas para esta demostración. Mi actual granja utiliza el puerto 8081 para el transporte XML. No utilizamos ningún mecanismo de encriptación y securización del tráfico.

La prueba a realizar es sencilla. Vamos a realizar los siguientes pasos sobre un entorno de XenApp con CloudGateway.

Abrir URL CloudGateway
Validar-nos en StoreFront
Lanzar aplicación

Durante este proceso vamos a lanzar un snifer de red, capturando todo el tráfico.

Conectamos en el entorno y nos validamos.

Se enumeran las aplicaciones disponibles.

Lanzamos una aplicación.

Durante todo el proceso, capturamos todos los paquetes en este proceso. Finalizado el mismo, es momento de echar-le un vistazo a lo obtenido.

Creamos un filtro para centrar-nos en los paquetes XML. Como indicamos anteriormente nosotros utilizamos el puerto 8081 para tal servicio.

Echo esto, solo hay que afinar un poco mas la búsqueda para poder ver todo aquello que proporcionan nuestros paquetes XML.

Granja, nombre de servidores, datos de configuración, nombre del dominio, nombre de las aplicaciones, configuración de las mismas, encriptación del canal ICA aplicada, incluso disponemos del nombre de usuario y su contraseña en texto plano navegando por nuestra querida red.

Y que hacemos con esto? Por supuesto, seguir las recomendaciones de fabricante al respecto ;-P

Citrix recomienda:

Utilizar IPSec para el crifrado de las comunicaciones.
Utilizar un Relay SSL para el trafico entre el WI y el XM Brocker. El relay SSL realiza la autenticación del host y el cifrado de datos.
En entornos donde no esta soportado el SSL Relay se recomienda la instalación de WI en servidores de XenApp/XenDesktop. (ello no soluciona el problema, pero evita el tráfico en texto plano circulando por la red empresarial).

Como Des-habilitar Windows Store en Windows 8

abril 8th, 2013 | Posted by cristiansan in Microsoft | Policy | Windows 8 - (0 Comments)

Disponemos de dos métodos para la realización de esta tarea. Una consta del uso de GPO, para el otro método, será necesario la edición del registro.

Método 1. GPO

Utilizaremos la siguiente directiva:

User Configuration\Administrative Templates\Windows Components\Store

Dónde podemos ver la opción: Turn off the Store application

Método 2. Register

Nos situamos en la clave de registro

[HKEY_CURRENT_USER\Software\Policies\Microsoft\WindowsStore]

Para des-habilitar la store, crear la clave con los valores a continuación indicados.

«RemoveWindowsStore»=dword:00000001

Versionado en GPO

abril 4th, 2013 | Posted by cristiansan in ActiveDirectory | Microsoft | Policy | TroubleShooting - (0 Comments)

Alguna vez nos habremos (o no) preguntado como hace nuestro sistema para actualizar las directivas de nuestras maquinas y aplicar los cambios. Lejos de comparar claves con claves para detectar cambios en las mismas, Microsoft utiliza un sistema de versionado para detectar cambios en las directivas de nuestro entorno.

Verificar versión:

Podemos verificar la versión de las directivas desde :

HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\

En este punto disponemos de una serie de claves {XXX}, cada una de ellas corresponde a una extensión documentada en:

http://bit.ly/14GoMce

Por ejemplo, la extensión {25537BA6-77A8-11D2-9B6C-0000F8080861} corresponde a directivas de FolderRedirection. Dentro observaremos las directivas aplicadas que contienen configuraciones de FolderRedirection.

En la clave GPONAME podremos observar el ID de la directiva en cuestión, la cual corresponde con el ID del Sysvol (podemos ver este ID, en la consola de gestión de directivas – gpmc.msc , campo DETALLES de la directiva en cuestión).

En esta, observamos también la VERSION de la directiva; el valor que actualmente nos interesa.

Versión: 3080239

Entendiendo la versión

Veamos de donde sale este número. Una directiva de grupo dispone de dos partes, directiva de maquina y directiva de usuario. Con el fin de verificar y rastrear cambios en la configuración, la GPO rastrea el número de versión en busca de cambios.

Este número se divide en dos partes, una primera para la configuración de maquina y una segunda para configuración de usuario, divididos en forma de 16bits.

En el caso ejemplo, disponemos del siguiente número:

3080239 teniendo en cuenta que la composición de una versión se compone de: [User versión 16Bits][Computer Versin 16Bits]

Realizamos conversión a hexadecimal, para ello podemos utilizar la propia calculadora de Windows la cual nos facilitará la tarea: 2F002F

Realizamos la separación del hexadecimal en dos bloques de 16 bits, el cual nos da el siguiente resultado:

0x00010021 : [002F] User Version [002F] Computer versión

Así disponemos de una versión 47 para la gpo de usuario y una 47 para la gpo de máquina.

Cualquier modificación en la directiva, modificara la versión para la GPO y en el proceso de verificación de directivas se compara la versión. En caso de que la versión no coincida, se reaplicarán cambios de la directiva, en caso que la versión sea igual, se informa que no existen cambios y la directiva no será re-aplicada.

La versión de la directiva, es posible visualizar-la desde la pestaña de DETALLES en la consola de administración de directivas de grupo (gpmc.msc)

Si navegáis un poco por esta sección del registro observareis mas detalles interesantes. Os dejo literatura al respecto para aquellos que queráis profundizar mas.

Habilitar GPSvcDebugLevel para Troubleshooting de GPOs (2008)

Para habilitar el debug en 2008, realizaremos lo siguiente:

Troubleshooting e información ampliada en el procesamiento de directivas

–   Abrir regedit
–   Situarnos en HKLM\Software\Microsoft\Windows NT\CurrentVersion
–   Crear una nueva clave llamada “Diagnostics”
–   Generar un DWORD con nombre “GPSvcDebugLevel” e incluir el valor hexadecimal 0x30002
–   Crear el directorio %systemroot%\Debug\Usermode
–   Realizar un gpupdate /force

A partir de este momento, los logons de usuario generarán un fichero gpsvc.log en la ruta creada, dónde podremos verificar que esta ocurriendo durante la aplicación de directivas.

Troubleshooting y errores durante en el uso directivas.

–   Abrir regedit
–   Situarnos en HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
–   Generar un DWORD con nombre “ExtensionDebugLevel” e incluir el valor decimal 2.
–   Reiniciar la maquina.

El fichero winlogon.log es creado en %systermroot% \Security\Logs para su revisión.

Recursos adicionales:

Computer Policy for Client-side Extensions: http://technet.microsoft.com/en-us/library/cc978265.aspx
Client-side Extension Preferences: http://technet.microsoft.com/en-us/library/cc978250.aspx
Group Policy Client Side Extension List: http://blogs.technet.com/b/mempson/archive/2010/12/01/group-policy-client-side-extension-list.aspx
Understanding the domain-based GPO version number: http://blogs.technet.com/b/grouppolicy/archive/2008/01/08/understanding-the-domain-based-gpo-version-number-scripts-included.aspx
Best Practices: http://technet.microsoft.com/en-us/library/cc961688.aspx
The Basics of Group Policies: http://blogs.technet.com/b/askperf/archive/2007/06/05/the-basics-of-group-policies.aspx
Group Policy Site: http://technet.microsoft.com/en-us/windowsserver/bb310732.aspx
Using Log files for Troubleshooting GPOs: http://technet.microsoft.com/en-us/library/cc775423%28v=WS.10%29.aspx
How Administrative Templates Extension Works: http://technet.microsoft.com/en-us/library/cc758189%28v=WS.10%29.aspx

Gpupdate masivo

marzo 22nd, 2013 | Posted by cristiansan in ActiveDirectory | CLI | Microsoft | PowerShell - (0 Comments)

Durante la integración y/o administración de una plataforma pueden aparecer necesidades constantes de actualizar GPOs en los servidores.

Modificar una GPO y realizar un gpupdate en los servidores no es una tarea complicada, pero cuando son unos cuantos los servidores a actualizar, puede ser un poco tedioso.

Las pruebas se realizarán sobre un servidor donde validaremos su correcto funcionamiento, pero confirmado el proceso, si queremos aplicar de forma inmediata estos cambios al resto de servidores, no nos quedará mas remedio que ir conectando uno por uno para forzar el update o esperar a que estas sean aplicadas de forma automática.

PowerShell permite a los administradores Windows automatizar tareas que solemos utilizar o que es necesario realizar de forma común o repetitiva.

Este pequeño script en PowerShell se encargará de actualizar mediante gpupdate una lista de servidores concreto. Para ello, nos son necesarias 3 cosas.

Lista de servidores a actualizar
Procedimiento para lanzar gpupdate de forma remota
PShell Script que incluya el script

El primer punto se solventa con un fichero .txt en el cual incluimos el nombre de maquina (fqdn). Ejecutar el comando en mas o menos servidores, implica únicamente modificar el fichero con mas o menos servidores a actualizar.

Para el segundo punto, busque la solución mas rápida. Y esta vino de Sysinternals con “psexec.exe” el cual nos posibilita la ejecución de comandos de forma remota.

Por último, solo quedaba generar el script. Y este es sin duda el punto mas sencillo 😉 Ahí os dejo el código:

$ListComputers = gc .\Servers.list.txt

# Creamos variable $ListComputers con el contenido del fichero servers.list.txt

Foreach ($strComputer in $ListComputers)

# Por cada elemento, asignar valor a la variable $strComputer y realizar:

{.\psexec.exe \\$strComputer gpupdate.exe /target:computer /force}

#Ejecuta de forma remota mediate psexec.exe sobre la maquina $strComputer, un gputdate.exe y actualiza las GPOs de maquina.

Modificando el target por :user las gpo de usuario serán actualizadas, pero tened en cuenta que las directivas de usuario en algunos casos requieren de un logoff de usuario. Para forzar este logoff utilizaríamos el modificador /Logoff.

$ListComputers = gc .\Servers.list.txt

Foreach ($strComputer in $ListComputers)

{.\psexec.exe \\$strComputer gpupdate.exe /target:user /forcé /Logoff}

Recursos:

Psexec: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Gpupdate: http://technet.microsoft.com/en-us/library/cc739112%28v=ws.10%29.aspx

3D to Cloud! de la mano de NVIDIA

Todo el mundo, o la mayoria del sector IT, a estas alturas, ya conocemos o nos suena «eso» del VDI. Una tecnologia al alza que posibilita el acceso a escritorio desde cualquier lugar, en cualquier momento, desde cualquier dispositivo y de forma segura. Tambien hablamos, y conocemos sobre la famosoa virtualización de aplicaciones (sobretodo de la mano de Citrix) y como no de la virtualización de servidores (donde vmware es el rey), pero cuando empezamos a tratar temas de renderizado 3D y diseño la cosa se complica.

La comunidad de diseñadores con necesidades intensivas de uso 3D esta de enhorabuena; por supuesto tambien, en

medio plazo, la comunidad gamer lo estará. A los grandes esfuerzos de fabricantes para el uso de GPU dedicadas y/o compartidas en entornos virtualizados, ya sea aplicaciones o escritorios, se une ahora un anuncio, que sin duda se antoja interesante (y mucho) de la mano de Nvidia.

Nvidia Grid

VCA o Apliance de Computación visual (nvidia Grid) es un potente sistema basado en GPU que corre aplicaciones complejas como las de Adobe ®, Autodesk y Dassault Systemes, y envía su salida de gráficos a través de la red hacia un equipo cliente,

proporcionando una experiencia de usuario en procesamiento de imagenes igual que si estuvieramos en nuestro equipo local.

GRID VCA ofrece una enorme flexibilidad a las empresas pequeñas y medianas con poca infraestructura de TI. GRID ofrecerá aceeración de graficos 3D a los usuarios que acceden a entornos virtualizados desde sus dispositivos mobiles, proporcionando soporte para los tres grandes del mercado, Microsoft, Vmware y Citrix.

Entre los fabricantes soportados:

Virtual Desktop Solutions

Citrix (Coming Soon)
> XenDesktop con HDX
> XenServer con NVIDIA VGX Software

Microsoft
> RemoteFX
> Windows Server 2012

VMware
> Ver 5.2
> ESX 5.1 con vSGA

Soluciones de aplicaciones virtualizadas

Citrix
> XenApp 6.5
> Windows Server 2008 R2 y 2012

Citrix (Coming Soon)
> XenApp 6.5 w / OGL add-on
> Windows Server 2008 R2 y 2012

Virtual Solutions estación de trabajo remota

Citrix
> XenDesktop 5.6 FP1 con HDX 3D Pro
> XenServer 6

VMware
> Ver 5.2
> ESXi 5.1 con vDGA

Así que todo es felicidad para los integrados especializados en Citrix, Vmware y Microsoft.

Y es que los beneficios de la tecnologia no quedan ahí. Poder realizar un diseño 3D desde autodesk o jugar a un Battlefiled o un Call of Duty en graficos de ultima generacion desde nuestro tablet o portail (o incluso smartphone!) va a ser posible, y con una experiencia cercana al uso de GPU en un entorno local.

Mobilidad absoluta en el diseño 3D, mobilidad absoluta en el juego. Se acerca un futuro móvil para disfrutar!

nvidia grid: http://www.nvidia.es/object/grid-vdi-desktop-virtualisation-es.html

OpenGL GPU Sharing Feature en XenApp

marzo 21st, 2013 | Posted by cristiansan in ctxdom | XenApp - (0 Comments)

Citrix ha anuciado el pasado Martes 18 un nuevo componente para XenApp: OpenGL GPU Sharing Feature Add-on. La mayoría de las aplicaciones gráficas 3D necesitan de un entorno servidor con GPUs dedicadas, las cuales se encargan de ofrecer un rendimiento mas rápido y descarga de trabajo la cpu.

Usar GPU o usar CPU: http://youtu.be/Zjh4oBZi00g

Con XenApp 6.0 vino el intercambio de uso de GPU con aplicaciones badadas en DirectX , ahora estos cambios, recaen sobre OpenGL.

OpenGl VS DirectX: http://youtu.be/Mgsc1h1HBxc

En este artículo, vamos a explicar como realizar instalar esta nueva característica en XenAp

1. Descarga del Add-on en MyCitrix.com

2. Instalación de XenApp

Seleccionamos el paquete y lo aplicamos.

Seguimos los pasos mostrados en el asistente y realizamos la instalación del mismo, una vez aplicado deberemos reiniciar el servidor.

Este proceso instala las siguientes DLL.

%PROGRAMFILES(X86)%\Citrix\System32\CtxGraphicsHelper.dll

%PROGRAMFILES(X86)%\Citrix\System32\CtxGraphicsHelper64.dll

Y se crean las siguientes claves de registro asociadas:

[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Graphics Helper] «Flag»=dword:00000014 «FilePathName»=»C:\\Program Files (x86)\\Citrix\\system32\\CtxGraphicsHelper64.dll»

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Graphics Helper] «Flag»=dword:00000014 «FilePathName»=»C:\\Program Files (x86)\\Citrix\\system32\\CtxGraphicsHelper.dll»

3. Configuración de uso.

OpenGl Sharing Feature no necesita de configuraciones adicionales.

Nota: Para configurar la compartición de GPU, la máquina virtual debe disponer de asignación Passtrough sobre la GPU física disponible.

Disponer del Add-On instalado habilita la compartición de GPU vía OpenGL.

4. Deshabilitar OpenGl Sharing Add-on

Para deshabilitar la funcionalidad, basta con instalar el modulo del servidor desde el administrador de programas.

La mayoría de usuarios no requieren de un uso de GPU dedicada, con lo que esta característica nos permite compartir la GPU. Esta funcionalidad no depende de la tarjeta gráfica (si el uso y/o soporte de DirectX o OpenGL).

El escalado utilizando funcionalidades de GPU compartida depende en mucho del tipo de aplicación y el uso dado sobre ella, el RAM utilizado y/o el tipo de GPU instalada.

Mas recursos:

Os recomendamos la lectura de este interesante artículo en Citrix Blogs:

http://blogs.citrix.com/2013/02/22/how-many-users-can-share-a-gpu/

Para verificar el uso de aceleración, podemos usar GPU-Z disponible en:

http://www.techpowerup.com/gpuz/.