Archivo

Archivo para junio, 2008

Como seleccionar el servidor de licencias por defecto

lunes, 23 de junio de 2008 Sin comentarios

Selección del servidor de Licencias por defecto.

Uno de los puntos más importantes en una instalación de Presentation Server 4, son los servidores de licencias de Terminal Server, en muchos casos pueden existir varios de estos servidores repartidos por nuestra red, y podríamos caer en el problema de estar utilizando un License Server inadecuado o incorrecto. En el siguiente punto indicamos como seleccionar el servidor de Licencias al cual deseamos conectar.

En este primer ejemplo generaremos un servidor de licencias Corporativo, para ello arrancaremos regedit para realizar la localización de la siguiente clave de registro:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTermServLicensingParameters

Realizaremos el cambio del Value Name “Role” de 0 a 1, el valor 0 está especificado para determinar un nivel de dominio de Terminal Server y 1, está especificado para determinar un Servidor de Licencias Corporativo.

Ejecutamos «Adsiedit.msc», esta utilidad está disponible en el proceso de instalación de Windows Server 2003 Support tools. Realizamos la apertura del contenedor, y realizamos la apertura del correspondiente a:

CN=Configuration,DC=<domainname>,DC=<com>

Posteriormente a ello, expandimos el nivel correspondiente a CN=Sites y realizamos un clic en el contenedor correspondiente a Enterprise License Server.

En la pantalla izquierda, realizamos clic seleccionado «New» -> «Object».y en el objeto «Class Object» arrancamos el correspondiente wizard, seleccionando «licensingSiteSettings» y pulsamos “Next”.
 

Añadimos el valor con el nombre «TS-Enterprise-License-Server» y pulsamos Next, finalizando con «Finish». Posteriormente a ello, cerramos Adsiedit.msc.

Realizamos la apertura de “dssite.msc” y localizamos el License Server creado con anterioridad, “Ts-Enterprise-License-Server”, donde pone “Licensing Computer” seleccionamos “Change”, seleccionamos el servidor de licencias correspondiente y pulsamos “Ok”, Aplicamos los cambios.

Una vez realizado este cambio, unicamente quedará pendiente la replicación en todos los controladores del dominio.

Para verificar el tipo de servidor utilizado y los parámetros del mismo, utilizaremos la utilidad “lsview” contenida en el Resource Kit de Windows 2003.

Otro de los posibles cambios, para realizar un cambio de servidor de Licencias no corporativo, se establece en la siguiente clave de registro:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTermServLicensingParameters

Realizaremos clic en File Menu, y crearemos el Nuevo servidor de Licencias, poniendo como parámetros y creación de clave como:

New Key -> “LicenseServers” con el botón derecho del ratón “Nueva->Clave”

Posteriormente a ello, generaremos una nueva clave dentro de esta misma, siguiendo el procedimiento anteriormente mencionado, en este caso pondremos el nombre NetBIOS con el FQDN o la dirección IP correspondiente al servidor de licencias que estamos utilizando en ese momento.

Un Saludo,
Xavier Sánchez
http://www.ctxdom.com/citrix
MCP,CCA,CCEA,Citrix Online Certified,Citrix Access Esentials Certified
ICCC,ITIL Fundations Certified

 

Categories: General Tags:

El diseño de la seguridad en una plataforma XenApp

sábado, 21 de junio de 2008 Sin comentarios

El diseño de la seguridad en una plataforma XenApp

La seguridad es algo que por defecto siempre estamos pensando, como proteger los
accesos,los datos, las validaciones y otro sin fín de elementos que estamos en
constante proceso de modificación y aseguramiento.

En las plataformas XenApp la seguridad pasa por una serie de elementos que pueden
ayudarnos a mejorarlas, como secure Gateway.

Citrix Secure gateway, es un punto de acceso para soluciones XenApp, incorpora
entre sus distintas funcionalidades, SSL, un punto de acceso, y está disponible en
Windows y Solaris.

Uno de los puntos que tenemos que tener en cuenta y presentes en cualquier proceso
de validación es que vamos a utilizar en este, este documento pretende ser una mini
guía a tener en cuenta y que puede ayudaros a saber que elementos pueden ser
necesarios.

En este caso tendríamos que tener en cuenta:

 – Integración de Secure Gateway
 – Redundancia de servidores
 – Certificados
 – Autenticación fuerte mediante (two-factor)

La redundancia estara establecida dependiendo siempre de los roles y las necesidades
de continuidad del servicio propiamente dicho, en estos aspectos podrá ser implementada
una solución de Cluster o similar, Secure Gateway elemina ciertos mecanismos de redundancia,
y elimina el punto de fallo, especialemnte cuando se depende de ciertos elementos.

El sistema de validación de doble factor, autenticación fuerte, podrá ser establecido,
mediante prodesos de validación como RSA SecurID, accediendo mediante un servidor RADIUS,
o en la propia integración con el directorio activo.

La arquitectura de una solución Secure Gateway podrá ser establecida siguiendo los siguiente
baremos o consultas.

si, necesitamos que usuarios externos accedan a las aplicaciones XenApp, entonces
implementaremos Secure Gateway o Access Gateway Advanced.
Si, los dispositivos que utilizamos no son Windows dependen de la DMZ el acceso, entonces
implementaremos Access Gateway Advanced o Secure Gateway for Solaris.
Si Secure Gateway is requerido en conjunto con Advanced Access Control, entonces implementaremos
Access Gateway Adcanced.

En el caso de los servidores de certificados, tendremos que tener en cuenta o basarnos en la
siguiente tabla.

Si nuestra organización utiliza un certificado de un tercero, entonces necesitaremos un
servidore de certificados.
Si la organización utiliza usuarios internos con una solución de certificados, entonces
tendremos que generar un root certificate para el dispositivo cliente.

Internamente se generan certificados o pueden ser generados para utilizarlos mediante el relay
de SSL que se utiliza con el Citrix XML communications.

En la planificación de un diseño Secure Gateway o la arquitectura del mismo, tendremos además que
tener en cuenta los siguientes puntos:

– Monitorización de la red
– Puertos del firewall
– La redundancia del firewall
– El proceso de seguridad de la red

en cuanto a los puertos del firewall, tendremos que tener en cuenta los siguientes de forma inicial,
puerto 443 para la red interna en la DMZ
Para una red segura en la DMZ, tendremosq ue tener en cuenta los puertos 443 y 80
Adicionalmente a nivel de firewall, serán necesarios los puertos 1494, en el caso de publicación de recursos
de XenApp y el 2598 en el caso de session reliability.
Otro de los aspectos a tener en cuenta, quedarán establecidos en el método del diseño del sistema de validación (password).

En este caso podríamos tener los siguientes elementos en cuenta para el disño del mismo,

– Entorno del usuario
– Local Store
– Central Store
– Definición de las aplicaciones
– Politicas a utilizar
– Configuración de usuarios
– Agentes (distribución)
– Conceptos avanzados en cuento a requerimientos

Si tenemos un entorno windows o novell intentaremos utilizar siempre estos entornos para las politicas de passwords.

Un Saludo,
Xavier Sánchez
http://www.ctxdom.com/citrix
MCP,CCA,CCEA,Citrix Online Certified,Citrix Access Esentials Certified
ICCC,ITIL Fundations Certified

 

Categories: General Tags:

Como bloquear la animación Flash en un WebSite

domingo, 15 de junio de 2008 Sin comentarios

Como bloquear la animación Flash en un WebSite

El proceso de eliminación o de bloqueo de una animación Flas, en cualquier servidor Web puede ser muy importante, debido a que en el caso de no ser eliminado y un uso excesivo puede causar ciertos problemas, para ello proponemos esta solución que puede ser del interés de todos (recordad de sacar copias de seguridad del registro, y que no nos hacemos responsables de los daños que pueda causar esta modificación en vuestros equipos).

Utilizaremos para ello REGEDIT.EXE

Eliminaremos la sub-key de la clave:

{D27CDB6E-AE6D-11CF-96B8-444553540000}
Shockwave Flash Object
C:WINDOWSsystem32macromedflashflash.ocx

Localizaremos la clave:

[HKLMSOFTWAREMicrosoftInternet ExplorerActiveX Compatibility]

Crearemos una sub-key con el nombre {D27CDB6E-AE6D-11CF-96B8-444553540000}

Crearemos un nuevo registro dentro de esta subclave REG_DWORD con el valor Data, y en hexadecimal, poniendo el valor: 400, con el nombre: Compatibility Flags

Categories: General Tags:

Es cierta la limitación de 4GB en Presentation Server 4.x

martes, 10 de junio de 2008 Sin comentarios

El tema de los 4GB puede ser algo complejo, la definición de un procesador de 32bits, tiene una definición por defecto que los recursos de gestión de memoria están establecidos en 32 bits, ello quiere decir que la localización o relocalización de memoria se establece a nivel de bytes con una memoria establecida de 2^32 = 4.2 billones de longitud máxima de memoria, ello establece que la localización máxima de memoria que se puede gestionar está establecida en 4.2 billones en una única localización o procesador, lo que es lo mismo que 4GB apróximadamente.

Las aplicaciones de 32 bits como se dice en Windows a nivel de aplicación podríamos decir que «virtual» puede indicarse que utiliza o que gestiona 4GB de espacio de memoria, pero la realidad es que el sistema operativo gestiona 2GB dedicado al Kernel y otros 2GB para el uso restante de aplicaciones.

La causa principal de este problema está determinado en entornos Terminal Server, los servicios de terminal tienen ciertos problemas en los procesos de gestión de memoría de caracter compartido.

El uso de la / 3GB (para Windows 2000) o / 4GT (para Windows 2003) en el boot.ini puede ser problemático en entornos de Terminal Server porque los interruptores realizan un cambio de funcionalidad a nivel de partición entre la solicitud de espacio de memoria y espacio de memoria del núcleo.

Estos interruptores da a cada solicitud 3GB de memoria, lo que a su vez sólo deja 1 GB para el núcleo lo que puede definirse como un gran problema en entornos de Terminal Server.

Sin embargo, los sistemas de arranque / PAE pueden soportar hasta 64GB de memoria física. Ello permite el que procesadores de 32-bits o procesos de 32-bits puedan «utilizar» grandes cantidades de memoria a través de AWE (Una extensión de funcionalidades).

Esto significa que ceden a nivel de la memoria física y distribuyen sus 2 GB de espacio de direcciones virtuales. Ello quiere decir que sólo pueden utilizar 2 GB de memoria a la vez.

Todos los de la familia x86 de Intel desde los procesadores Pentium Pro incluyen una memoria de modo de llamada PAE. Con el chipset adecuado, el modo PAE permite el acceso hasta 64 GB de memoria física.

Cuando los procesadores x86 se ejecuta en modo PAE, la unidad de gestión de memoria MMU, permite la asignación de direcciones virtuales divididas en cuatro campos o bloques.

La MMU todavía implementa paginación y direccionamiento de paginación, pero a tercer nivel. El modo PAE puede hacer frente a más memoria que el estándar en modo de traducción, sino porque EDPs y PTEs son de 64 bits de ancho en lugar de 32-bits.

El sistema de direcciones físicas representa internamente con 24 bits, lo que x86 la capacidad de soportar un máximo de 2 ^ (24 +12) bytes, o 64 GB, de memoria.

Muchas de estas limitaciones quedan establecidas a nivel de desarrollo de aplicativo, si este no aprovecha dichas funcionalidades el crecimiento nunca llega a ser de carácter progresivo.

Un Saludo,
Xavier Sánchez
http://www.ctxdom.com/citrix
MCP,CCA,CCEA,Citrix Online Certified,Citrix Access Esentials Certified
ICCC,ITIL Fundations Certified

 

Categories: General Tags: