Mes: febrero 2010

Una forma de averiguar la configuración del Registro y que al mismo tiempo nos sirve para controlar el acceso al mismo es Auditarlo. El problema con esto es la necesidad de ser muy específico con las llaves que queremos auditar a riesgo de perder rendimiento si auditamos todo o gran parte del Registro.

El proceso para auditar una llave: habilitar la directiva de auditoría – podemos hacerlo mediante la directiva de grupo en la red o activarlo de forma local. Desde el panel de control, vista clásica, herramientas administrativas, directiva de seguridad local. No hay directiva de seguridad local si se trata de un DC. Seleccionamos Directiva de auditoría del panel de la izquierda, y en el panel de la derecha doble clic en los objetos de acceso a auditar y seleccionar las casillas correspondientes a errores y aciertos. Después de habilitar las auditorías, abriremos RegEdit para auditar llaves individuales.

1. Clic en la llave a auditar
2. Menú Edición, permisos, avanzado.
3. Pestaña Auditoría, añadir.
4. Seleccionamos usuarios, grupos o equipos, ubicaciones y clic en el equipo, dominio u OU del usuario a auditar.
5. Introducimos el nombre del usuario o grupo a añadir a la auditoría de la llave y Aceptar.
6. Cada casilla de verificación indica los aciertos o errores en las actividades de las acciones de su izquierda

Una vez activada y establecida, la comprobaremos desde el visor de sucesos.

Impedir el acceso al registro

La verdad es que impedir el acceso al registro no parece recomendable ya que éste contiene configuraciones que los usuarios han de ser capaces de leer para que sus Windows funcionen correctamente, además, por ejemplo, de un control total sobre sus perfiles para el sistema y aplicaciones. Así que en todo caso, quizás lo que se desee es evitar que lo EDITEN usando el RegEdit u otras herramientas.

Evitar el uso de RegEdit puede hacerse mediante la directiva correspondiente: Impedir al acceso a Herramientas de edición del Registro

Con ello el usuario recibirá el mensaje de que ha sido deshabilitado por el administrador.

El mayor problema en esto radica en que NO todos los editores se rigen por esta directiva, así que parece que nada podría evitar a un usuario que se descargue de internet un editor, lo instale y lo use. Así que hay que usar las directivas de restricción de software y aunque esto no impedirá que los usuarios puedan usar alguno, al menos podremos restringirlos al mínimo.

Restringir el acceso remoto.

Asegurar el acceso local del Registro es una cosa y asegurar el acceso remoto es otra. Windows proporciona a los administradores y a los operadores de copia, acceso remoto al Registro. Lo que hace que cualquiera de ellos puedan acceder de forma remota desde cualquier equipo del dominio a cualquier equipo que esté unido al dominio, aunque en versiones actuales de Windows esto está más limitado.

Hay pocas veces en las que puede que queramos acceder remotamente al registro de algún equipo, por ejemplo crear un grupo de administradores en cada OU de AD para que puedan editar el registro de equipos si son de dicha OU. Para habilitar a un grupo para que pueda editar el Registro de forma remota añadiremos al grupo en la ACL de la llave: HKLMSYSTEMCurrentControlSetControlSecurePipeServerswinreg. El problema qeu se corre con esto es que aunque añadir al grupo a winreg le permite el acceso remoto, cada ACL de las llaves son las que determinan qué llaves puede cambiar el grupo.

Puede que la seguridad no sea el tema relacionado con el registro más interesante o popular, aunque para los administradores debería ser uno de los importantes.

Hay centenares de facetas de la seguridad, pero aquí vamos a ver sólo uno: El registro. Podemos cambiar la ACL de una llave, auditar las llaves, tomar su propiedad, pero no podemos hacer estos cambios en valores individuales como los haríamos en archivos individuales.

El que podamos editar las ACL de las llaves no significa que debamos hacerlo. Cambiar la seguridad del registro no es muy buena idea a menos que se tenga una razón de peso para hacerlo. A lo mejor, haremos un cambio irrelevante, pero a lo peor, impedimos el funcionamiento correcto de Windows. Hablar de ello no significa que hayamos de cambiar las cosas, pero si que hay que conocerlas y entenderlas para el caso en que sí nos veamos obligados a cambiarlas.

Ejemplo: Tenemos una aplicación que los usuarios solamente pueden ejecutar si pertenecen al grupo de administradores, en un entorno corporativo normalmente esto no es deseable. La solución podría ser implementar Windows con permisos personalizados para que dichos usuarios puedan ejecutar esos programas como del grupo usuarios o usuarios avanzados. Dos metodos para implementar permisos personalizados: manualmente, usando regedit; o, usando una plantilla administrativa donde realizamos la aplicaión de permisos que deseamos y luego aplicamos esa plantilla al equipo. Por supuesto no queremos ir de escritorio a escritorio implementando la plantilla, así que la implementamos en nuestros discos/imagénes para instalación (nuevos equipos) o usamos directivas de grupo para ello: creamos una gpo importamos la plantilla y así creamos una nueva directiva de grupo para nuestra red. Los permisos los aplicará Windows automáticamente mediante la plantilla al equipo y usuario dentro del ámbito de la GPO.

Establecer permisos en llaves

La seguridad en el registro es similar a la seguridad del sistema de archivos exceptúando que podemos establecer permisos solamente en llaves y no en valores individuales.

Si tenemos control total o la propiedad de una llave del registro, podemos editar los permisos de grupos y usuarios de su ACL.

1. Con Regedit, clic en la llave a la que queremos editar su ACL.
2. En el menú Edición, clic en permisos.
3. En la lista de usuarios y grupos, clic en el cual queremos editar los permisos y seleccionar las casillas de verificación de permitir, denegar según conveniencia:
   • Control total. Asigna o le da el permiso al usuario o grupo para abrir, editar y tomar la propiedad de la llave. Literalmente, todo.
   • Lectura. Asigna o da el permiso al usuario o grupo para leer los contenidos de la llave, pero no realizar cambios. Es sólo-lectura.
   • Permisos especiales. Asigna o da permisos al usuario o grupo de forma combinada. Para asignarlos debemos acceder a Opciones Avanzadas.

Algunas veces tendremos algunos permisos difuminados, significa que no podemos cambiarlos, normalmente es porque la llave hereda el permiso desde una llave padre. Podemos quitarle la herencia si fuera el caso.

Usando los mismos pasos podemos tanto añadir como eliminar usuarios o grupos en lugar de editar los permisos de los existentes.

Asignar permisos especiales

Los permisos especiales nos permiten un mayor afinamiento en el control de las ACL de las llaves que el Control Total o Leer. Podemos permitir a usuarios el crear sub-llaves, establecer valores, leerlos y algunos más. Para ello:

1. Con RegEdit, clic en la llave a que le queremos editar su ACL.
2. En el menú Edición, clic Permisos.
3. Clic en Avanzadas.
4. Doble clic en el usuario/grupo o lo añadimos.
   

    

5. De los combos, desplegar Aplicar a: y entonces seleccionar de la lista el deseado.
1. Esta Clave. Los permisos sólo se aplicarán a la clave seleccionada.
2. Esta clave y sus subclaves. Los permisos se aplicarán a la clave seleccionada y a todas sus subclaves.
3. Subclaves solo. Los permisos se aplicarán a todas las subclaves de la clave seleccionada pero no a ésta.
6. En la lista de permisos, seleccionaremos las casillas de Permitir o Denegar en cada permiso deseado.
1. Control total. Todos los permisos
2. Consultar valor. Leer el valor de la llave
3. Establecer valor. Establecer valor de la llave
4. Crear subclave. Crear subclaves en la clave
5. Enumerar subclaves. Identificar las subclaves de la clave
6. Notificar. Recibir notificaciones de eventos desde la clave.
7. Crear vínculo. Crear vínculos simbólicos en la clave
8. Eliminar. Eliminar la clave y sus valores
9. Escribir DAC. Escribir la lista de acceso de la clave
10. Escribir propietario. Cambiar el propietario
11. Controles de lectura. Leer la lista del control de acceso de la clave.

Sobre la herencia: Con la herencia habilitada, las subllaves heredan los permisos de sus llaves padre, es decir, si le damos permiso Control Total a una llave, sus subllaves heredarán el mismo permiso. Podemos cambiar esto e impedir la herencia, desde el cuadro de diálogo de Opciones avanzadas y desmarcando la casilla correspondiente.

PowerShell v2

Lo primero, asegurarse que la característica está instalada.

Cuando comenzamos el aprendizaje de powershell es importante hacerlo familiarizándonos con la terminología y estructura básica de los comandos. Esto nos permitirá aprender la sintaxis, y poder escribir nuestros propios scripts y comandos.

La construcción básica de scripts de powershell se denominan cmdlets. Todos los cmdlets siguen una pauta: verbo+sustantivo, Get-service, Start-service, Format-Table, etc… En general, cuando vemos cmdlets hemos de ser capaces de entender el propósito general de lo que hacen viendo su estructura.

Podemos usar los verbos y los sustantivos de muchas combinaciones, para el sustantivo Service podemos usar los verbos Start, Stop, Suspend, Set, quedando como Start-Service, Stop-Service, Suspend-Service y Set-Service.

Esta pauta u orden es la clave para aprender la estructura de línea de comandos. Que también nos da una forma fácil para encontrar y recordar los comandos que usemos con regularidad.

Podemos añadir funcionalidad a muchos cmdlets especificando parámetros como parte de la sintaxis del comando. Por ejemplo: si usamos Get-Service, obtendremos el estado de todos los servicios en ejecución del servidor local.

Pero si en vez de eso, añadimos el parámetro –Name podemos filtrar los resultados por un comando específico en el que estemos interesados.

Por ejemplo: Get-Service –Name seclogon que nos devolverá el resultado filtrado por ese nombre, o incluso usar comodines Get-Service –Name s* que devolverá …

Además del uso de parámetros, PowerShell nos da la posibilidad de usar atajos mediante Alias, por ejemplo los mismos que los anteriores: gsv –n seclogon ,gsv –n s*

Los alias nos permiten abreviar el verbo y los parámetros de nuestros cmdlets. Podemos crear nuestros propios alias con el cmdlet New-Alias. Con Get-Help New-Alias obtenemos el cómo hacerlo. A simple vista parece que el cmdlet diga: ayuda de nuevo alias.

Aunque hay que advertir que no todos los cmdlets y parámetros disponen de un alias predeterminado. Para obtener una lista de alias actuales en nuestro R2… ???

Get-Alias, perfecto!

Seguramente ya sabreis que hay unos pocos alias integrados con el propio sistema, y nos sonarán bastante familiares de otros programas de shell, por ejemplo estos tres:

• cd
• chdir
• sl

Todos tienen el mismo cmdlet asignado: Set-Location. Así que si escribimos cualquiera de ellos en PowerShell obtendremos lo mismo:

cd c:windows

chdir c:windows

sl c:windows

Set-Location c:Windows.

Dicen que esto ayuda a la transición del aprendizaje.

Finalmente os diré que también podemos usar muchos parámetros en su posición correcta (si la sabemos) sin necesidad de indicar previamente –name o –n, puede que esto cree algo de confusión si desconocemos los comandos que ejecutamos, pero siguiendo un ejemplo anterior:

Get-Service –name seclogon, es lo mismo que gsv –n seclogon y lo mismo que gsv seclogon.

Las Funciones son otra característica de PowerShell que debemos saber, con get-command –type function obtenemos una lista.

Las funciones en algunos casos son una variación de los alias y proporcionan lo mismo que los comandos. Sin embargo, las funciones generalmente se usan para extender powershell o añadirle posibilidades. También proporcionan información adicional a los verbos.

Esto significa nada más que podemos personalizar las plantillas administrativas existentes o crear nuevas plantillas y así aumentar las directivas. Windows nos proporciona unas plantillas administrativas para sus directivas, otras aplicaciones, ya puse el ejemplo de Office, también pueden proporcionar plantillas administrativas. Más que cambiar o modificar las existentes, es más recomendable crear nuestras propias plantillas.

Un aviso: las directivas son generalmente algo que los desarrolladores hacen para dar a los administradores más control sobre las aplicaciones de usuario. Una directiva necesita de código añadido por los desarrolladores que lea las directivas y obligue sus configuraciones a sus aplicaciones. Si los desarrolladores añaden directivas a su código, también crean plantillas para ello. Por otra parte, sin código que obligue a la aplicación de la configuración de directiva, el crear una plantilla administrativa para el es inútil.

• Reparar directivas rotas. No es muy frecuente, pero puede darse el caso que para reparar una directiva incorrecta se cree una plantilla personalizada.
• Crear plantillas administrativas personalizadas. Windows tiene cientos de directivas, office también. Ir a la caza de directivas es a veces frustrante. Podemos crear plantillas personalizadas que recoja en un lugar todas las que implementamos, haciendo el trabajo más sencillo. También podemos repasar la descripción de una directiva y cambiarla para que sea más fácil de entender.
• Personalizar Windows. Muchos de los valores del registro que podemos utilizar para personalizar Windows no tienen interfaz de usuario. Podemos construir una para ellos mediante una plantilla administrativa y entonces cambiar esos valores con el Editor de Directivas.

Podemos usar cualquier editor de texto para la creación de plantillas administrativas. Las plantillas tienen su propio lenguaje y debemos aprenderlo y acostumbrarnos a él. El editor de directivas es perfecto para indicarnos mensajes de error cuando una plantilla los contiene, indicándonos el número de línea, la clave del error y algo más de info. En resumen, cómo usar una plantilla administrativa:

1. Con el lenguaje de la plantilla, creamos una, es un archivo de texto con la extensión .adm.
2. Cargamos la plantilla en el Editor de directivas.
3. Editamos la configuración que define la plantilla.

Un ejemplo, ejemplo.adm:

   1: CLASS USER

   2:  

   3: CATEGORY "Directivas de ejemplo"

   4: #if version >= 4

   5:     EXPLAIN "Este ejemplo no hace nada"

   6: #endif

   7:  

   8:  POLICY "Directiva de ejemplo"

   9:  #if version >= 4

  10:     SUPPORTED "Al menos XP Profesional"

  11:  #endif

  12:  EXPLAIN "Este tampoco hace mucho"

  13:  KEYNAME "SoftwarePolicies"

  14:  VALUENAME Ejemplo

  15:  VALUEON NUMERIC 1

  16:  VALUEOFF NUMERIC 0

  17:  END POLICY

  18: END CATEGORY

Los If y endif engloban estados que sólo funcionan con ciertas versiones de Windows.

NT = 2; 2000 = 3; XP SP1 = 4; XP SP2 y 2003 = 5.

Sí queremos añadir comentarios a la plantilla:

; Esto es un comentario

// Esto también lo es

CLASS USER //configuración por usuario

CLASS MACHINE; Configuración por equipo.

Cadenas (strings)

Cuando creamos una plantilla fácil no nos será muy necesario, pero en cuanto trabajemos con plantillas más complicadas nos será muy útil trabajar con la codificación de cadenas, es como definir variables de texto para entendernos.

POLICY !!variable //aquí usamos una variable y no un texto.

POLICY “Ejemplo” // aquí es un texto y no una variable.

En el primer caso para que sustituya la variable variable por la cadena texto, usaremos la definición de cadenas, que no es más que añadir una sección denominada [strings] tal cual, corchetes incluídos. Con lo que el ejemplo quedaría:

POLICY !!variable //aquí usamos una variable y no un texto.

[strings]

variable=”Ejemplo”

Sintaxis de las plantillas

La primera entrada en un archivo de plantilla es la clave CLASS donde se define si la configuración de directiva que seguirá se aplica por-usuario o por-equipo. Pueden utilizarse múltiples CLASS en una misma plantilla. Cuando Windows procese el archivo de plantilla, las definidas en las secciones CLASS USER se unirán en HKCU y las de las secciones CLASS MACHINE en HKLM.

Queda claro pues que su sintaxis es: CLASS USER o CLASS MACHINE, sea para usuario o equipo.

Clave CATEGORY

Después de utilizar CLASS con los valores que aparecerán bajo Configuración de usuario o de Equipo, usaremos CATEGORY para crear subcarpetas en esa rama. El editor mostrará la configuración en esa carpeta. Podemos anidar CATEGORY dentro de CATEGORY.

Estas pueden contener cero o más directivas, las que no contienen directivas tienen una o más subcategorías.

Dentro podemos emplazar claves KEYNAME.

Para cerrar CATEGORY, END CATEGORY.

CATEGORY nombre

  KEYNAME subllave

  Directivas

END CATEGORY

nombre es el nombre de la carpeta que queremos que se vea en el editor de directivas, podemos usar variables.

Subllave es una subllave opcional de HKLM o HKCU que usamos para la categoría. No se incluye la llave raíz puesto que al definir CLASS ya le estamos indicando de donde colgará. Si hay espacios entre el nombre de la subllave hay que encomillarla.

Las claves que podemos usar dentro de CATEGORY son: CATEGORY, END, KEYNAME y POLICY.

Clave KEYNAME

Esta se usa dentro de CATEGORY y define que subllave HKCU o HKLM (dependiendo de CLASS) contiene el valor que estamos cambiando.

Clave POLICY

Esta clave es para definir una directiva que el administrador pueda cambiar. El editor mostrará la directiva y sus controles en un cuadro de diálogo que el administrador usará para cambiar el estado y valores de la directiva. Se pueden incluir múltiples POLICY en una CATEGORY, pero no es necesario una KEYNAME antes de cada POLICY, la más reciente se aplica a cada POLICY. Para finalizar, END POLICY.

Cada directiva contiene una clave VALUENAME para asociar un valor de registro con ella. De forma predeterminada, el editor asume que es un REG_DWORD y coloca un 0x01 al habilitar la directiva y la elimina al deshabilitarla; si no queremos que lo haga usaremos las claves VALUEON y VALUEOFF. No necesitamos ninguna otra clave aparte de VALUENAME para obtener este comportamiento. Sin embargo podemos especificar opciones adicionales, casillas de verificación, listas, cuadros de texto, y más, incluyendo las claves opcionales PART.

#

POLICY nombre

[KEYNAME subllave]

EXPLAIN ayuda

VALUENAME valor

[PART]

..

END POLICY

Nombre de la directiva.

Subllave, opcional, de HKCU oHKLM a usar por la categoría.

Ayuda es el texto que mostrará el editor en la pestaña de Explicación.

Valor, valor de registro a modificar.

Las claves que podemos usar dentro de una sección POLICY: ACTIONLISTOFF, ACTIONLISTON, END, KEYNAME, PART, VALUENAME, VALUEON, VALUEOFF, HELP, POLICY.

(Hay algunas más pero son para que los desarrolladores creen extensiones de directiva).

Clave	Descripción
EXPLAIN “text”	Texto de ayuda para una directiva específica. Las directivas incluyen una pestaña de Explicación, donde se proporcionan detalles sobre la misma directiva. También se ve el texto en el editor de directivas si se usa Extendido. Para las directivas en 2000, XP y 2003 deben contener un EXPLAIN seguido de una descripción completa de la directiva y su configuración, dentro de un #if version >= 3 EXPLAIN “text” #endif.
VALUENAME nombre	Esta clave identifica el valor del registro que el editor de directivas modifica cuando habilitamos/deshabilitamos la directiva. A menos que se especifiquen las claves VALUEON y VALUEOFF, el editor creará la directiva como un REG_DWORD: – Habilitada: establece como valor 0x01. – Deshabilitada,No configurada: elimina el valor. El conjunto de las tres describen el valor que habilita y deshabilita la directiva, si queremos definir valores adicionales para refinar la directiva hay que usar la clave PART.
VALUEON [NUMERIC] VALUEOFF [NUMERIC]	Se usan para escribir valores determinados basados en el estado de la directiva. VALUEON [NUMERIC] habilitado, VALUEOFF [NUMERIC] deshabilitado. VALUEON 0  //Creado como valor REG_SZ conteniendo un “0”. VALUEOFF NUMERIC 1 // Creado como REG_DWORD conteniendo 0x01.
ACTIONLIST	Permite un grupo de configuración juntas. Como una lista de valores que queremos que el editor cambie cuando cambiamos la directiva. ACTIONLISTON  *lista de valores a cambiar cuando se habilita la directiva. ACTIONLISTOFF *lista de valores a cambiar cuando se deshabilita la directiva. ACTIONLIST     [KEYNAME subllave] //subllave opcional de HKCU o HKLM.    VALUENAME valor      VALUE datos           END ACTIONLIST //valor es el valor del registro a modificar, si se habilita la directiva se establece un REG_DWORD conteniendo 0x01. Para valores diferentes a 0x01 y 0x00 hay que usar la clave VALUE. // datos que queremos que se establezcan en el valor, de forma predeterminada REG_SZ, podemos cambiar a REG_DWORD usando NUMERIC. VALUE DELETE hará que el editor elimine el valor del registro, aunque si el estado pasa a No configurada el valor tamién es eliminado.
PART	La clave PART nos permite especificar varias opciones, listas, cuadros de texto, casillas de verificación, en la parte inferior del cuadro de diálogo de la directiva. 1: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 2: CLASS USER ;;;;;;;;;;;;;;;;;; 3: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 4:  5: CATEGORY "Directivas de ejemplo" 6: EXPLAIN "Vamos a ver los PART" 7: POLICY "Directiva de ejemplo" 8: KEYNAME "SoftwarePolicies" 9: EXPLAIN "No hace nada" 10: 11: PART ejem01 CHECKBOX 12: VALUENAME ejemplo1 13: END PART 14: PART ejem2 CHECKBOX 15: DEFCHECKED 16: VALUENAME ejemplo2 17: VALUEON NUMERIC 11 18: VALUEOFF NUMERIC 12 19: END PART 20: 21: END POLICY 22: END CATEGORY Para directivas simples sólo necesitamos habilitarlas o deshabilitarlas, no necesitaremos esta clave. De hecho, sólo un puñado relativo de directivas en Windows la usan.

Clave PART

PART Name Type

Donde Type puede ser:

Windows 2008 R2 proporciona un conjunto de funciones añadidas para el servidor llamadas características. Estas formaban parte de Windows 2008 con algunas nuevas en R2. De estas características se extraen las que son obligatorias para que ciertos roles funcionen, de las que añaden fiabilidad al servidor, como el clustering por ejemplo. Algunos sólo añaden estética, como Experiencia de Escritorio. Cuando planeamos nuestro servidor puede que necesitemos instalar algunas de ellas para lograr la configuración querida. En muchos casos no necesitaremos instalar características necesarias a un role. Las que son obligatorias normalmente se instalarán al instalar el propio role.

Para instalar una característica abrimos el Administrador del Servidor, y elegimos Características.

Pulsando en el enlace Agregar características obtendremos acceso al asistente:

Tabla de características:

Para administrar los entornos de escritorio de los usuarios se utilizan las Directivas de grupo, las GPO. Más que ver las directivas a nivel de Active Directory lo que veremos es como implementar las directivas a nivel local, incluso crear nuestras propias directivas para redes que no están basadas en AD.

Las directivas no son Preferencias, comparándolas entendemos mejor cómo Windows usa las primeras. Los usuarios establecen preferencias, su fondo de pantalla por ejemplo y las pueden cambiar en cualquier momento. Los administrdores establecen directivas como donde está la carpeta Mis Documentos y éstas toman precedencia sobre la preferencia equivalente del usuario. Windows las almacena en el registro de forma separada. Si existe una directiva, el sistema usa la configuración especificada en ella, si no la hay, usará la preferencia del usuario; en ausencia de ambas, la configuración predeterminada. Una directiva no cambia una preferencia de usuario sino que toma precedencia en su aplicación coexistiendo ambas. En cuanto un admin suprime la directiva, la preferencia vuelve a usarse.

Windows combina las directivas en una GPO. En AD hay múltiples GPO que se aplican a usuarios y equipos, dependiendo de donde se encuentren en el directorio. En Windows sólo hay UNA GPO, Local GPO. Su configuración se aplica al equipo local y a cualquier usuarios que inicie sesión en el. Ya que la Directiva Local es la primera que aplica Windows cuando arranca y los usuarios inician sesión, las directivas de red pueden sobreescribir su configuración. Es decir, si la directiva local indica una configuración y la establecida en la red por el administrador la niega, se aplicaría la segunda.

Las Directivas de grupo contienen configuración tanto para usuario como para equipo, conteniendo dos ramas principales:

• Configuración de Equipo. Valores de configuración de directiva por-equipo que especifican el comportamiento del sistema operativo, del escritorio, de seguridad, de scripts de inicio y apagado del sistema, de aplicaciones asignadas al equipo y configuración de aplicaciones. Windows las aplica las directivas por-equipo cuando se inicia el sistema y a intervalos de forma regular.
• Configuración de Usuario. Valores de configuración de directiva por-usuario que especifican el comportamiento del sistema operativo, del escritorio, de las aplicaciones publicadas y asignadas, de redirección de carpetas, de seguridad, de scripts de inicio y cierre de sesión de usuario y configuración de aplicaciones. Windows las aplica cuando el usuario inicia sesión en el equipo y a intervalos de forma regular.

Para editar la Directiva Local usamos el Editor de directivas:

A) Abrimos Inicio, ejecutar y escribimos gpedit.msc

B) O, nos creamos una MMC con el snap-in.

1. escribimos mmc en Inicio-Ejecutar

 

2. Menú Archivo, Agregar o quitar complemento

3.  En la pestaña Independiente, botón Agregar

4. Elegimos Editor de Directivas de grupo del cuadro y botón Agregar

5. Seguimos el asistente eligiendo Equipo Local

6. Pulsamos en Finalizar y cerramos todos los diálogos abiertos, pulsando luego en Aceptar del diálogo Agregar o quitar complemento.

7. obtenemos una consonla con el complemento añadido.

 

Extensiones de directiva

Las directivas tienen varias extensiones que podemos ver cuando las configuramos. De hecho, cada nodo que vemos en el editor de directivas es una extensión. De forma predeterminada, el editor carga todas las que están disponibles al iniciar. Configuración de Equipo y Configuración de Usuario contienen diferentes extensiones, podemos ver más al editar una directiva en AD que en una directiva Local. Algunas de las extensiones, resumidas, en una directiva local son:

• Scripts. Podemos asignar scripts a los usuarios que se ejecuten al inicio o cierre de sesión. También a equipos para que se ejecuten al arrancar o apagar Windows. Se encuentra dentro de la carpeta de Configuración de Windows.
• Configuración de seguridad. Podemos administrar valores de seguridad, como contraseñas, auditoría y bloqueo de directivas. También podemos administrar derechos de usuario y restringir las aplicaciones que los usuarios pueden ejecutar. Se encuentra dentro de la carpeta Configuración de Windows.
• Plantillas administrativas. Directiva crea un archivo que contiene valores de Registro y que se escriben en HKCU o HKLM. Windows carga los valores desde este archivo cuando el sistema inicia o el usuario inicia sesión. Estas son las directivas basadas en el registro.

Directivas en el registro

Directivas del registro o directivas administrativas son la misma cosa. Son valores en el registro que sobreescriben las preferencias de los usuarios y hay buenas razones para que los usuarios no las puedan cambiar. Otras directivas, como la configuración de seguridad pueden o no ser valores de registro. En el editor de directivas encontramos las directivas de registro en la carpeta Plantillas Administrativas, tanto bajo la Configuración de Equipo como de la Configuración de Usuario.

Las plantillas administrativas, archivos con la extensión .adm, definen las directivas que los administradores pueden establecer. Estas plantillas describen el interfaz de usuario para reunir configuraciones del administrador y las ubicaciones de estas configuraciones desde el registro. Cuando el administrador define directivas, el editor las guarda en un archivo llamado Registry.pol. Windows carga la configuración contenida en Registry.pol cuando el sistema se inicia, cuando los usuarios inician sesión, y a ciertos intervalos regulares.

Las extensiones, Plantillas administrativas y una extensión de parte del cliente integrada en el registro* trabajan juntas para implementar las directivas basadas en el registro.

*Procesa las directivas y crea sus correspondientes valores en el registro.

Windows tiene plantillas administrativas que definen todas las directivas compatibles con el sistema operativo. Si queremos usarlas para una aplicación, como Office, debemos cargar la plantilla administrativa correspondiente a Office. (El kit de recursos de Office contiene muchas plantillas administrativas para el manejo y administración de la suite) Las que nos proporciona Windos son:

• System.adm. Valores principales y primer archivo de plantilla, define la mayoría de valores que vemos en Plantillas Administrativas.
• Wmplayer.adm. Valores de Windows Media.
• Conf.adm. Software de NetMeeting.
• Inetres.adm. Microsoft Internet Explorer.

Todas las directivas se establecen en uno de tres estados: Hailitada, Deshabilitada o No configurada.

Habilitada explícitamente aplica la configuración añadiéndola al registro con un valor de 0x01. Deshabilitada explícitamente desactiva la configuración añadiéndola al registro con un valor de 0x00(o quitándolo). No configurada elimina el valor de configuración del registro. Hay algunas directivas que necesitan de datos adicionales.

Cuando configuramos una directiva prestemos atención a la explicación para asegurarnos que el resultado será el que queremos. Algunas directivas son positivas –se activa la característica al habilitarla-, otras negativas –se desactiva la característica al habilitarla-. Un poco de confusión, a veces para aplicar hemos de deshabilitar y al contrario. Así que leed bien la directiva y lo que hace antes. 😉

¿Donde guarda Windows las directivas?

En la rama SoftwarePolicies preferentemente. En la llave HKLM, contendrá las directivas por-equipo y en HKCU las directivas por-usuario.

Otra rama, heredada de versiones anteriores, es SoftwareMicrosoftWindowsCurrentVersionPolicies. En la que las directivas tienden a tatuar el registro, lo que quiere decir que hacen cambios permanentes en el registro; Debemos explicítamente cambiar estas directivas. Las ACL, listas de control de acceso, impiden a los usuarios hacer cambios en estas llaves y de ese modo las directivas que se aplican. Los grupos locales usuarios y usuarios avanzados no tienen permisos para cambiar valores en estas llaves, pero un administrador puede sobreescribirlas directamente y cambiar la directiva.

Ya que sabemos donde se ubican en el registro sólo nos resta saber en ué lugar del sistema de archivos están. La directiva local está en %raíz_del_sistema%System32GroupPolicy. Es una carpeta super oculta . Para verla en el explorador de Windows hemos de habilitarlo desde herramientas del menú y cambiar las opciones en la pestaña Ver del diálogo de Opciones de carpeta, tanto Ver archivos y carpetas ocultos como desmarcar ocultar archivos del sistema.

Dentro de esta carpeta encontramos las siguientes subcarpetas y archivos:

• Adm. Donde están todos los archivos adm de la directiva local.
• User. Archivo Registry.pol.
• UserScripts. Scripts por-usuario de la directiva local. Dentro de Logon para el inicio de sesión en Windows y dentro de Logoff para el cierre de sesión en Windows.
• Machine. Registry.pol del equipo.
• MachineScripts. Scripts por-equipo de la directiva local. Dentro de Startup para el arranque y en Shutdown para el apagado.

Puede copiarse la carpeta de un equipo a otro para replicar las directivas que contienen, aunque mejor comprobarlo antes de hacerlo en un entorno de trabajo.

Servicio Servidor

Manualmente podemos optimizar el servicio Servidor, personalizándolo a favor del uso de memoria, de la red o de ambos.

HKLMSYSTEMCurrentControlSetServiceslanmanserverSize

Valor REG_DWORD, con:

0x01 para minimizar el uso de memoria.

0x02 balancear el uso de memoria y el rendimiento de red.

0x03 máximizar el rendimiento de red.

Autenticación

Hay una serie de personalizaciones que pueden ayudarnos a resolver problemas y optimizar la autenticación.

Kerberos, Obligatoriedad de Catálogo Global y la habilitación de los mensajes de Winlogon extendidos para obtención de información.

KERBEROS

Kerberos es un mecanismo de autenticación que se usa para comprobar la identidad de un usuario o equipo. Es el método preferido para autenticar servicios en Windows Server 2003. Podemos modificar los parámetros de Kerberos para resolver contratiempos o simplemente para testear el protocolo, al acabar eliminamos las entradas añadidas, ya que podría influir en el rendimiento del equipo.

En la llave: HKLMSYSTEMCurrentControlSetControlLsaKerberosParameters con valores del tipo REG_DWORD.

SkewTime	5 (minutos)	Este valor es el máximo de diferencia de hora permitido entre el equipo cliente y el servidor que acepta la autenticación.
LogLevel	0	Indica si los sucesos se guardan en el Registro de sucesos del sistema. Cualquier valos distinto a 0 provocará que todos los sucesos relacionados con Kerberos se guarden.
MaxPacketSize	1465(bytes)	Tamaño máximo del paquete UDP. Si se supera el tamaño se usa TCP.
StartupTime	120(segundos)	Tiempo que espera Windows al KDC para iniciar antes de darse por vencido.
KdcWaitTime	10(segundos)	Tiempo que espera Windows una respuesta del KDC.
KdcBackoffTime	10(segundos)	Tiempo entre sucesivas llamadas al KDC si la anterior ha fallado.
KdcSendRetries	3	Intentos de contactar con el KDC.
DefaultEncryptionType	23 (0x17)	Tipo de cifrado para la preautenticación.
FarKdcTimeout	10(minutos)	Tiempo de caducidad usado para invalidar a un controlador de dominio desde un sitio distinto en la caché de controlador de dominio.
NearKdcTimeout	30(minutos)	Tiempo de caducidad usado para invalidar a un controlador de dominio en el mismo sitio en la caché de controlador de dominio.
StronglyEncryptDatagram	FALSE	Bandera que indica si se usa un cifrado de 128 bits, lo contrario a un cifrado débil, en paquetes de datagrama.
MaxReferralCount	6	Numero de referencias KDC que un cliente sigue antes de darse por vencido.
KerbDebugLevel	0	Indicador de depuración: 1 ON, 0 OFF.
MaxTokenSize	12000	Valor máximo del token Kerberos (Se recomienda siempre un valor menor a 65535).
SpnCacheTimeout	15(minutos)	Tiempo de vida de las entradas en caché del servicio principal de nombres SPN. En DCs la caché SPN está deshabilitada.
S4UCacheTimeout	15(minutos)	Tiempo de vida de las entradas negativas en caché S4U que se usan para restringir el número de solicitudes Proxy S4U desde un equipo en particular.
S4UTicketLifeTime	15(minutos)	Tiempo de vida de los tickets obtenidos por solicitudes proxy S4U.
RetryPdc	0	Indica si el cliente contactará con el DC primario para solicitudes de autenticación (AS_REQ) si recibe un error de contraseña caducada. 0=falso; distinto a 0=verdadero.
RequestOptions	Cualquier valor de la RFC 1510	Indica si hay opciones adicionales que puedan enviarse como opciones KDC en las solicitudes de Ticket de concesión de servicio (TGS_REQ).
ClientIPAddress	0	Indica si una dirección IP de cliente se añadirá en un AS_REQ para obligar al campo Caddr a contener direcciones IP en todos los tickets. 0=falso; cualquier otro = verdadero.
TgtRenewalTime	600(segundos)	Tiempo que Kerberos espera antes intentar renovar un ticket (TGT) antes de la caducidad del ticket.
AllowTgtSessionKey	0	Indica como se exportan las claves de sesión. El valor es 0 por seguridad. 0=falso, cualquier otro=verdadero.

 

En la llave: HKLMSYSTEMCurrentControlSetServiceskdc con valores del tipo REG_DWORD.

KdcUseClientAddresses	0	Indica si la dirección IP se añade a la respuesta de Ticket de concesión (TGS_REP). 0=falso; cualquier otro=verdadero.
KdcDontCheckAddresses	0	Indica si las direcciones IP para el TGS_REQ i el campo Caddr del TGT se comprobarán. 0=falso; cualqueir otro=verdadero.
NewConnectionTimeout	50(segundos)	Tiempo en que el extremo de una conexión TCP inicial permanecerá abierta para recibir datos antes de desconectarse.
MaxDatagramReplySize	1465(bytes)	Tamaño máximo de paquete UDP en los mensajes TGS_REP y AS_REP. Si el paquete excede el tamaño, el KDC devuelve un mensaje KRB_ERR_RESPONSE_TOO_BIG que solicita al cliente que cambie a TCP.
KdcExtraLogLevel	2	Indica que información escribirá y auditará el KDC en el registro de sucesos.
KdcDebugLevel	0	Depurador ON o depurador OFF.

 

Deshabilitar obligación Catálogo Global

Emplazar los servidores de Catálogo Global en sitios remotos suele ser deseable para mejorar el rendimiento del inicio de sesión de usuario, búsquedas y otras acciones que necesitan comunicación con el catálogo, y para reducir el tráfico WAN. Sin embargo, para reducir la intervención adminitrativa, las necesidades de hardware y otros relacionados, puede que no queramos tener un servidor de catálogo global en un sitio remoto. Esto es relevante en ciertos entornos, pero el problema es que los inicios de sesión necesitan que un controlador de dominio autentifique al usuario para contactar con el catálogo global y determinar si pertenece a un grupo universal. Si la oficina remota o sucursal no dispone de un catálogo global y no puede contactarse con uno, puede fallar el inicio de sesión del usuario.

Windows Server 2003 ofrece una alternativa de caché de grupos universales. Cuando se habilita para un sitio, los usuarios que inician sesión mientras el catálogo global está en línea pueden seguir haciéndolo aún cuando el catálogo global esté fuera de línea en el próximo inicio de sesión.

Para eliminar la obligación de catálogo global en un sitio y esquivar inicios denegados de sesión de usuario, lo habilitamos en el valor de configuración del controlador de dominio que lleva a cabo la autenticación del usuario:

IgnoreGCFailures (REG_DWORD) en HKLMSYSTEMCurrentControlSetControlLsa, dándole un valor de 0x01 y reiniciando el DC.

Habilitar mensajes de Winlogon extendidos

Podemos configurar Windows para obtener mensajes de inicio de sesión, apagado, arranque y cierre de sesión extendidos, obteniendo información extendida para resolver cualquier incidencia en el comportamiento de estas acciones.

Creamos el valor verbosestatus del tipo REG_DWORD en la llave HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem, y le damos el valor 0x01.

*Hay que comprobar que no exista el valor DissableStatusMessages en la misma llave sino no se mostrarán los mensajes.

Después de instalarlo supongo que hemos de configurarlo para ‘algo’ que deseamos, ¿no?.

Tenemos funcionalidades ‘Roles’ y características añadidas para variedad de propósitos y de eso se trata, ¿que plan tenemos?

Yo destacaría algunos roles:

• Los referentes a Active Directory
• Hyper-v, y
• Servicios de Escritorio Remoto.

A grosso modo, y teniendo en cuenta que el que se maneje con soltura con 2003 esto lo tiene superchupao, haremos una incursión a nuestros planes.

Repaso de términos:

Queremos Active Directory

Es una de las funciones más común en Windows Server 2008 R2, AD vigila el acceso y autenticación de aplicaciones y recursos de nuestra red, nos proporciona los servicios de directorio para que organicemos y aseguremos la infraestructura de red.

Bosque

Principal estructura lógica de la estructura de directorio. Contiene todos los objetos de nuestro directorio, comenzando por Dominios. Los dominios de un bosque único automáticamente tendrán confianza transitiva en dos sentidos. También define varias cosas para todos los dominios en el bosque: PRIMERO, el esquema de la estructura AD – El esquema contiene la definición y atributos para todos los objetos en el bosque y es muy importante para AD ya que define diversos objetos como usuarios y grupos. Definirá que propiedades tendrán estos objetos, extenderá la compatibilidad con nuevos objetos y propiedades necesarias en aplicaciones como el correo electrónico. Y SEGUNDO, el bosque contiene la información de replicación para un funcionamiento adecuado del directorio. Finalmente, el bosque mantiene el catálogo global que proporciona capacidades de búsqueda para él mismo.

Dominio

Los dominios son la división del bosque en partes lógicas. Se crean como ayuda al control de replicación de datos y son instrumentos que nos permitirán escalar en nuestra estructura de directorio. El dominio contiene todos los principales de seguridad de la organización. También maneja la autenticación de red y mediante ella proporciona la base de protección de los recursos. Los dominios ayudan a administrar las confianzas, se consideran límites de seguridad de la red y no solo nos permiten segmentar el acceso a los recursos rápidamente sino que también son una herramienta para delegar tareas administrativas.

Árboles

Dentro de un bosque hay… árboles. Lugar de residencia de los dominios. Un árbol es donde tenemos dominios compartiendo un espacio de nombres común, un contexto de seguridad para compartir los muchos recursos ubicados en un dominio. Cualesquiera dominios que instalemos por debajo del primer dominio se convierten en dominios hijos y tienen un nuevo nombre DNS. Sin embargo, el nombre hereda el del padre. El padre dominio_padre.com, el hijo dominio_hijo.dominio_padre.com.

Confianzas

Las relaciones de confianza hacen que los dominios autentiquen recursos no almacenados en el propio dominio. Estas confianzas pueden ser de un sentido o de dos. Normalmente son de dos sentidos. Dentro de un único árbol en un bosque todos los dominios tienen una relación en dos sentidos automáticamente entre ellos.

OU

Esto proporciona una organización lógica de un dominio. Sin el uso de OUs, el dominio es un gigante de objetos desorganizados dificultando la administración. Nos ofrecen la posibilidad de organizar con lógica los objetos de nuestro directorio, normalmente cuentas de usuarios y grupos, sin embargo hay más objetos en un dominio aunque usaremos más las cuentas de usuario y equipo. Los beneficios administrativos son varios. Búsqueda de usuarios o grupos, delegación de administración de las OU que nos permite tener múltiples administradores sin que tengan privilegios en todo el dominio. Y como no, la facilidad de implementación de las directivas de grupo, una herramienta muy útil.

Usuario

Cuenta que garantiza el inicio de sesión en la red.

Grupo

Forma de organización de usuarios y grupos para dar acceso seguro a los recursos de la red.

DC

Sevidor principal donde se tienen los objetos del dominio. Responsable de la replicación a otros DC.

RODC

Variación de DC, en este caso de sólo-lectura.

Sitios

Cuando se diseñan los dominios de AD, OUs y los muchos objetos que ofrecen los contenedores lógicos para ayuda de nuestra estructura, tenemos un elemento físico de AD importante: el sitio. Los sitios nos permiten controlar la estructura física de la red. Ayudan al gobierno de las funciones principales del entorno:

• Replicación
• Autentificación y,
• Ubicación de servicio.

Con los sitios definimos los límites de nuestra red mediante las direcciones IP y las subredes, que nos dan un mecanismo para controlar el tráfico.

Cuando se planea la estructura AD se comienza desde arriba: el bósque y los dominios. Cuando instalamos el primer controlador de dominio, éste se convierte en el dominio raíz y en el principio del bosque. Definimos el espacio de nombres DNS al instalar el primer DC.

Sólo Hyper-v por favor…

Una demanda creciente es el uso de técnicas de virtualización para el relanzamiento de recursos reutilizables que ayuden a la consolidación y flexibilidad del servidor. Windows Server 2008 R2 Hyper-v está basado en la tecnología del hypervisor. Lo que permite a sistemas virtuales acceder al hardware del servidor eficientemente. A diferencia de otras tecnologías de virtualización, Hyper-v no integra controladores de terceros en la capa del hypervisor. Los controladores que son utilizados por los sistemas virtuales se colocan en la partición padre, que es el sistema operativo host. Todas las máquinas virtuales que instalemos se ubicarán en particiones hijas.

Decidir tener un servidor que maneje la carga de virtualización puede parecer simple, pero este role necesita planearse a conciencia. Microsoft proporciona una herramienta: MAP toolkit con la que podremos analizar y sacar informes que nos ayuden a decidir nuestro Hyper-v.

Servicios de escritorio remoto

Lo que hasta ahora eran Terminal Services ha pasado a Remote Desktop Services (RDS) en 2008 R2. Su funcionalidad tiene mucho de la misma de TS en 2008. Estos servicios nos servirán para proporcionar una presentación virtualizada de nuestro entrono. La metodología para planear su implementación es como la de virtualización.

Cuando instalamos RDS debemos considerar el orden adecuado de instalación de estos servicios comparándolos con las aplicaciones que usaremos en el servidor RDS. La regla general a seguir es instalar las aplicaciones y luego RDS para evitar problemillas potenciales y reinstalaciones de aplicaciones. Estas aplicaciones, en muchos casos, tienen instrucciones de instalación concretas para compatibilizarlas con su funcionamiento en Terminal Server.

Otra consideración es el cómo permitir a los clientes autentificarse contra el servidor y cuál es el nivel de seguridad. Hay dos opciones, Obligar a autentificación a nivel de red y no obligar. Esta decisión puede tener impacto sobre el tipo de clientes y el nivel de seguridad proporcionado por nuestro RDS. También controla el momento de autentificación de los clientes durante el proceso de inicio de sesión, si obligamos, el usuario se autentica antes de establecer la conexión de escritorio remoto con lo que el nivel de seguridad es mayor, sin embargo, se necesita que los clientes ejecuten al menos la versión 6.0 de escritorio remoto y que el cliente Windows sea compatible con el protocolo CredSSP, Vista Xp sp3. Si la elección es no obligar a la autenticación a nivel de red, permitiremos a cualquier versión de escritorio remoto a conectar, lo que significa una segurida menor ya que la autentificación se produce después en el proceso de conexión.

Como consejo: No es nada recomendable tener los servicios RDS en un servicor con AD en marcha (DC), primero porque creamos riesgos innecesarios a AD y segundo por la carga de trabajo que representa y la degradación de rendimiento que puede causar.

Hay dos roles de RDS: Remote Desktop Gateway y RemoteApp and Desktop Web Access, que requieren de la instalación de más servicios para su función correcta.

Si instalamos Remote Desktop Gateway, necesitaremos el servidor Web, NAP, RPC sobre HTTP y las herramientas de administración de Remote Server.

Si instalamos RemoteApp and Desktop Web Access, necesitaremos el servidor Web y las herramientas de administración de Remote Server.

Las funciones de RDS:

Remote Desktop Session Host: Un servidor Host de sesión de Escritorio remoto es el servidor que hospeda programas basados en Windows o todo el escritorio de Windows para clientes de Servicios de Escritorio remoto. Los usuarios pueden conectarse a un servidor Host de sesión de Escritorio remoto para ejecutar programas, guardar archivos y usar los recursos de red de dicho servidor. Los usuarios pueden obtener acceso a un servidor Host de sesión de Escritorio remoto mediante Conexión a Escritorio remoto o con RemoteApp.

Remote Desktop Licensing: Servidor que administra las licencias de acceso de cliente de Escritorio remoto (CAL de RDS) que son necesarias para la conexión de cada dispositivo o usuario a un servidor Host de sesión de Escritorio remoto. Administración de licencias de Escritorio remoto se usa para instalar y emitir CAL de RD en un servidor de licencias de Escritorio remoto, y para realizar el seguimiento de la disponibilidad de las mismas. Es un componente necesario para RDS.

Remote Desktop Connection Broker: El Agente de conexión a escritorio remoto es una función para granjas de servidores, ayuda esencial en el balanceo de carga de las conexiones al servidor.

Remote Desktop Gateway: Puerta de enlace de Escritorio remoto es un servicio que permite a los usuarios conectar con el servidor de escritorio remoto a través de internet, sin la necesidad de conexión directa con la red corporativa.

RemoteApp and Desktop Web Access: Esto permite a los usuarios conectar vía navegador web con los espacios de trabajo remotos configurados en el servidor RDS; este servicio también proporciona valores de configuración que pueden dejarse en el Menú de inicio del equipo cliente. La página web proporciona acceso a las aplicaciones o escritorios que están autorizados para acceso web.

Remote Desktop Virtualization Host: Habilita al servidor RDS a proporcionar servicios de virtualización de escritorios. Este servicio necesita de Hyper-v.

http://www.microsoft.com/windowsxp/Downloads/powertoys/Xppowertoys.mspx

Es fácil de instalar, luego accederemos desde Inicio, todos los programas, Powertoys for Windows y TweakUI. En el panel izquierdo elegiremos la categoría y en el derecho editamos la configuración a cambiar deseada.

——————————-

Taskbar y Start Menu

Grouping

La configuración de esta categoría, descrita en la tabla posterior, nos permite controlar como se agrupan los botones en la barra de tareas. Con el valor TaskbarGroupSize, que crearemos si no existe, determinamos las aplicaciones que Windows agrupa primero:

• Las menos utilizadas primero
• Las más utilizadas primero
• Cualquiera con al menos N ventanas abiertas.

En los tres casos es un valor REG_DWORD(tabla).

Menos usadas primero	TaskbarGroupSize	REG_DWORD	0x00	KKCUSoftwareMicrosoftWindows CurrentVersionExplorerAdvanced
Más usadas primero	TaskbarGroupSize	REG_DWORD	0x01	KKCUSoftwareMicrosoftWindows CurrentVersionExplorerAdvanced
Con N ventanas abiertas	TaskbarGroupSize	REG_DWORD	N	KKCUSoftwareMicrosoftWindows CurrentVersionExplorerAdvanced

Start Menu

Windows nos muestra los programas más utilizados en el menú de inicio. Esta característica nos impide tener localizadas por aplicaciones que usamos frecuentemente. Algunas aplicaciones no pertenecen a esta lista, sin embargo. Es cansado ver el bloc de notas aquí sólo porque hemos abierto un archivo de texto o el Command Prompt por haber escrito cmd en ejecutar como. La solución es decirle a Windows que no queremos añadirlas al menu de inicio. La llave es HKCUSoftwareClassesApplications, las aplicaciones que sí queremos mantener en el menú de inicio se añadirán en una sub-llave con el mismo nombre del nombre del archivo del programa(sin la ruta), dentro añadimos un valor REG_SZ de nombre NoStartPage y lo dejamos en blanco.

P.e.: Si no queremos que la calculadora aparezca, HKCUSoftwareClassesApplicationsNotepad.exeNoStartPage

Desktop

No mostrar ciertos iconos en el escritorio, esto se usaba en Windows98 porque salían todos por defecto, pero ahí está.

First Icon

Aquí se elige qué icono aparece el primero en el escritorio, My documents o My Computer.

My Computer

Determinamos los iconos que queremos ver en Mi PC.

Drives

Unidades a ocultar.

Special Folders

Carpetas especiales, como Mis imágenes, Mis Documentos,…

Autoplay

Toda acción de esta categoría se halla en las subcategorías siguientes. En Drives, impedimos qué unidades ejecuten automáticamente medios al insertarlos.

          Drives

         

En Types controlamos el autoplay para tipos específicos de medio. 

          Types

         

Y en la última, handlers: cuando Windows detecta que hemos insertado un CD, DVD o unidad removible, automáticamente ejecuta el programa asociado con el tipo de contenido de ese disco; en esta categoría tenemos una lista para controlar que programas se están usando con esos distintos tipos de contenido.

          Handlers

         

Drive Letters

Esta categoría nos permite configurar como el explorador de Windows muestra las letras de unidad en relación con su etiqeuta de Volumen.

– Mostrar después de la etiqueta.

– Mostrar antes de la etiqueta.

– Mostrar las unidades de red antes de la etiqueta y las locales después de la etiqueta.

– Nunca se muestran las letras de unidad.

Control Panel

Mostrar u ocultar iconos del Panel de Control específicos.

Templates

Personalizar las plantillas que veremos cuando hagamos clic derecho sobre el escritorio o espacio sin usar de una ventana de carpeta y pulsamos NUEVO.

Internet Explorer

Las dos configuraciones que se ven en la categoría de IE: Autocorrect Backslashes to Slashes e Include Path Search in address bar están en la llave HCUSoftwareMicrosoftWindowsCurrentVersionExplorerBandAddress, valores AutoCorrect y PATH (ambos REG_DWORD).

Tool Background

Configuración que TweakUI establece al personalizar IE y Windows Explorer con una imagen bitmap.

KCUSoftwareMicrosoftInternet ExplorerToolbar

Fondo personalizado para la barra de IE	BackBitmapIE5	REG_SZ	archivo
Fondo personalizado para la barra de Windows Explorer	BackBitmapShell	REG_SZ	archivo

Search

Aquí podemos añadir URLs de búsqueda a IE para usarlas desde la barra de direcciones del navegador.

Por ejemplo:

Añadimos CycleOps news

 

Si abrimos el IE y en la barra de direcciones escribimos directamente Cycleops News, se abrirá el buscardor con dichas palabras de búsqueda y sus resultados.

View source

Cambio del programa con que IE mostrará el código fuente de la página web.

Small Animation

Este icono es el que vemos en la esquina derecha y arriba de la barra de IE. El icono es animado cuando el IE está ocupado y estático cuando finaliza su carga. Aquí podemos personalizar esta animación.

Large Animation

Este icono es la versión en grande del anterior.

Image Toolbar

 

Command Prompt

Configuración para la ventana de prompt.

Logon

Autologon

Útil para habilitar automáticamente el inicio de sesión, si es que es útil…

Settings

Permite copiar la configuración actual de escritorio al perfil de usuario actual.

Screen Saver

Salvapantallas

Access Control

Control de Acceso.

Repair

Pequeñas reparaciones que eran interesantes en XP o anteriores.

—

Está claro que cada versión de Windows Server ha ido dotándonos de características y funcionalidades para la administración día a día de la red. Y como no podía ser de otra manera, hemos llegado a nuestro amigo 2008 R2. Si he de destacar algunas de las posibilidades que tenemos con este sistema, yo lo haría con Hyper-v, aunque la verdad es que hay otras por enmedio.

¿Un nuevo servidor? ¿Actualizar uno que ya tenemos? ¿Migrar servicios?

Hemos de tener las ideas claras para llevarlas a cabo.

2008 R2 Hardware

Como sus antecesores este sistema ofrece ciertas funciones (a partir de ahora y en favor de una descripción única los llamaré ROLES) y diversas versiones del sistema operativo en sí. Hay una gran distinción en este caso: sólo existen versiones de 64-bits, lo cual significa que nuestro primer paso es asegurarnos del hardware que tenemos y su completa compatibilidad con esto. Como más de uno habrá pensado, esto afecta directamente a una actualización o migración no tanto a un nuevo servidor.

En principio la propia MS marca unos mínimos, mejor si los superáis con creces, que luego todo se queda corto.

Hemos de ser conscientes de la importancia de los requerimientos. La cantidad de memoria que podemos tener en el servidor depende de la elección de la versión, si es Enterprise o Datacenter podemos tener hasta 2TB, mientras en el resto están limitado a 32GB, con la salvedad de que si tenemos más de 16GB necesitaremos un espacio en disco mayor para diversas funciones del sistema como el paginamiento p.e. De la versión también depende la cantidad de núcleos del procesador soportados, en las versiones web y estándar son 4, en la Enterprise hasta 8 y la Datacenter hasta 64, sin contar con las versiones Itanium.

Los mínimos sólo indican que el sistema se instalará y ¿arrancara?, bueno sí… pero que funcionalidad tendremos???

En un hipotético caso de que nuestro deseo sea usar Hyper-v y teniendo en cuenta los cálculos que hagamos de qué vamos a virtualizar, hemos de asegurarnos de disponer de suficientes núcleos de procesador y de memoria RAM para el anfitrión y de las máquinas que hemos de virtualizar.

2008 R2 Versiones y ROLES

Las versiones son las mismas que Windows Server 2008, Datacenter, Enterprise, Standard, Itanium y Web, con la salvedad que se incorpora el nuevo Hyper-v menos en Web y ya no hay versiones sin Hyper-v.

Podemos ver comparaciones por Características por Roles u otras, accediendo a http://www.microsoft.com/windowsserver2008/es/xl/r2-editions.aspx

Cuando tengamos claro lo que deseamos hacer elegimos nuestra versión.

Roles

Dependiendo de la versión de 2008 R2 elegida, estarán disponibles o no los Roles:

• Edición Web: Diseñado para se un servidor web únicamente, los roles disponibles son DNS y Web Server. Además de la limitación de 4 procesadores y 32GB de memoria RAM.
• Edición Standard: Todos los roles de la tabla a excepción de servicios de federación AD. Limitaciones a los roles de servicios de certificados, servicios de archivo, NAP y servicios de escritorio remoto. También está limitado a 4 procesadores y 32GB de RAM.
• Edición Enterprise: Todos los roles de la tabla. Limitado a 8 procesadores y 2TB de RAM.
• Edición Datacenter: Igual que la Enterprise, pero hasta 64 procesadores y 2TB de RAM.

Server Core

Hay una instalación opcional, Server Core, qué como en Windows Server 2008 es una versión racionalizada del Windows Server. Tiene funcionalidad limitada y ejecuta un subconjunto de los roles de Windows Server R2, no tiene interfaz gráfico, lo que significa que la administración ha de ser remota o via comandos desde el prompt, y aunque pueda pensarse lo contrario no quiere decir que no tenga su utilidad dentro de una red. Puede proporcionarnos funciones sin la carga de trabajo de un servidor tradicional y con riesgos inferiores de seguridad, además de necesidades de parcheado menores para mantenerlo al día.

Los roles son 9:

• DNS
• DHCP
• AD DS
• AD LS
• Servicios de archivo
• Servicios de impresión
• IIS
• AD CS
• Hyper-v

Y las características aumentadas en la versión R2:

• Un subconjunto de .NET framework, versiones 2.0, 3.0 y 3.5.
• PowerShell
• ASP.NET
• WoW64, necesario para AD y AD LS.

Licencias?

Al instalar 2008 R2 en nuestro entorno hemos de tener en cuenta el licenciamiento. En general no ha cambiado desde Windows Server 2008, y cada R2 requiere dos tipos de licencia: Una licencia de servicor para ejecutar el sistema operativo y una licencia de acceso de cliente (CAL) que permita a los clientes acceder al servidor. Las CAL se dividen en dos a su vez: CAL por dispositivo –Un dispositivo por cualquier usuario, CAL por usuario –Un usuario desde cualquier dispositivo. Todas las CAL de Windows Server 2008 que tengamos nos sirven también para 2008 R2.

En cuanto a la parte de virtualización conviene quizás saber qué: Sí sólo utilizamos 2008 R2 para virtualizar servidores éstos no necesitan CAL para el sistema host pero sí las los sistemas anfitriones que se ejecuten; aunque hay un beneficio potencial si usamos Hyper-v en un 2008 R2 y es que dependiendo de la versión elegida puede que no necesitemos comprar licencias para las instancias virtualizadas de 2008 R2: Standard = 1 instancia virtualizada bajo la misma licencia, Enterprise = hasta 4 instancias virtualizadas y Datacenter/Itanium = sin limitación de instancias virtualizadas.