Como configurar y utilizar policies en Citrix Presentation Server

Les dejo el link a un video muy interesante, creado por Brian Madden, Microsoft MVP y Citrix CTP. Para poder ver el mismo, deberán contar previamente con un usuario de MyCitrix, el cual se puede gestionar sin problemas y en el momento.

Es un video útil para algunos, y básico para los mas idóneos, pero no deja de ser interesante. Vale la pena ver el trabajo y el nivel de los aportes a la comunidad de esta persona.

Saludos.

Marcelo.

Leer más...

La Pregunta del Día - Terminal Services Web Access

¿Cuál es el mejor método para proveer una lista de programas con acceso permitido?

1. 1. Editar remprogs.txt.
2. 2. Distribuir un archivo de texto de TS Remote Programs.
3. 3. Utilizar la MMC TS Remote Programs.
4. 4. Otorgar acceso a los usuarios a un escritorio personalizado.

La respuesta la tendrán la próxima semana.

Saludos.

Marcelo.

Leer más...

La Pregunta del Día - Terminal Services Web Access

¿Cuál de los siguientes servicios es requerido por TS Web Access?

1. 1. Windows Internet Naming Service (WINS).
2. 2. Dynamic Host Configuration Protocol (DHCP).
3. 3. Microsoft Internet Information Services (IIS).
4. 4. File Transfer Protocol (FTP).

La respuesta la tendrán la próxima semana.

Saludos.

Marcelo.

Leer más...

Integración de Access Gateway con Web Interface

Citrix Access Gateway 4.0 y sus versiones posteriores, pueden configurarse de manera tan que se integre con Web Interface con el fin de brindar acceso seguro a las aplicaciones de Presentation Server.

Antes de comenzar, y para aquellos que aún utilicen Secure Gateway, vale la pena aclarar que toda funcionalidad brindada por dicho producto, está incorporada actualmente en Access Gateway 4.2 y posteriores.

Para configurar Web Interface para el uso integrado con Access Gateway, se deberán seguir los siguientes pasos:

Redireccionamiento de Credenciales de Log On hacia Web Interface (Requiere al menos Web Interface 3.x)

Si Portal Page Authentication se encuentra habilitado, y Access Gateway configurado para utilizar autenticación LDAP, se podrán redireccionar las credenciales capturadas por Access Gateway hacia Web Interface. En este caso, en primer lugar se deberá habilitar Portal Page Authentication el el tab Global Policies:

En el caso de que Portal Page Authentication no esté habilitado, Access Gateway redireccionará a todos los usuarios hacia el Portal Page del Default User Group, sin solicitar previamente credenciales.

Luego de habilitar Portal Page Authentication, se deberá seleccionar el checkbox Forward Log On Credentials en la página de propiedades del grupo, en los detalles de Web Interface Server.

A partir de ahora, las credenciales de usuario serán redireccionadas a la Web Interface, a través de Single Sign-on (SSO).

Nota: Los requerimientos para poder utilizar SSO son:

• Web Interface 3.0 ó 4.0.
• Portal Page Authentication debe estar habilitado en el Access Gateway.
• La Web Interface debe encontrarse detrás del Access Gateway, de acuerdo con los escenarios indicados en el presente.
• La autenticación por defecto de Access Gateway debe ser LDAP. Si se utiliza RSA, SafeWord o RADIUS en el Access Gateway, se deberán tener en cuenta las excepciones mencionadas en el artículo CTX106202.

Configuración del Secure Ticket Authority

Se deberán seguir los siguiente pasos:

1. 1. Conectarse a la Administration Tool de Access Gateway.
2. 2. Seleccionar el tab Authentication and Local Users.
3. 3. Seleccionar el tab Secure Ticket Authority.
4. 4. Ingresar los datos de el/los STA/s utilizados por Web Interface.
5. 5. Ingresar la dirección IP o el nombre de host del servidor en el primer campo, seguido de /Scripts/CtxSTA.dll en el campo STA Path.
6. 6. Si el servidor STA soporta HTTPS, seleccionar el Connection Type "Secure".
7. 7. Seleccionar Add, para agregar la información.
8. 8. Si todos los datos son correctos, y el Access Gateway logra contactar al STA mediante la información ingresada, el identificador STA será completado, y el sistema solicitará el reinicio de los servicios de Access Gateway.

Web Interface paralelo a Access Gateway

En este caso, tanto Web Interface como Access Gateway residen en la DMZ. Los usuarios se conectan directamente a la Web Interface. Cuando los usuarios ejecutan una aplicación, Web Interface genera un archivo ICA que contiene instrucciones para enrutar el tráfico ICA a través del Access Gateway, como si se tratara de un Secure Gateway. Este archivo ICA generado, contiene, además, un ticket de conexión generado por el STA.

El cliente ICA presenta el ticket al conectarse al Access Gateway. El Access Gateway contacta al STA nuevamente para validar el ticket de conexión. Si el ticket aún es válido, el tráfico ICA del usuario será redireccionado hacia el Presentation Server correspondiente.

Web Interface detrás de Access Gateway

Para enrutar todo el tráfico ICA y HTTPS a través de un único puerto externo, y requerir el uso de un certificado SSL, Access Gateway puede actuar como un Web Proxy Reverso para Web Interface.

Para implementar Web Interface detrás de Access Gateway, se deberán seguir los siguientes pasos:

1. 1. Editar las propiedades del Default User Group, o el grupo para el cual Web Interface es habilitado.
2. 2. En la sección Portal Configuration de las propiedades del grupo, seleccionar Redirect to URL.
3. 3. Ingresar la URL relativa de la Web Interface (generalmente /Citrix/MetaFrame/) en el campo Portal Page Path.
4. 4. En el campo Base Server, ingresar la dirección IP o el FQDN del servidor Web Interface. Si el Web Interface soporta conexiones HTTPS, seleccionar Secure Connection, para encriptar el tráfico entre Access Gateway y Web Interface.
   

Web Interface en la Red Interna

En este caso, solo Access Gateway se encuentra en la DMZ. Las solicitudes de los usuarios son autenticadas por el Access Gateway, antes de ser redireccionadas al Web Interface.

Nota: En este caso, Portal Page Authentication debe estar habilitado en el Access Gateway. En caso contrario, se reenviarán solicitudes HTTP no autenticadas directamente al Web Interface. Se recomienda deshabilitad Portal Page Authentication solo si el Web Interface se encuentra en la DMZ.

Si Access Gateway se configura para utilizar autenticación LDAP, las credenciales LDAP del usuario pueden ser incluidas junto con la solicitud a la Web Interface, para habilitar el uso de SSO en la Web Interface.

Saludos.

Marcelo.

Leer más...

Nuevas certificaciones para Windows Server 2008

Microsoft libera al mercado dos nuevos exámenes de certificación para aquellos que actualmente sean MCSA o MCSE en Windows Server 2003.

Estos exámenes son:

• 70-648: TS: Upgrading your MCSA on Windows Server 2003 to MCTS on Windows Server 2008.
• Certificaciones a obtener:
• MCTS: Windows Server 2008 - Active Directory Configuration.
• MCTS: Windows Server 2008 - Network Infrastructure Configuration.
• 70-649: TS: Upgrading your MCSE on Windows Server 2003 to MCTS on Windows Server 2008.
• Certificaciones a obtener:
• MCTS: Windows Server 2008 - Active Directory Configuration.
• MCTS: Windows Server 2008 - Network Infrastructure Configuration.
• MCTS: Windows Server 2008 - Application Platform Configuration.

Además, para aquellos interesados, existe la posibilidad de suscribirse para la solicitud de un Voucher por el 40% del costo del examen, hasta el 30 de Junio del presente, siempre y cuando cumplan con los requisitos mencionados en el link.

Saludos.

Marcelo.

Leer más...

Citrix Application Isolation Environments

Application Isolation Environments (AIE), es una tecnología orientada a la compatibilidad de aplicaciones en un entorno de Terminal Services.

Suele suceder que algunas aplicaciones publicadas compartan componentes (.DLLs por ejemplo) y recursos, y que por tal motivo entren en conflicto durante su instalación o ejecución, con AIE, este tipo de problema estaría solucionado.

AIE se encuentra integrado con la Management Console de Presentation Server 4.0 Enterprise Edition, permitiendo administrar este tipo de aplicaciones de manera centralizada.

¿Cómo trabaja un AIE?

Un AIE virtualiza específicamente aquellos recursos del sistema operativo que determinada aplicación requiera, generando una vista virtual de los mismos, mapeándolos a los recursos físicos.

Citrix Presentation Server crea una capa de aislamiento entre la aplicación y los recursos físicos, lo que permite flexibilidad y coordinación en la compartición de los recursos. Las solicitudes de recursos del sistema de aplicaciones son interceptadas, procesadas y puestas en capa por Presentation Server. De esta forma, si la aplicación requiere modificar alguna característica del recurso, lo podrá hacer en su propia copia virtual del recurso solicitado.

¿Qué se virtualiza?

• File System: Los archivos y directorios que una aplicación utiliza, puede ser el origen de un conflicto entre aplicaciones. Este tipo de conflictos son generalmente causados debido a que dos o más aplicaciones, en especial las Legacy, no están diseñadas para ser utilizadas en ambientes multiusuario. Particularmente para este caso, AIE incluye un set de herramientas y reglas orientadas a la virtualización del File System que permite redireccionar, ignorar o aislar archivos, claves de registry, y objetos nombrados.
• Registry: Las aplicaciones almacenan la información de configuración en registry. Las dos partes más importantes son: HKLM (para elementos relacionados al sistema), y HKCU (para elementos que se encuentran relacionados con el perfil del usuario). Aquellas aplicaciones de Terminal Services están diseñadas para usar estas secciones de registry correctamente. Sin embargo, aplicaciones monousuario, multiversión, o aplicaciones que simplemente no están preparadas para TS, pueden usar estas secciones de registry de manera incorrecta, lo cual puede resultar en conflictos o comportamientos no esperados.
• Named Objects: Las aplicaciones Win32 puede crear objetos como eventos, semáforos, y memoria compartida, entre otros, los cuales son usados para comunicarse con otras aplicaciones. Cada objeto tiene su nombre visible en la sesión activa en Presentation Server. En este caso, un conflicto esperado es aquel en el cual dos aplicaciones utilizan referencias del mismo nombre hacia un objeto. Al utilizar Isolation Environments, estos intentos de acceso a objetos con el mismo nombre identificatorio son redireccionados al objeto virtual creado para tal aplicación, eliminando de esta manera, cualquier conflicto.
• COM Objects: Las aplicaciones Win32 utilizan generalmente objetos COM en su diseño, o para integrarse con otras aplicaciones en la misma suite. Un claro ejemplo de esto son dos aplicaciones pertenecientes a la suite de Office.

Cuando es recomendable utilizar AIEs

• No pueden ejecutarse multiples instancias de una aplicación.
• No pueden instalarse diferentes versiones de la misma aplicación en un mismo servidor.
• Las aplicaciones comparten de manera incorrecta recursos.
• Las aplicaciones cuentan con paths o configuraciones "hardcodeadas".
• La aplicación no se integra correctamente con Terminal Services.
• Se desean reducir las pruebas de compatibilidad previas.

Situaciones en las cuales la utilización de AIEs no tiene efecto alguno

• Dispositivos o Kernel Drivers.
• Servicios de Windows.
• Windows Class Names o Windows Names.
• Aplicaciones que no se linkean con USER32.DLL.
• DCOM.
• Instaladores que requieren reiniciar el sistema durante el proceso de instalación.

Impacto de los AIEs en el sistema

Principalmente, en algunos casos suele presentarse un incremento en lo que respecta a la actividad de discos y registry, principalmente en lo que a espacio utilizado se refiere.

Es posible reducir este impacto, personalizando las reglas por defecto correspondientes a AIEs.

En lo que respecta a la interacción con el usuario, el impacto es imperceptible en la mayoría de los casos, ya que suelen notarse algunas diferencias debido a que las aplicaciones interactuan con el sistema utilizando como intermediaria una capa virtualizada.

Cualquier modificación al file system o registry se encuentra totalmente aislada, acotando toda actividad al propio entorno de la aplicación.

Instalación de aplicaciones en un AIE

Los pasos básicos para aislar una aplicacion son:

1. 1. Identificar a través de diferentes pruebas, que la aplicación efectivamente presenta algún tipo de conflicto.
2. 2. Verificar que AIE se encuentre habilitado en la granja. (Por defecto AIE se encuentra habilitado).
1. 2.1. Acceder a las propiedades de la granja, y luego a Isolation Settings.
3. 3. Crear un AIE.
1. 3.1. En la consola Presentation Server, seleccionar el nodo Isolation Environments.
2. 3.2. En el menú Actions, seleccionar New > Isolation Environment
4. 4. Configurar las propiedades del AIE (en caso de ser necesario).
5. 5. Aislar la aplicación publicada.
1. 5.1. Seleccionar el nodo Isolation Environments.
2. 5.2. En el tab Contents, seleccionar el AIE correspondiente.
3. 5.3. En el menú Actions, seleccionar Properties.
4. 5.4. En la página Applications, seleccionar Add.

Instalación de aplicaciones a través del comando AIESETUP

Ejecutar desde línea de comandos:

"AISETUP AIE_Name Setup_Application"

Esto llevará a cabo una instalación por defecto de la aplicación en el entorno aislado seleccionado.

Para mayor información sobre el comando AIESETUP: Metaframe Presentation Server Administrator's Guide. Pag 339"

Saludos.

Marcelo.

Leer más...

Windows Server 2008 - Terminal Services

Terminal Services incluye, en lo que respecta a funcionalidades Core, las siguientes nuevas características:

• Remote Desktop Connection 6.0: Disponible con Windows Vista y, por supuesto, Windows Server 2008. Sin embargo, también se encuentra disponible para su descarga y utilización en sistemas operativos Windows XP SP2, y Windows Server 2003 SP1.
• Remote Desktop Connection Display:
  • Nuevas resoluciones: Mientras que en versiones anteriores, solo se soportaba un ratio de 4:3, con resolución máxima de 1600 x 1200, esta nueva versión soporta ratios de 16:9/10, con una resolución máxima de 4096 x 2048.
  • Monitor Spanning: Como su nombre lo indica, soporte de múltiples monitores de forma horizontal, con la resolución máxima indicada anteriormente.
  • Desktop Experience: Reproduce el desktop existente en el equipo remoto, en el cliente. Provee un Look and Feel estilo Windows Vista.
  • Desktop Composition: Principalmente, la inclusión de Windows Aero™
  • Font Smoothing: Soporte de ClearType.
  • Display Data Priorization: Funcionalidad que controla el tráfico de un canal virtual para que de esta forma, el tráfico de display, teclado, y mouse, tengan una mayor prioridad sobre otros canales, por ejemplo de impresoras o transferencias de archivos.
  
  
• Plug and Play Device Redirection for Media Players and Digital Cameras: Posibilidad de redireccionar Windows Portable Devices, específicamente Media Players basados en el Media Transfer Protocol (MTP), y Cámaras Digitales basadas en el Picture Transfer Protocol (PTP).
• Microsoft Point of Service for .NET Device Redirection: Solo disponible en versiones x86 de Windows Server 2008.
• Single Sign-On for Terminal Services: Solo disponible para conexiones remotas desde sistemas operativos Windows Vista, a Windows Server 2008.

Terminal Services Printing

Las características de impresión de Terminal Services han sido mejoradas, debido a la inclusión de Terminal Services Easy Print driver, y de Group Policies que permiten la redirección de únicamente la impresora por defecto. Esto permite limitar el número de impresoras que el spooler debe enumerar.

Terminal Services Easy Print es una nueva característica que básicamente permite imprimir desde aplicaciones remotas en impresoras del cliente, ya sea locales o de red.

• Requerimientos: Remote Desktop Connection 6.1 y Framework 3.0 SP1 en los clientes.

Terminal Server Fallback printer driver no se incluirá en Windows Server 2008, sin embargo, la policy seguirá existiendo, y solo podrá ser utilizada en servidores Windows Server 2003 SP1.

Terminal Services RemoteApp (TS RemoteApp)

Como su nombre lo indica, provee acceso a aplicaciones, a clientes remotos que cuenten con los sistemas operativos Windows Vista, Windows XP SP2, siendo en el último de los casos necesario contar con la nueva versión del cliente RDC.

Terminal Services Web Access (TS Web Access)

Es un rol de TS que permite disponer a los clientes de acceso a aplicaciones a través de una interfaz Web.

Beneficios:

• Acceso desde Internet o Intranet.
• Si se ejecutan dos o más aplicaciones instaladas en un mismo Terminal Server, estas utilizarán la misma sesión.
• Reducción del overhead administrativo. Centralización de aplicaciones y reducción de soporte en el lado del cliente.
• Requerimientos de configuración mínimos. Configuración a través de un sitio web personalizado. Integración con Sharepoint.
• Personalización del listado de aplicaciones disponibles a los usuarios en base a la utilización de Group Policies.

Terminal Services Licensing (TS Licensing)

Permite a Terminal Servers obtener y administrar Client Access Licenses (TS CALs), para terminales que se conectan a servidores TS. Este rol soporta Terminal Servers Windows Server 2008, así como también 2003 o 2000.

Nuevas funcionalidades: Habilidad para tracking de asignaciones de licencias por usuario al utilizar Terminal Services Licensing Manager.

Si el TS se encuentra en modo Per User, los usuarios que se conecten al mismo deberán contar con su licencia correspondiente. Si el usuario no cuenta con la licencia requerida, el TS contactará al License Server para obtener una TS CAL para el usuario.

Luego de que el License Server asigne una licencia Per User, quien lo administre, podrá llevar a cabo el seguimiento de dicha asignación utilizando la consola TS Licensing Manager.

Terminal Services Gateway (TS Gateway)

Este rol provee acceso a usuarios remotos a conectarse a recursos internos.

TS Gateway utiliza RDP sobre HTTPS, para brindar una conexión segura y encriptada entre el usuario remoto y los recursos de la red interna.

Nuevas funcionalidades:

• TS CAPs: Terminal Services Connection Authorization Policies, (TS CAPs), permite especificar grupos de usuarios/computadoras, que pueden acceder a un servidor TS Gateway. Estas políticas pueden crearse desde la consola TS Gateway Manager.
• TS RAPs: Permite especificar los recursos de la red interna que los usuarios remotos podrán acceder a través de un servidor TS Gateway. Al crear un TS RAP, adicionalmente pueden crearse grupos de computadoras y asociarlos con la TS RAP. Los usuarios remotos tendrán acceso solo si cumplen al menos con una de las condiciones especificadas en el TS CAP y una del TS RAP.
• Monitoreo: A través de TS Gateway Manager, podrá monitotearse la siguiente información:
• Dominio y User ID del usuario logueado.
• Dirección IP.
• Nombre del equipo destino.
• Puerto origen desde el cual el cliente se conecta.
• Fecha/Hora.
• Duración de la conexión.
• Tiempo Idle de la conexión.
• Volumen de información enviado/recibido

Group Policies para TS Gateway:

• Set the TS Gateway Server Authentication Method: Permite especificar el método de autenticaciónque los clientes deben cumplir.
• Enable Connections Through TS Gateway: Permite especificar que, cuando un cliente no pueda conectarse directamente a un recurso, el mismo intentará conectarse a través de un TS Gateway definido en la policy Set the TS Gateway server address.
• Set the TS Gateway Server Address: Permite especificar el servidor TS Gateway que los clientes utilizarán cuando no puedan conectarse directamente a un recurso.

Terminal Services Session Broker (TS Session Broker)

Es un rol que permite a los clientes reconectarse a una sesión existente en una granja de Balanceo de Carga.

TS Session Broker almacena información correspondiente a la diferentes sesiones, como por ejemplo Session ID y los usuarios asociados a la misma, y el nombre del servidor en el cual dicha sesión se encuentra.

Esta funcionalidad permite distribuir la carga de sesiones entre servidores de la misma granja.

Nuevas características: En vez de utilizar NLB, con este nuevo rol solo es necesario configurar las entradas DNS correspondientes. Este rol permite, adicionalmente, asignar un peso a cada servidor, a modo de prioridad y con el fin de distribuir eficientemente la carga.

Además, se presenta un nuevo mecanismo que permite otorgar o denegar nuevas conexiones. Este mecanismo provee la capacidad de colocar un servidor en estado Offline, sin interrumpir la actividad de los usuarios. Si nuevas conexiones son denegadas, el rol en sí redireccionará dichas conexiones a servidores de la granja que se encuentren disponibles.

Group Policies asociadas:

• Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\TS Session Broker\TS Session Broker Load Balancing
• Enabled: Permite el redireccionamiento de sesiones no existentes en el servidor en cuestión, al servidor con menor cantidad de sesiones activas.
• Disabled: Los usuarios que no tengan una sesión existente en el servidor en cuestión, se conectarán al primer servidor disponible.
• Not Configured: TS Session Broker no se encontrará especificado a nivel de Group Policy. En este caso, se podrán configurar los servidores que participarán en el balanceo de carga utilizando la Terminal Services Configuration Tool, o el Terminal Services WMI provider.

Terminal Services and Windows System Resource Manager

Permite controlar los recursos de Procesador y Memoria asignados a aplicaciones, servicios, y procesos. Administrar recursos es una forma de optimizar el rendimiento del sistema y reducir las posibilidades de que aplicaciones, servicios o procesos, tomen mayor cantidad de Procesador o Memoria de la que requieran.

Saludos.

Marcelo.

Leer más...

La Pregunta del Día - Functional Levels

¿Qué Functional Level provee la característica de actualización y replicación del atributo Logon TimeStamp?

• 1. Windows 2000 (Mixed)
• 2. Windows 2000 Native
• 3. Windows Server 2003 Interim
• 4. Windows Server 2003

Saludos.

Marcelo.

Leer más...

La Pregunta del Día - Citrix Web Interface

¿Qué tipos de sitios pueden crearse al utilizar la tarea "Create Site" en lo que respecta a Web Interface? (3 correctas)

• 1. Metaframe Presentation Server - Para usuarios que acceden a aplicaciones a través del Web Browser.
• 2. Program Neighborhood Agent Client - Para usuarios que acceden a aplicaciones utilizando el Program Neighborhood Client.
• 3. Conferencing Manager Guest Attendee - Para que usuarios invitados accedan a conferencias de Conferencing Manager.
• 4. Program Neighborhood Agent Services - Para usuarios que acceden a aplicaciones utilizando el Program Neighborhood Agent.

Saludos.

Marcelo.

Leer más...

Read-Only Domain Controllers (RODC)

RODC es un nuevo tipo de Domain Controller introducido a partir de Windows Server 2008, diseñado principalmente para su implementación en sitios en los cuales no puede garantizarse total seguridad.

Anteriormente, con Windows Server 2003, los usuarios de aquellos sitios en los cuales no se cuenta con un Domain Controller propio, debían autenticarse a través de vínculos que, en algunos casos, no proveen ni las características de seguridad ni de rendimiento aceptables para tal fin.

Con esta nueva alternativa, los usuarios que se encuentren en esa situación obtendrán una seguridad mejorada, tiempos de demora en el acceso menores, y acceso más eficiente a recursos de la organización.

Como consideraciones particulares a la hora de implementarlo, se debe tener en cuenta que el DC que contenga el rol PDC Emulator, debe ser Windows Server 2008. Además, el Functional Level del dominio y el Forest, debe ser Windows Server 2003 o superior.

Nuevas Funcionalidades:

RODC trata algunas problemáticas que son comunes de una Branch Office (BO). Puede suceder que las BO no tengan un Domain Controller local, o que lo tengan, pero no cumplan con las condiciones de seguridad necesarias que esto conlleva, además del ancho de banda necesario, o la propia experiencia y/o conocimientos del personal técnico.

A raíz de la problemática enunciada anteriormente, RODC provee las siguientes características:

• Read-only AD DS Database.
• Unidirectional replication.
• Credential Caching.
• Administrator role separation.
• Read-only DNS.

Read-only AD DS Database

Exceptuando contraseñas, un RODC contiene todos los objetos y atributos que tiene un DC típico. Sin embargo, por supuesto, no pueden llevarse a cabo cambios que impacten a la base de un RODC. Todo tipo de cambios que se quieran realizar, deberán llevarse a cabo en un DC no RODC, y luego impactados vía replicación en la base del RODC.

Aquellas aplicaciones que requieran acceso en modo lectura a la base de AD lo tendrán sin problema alguno. Sin embargo, aquellas que requieran acceso de escritura, recibirán un LDAP referral, que apuntará directamente a un DC no RODC.

Unidirectional replication

La replicación unidireccional de RODC, que aplica tanto para AD DS y DFS, permite que, en caso de que se logre hacer algún cambio con la intención de modificar la integridad de la base de datos de AD, no se replique al resto de los DCs. Desde el punto de vista administrativo, este tipo de replicación reduce la sobrecarga de bridgehead servers, y la monitorización de dicha replicación.

Credential Caching

Por defecto, RODC no almacena credenciales de usuario o computadora, exceptuando por supuesto, la cuenta correspondiente al propio RODC y la cuenta especial krbtgt que cada RODC tiene. Se debe habilitar explícitamente el almacenamiento de cualquier otro tipo de credencial.

Se debe tener en cuenta que limitar Credential Caching solo a aquellos usuarios que se autentican en el RODC, limita también la seguridad de dichas cuentas. Sin embargo, solo dichas cuentas serán vulnerables a posibles ataques.

Deshabilitar Credential Caching conlleva a que cualquier solicitud de autenticación se redireccione a un DC no RODC. Es posible, sin embargo, modificar la Password Replication Policy para permitir que las credenciales de usuarios sean cacheadas en un RODC.

Administrator Role Separation

Es posible delegar permisos administrativos únicamente para un RODC, limitando la realización de tareas administrativas únicamente en el RODC, y no en otros DCs.

Read-only DNS

El servicio DNS de un RODC no soporta actualizaciones de clientes directas. Como consecuencia de esto, tampoco registra registros NS de ninguna zona integrada que contenga. Cuando un cliente intenta actualizar su registro DNS contra el RODC, el servidor devuelve un referral, que por supuesto, es utilizado posteriormente por el cliente para actualizar su registro. Sin embargo, el RODC solicita también la replicación del registro específico.

Configuraciones y seteos agregados y/o modificados:

Con el fin de soportar Password Replication Policy, Windows Server 2008 incluye nuevos atributos que forman parte del esquema, que permiten soportar esta funcionalidad en un RODC.

• msDS-Reveal-OnDemandGroup.
• msDS-NeverRevealGroup.
• msDS-RevealedList.
• msDS-AuthenticatedToAccountList

Resumen de requisitos previos para utilizar RODCs:

• El RODC debe reenviar solicitudes de autenticación a un DC no RODC que sea Windows Server 2008. La Password Replication Policy se configura en este DC para determinar si las credenciales son replicadas hacia la Branch Office a partir de una solicitud del RODC.
• El Domain Functional Level debe ser Windows Server 2003 o superior, para que de esta forma esté disponible la delegación de Kerberos.
• El Forest Functional Level debe ser Windows Server 2003 o superior, para que linked-value replication esté disponible. Esto provee mayor consistencia en lo que respecta a replicación.
• Se debe ejecutar adprep /rodcprep a nivel forest para actualizar los permisos en todas las DNS application Directory Partitions. Esto posibilita que los RODCs que a su vez son servidores DNS, puedan replicar los permisos sin problemas.

Pasos básicos para implementar un RODC:

Instalación del Rol Active Directory Domain Services:

1. 1. Seleccionar Add Roles.
   
   
   
   
2. 2. Seleccionar Next.
   
   
   
   
3. 3. Seleccionar Active Directory Domain Services, luego, seleccionar Next.
   




4. 4. Seleccionar nuevamente Next.




5. 5. Y luego seleccionar Install, para comenzar con la instalación de los componentes seleccionados.
   




6. 6. Una vez finalizada la instalación, seleccionar Close.
   

Instalación del Rol Read-Only Domain Controller (y componentes adicionales requeridos):
Nota: El procedimiento indica solo los pasos de configuración básicos.

1. 1. Seleccionar Start.
2. 2. Seleccionar Run...
3. 3. Ejecutar DCPromo.exe.
4. 4. Seleccionar Use Advanced Mode Installation. Luego, seleccionar Next.
   




5. 5. Seleccionar Create a New Domain in the Forest. Luego, seleccionar Next.
   




6. 6. Ingresar el nombre DNS completo del dominio. Luego, seleccionar Next.
   




7. 7. Aceptar o modificar el nombre NETBios en caso de ser necesario. Luego, seleccionar Next.
   




8. 8. Seleccionar el Forest Functional Level que corresponda. Luego, seleccionar Next.
   




9. 9. Seleccionar las opciones adicionales particulares para el Domain Controller, entre ellos, DNS, Global Catalog, o Read-Only Domain Controller (el cual deberemos seleccionar). Luego, seleccionar Next.
   




10. 10. Aceptar o modificar las opciones de configuración referidas a la ubicación de la base de datos de Active Directory, logs y SYSVOL. Luego, seleccionar Next.
    




11. 11. Ingresar la contraseña del Administrador correspondiente al Directory Services Restore Mode. Luego, seleccionar Next.
    




12. 12. En la ventana de Summary, seleccionar Next.
    




13. 13. Seleccionar el checkbox Reboot on Completion, y esperar a que finalice el proceso de configuración y se reinicie el sistema operativo.
    

Espero que les sirva.

Saludos.

Marcelo.

Leer más...

La Pregunta del Día - Virtualización de servidores con Windows Server 2008

¿Cuáles de las siguientes opciones son verdaderas sobre la característica de Virtualización de Servidores de Windows Server 2008?

1. 1. La virtualización de servidores incrementa el rendimiento del sistema operativo.
2. 2. La virtualización de servidores minimiza la sobrecarga de administración.
3. 3. La virtualización de servidores optimiza el uso de los recursos del servidor físico.
   
4. 4. La virtualización de servidores reduce el costo de Hardware.

La respuesta correcta, la próxima semana.

Saludos.

Marcelo.

Leer más...

Nueva sección - La Pregunta del Día

Se estrena una nueva sección: "La Pregunta del Día". La idea es publicar preguntas sobre temas varios relacionados con Microsoft Windows en sus diferentes versiones y características, además de otros productos de la misma empresa, y Citrix, basándolas en este caso en los productos de uso más frecuente, como Presentation Server, Access Gateway, o Password Manager.

---

¿Cuáles son los pasos y la secuencia correcta para configurar la asignación de impresoras por proximidad en Presentation Server (Proximity Printing) basada en una configuración ejemplo en la cual se tienen que asignar por piso?

1. 1.En la consola de Presentation Server, seleccionar Policies.
2. 2. En el menú Actions, seleccionar Properties (de la Policy seleccionada).
3. 3. Identificar las impresoras para las cuales se aplicará la policy.
4. 4. Dentro de las propiedades de la Policy, expandir Printing, y luego Client Printers.
5. 5. Dentro de las propiedades de la Policy, expandir Printing, y luego Session Printers.
6. 6. Seleccionar una impresora por default para todas las sesiones para las cuales esta 7. Policy aplique.
7. 7. Seleccionar Client IP Address.
8. 8. Seleccionar Apply this policy to...
   
9. 9. Ingresar el rango de direcciones IP al cual se aplicará esta configuración.
10. 10. Seleccionar Apply to all client IP Addresses.
11. 11. Seleccionar Filter Based on client IP address.
    
12. 12. Seleccionar Add.
13. 13. En el tab Contents, seleccionar la política para la cual se quieren configurar las reglas de impresoras.
14. 14. Guardar la configuración.

---

Publiquen sus respuestas. La próxima semana tendrán la solución.

Saludos.

Marcelo.

Leer más...