Uno de los blogs de Juansa

Copia de seguridad y restauración II

Habilitar las instantáneas

Las instantáneas nos ayudan a proteger los datos de recursos compartidos y Unidades de nuestro Windows Server 2008 R2. Las instantáneas son copias de seguridad en un instante temporal. Se encuentran habilitadas a nivel de volumen. Lo que significa que cuando las activamos en un volumen se protegen todos los recursos compartidos residentes en el mismo. Y aunque no podemos seleccionar recursos de manera individual, sí seremos capaces de recuperar información individualmente si fuese necesario ya qué el volumen está protegido.

Cuando se crea una instantánea de un archivo sólo se almacenan los cambios incrementales. Así que el espacio de almacenamiento necesario en la red está basado en cuántos archivos y la cantidad de cambios que se les hace. Las copias creadas se almacenan en el mismo volumen en la que están los datos. Podemos mover las instantáneas a otro volumen para ayudar en el rendimiento de las mismas y de los propios vólumenes. Antes de habilitar las instantáneas, debemos también tener en cuenta qué sólo podemos tener 64 copias en el volumen al mismo tiempo. Esto tendrá un impacto en la programación que se escoga como adecuada, que es de lunes a viernes y entre las 7 y las 12 de forma predeterminada. Las instantáneas se ejecutan por el VSS (Volume Shadow Copy Service). En cuanto las habilitamos se crea un espacio de 100MB de copia de seguridad de forma automática. Además, el máximo tamaño por defecto usado por las copias se establece en un 10% del total del espacio del volumen. Lo cual significa que si nos acercamos al límite de espacio el VSS comenzará el borrado de versiones anteriores de las instantáneas.

Permitiendo a tus usuarios trabajar rápidamente con estos vólumenes te ahorrará tener que usar medios de recuperación para restaurar datos perdidos. Sin embargo, las instantáneas no son un sustituto de una implementación de copia de seguridad y recuperación necesaria, sino más bien un complemento útil.

Para habilitar las instantáneas:

• Herramientas administrativas
• Administración de equipos

• Clic derecho en las carpetas compartidas y en Todas las tareas, configurar Instantáneas.

Copia de seguridad y Restauración.

Los accidentes ocurren. Hay multitud de escenarios en los que los datos se pueden perder, borrar, infectar o corromper, ya sea porque un usuario borre accidentalmente un archivo del disco, falle un disco duro o falle el propio sistema operativo. También podemos pensar que la naturaleza a veces nos aguarda con tristes desastres.

Ha llegado la hora de saber cómo resguardar esos datos y poder recuperarlos posteriormente.

Entender la terminología: Copia de seguridad y Recuperación.

Al trabajar con estas tecnologías en Windows Server 2008 R2 ® o en un entorno Windows, necesitamos aprender el argot utilizado por el propio Sistema.

Copia de seguridad normal o completa: Las copias de seguridad normales o completas son las más lentas en terminar el proceso de copia. El tiempo vendrá determinado por la cantidad de datos. Aunque, si podemos hacerla cada noche y fuera de horario de trabajo sería el camino ideal para la protección del sistema. Es la opción predeterminada de Windows Server Backup.

Copia de seguridad incremental: Las copias de seguridad incrementales son las más rápidas en realizar el proceso de copia, ya que éste tipo sigue sólo los cambios en los datos desde la última copia, de cualquier tipo. Este tipo determina también el cómo trabajará tú proceso de recuperación. Cuando quieras recuperar datos, primero necesitarás restaurar la última copia de seguridad normal, seguida de todas las copias incrementales en orden. Este método produce también un impacto en el rendimiento de los servidores.

Estado del sistema: Estado del sistema contiene la mayor parte de la información de configuración del sistema. No toda la necesaria, así que debemos utilizarla junto a una copia de seguridad normal. Los Roles que estén instalados determinarán la copia del estado del sistema también.

Copia desde-cero (Bare-metal): Este tipo de copia nos permite recuperar un servidor desde una imagen creada previamente (y sin tener que instalar un sistema antes). Esto nos permite la recuperación de un servidor que de otra manera y debido a errores que una copia de seguridad normal no puede arreglar, sería inoperable. Digamos que esta recuperación es uno de los últimos cartuchos de recuperación de un sistema roto.

Instantáneas (Shadow copy): Una copia hecha en un momento concreto de datos que normalmente están compartidos. Proporciona a los usuarios un método self-service de recuperación de archivos que hayan sido borrados o sobreescritos accidentalmente.

Servicio de instantáneas de volumen (VSS): Servicio maestro dentro de Windows Server 2008 R2 que dirige la mayor parte de la infraestructura de copias de seguridad. Proporciona la capacidad de crear instantáneas.

Las herramientas

Tres son las que nos permiten acceder al juego de aplicaciones de copia de seguridad y recuperación en Windows Server 2008 R2®. Tenemos a Windows Server Backup, una herramienta totalmente funcional con interfaz a wbadmin.exe, una herramienta en símbolo del sistema, y finalmente nuestro querido PowerShell, con el que podemos llevar a cabo estas tareas.

Asegúremonos que tenemos las herramientas en nuestro servidor. De hecho la característica no está instalada de forma predeterminada, con lo cual si intentamos ejecutarla recibiremos un mensajito similar a:

Así que hemos de instalarla por nuestra cuenta.

Desde el administrador del servidor elegimos características, del panel agregar características.

Bajamos hasta Características de copias de seguridad de Windows Server.

Puede que al marcar cualquiera de las dos opciones se nos solicite agregar, pincharemos en el botón de Agregar características requeridas.

Pinchamos en siguiente y seguimos el asistente.

Ahora ya si tenemos la posibilidad de ejecutar la herramienta gráfica:

PowerShell y las GPO

Con Active Directory desplegado en nuestra entorno deberíamos ser capaces de controlar la seguridad, administración y el acceso a los recursos desde una ubicación centralizada. Y además administrar y controlar los escritorios!

Cómo hemos ido viendo en multitud de ocasiones, AD tiene una herramienta… Group Policy (Directiva de grupo), para centralizar los escritorios. Con ella podemos administrar virtualmente todo en los sistemas de nuestro entorno, desde el fondo del escritorio hasta qué aplicaciones pueden ejecutarse. Incluyendo no sólo los escritorios cliente sino también los servidores.

Directiva de grupo nos permite obligar el cumplimiento de nuestras políticas, implementar cualquier configuración de seguridad que queramos e, implementar un entorno estándar a través de todo el Directorio Activo.

Con un entorno estándar proporcionamos una base consistente y además aligerar las llamadas de soporte al departamento. Antes de ver como podemos trabajar con Poweshell y GP, repasemos algunas cuestiones básicas:

En cuanto a los ámbitos o alcance hemos de tener en cuenta qué:

El ámbito más grande es el SITE y aquí se ven afectados todos los dominios y objetos que contenga.

En el DOMINIO se verán afectados todos los objetos contenidos en él.

En las OU, todos los objetos que contengan, así como los sucesivos anidamientos de OUs y sus objetos.

El uso de unos u otros se determina por las necesidades, si bien hay algunas recomendaciones al efecto:

Configuración de seguridad de red o IPSec, a nivel de SITE.

Contraseñas y resto de valores de seguridad, DOMINIO.

Aplicación de Directivas de Grupo en las OU, es lo que más recomiendan, proporcionan facilidad de administración y localización de nuestras Directivas.

Administrar las Directivas de Grupo

Como otras herramientas, powershell ha dedicado un módulo para almacenar los cmdlets que podemos usar en la administración de Directivas de Grupo. Éste módulo no está disponible en todos los sistemas en los que Powershell está instalado. Sólo se encuentra en DCs, servidores miembros con GPMC instalada o Windows 7 con RSAT instaladas.

Para importar el módulo usamos el comando:

Import-Module grouppolicy

Aunque si lo intentamos en un equipo que no cumpla los requisitos recibiremos un mensajito…

Pero sigamos en uno que sí,

Una vez importado podemos listar los cmdlets disponibles, Get-Command –module grouppolicy 

El comando Get-GPO –All nos permite ver las GPO del dominio.

Ejemplos: Get-GPO –All

Podemos ver la configuración de una en particular, por ejemplo listamos las que hay en SySVol…

Y con su GUID…

Y con su nombre…

Carpetas: seguridad, acceso y replicación IV

Crear y configurar un DFS Namespace

Después de la instalación del role DFS podemos comenzar el proceso de creación del espacio de nombres DFS y configurar la raíz DFS.

1. Abrimos el administrador del servidor
2. Expandimos Roles
3. Expandimos servicios de archivo
4. Seleccionamos el elemento Administración DFS
5. Clic derecho, Nuevo espacio de nombres
   
6. Escribimos el nombre del servidor o lo buscamos mediante Examinar.
   
7. Siguiente
8. Le damos nombre al espacio de nombres. (es el que verán los usuarios)
   
9. Podemos editar la configuración, sino Siguiente
   
10. Ahora se nos pregunta el tipo de espacio de nombres, basado en dominio (que es el que voy a seguir haciendo) o independiente.
    
11. Un resumen de todo lo elegido antes de darle el sí final.
    
12. Creación del espacio de nombres.
    
13. Ahora ya tenemos la raíz DFS.
    
14. Desde aquí, con clic derecho sobre esta raíz añadiremos las carpetas y sus rutas correspondientes.
    

Carpetas: seguridad, acceso y replicación III

Si queremos colocar datos accesibles tenemos varias opciones, como las carpetas compartidas y usar archivos fuera de línea. Si además queremos extender la disponibilidad de nuestros archivos y carpetas, deberíamos considerar tener más de un servidor de almacene dichos datos de forma que se copien y repliquen entre ellos. Con ello ganamos en consistencia, disponibilidad y rapidez de acceso desde sitios remotos. La replicación se configura mediante espacios de nombres DFS o Sistema Distribuido de Ficheros. Estos ‘namespaces’ nos permiten agrupar carpetas compartidas diseminadas en distintos servidores y conectar de forma transparente mediante uno o más de estos espacios de nombres. Un namespace es una vista virtual de carpetas compartidas en una red. Cuando creamos un namespace, seleccionamos qué carpetas compartidas se añaden, diseñamos la jerarquía en la que aparecerán y, le ponemos los nombres con las que aparecerán en el namespace. Un usuario al acceder al namespace verá las carpetas  como si residieran en un único disco, y navegarán entre ellas sin necesitar conocer los nombres de servidor o carpetas de datos.

La ruta de un ‘namespace’ es similar a la convención UNC para carpetas compartidas, \servidor\recurso\carpeta.

Para tener un espacio de nombres necesitamos un servidor de espacios de nombres, y éste puede ser un servidor miembro o un controlador de dominio.

Para instalar DFS necesitaremos añadir el Role DFS.

1. Administrador del Servidor
2. Clic derecho en Roles, o en el Role Servicios de Archivos
3. Agregar Roles, o Agregar Servicios de Role
   
4. Servicios de archivos
5. Siguiente
6. Marcamos Sistema de archivos distribuido(se añadirán dos roles)
   
7. Siguiente
8. Crear un espacio de nombres más adelante con el complemento Administración de DFS.
   
9. Siguiente
10. Instalar
    
11. Cerrar
    

Como durante el proceso anterior no creamos un Namespace, sino que escogimos crear un Espacio de nombres más adelante, Lo siguiente será crear y configurar ese Espacio de Nombres DFS.

Carpetas: seguridad, acceso y replicación II

¿Asegurar carpetas y archivos?

Las carpetas y los archivos contienen datos, estos pueden no tener importancia o sí tenerla, lo que nos indicará que necesiten más o menos protección, y dentro de esta puede que queramos una protección extendida. En cada uno de los casos necesitaremos implementar una estrategia de seguridad distinta: permisos, almacenamiento, cifrado y auditoría. Como ya comentamos los permisos, veamos otras opciones.

EFS Cifrado del sistema de archivos.

El cifrado es una característica de Windows que podemos utilizar para cifrar archivos y carpetas en nuestro disco y proporcionar un formato de almacenamiento seguro.

EFS es el núcleo de la tecnología de cifrado usada en volúmenes NTFS(sólo). Un archivo cifrado no puede utilizarse a menos que el usuario tenga acceso a las claves necesarias para descifrarlo. Los archivos no tienen porque ser manualmente cifrados/descifrados cada vez que se usen. Se abrirán y cerrarán justo como cualquier otro archivo. Una vez habilitado EFS, el cifrado es transparente para el usuario.

El uso de EFS es similar a utilizar permisos NTFS sobre archivos y carpetas. Sin embargo, un usuario que tuviera acceso físico a archivos cifrados seguiría siendo incapaz de leerlos debido a su cifrado.

Podemos cifrar o descifrar archivos y carpetas configurando el atributo de la propiedad de cifrado para ese archivo o carpeta. La propiedad de cifrado es un atributo que se aplica como los de solo-lectura, comprimido u oculto en archivos y carpetas.

Así pues:

	Elegimos el archivo o carpeta, clic derecho, propiedades, botón avanzadas y marcamos el atributo de cifrado. Luego Aceptar.
	Ahora le damos a Aplicar.
	Se nos advierte para que cifremos la carpeta también para evitar copias sin cifrar.
	Luego podemos ir de nuevo a Propiedades, botón avanzado y tenemos el botón Detalles activo, si lo pulsamos…
	Nos muestra los detalles del archivo/carpeta. Aquí podemos agregar otros usuarios para que puedan acceder a ese archivo/carpeta cifrada, clic en Agregar.
	Podemos ver los certificados dándole al botón de Ver certificado.
	Pero nosotros elegimos el que pertenece al usuario a añadir y le damos a Aceptar.
	Ya tenemos activos los usuarios que podrán acceder al archivo/carpeta.

Es importante ver que los atributos de Compresión y de Cifrado son excluyentes, es decir, sólo podemos marcar uno al mismo tiempo.

Otras consideraciones a tener en cuenta cuando usamos EFS son:

- Sólo pueden cifrarse archivos y carpetas en volúmenes NTFS. Podemos usar WebDAV si queremos tranferir archivos y carpetas cifradas.

- Los archivos/carpetas cifrados se descifrarán si los movemos a un volumen que no sea NTFS.

- Si movemos archivos/carpetas dentro de una carpeta cifrada producirá el cifrado de lo movido; sin embargo esto no sucede al contrario, si movemos un archivo/carpeta cifrado desde una carpeta cifrada a otra no cifrada, no se descifrarán automáticamente, deben descifrarse explícitamente de forma manual.

- Los archivos marcados con el atributo de archivos de sistema y aquéllos residentes en el directorio raíz del sistema no se pueden cifrar con EFS.

- Marcar un archivo/carpeta con el atributo de cifrado no impide que un usuario con los permisos NTFS adecuados puede borrarlos, listarlos o listar directorios si estos permisos permiten dichas funciones. USA EFS y permisos NTFS equilibradamente.

- Podemos cifrar/descifrar archivos y carpetas de un equipo remoto en el que ha sido habilitado el cifrado remoto. Cuando lo hacemos, los datos son transmitidos por la red de forma NO-Cifrada, deben usarse protocolos como SSL o IPSec para cifrar el tráfico.

Podemos implementar EFS mediante GPO, por supuesto. Configuración de Equipo\Configuración de Windows\Configuración de Seguridad\Directivas de Clave Pública\Sistema de cifrado de archivos (EFS). Mediante esta configuración podemos elegir diversas opciones sobre EFS.

BITLOCKER

Como vimos anteriormente, EFS no cifra los archivos marcados como de sistema o que se encuentren el el directorio raíz del mismo. Entonces, ¿qué podemos hacer? La respuesta es Bitlocker. Diseñado para cifrar la partición en la que se encuentra el sistema operativo. A diferencia de EFS, que permite al usuario seleccionar y escoger archivos y carpetas para cifrar, Bitlocker cifra particiones y/o unidades enteras. Puede utilizarse para unidades conectadas localmente, mientras que Bitlocker To Go puede usarse para dispositivos como sticks USB que pueden conectarse de forma temporal. Si el dispositivo se conecta a otro sistema, los datos son inaccesibles. Bitlocker usa una parte hardware incorporada en la placa base llamado chip TPM. Y lo usa para dar las claves que se usarán para desbloquear la unidad cifrada del sistema. Cuando iniciamos el sistema, bitlocker solicita la clave al chip TPM y la usa para desbloquear la unidad.

Cuando usamos una unidad cifrada con bitlocker, si añadimos nuevos archivos éstos se cifran automáticamente. Las unidades (fijas o extraíbles) pueden desbloquearse con una contraseña o tarjeta inteligente, o establecer que se desbloquee automáticamente en cuanto iniciemos sesión en el equipo.

Puede usarse junto a EFS. Tened clara la estrategia para que el impacto sobre los usuarios y el acceso a los datos no se penalice.

Habilitar Bitlocker:

Lo primero es habilitar el chip TPM en la BIOS.

Ahora podemos ir al Administrador del servidor y habilitar bitlocker:

- Características, añadir características, seleccionamos Cifrado de unidad Bitlocker y Seguir, luego le damos a Instalar. Se nos pedirá que reiniciemos el equipo, una vez reiniciado cerramos la ventana del administrador del servidor.

- Desde el botón de inicio, escribir Bitlocker en la caja de búsqueda y pulsar INTRO.

Desde aquí podemos activar el bitlocker.

En todo esto hay que tener en cuenta que algo puede ir mal, ¿qué pasa si algo va mal en un servidor con Bitlocker? ¿qué pasa si las claves que contienen el modulo TPM son inaccesibles? ¿Si un usuario pierde su PIN? ¿qué pasa si el hardware falla y queremos salvar el disco duro? Afortunadamente hay un sistema de recuperación y el proceso depende de un componente muy importante, la CLAVE de recuperación. Cuando activamos Bitlocker se nos pregunta por una ubicación en la que almacenar la clave de recuperación de Bitlocker. Si tenemos acceso a dicha clave podremos recuperar la unidad cifrada. Simple y directa:

- Iniciamos el ordenador

- Se nos indicará que no se encuentran las claves para iniciar el descifrado, y una opción de recuperación.

- Escribimos los 48 dígitos de la clave de recuperación.

- Se descifrará la unidad y el sistema iniciará con normalidad.

Aquí debemos tomar medidas: deshabilitar Bitlocker y descifrar la unidad (más adelante podemos volver a activarlo y crear una nueva serie de claves) o restablecer la conectividad con la clave original si aún disponemos de ella.

Bitlocker To Go

Esta herramienta nos proporciona el cifrado de una partición pero en unidades removibles. En lugar de usar una herramienta de cifrado, podemos usar Bitlocker para cifrar el contenido de una unidad removible. Como vemos en la imagen anterior de Bitlocker para usar Bitlocker To Go sólo se necesita insertar una unidad extraíble.

Esta herramienta difiere un poco con la anterior: No se necesita el chip TPM para guardar las claves. Necesitarás elegir el cómo quieres desbloquear la unidad. Puede hacerse mediante una contraseña que aportarás durante la instalación o con una tarjeta inteligente y su PIN. Así como en Bitlocker, aquí también hay una clave de recuperación asociada, guardar este archivo cuidadosamente en un lugar donde no se pierda, o mejor aún, se imprime y se guarda en lugar seguro. Recuerda que si el dispositivo se vuelve inaccesible por cualquier razón, la clave de recuperación será el único medio para recuperar los datos.

La unidad se cifrará de la misma forma que se cifra la unidad del sistema, un poco más rápido si el tamaño del extraíble es más pequeño. Ya cifrado, en cuanto lo insertemos en cualquier equipo se nos pedirá la contraseña o la tarjeta/PIN. Los archivos que se copien o muevan a la unidad se cifrarán.

Una opción para tener archivos y carpetas almacenadas en una unidad extraíble de forma segura. Podemos usar además las GPO para forzar Bitlocker To Go para usar unidades extraíbles y que las claves de guarden en AD.

Carpetas: seguridad, acceso y replicación.

Estaremos de acuerdo en qué uno de los propósitos de una red de servidores es, controlar el acceso a los recursos que se comparten en élla. Estos recursos, como sabemos, pueden ser archivos, carpetas, páginas web, BD, impresoras, etc… El trabajo de los servidores es proporcionar acceso a todas estas ‘cosas’. Si no hay cosas no es necesaria ninguna seguridad ni protección, no necesitamos Windows Server.

Los permisos

Un sistema de archivos por definición es una estructura jerárquica de carpetas que alojan archivos, y los aseguran mediante series de Listas de Control de Acceso (ACLs) y Entradas de Control de Acceso (ACEs) que definen el tipo de permisos que se permiten o niegan a aquéllas carpetas y archivos. Así que el primer método para asegurar carpetas y sus archivos en un mundo Windows son los permisos.

Los permisos se encuentran en dos variedades: los permisos para compartir y los permisos NTFS. Cuando se crea una carpeta en el sistema de archivos, hay un conjunto de permisos predeterminados que se le asignan. SYSTEM (el propio sistema), el usuario qué la ha creado y el grupo local de administradores del servidor donde se creó, todos ellos necesitan algún tipo de acceso sobre la carpeta creada. En este caso, al crear una carpeta en la raíz del disco un 2008 R2(de ejemplo), quedan así:

Los permisos NTFS se asignan cuando se crea la carpeta, pero se pueden editar en cualquier momento por el usuario o miembro del grupo que tenga el permiso modificar sobre la carpeta.

A su vez, los permisos NTFS se dividen en dos tipos: permisos estándar y permisos especiales. Los primeros son exactamente, control total, modificar, lectura y ejecución, mostrar el contenido de la carpeta, lectura y escritura. Cada uno de ellos pueden permitirse o negarse. Ya que tenemos la opción de permitir o negar los permisos sobre una carpeta, en un sistema de archivos NTFS, disponemos de flexibilidad sobre el nivel de acceso a una carpeta predeterminada.

Como añadido a los permisos estándar, hay permisos especiales que también pueden establecerse en cada carpeta y/o archivo. Estos últimos hacen más que proporcionar acceso simple a la carpeta en la que se aplican, proporcionan la propiedad de la misma, así como la capacidad de cambiarle los permisos y la jerarquía que pueda existir por debajo de la misma.

Para configurar permisos NTFS hemos de seguir unos sencillos pasos:

- Clic derecho en la carpeta, seleccionar propiedades, seleccionar la pestaña Seguridad y pulsar el botón Editar.

A partir de aquí, podemos seleccionar un usuario/grupo existente de la lista de los que ya tienen permisos asignados o, también, añadir usuarios/grupos a los que queremos asignarles permisos sobre la carpeta. Estos usuarios/grupos pueden ser locales o pertenecientes al AD (si el equipo está en un dominio y no es un DC en el caso de usuarios locales porque no existen). Y eliminar usuarios/grupos de los que ya tienen permisos asignados.

Tengamos en cuenta una cosa importante, cualquiera no puede añadir, cambiar o eliminar permisos NTFS en una carpeta. Se necesita tener permisos sobre la carpeta para poder hacerlo. Los permisos para cambiar permisos o tomar la propiedad de la carpeta son permisos especiales.

Para establecer permisos especiales el camino es parecido:

Clic derecho en la carpeta y seleccionamos propiedades,

Seleccionamos la pestaña Seguridad y clic en el Botón Opciones Avanzadas

Ahora elegimos la pestaña Permisos y pulsaremos el botón Cambiar Permisos

En la ventana de configuración de permisos dispondremos de la posibilidad de añadir, editar y cambiar la herencia de los mismos.

Si lo que queremos es ver los permisos efectivos, en vez de elegir la pestaña Permisos, elegiremos la de Permisos efectivos.

Seleccionamos el grupo/usuario y le damos a aceptar.

Para tomar la propiedad de la carpeta, seleccionamos la pestaña Propietario y usamos el botón Editar.

Compartir

Para hacer que una carpeta y su contenido estén al alcance mediante la red:

1. Escogemos la carpeta
2. clic derecho y propiedades
3. pestaña Compartir
   
4. Aquí disponemos de dos opciones, un botón compartir y uno de Uso compartido Avanzado.
   1. Botón compartir
      
      1. Seleccionamos usuario/grupo
         
      2. Agregamos
         
      3. Seleccionamos los permisos
         
      4. le damos al botón compartir
         
   2. Uso compartido Avanzado
      
      1. Nos sirve tanto para compartir como para dejar de compartir (casilla compartir esta carpeta)
         
      2. Nombre del recurso, comentarios.
      3. Botón permisos, Agregamos usuarios/grupos y marcamos los permisos: sólo disponemos de tres.
         

El recurso finalmente compartido ya muestra en sus propiedades la ruta y que está compartido.

Permisos compartir vs permisos NTFS, la lucha...

¿Por qué digo lucha? Pues porque el cruce de ambos tipos de permisos siempre producen quebraderos de cabeza, por experiencia.

Conflictos. Eso es lo que tienen los permisos compartir y NTFS, conflictos, pero ¿cómo los resolvemos? En principio os comentaré algo básico a tener en cuenta:

a) Cuando marcamos NEGAR siempre es precedente sobre PERMITIR.

b) Si los permisos COMPARTIR y NTFS chocan, siempre se aplica el MÁS RESTRICTIVO!

¿Qué quiero decir con esto? Pues viendo unos ejemplos quizás…

Esto puede complicarse mucho si aplicamos permisos sobre usuarios/grupos, cuantos más usuarios y grupos más liado.

Yo normalmente utilizo un pequeño sistema, Aplico a COMPARTIR Control Total al grupo todos y me olvido de esta parte, desde aquí uso los NTFS sobre la carpeta y sólo me preocupo de estos. Así si veo que tiene Lectura y quiero que escriba, sólo modifico el correspondiente en la pestaña Seguridad. También podría hacerlo a la inversa, pero tendría menos granularidad.

En todo caso, me aseguro bien cuando aplico permisos diferentes en Compartir, es decir, si es un recurso que tengo claro que sólo debe leerse ni lo cambio, digan lo que digan los NTFS por la Red sólo podrá leerse.

¿Problemas con Directivas de Grupo?

Cuando se trabaja con Directivas de Grupo podemos tener algunos problemas en su aplicación, así qué hay que usar algunas herramientas para buscar solucionarlos y no perder nuestro tiempo de administración.

Las herramientas integradas se enfocan en predecir el cómo se aplican y el cómo buscar el resultado de esa aplicación. Group Policy Modeling Wizard (GPMW), Group Policy Results Wizard (GPRW), GPresult.exe, y el elemento de MMC: RSOP. Por último, estas herramientas nos permitirán ver el orden de precedencia en acción. Podemos ver qué directivas se aplicaron sobre el sistema y cuáles son las qué vencieron.

Además, ya que las directivas se basan en la red, todas las herramientas que utilizamos para comprobarla –desde el ping a la resolución de nombres- son válidas para solucionar problemas de directiva.

GPMW  Modelado de directivas de grupo

GPMW nos permite previsualizar nuestras directivas de grupo. La herramienta modela los resultados de las directivas antes de implementarlas. Esta herramienta construye informes basados en lo qué está configurado a nivel de sitios, dominios y OUs, tanto para equipos como para usuarios. Basado en las reglas de aplicación de directivas, la herramienta nos proporciona una instantánea de las directivas que se aplicarán. También nos muestra cómo afectará cualquier filtro WMI o de seguridad.

GPMW se encuentra en la consola GPMC. Es importante recalcar que GPMW evalúa sólo un RSOP teórico basado en todas las directivas y filtros establecidos vía Active Directory.

Para crear un modelado:

1. Clic derecho en Modelado de directivas de grupo, clic en Asistente para modelado de directivas de grupo.
   
2. Siguiente en la ventana de bienvenida.
   
3. Seleccionamos el Controlador de dominio que queremos utilizar para procesar la solicitud de modelado y siguiente.
   
4. Escoger que queremos modelar. Podemos elegir un usuario o equipo individual, o un ámbito (dominio u OU) para cualquiera de ellos (equipo o usuario). Una combinación de lo anterior. …
   
5. También podemos simular una red lenta o un bucle invertido en la página de diálogo de simulación.
   
6. Elegiremos la ruta de AD alternativo u otras ubicaciones a simular. (Esta página podría no mostrarse dependiendo de la elección en el paso 3)
7. Simular los cambios en el grupo de seguridad del usuario.
   
8. O, simular los cambios en el grupo de seguridad del equipo.
   
9. Los filtros para usuarios.
   
10. Los filtros para equipo.
    
11. Vemos un resumen y siguiente para la creación del modelado.
    
12. Pulsamos en finalizar y obtenemos el informe, aparece bajo el nodo de modelado de directivas de grupo.
    

El informe queda bajo el nodo de Modelado.

GPRW o Asistente de Resultados de Directivas de Grupo

Hay algunas herramientas que nos permiten obtener el RSOP. Una de ellas se encuentra en la consola, GPMC, el asistente de Resultados de directiva de grupo.

Una vez localizada en el árbol de la izquierda:

1. Clic derecho y seleccionamos Asistente de resultado de directivas de grupo.
   
2. Siguiente en la ventana de bienvenida.
   
3. Seleccionamos el equipo, local o remoto. Siguiente.
   
4. Seleccionamos la cuenta de usuario para el que queremos el RSOP, Siguiente.
   
5. Ventana resumen, siguiente.
   
6. Pulsamos en finalizar para volver a GPMC y ver el informe.
   

GPResult.exe

Herramienta desde él símbolo del sistema, nos permite ver los resultados de directiva de grupo tanto para el sistema local y usuario actual, como equipos remotos y otros usuarios. Como otros comandos, dispone de commutadores y parámetros que proporcionan información adicional. Pueden entubarse los resultados hacia un archivo de texto y utilizar el comando en archivos de lotes y/o scripts.

RSOP, elemento de MMC, conjunto resultante de directivas.

Sólo hemos de abrir la MMC y añadirlo. También podemos iniciarlo desde el elemento Usuarios y equipos de ACtive Directory.

Esta herramienta es similar al asistente de resultados de directiva, pero con la ventaja de que puede mostrar los resultados de múltiples directivas. Disponible en dos modos, Planning i Logging modes. La diferencia principal entre ellos es el cómo proporcionamos el RSOP. Planning mode es similar a GPMW, simula el proceso de directivas, mientras Logging mode consulta la BD WMI de un equipo específico, que se reune cuando se aplica la directiva. Podemos ver información del usuario con esta herramienta sólo si el usuario ha iniciado sesión en el sistema. Además, veremos sólo aquéllas directivas que se hayan procesado en el sistema.

Ambos modos tienen ventajas. La principal de Planning es la generación de informes basados en los valores que serán procesados antes de serlo. Permite la simulación de comportamientos y solucionar problemas antes de aplicar las directivas en producción. En cuanto a Logging, la principal ventaja es la exactitud, ya que el informe está basado en lo qué realmente se ha procesado.

Automatizando tareas administrativas: Copia de seguridad de las GPO del dominio

Tener una copia de seguridad de las Directivas de Grupo nos vendrá bien en algunos casos. Para realizar dicha copia podemos acceder simplemente a la Consola de administración de Directivas y hacer unos pocos pasos:

1. Clic derecho en los objetos de Directiva de Grupo y clic en hacer copia de seguridad de todos
   
2. Indicamos la ruta y la descripción, y se realiza la copia de seguridad.
   
3. 
4. 
5. 

Aunque también podemos hacerlo con Powershell, por ejemplo desde El script-center tenemos un script para copiar las Directivas de Grupo modificadas en el mes.

http://blogs.technet.com/b/grouppolicy/archive/2009/03/26/powershell-script-backup-all-gpos-that-have-been-modified-this-month.aspx

El código es prácticamente el mismo, pero he traducido las cadenas y añadido import-ActiveDirectory para que pueda usar los cmdlets de AD, y cambiado la sentencia que recoge las GPO para que hiciera el backup de todas en lugar de las modificadas.

 1 # El siguiente script busca todas las Directivas de Grupo en el dominio que hayan sido modificadas este mes. Entonces genera una copia de seguridad y un informe de configuración por cada una. Finalmente lista todas las que se han copiado. 
 2 ## depende de si se accede por el acceso a la consola powershell de AD o se ha navegado hacia allí primero 
 3 
 4 # necesario para usar los cmdlets de directiva de grupo y Active Directory 
 5 import-module ActiveDirectory
 6 import-module grouppolicy 
 7 
 8 #Sacar todas las directivas de grupo enlazadas en el dominio del equipo local 
 9 #el primer paso es obtener el objeto dominio 
10 # intro "get-ADDomain -?" para la ayuda 
11 
12 $mydomain = get-ADDomain -current LocalComputer 
13 
14 # el siguiente paso es obtener todas las directivas de grupo actualmente en el dominio que hayan sido modificadas este mes 
15 
16 $currentDate = get-Date 
17 
18 # $ModGPOs = get-gpo -domain $mydomain.DNSRoot -all | where {$_.ModificationTime.Year.equals($currentDate.Year) -And $_.ModificationTime.Month.equals($CurrentDate.Month)} 
19 
20 $ModGPOs = get-gpo -domain $mydomain.DNSRoot -all
21 
22 # bucle de las directivas de grupo 
23 
24 $RootPath = "C:\GPOBackup\Reports\" 
25 
26 Foreach ($GPO in $ModGPOs) { 
27     # Copia de seguridad de la directiva en la ruta especificada 
28     $GPOBackup = backup-GPO $GPO.DisplayName -path "C:\GPOBackup" 
29 
30     # Primero crea la ruta del informe, luego lo genera con la configuración guardada. 
31     $ReportPath = $RootPath + $GPO.ModificationTime.Month + "-"+ $GPO.ModificationTime.Day + "-" + $GPO.ModificationTime.Year + "_" +  $GPO.Displayname + "_" + $GPOBackup.Id + ".html" 
32     get-GPOReport -Name $GPO.DisplayName -path $ReportPath -ReportType HTML 
33 } 
34 
35 # Salida de cuales directivas de grupo se han guardado correctamente. 
36 
37 "Las siguientes " + $ModGPOs.count + " Directivas de Grupo se han guardado correctamente:" | out-host 
38 
39 Foreach ($GPO in $ModGPOs) { 
40     "          " + $GPO.DisplayName | out-host 
41 } 
42 
43 "Ir a " + $RootPath + " para ver los informes de configuración de las Directivas de Grupo guardadas." | out-host
44 

Directivas y Preferencias

Si leemos GPMC, herramienta principal de creación de Directivas.

Una GPO es un objeto que contiene la configuración de valores que queremos aplicar a usuarios y/o equipos. En español, Directiva de Grupo.

Un Link de Directiva de Grupo es lo que enlaza la directiva a la parte del entorno de AD donde queremos aplicarla. Referido a su ámbito, en el que hay tres niveles donde las aplicamos: Sitios, dominios y OUs.

El Editor de Directivas de grupo es la herramienta que se utiliza para modificar los valores de las directivas, y los valores disponibles se basan en las plantillas administrativas disponibles y cargadas.

Los archivos ADMX tienen dos propósitos. El primero es definir los valores y la ubicación de configuración (en el equipo local) para aquéllos. La segunda es crear el interfaz que usamos para las modificaciones desde el Editor.

Las PREFERENCIAS proporcionan una alternativa para trabajar con imágenes en toda la organización y administrar valores que no se han configurado antes en una GPO. Inicialmente esta configuración establecida por el administrador del sistema refleja un estado predeterminado del sistema operativo y, estos valores no son obligatorios necesariamente.

Cuando hablamos de RSOP nos referimos al conjunto resultante de configuración de Directivas de Grupo aplicadas al finalizar completamente su proceso. Podría ser una combinación de varios niveles de Directivas.

Directivas vs Preferencias

Dos son las formas de configurar sistemas, las Directivas y las Preferencias. Ambas pueden modificar los objetos equipo y usuario, sin embargo la razón de su uso es muy diferente. La más importancia su obligatoriedad, las Directivas lo son, mientras que las Preferencias no lo son estrictamente.

Directivas:

Los valores e interfaz se basan en plantillas administrativas. Realizan cambios en el Registro según las indicaciones de la plantilla. Hay secciones especiales de las ramas del Registro que se controlan mediante Directivas, conocidas como las verdaderas. En caso de valores de Equipo:

• HKEY_LOCAL_MACHINE\SOFTWARE\policies
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

y para el Usuario:

• HKEY_CURRENT_USER\SOFTWARE\policies
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\policies

Cada vez que el sistema procesa una Directiva y obtiene el RSOP, estas ramas del Registro (claves y valores) son borrados y reescritos con la nueva RSOP. Esto pasa sólo en la medida que una Directiva de grupo válida se sigue aplicando al equipo o usuario.

Finalmente, podemos crear nuestros propios valores de Directiva modificando una de las plantillas administrativas existentes o creando una nueva. Esto nos permite trabajar con el Registro completo (exceptúando las ramas mencionadas antes). Sin embargo, es muy importante advertir que estos valores tatuarán el Registro. En otras palabras, los valores quedarán establecidos permanentemente hasta que específicamente los revertamos en la Directiva. Esto significa que si eliminamos nuestra Directiva, este tipo de valores no desaparecen y debemos revertirlos a mano.

Preferencias:

Introducidas desde MS Windows 2008, nos proporcionan una alternativa al uso de scripts para realizar tareas comunes. Estas tareas, en todo caso, no eran fáciles de hacer en las Directivas. Las preferencias nos permiten ahora modificar valores del Registro Local, grupos y usuarios locales, archivos y carpetas, impresoras, servicios locales, unidades de red, y otros muchos valores locales. Ya que las Preferencias no son obligatorias, los usuarios pueden realizar cambios. Además, son de utilidad para aplicaciones a las que las Directivas no cuenta y valores del sistema. Sin embargo, siempre que un usuario decide cambiar algo, lo más probable es que no disponga del permiso necesario para hacerlo ya que la mayoría de las Preferencias requieren algún tipo de credenciales administrativas.

También podemos aplicar elementos de preferencias individuales mediante el filtrado de Directivas, aunque de forma distinta a las Directivas verdaderas, ya que en las segundas no podemos individualizar valores dentro de la Directiva.

En Windows Server 2008 R2, la edición de Preferencias se ha mejorado.

Veamoslo con un ejemplo:

Hasta ahora, yo mismo usaba un script de vbs para asignar unidades de red e impresoras a los usuarios, por ejemplo -

Dim oNet
Set oNet = CreateObject("WScript.Network")
ONet.MapNetworkDrive "Z:", "\\SRVDOMpruebas\compartido"
Set WshNetwork = CreateObject("WScript.Network")
PrinterPath = "\\SRVDOMpruebas\hpbusiness"
PrinterDriver = "HP BUSINESS injeck 1000"
WshNetwork.AddWindowsPrinterConnection PrinterPath, PrinterDriver
WshNetwork.SetDefaultPrinter "\\SRVDOMpruebas\hpbusiness"

Una unidad mapeada como Z que apunta al recurso ‘compartido’ y una impresora instalada en SRVDOMpruebas denominada hpbusiness, que ademas se establecía como predeterminada.

Bien, ahora esto podemos hacerlo con una GPP , es decir, Group Policy Preferences o Preferencias de Directiva de Grupo.

Crear una GPP es como crear una GPO, abrimos la consola de Administración de Directivas y vamos con el ejemplo.

1. Seleccionamos Objetos de Directiva de Grupo, clic derecho y NUEVA, le damos un nombre descriptivo y dejamos el origen como sale.
   
2. Clic derecho en la nueva directiva y Editar.
   
3. Unidad de red:
   
   1. En el editor escogemos la ruta, Configuración de Usuario|Preferencias|Configuración de Windows|Unidades de red, clic derecho, Nueva Unidad y seguimos el asistente.
      
   2. El valor de Acción es lo más importante, cuatro posibilidades:
      1. Crear. La preferencia se configurará si la configuración no existe, por el contrario si ya existe, no se realizará ninguna acción.
      2. Reemplazar. Se elimina y se recrea de nuevo la configuración.
      3. Actualizar. La más poderosa, con ella lo hacemos todo, lo crea si no existe y si existe la actualiza.
      4. Eliminar. Se quita la configuración.
      
   3. Realizada la configuración como queda en la imagen, seguimos con el siguiente paso, configurar a qué usuarios les afectará la preferencia. (En este caso, esta es una de las dos configuraciones que residirán en la misma GPO que se enlazará a los usuarios de una OU, la otra es la impresora.) Para elegir los destinatarios de la OU receptora que pertenecerán al grupo ‘pruebas’.
      1. Pestaña ‘Comunes’.
         
      2. Marcar la casilla ‘Destinatarios de nivel de elemento’.
      3. Pulsar el botón ‘Destinatarios’.
   4. Aquí tenemos el Editor de Destinatarios, vamos a individualizar, en este caso usuarios pero podríamos hacerlo con equipos también.
      
      1. En este caso los destinatarios son los usuarios del grupo pruebas, Nuevo elemento, grupo de seguridad.
         
      2. Pulsamos en el botón y elegimos el grupo.
         
      3. Aceptar para finalizar la configuración.
         

Aquí ya tenemos la UNIDAD DE RED en Z:\, equivalente a la primera parte del script de ejemplo.

Para añadir la impresora realizaremos los mismos pasos, pero esta vez elegiremos Impresora compartida.

Y también escogeremos los destinatarios, en este caso por rango de IP.

Juansa©2011

PowerSE Professional, editor scripts powershell free.

Conocida herramienta de edición de scripts de PowerShell de Devfarm Software, Al parecer PowerSE está disponible gratuitamente ahora. PowerSE está diseñada para administradores, con el ánimo de ayudarles en las tareas diarias. PowerSE dispone de todas las características de los editores de gama alta, como remarcar con colores la sintáxis, Intellisense, y tabulación completa, pero lo que lo hace especial es la conjunción perfecta de editor y consola de comandos de PowerShell.

2008 R2: Automatizando tareas administrativas: Powershell(5)

Copiar y guardar los eventos, y al tiempo limpiar el registro.

Hay que descargarse la extensión Pscx-2.0.0.1.zip desde http://pscx.codeplex.com, y extraerla en el directorio de modulos del usuario: 'Mis Documentos\WindowsPowerShell\Modules', o en el directorio de modulos de PS, valor que devuelve la variable $PSHome desde el ISE, en mi caso:

El Script en castellano (más o menos).

<#

   .Sipnosis

    Este script guarda los log de Eventos

   .Descripción

    Se puede ejecutar de forma periódica (regularmente) para el archivo o copia de los log de eventos

    NB, este script los guarda y limpia el registro de eventos, no solamente hace una copia de seguridad.

    El script se ha diseñado con el ánimo de investigar y auditar los log de seguridad.

    De hecho copia los log en memoria, y luego los borra, y entonces los guarda en archivos csv, 

    por ello se recomienda ejecutarlo de forma local o vía PS en remoto.

   .Ejemplo

    .\Inicia-copiasegEventLogs.ps1

   .Entradas

    Ninguna

   .Salidas

    Ninguna

   .Notas

    Nombre: Inicia-copiasegEventLogs.ps1

    AUTHOR: Benjamin R Wilkinson

    TRADUCCIÓN y ADAPTACIÓN CASTELLANO: Juansa

    DESARROLLADO: Mediante Windows PowerShell ISE.

    VERSIÓN: 1.0.0

    ULTIMA EDICIÓN: 20/07/2010

    CLAVES: 

   .Link

#>

#Se requiere -Versión 2.0

[CmdletBinding()]

 Param 

   (

    [Parameter(Mandatory=$false,

               ValueFromPipeline=$true,

               ValueFromPipelineByPropertyName=$true)]

    [String]

    $computer = "$ENV:COMPUTERNAME",            

    [ValidateSet("Application", "Security", "System")]

    [Alias("l","log")]

    [String]

    $LogName = "Security",

    #$MinBackupSize = "209715200", # 200MB

    #$MinBackupSize = "204472320", # 195MB

    $MinBackupSize = "1024", # 1MB

    [String]$BackupLocal = "D:\COPIALOGS",

    #[String]$Backupremote = "D:\COPIALOGS"

    #[String]$Backupremote = "\\ADTEST04\logs\seclogs"

    [String]$Backupremote = "\\srvpl01\COPIALOGS"

   )#End Param

Begin

{

 # El cmdlet para exportar a zip es de: http://pscx.codeplex.com/

 Import-Module PSCX

 Write-Host "Procesando $Logname Logs .. .. Server:"$computer (get-date)

}

Process

{

    $BaseDirLocal = "$BackupLocal\{0:yyyy_MM}-Logs" -f [DateTime]::now

    $LogFileName = "{0}-{1:yyyyMMdd_HHmm}-{2}.csv" -f $Computer,[DateTime]::now,$LogName

    $PathLocal = Join-Path -Path $BaseDirLocal -ChildPath $LogFileName

    Write-Host "  + Procesando $LogName Log"

    Write-Host "    - Leyendo $LogName Log"

    $Query = "Select * from Win32_NTEventLogFile where LogfileName = '$LogName'"

    if ((Get-WmiObject -Query $Query -ComputerName "localhost").FileSize -gt $MinBackupSize)

       {

        #Guarda los log a un Objeto de PS en memoria

        $SecLogs = get-eventlog -LogName $LogName

        #Limpia los log de eventos

        Write-Host "    - Limpiando $LogName Log"

        Clear-EventLog -LogName $LogName

        # Se asegura que existe el directorio local

        If(!(Test-Path $BaseDirLocal))

        {

          New-Item $BaseDirLocal -type Directory -force | out-Null

        }

        Write-Host "    - Exportando a CSV"

        # Exporta desde la memoria a CSV 

        $SecLogs | ForEach-Object {$RString = $_.ReplacementStrings | ForEach-Object {$_}

        $Hash = @{             

        EventID       =$_.EventID

        MachineName   =$_.MachineName

        Category      =$_.Category

        CategoryNumber=$_.CategoryNumber

        EntryType     =$_.EntryType

        ReplStrings   ="$RString"

        TimeGenerated =$_.TimeGenerated

        UserName      =$_.UserName}

        New-Object PSObject -Property $Hash

        } | Export-Csv -Path $PathLocal -NoTypeInformation

        Write-Host "    - exportación a CSV completada"

        # Empaquetar en Zip

        Write-Host "    - Empaquetando Zip"

        $ZipLogArchiveFile = Get-ChildItem $PathLocal | write-zip -level 9

        if (Test-Path -Path $ZipLogArchiveFile)

        {

         Remove-Item -Path $PathLocal

        }

        # Copia los Log/CSV a carpeta compartida

        $BaseDirRemote = "$Backupremote\{0:yyyy_MM}-Logs" -f [DateTime]::now

        If(!(Test-Path -Path $BaseDirRemote))

        {

          New-Item $BaseDirRemote -type Directory -force | out-Null

        }

        # Elimina el archivo anterior

        If(Test-Path -Path $BaseDirLocal)

        {

          # Mueve todos los archivos desde el directorio local y lo limpia

          Write-Host "    - Archivando en Zip:"$ZipLogArchiveFile.Name

          Move-Item "$BaseDirLocal\*.zip" -Destination $BaseDirRemote -Force

          Remove-Item -Path $BaseDirLocal

        }

       }

    else

       {

        $Skip = $True

       }    

}

End

{

 if (!$Skip)

    {

     $Msg = "Proceso de $LogName log completado, hay {0} logs exportados." -f $SecLogs.count

     $Msg2 = "Logs guardados a {0}\{1}" -f $BaseDirRemote, $ZipLogArchiveFile.Name

     Write-Host $Msg

     Write-Host $Msg2

     (get-date)

    }

 else

    {

     Write-Host "El tamaño de los Log es menor de $($MinBackupSize/1MB) MB, no se realizan cambios" 

    }

$Skip = $Null

}

Este scrip nos sirve para vaciar los logs. En el ejemplo lo hace con el de seguridad, pero podemos cambiar el valor de la variable $LogName a Application o System.

Por supuesto hay otras variables a explicar:

$LogName Security, Application o Security

$MinBackupSize Tamaño mínimo del registro de Seguridad, Aplicación o Sistema para realizar la copia, guardado y limpieza.

$BackupLocal Directorio local donde se vuelca la info a archivos CSV que serán empaquetados en zip y eliminados de dicho directorio (temporal)

$BackupRemote Directorio donde se guarda el zip empaquetado con el CSV.

2008R2: Automatizando tareas administrativas: powershell(4)

Variables, Alias, Ámbitos, perfiles y seguridad.

Variables en powershell

Una variable en un lugar de almacenamiento de datos. En muchos shells los únicos datos que pueden almacenarse en una variable son de tipo texto. En shells avanzados y lenguajes de programación, estos datos pueden ser de cualquier tipo, desde cadenas de texto a secuencias de objetos. Powershell es de los segundos, puede almacenar cualquier tipo.

Para definir una variable en powershell debemos nombrarla con el signo dolar $ como prefijo que nos ayuda a definir variables de álias, cmdlets, archivos y otros elementos que el usuario del shell quiera utilizar. El nombre de una variable puede contener cualquier combinación de carácteres alfanuméricos (a-z, 0-9) y el subrayado (_). Aunque no hay establecida una nomenclatura en los nombres de variables en powershell, no deja de ser interesante utilizar un nombre que refleje el tipo de datos que contiene la variable.

En el ejemplo he usado el ISE, he definido una variable $Detenido cuyo contenido es una colección de servicios donde su estado es Detenido.

Alias

En Powershell, como en la mayoría de shells de línea de comandos, se pueden definir alias de comandos. Es un método de ejecución de comandos del shell (cmdlets) usando un nombre diferente. En todo caso la razón del uso de alias es por la reducción de carácteres en el nombre a usar y reducir lo que se escribe.

Por ejemplo: en lugar de usar get-process usar sólo gps. Este es un alias predefinido, hay otros: con el cmdlet get-alias obtenemos la lista de los predefinidos.

Pero en Powershell disponemos de varios cmdlets que nos permiten definir nuevos alias, exportarlos, importarlos y como el dicho anteriormente, mostrarnos una lista de los existentes. La lista de estos cmdlets también la podemos obtener con otro cmdlet:

Con get-alias obtenemos una lista de alias disponibles en la sesión actual, todos los predefinidos y los que hayamos creado nosotros, export-alias e import-alias nos servirán tanto para exportar como para importar la lista entre sesiones, mientras new-alias y set-alias nos permiten definir nuevos alias en la sesión actual.

Los alias creados mediante los dos últimos cmdlets son válidos únicamente en la sesión actual. Para disponer de alias persistentes entre sesiones de powershell se han de definir en un archivo de perfil, en cada línea un alias:

set-alias nuevo new-object

set-alias hora get-date

…

Y aunque el uso de comandos cortos no deja de tener su encanto, un uso indiscriminado no es muy recomendable. Primero porque los alias no son tan portables como los scripts, imaginad: un script lleno de alias, cada uno de ellos debe incluirse mediante set-alias al principio del script para asegurarse que todos los necesarios están presentes, independientemente del equipo o del perfil de la sesión, cuando se ejecute el script. Hay que reconocer que una concentración grande de alias pueden causar confusión en comandos y scripts. Los alias definidos podrían tener sentido para un programador, pero no todos comparten esa lógica en la definición de alias. Así qué, si uno quiere que otros entiendan sus scripts, cuantos menos alias mejor, o en todo caso alias entendibles y claros.

Ámbitos

Un ámbito o alcance es un límite lógico donde Powershell aisla el uso de funciones y variables. Los ámbitos se pueden definir como: global, local, script y private. Funcionan en una jerarquía en que la información del ámbito se hereda descendentemente, es decir, el ámbito local puede leer del ámbito global, pero no al revés.

global

Como su nombre indica, el ámbito global se aplica a toda la instancia de powershell. Los datos se heredan por todos los ámbitos hijo, comandos, funciones o scripts que se ejecutan usando variables definidas en global. Sin embargo, tened en cuenta que no se comparten ámbitos globales entre instancias de powershell.

local

Un ámbito local se crea dinámicamente cada vez que se ejecuta una función, filtro o script. Después de la ejecución, la información se descarta. Puede leer información del ámbito global, pero no realizar cambios. Veamos el mismo ejemplo anterior pero en forma local.

script

El ámbito de script se circunscribe a la ejecución del script y acaba cuando éste finaliza. Veamos un ejemplo:

Cuando ListaServicio.ps1 se ejecuta, la información guardada en la variable $Servicios (el primer servicio) se muestra en el panel de salida. Pero al intentar acceder a la información de la variable desde la consola con $Servicios[0] se devuelve un error, ya que la variable sólo es válida en el ámbito del script. Cuando finaliza el script, el ámbito y todo su contenido es descartado.

¿Qué pasa si un administrador quiere usar un script en un Pipeline o acceder como a un archivo de biblioteca en busca de funciones comunes? Normalmente esto no es posible ya que powershell descarta el ámbito de script en cuanto éste script finaliza. Por suerte, Powershell admite la técnica del punto-origen (dot-sourcing), un término original de UNIX. Aplicarla a un script hace que Powershell cargue el ámbito de script dentro del ámbito padre de la llamada. Para usarla, simplemente hay que añadir el prefijo (.) punto al nombre del script cuando se ejecute, algo como: PS C:\> ..\script.ps1

private

Parecido al ámbito local pero con una diferencia clave: Las definiciones en el ámbito privado no son heredadas por ningún ámbito hijo. Qué mejor que verlo en un ejemplo, siguiendo el hilo de los anteriores.

El ejemplo se ejecuta porque usa el operador de llamada &. Con este operador, podemos ejecutar fragmentos de código script en un ámbito local aislado. Esta técnica es útil para aislar un bloque del script y sus variables de un ámbito padre o, como vemos aquí, separar una variable de ámbito privado de un bloque del script.

Perfiles

Un perfil de powershell no es más que una colección de valores guardados para personalizar el entorno de powershell. Hay varios tipos de perfiles, cargados en un orden específico cada vez que powershell se inicia.

todos los usuarios todos los hosts

Debe ubicarse en %windir%\system32\windowspowershell\v1.0\profile.ps1 (1). Los valores de este perfil se aplicarán a todos los usuarios de powershell en el quipo actual.

todos los usuarios host actual

Debe ubicarse en %windir%\system32\windowspowershell\v1.0\ShellID_profile.ps1 (2). Se aplican a todos los usuarios del shell actual (de forma predeterminada la consola).

usuario actual todos los hosts

Debe ubicarse en %userprofile%\My Documents\windowspowershell\profile.ps1 (3). Aquéllos usuarios que desean controlar su propio perfil pueden utilizar este tipo. Se aplica sólo al usuario actual de la sesión de powershell y no afecta al resto.

usuario actual host actual

 Debe ubicarse en %userprofile%\My Documents\windowspowershell\ShellID_profile.ps1 (4). Como el perfil todos de host específico, este tipo carga valores para el shell actual, aunque los valores son de usuario específico.

Hay otros perfiles, por ejemplo para el ISE, usuario actual ISE(5) o todos los usuarios ISE(6).

Antes de crear un perfil: get-help about profiles

(1) if (!(test-path $profile.AllUsersAllHosts)) {new-item -type file -path $profile.AllUsersAllHosts-force}

(2) if (!(test-path $profile )) {new-item -type file -path $profile -force} Desde la consola de Powershell.

(3) if (!(test-path $profile.CurrentUserAllHosts)) {new-item -type file -path $profile.CurrentUserAllHosts -force}

(4) if (!(test-path $profile.AllUsersAllHosts)) {new-item -type file -path $profile.AllUsersAllHosts-force} Desde la consola de Powershell.

(5) if (!(test-path $profile )) {new-item -type file -path $profile -force} Desde el ISE.

(6) if (!(test-path $profile.AllUsersAllHosts)) {new-item -type file -path $profile.AllUsersAllHosts-force} Desde el ISE.

Si deseamos editar el perfil desxe el ISE: psEdit $profile

Aunque en este caso no me lo edita porque no existe.

SEGURIDAD

Cuando se liberó WSH con Windows 98 (ufffff), fue un regalo para los administradores que buscaban capacidades de automatización como sus hermanos UNIX. Pero al mismo tiempo, los viruseros descubrieron rápidamente que abría un gran frente de ataque contra los Windows.

Casi cualquier cosa de un sistema Windows puede automatizarse o controlarse con WSH, lo cual es una ventaja para administradores. Pero WSH no aporta ningún tipo de seguridad en la ejecución de scripts. Le das un script y lo ejecuta. De donde proviene o cual es su propósito no importa. Con este comportamiento WSH es más conocido como una vulnerabilidad que como una herramienta.

Con todas las críticas contra la seguridad de WSH, el equipo de diseño de powershell decidió incluir una directiva de ejecución para mitigar las amenazas de seguridad que plantea el código malicioso. Una directiva de ejecución define restricciones en cuanto a Cómo permite ejecutar los scripts o que archivos de configuración se cargan. Powershell tenía cuatro directivas de ejecución principales: Restricted, AllSigned, RemoteSigned y Unrestricted. Algo como: Restringida, Todos firmados, Remotos firmados y Sin restricción.

De forma predeterminada Powershell está configurado para ejecutarse bajo la Restringida. La más segura y qué sólo le permite ejecutarse en modo interactivo. Nada de scripts, y archivos de configuración firmados digitalmente por un emisor de confianza.

Todos firmados es la inmediatamente inferior a Restringida. Significa que los scripts y archivos de configuración deben ir firmados digitalmente por un emisor de confianza para ser cargados o ejecutados.

La directiva de Remotos firmados está pensada para evitar la ejecución de scripts y archivos de configuración remotos que no estén firmados digitalmente, pero que no será necesario si los mismos son locales.

Y la última y como su propio nombre sugiere: Sin restricción, permite la ejecución y/o carga de scripts y archivos de configuración. Locales y firmados, aunque a los remotos les antecede una opción para elegir si se ejecuta o no.

Con la liberación de powershell 2.0, se añadieron las directivas Bypass y Undefined.

Con la primera, Bypass, no se bloquea nada y además no hay avisos ni preguntas para elegir.

Undefined que no existe ninguna directiva definida en el ámbito actual, y si esta es la que hay para todos los ámbitos entonces la directiva es la Restringida.

Configurar la directiva de ejecución

De forma predeterminada la directiva es la Restringida, si queremos cambiarla usaremos el cmdlet Set-executionPolicy. (También podemos usar la Directiva de Grupo para establecer la directiva de ejecución en varios equipos).

Vamos a cambiar la directiva mediante el ISE, primero vemos la que hay get-executionpolicy, y el resultado es Unrestricted. Vamos a establecerla en Set-executionpolicy AllSigned… Por seguridad nos envía una ventana de confirmación, le damos al Sí y …¿qué pasa?

No la cambia y nos lanza una serie de mensajes y advertencias. El acceso es denegado. Bien, lo que sucede es que hemos de iniciar el ISE con el comando Ejecutar como Administrador, veamos ahora:

Sin ningún problema, está cambiada sin errores.

2008 R2: Automatizando tareas administrativas: powershell(el ISE)

Powershell ISE

Otra de las características introducidas con Powershell 2.0 es el denominado Entorno de scripting integrado(ISE). Aplicación Host basada en WPF (Windows Presentation Foundation) para Powershell. Mediante el ISE podemos ejecutar comandos y escribir, probar y depurar scripts. Entre sus cualidades nos encontramos con:

> Un panel de comandos para ejecutar interactivamente comandos.

> Un panel de script, para escribirlos, editarlos y ejecutarlos. Se pueden ejecutar completos o sólo las líneas seleccionadas.

> Un panel de salida con desplazamiento que muestra una copia de los comandos desde su panel, scripts desde el suyo y sus resultados.

> Hasta ocho entornos de ejecución de Powershell independientes en la misma ventana, cada una con sus propios comandos, scripts y salidas.

> Edición multilínea en el panel de comandos, que nos permite pegar múltiples líneas de código, ejecutarlo, y rellamarlo como una unidad.

> Depurador integrado para la depuración de comandos, funciones y scripts.

> Características personalizables que nos permiten ajustar colores, fuentes y capas.

> Un modelo de objeto de script que nos permite más personalización y así extender el ISE.

> Números de línea y columna, atajos de teclado, completar tabulaciones, ayuda sensible al contexto y compatibilidad con Unicode.

El ISE de Powershell es una característica opcional en Windows Server 2008 R2. Para usarlo debe instalarse desde Añadir Características. El Administrador del Servidor instalará los requerimientos necesarios, .NET framework 3.5 SP1.

Luego podremos acceder desde Inicio, accesorios, Windows Powershell, con dos accesos:

El título de la ventana nos dirá en qué entorno estamos.

Los requisitos para usar el ISE:

- XP o posterior.

- .NET Framework 3.5.

Centro de Administración de Active Directory

Una de las nuevas herramientas incorporadas en Windows Server 2008 R2 es el Centro de Administración de Active Directory o ADAC, dicen que para facilitarnos la vida. Con esta herramienta podemos realizar diversas tareas administrativas, además de crear usuarios y grupos.

Desde Inicio, Herramientas Administrativas, Centro de Administración de Active Directory:

Es una herramienta intuitiva y fácil de ejecutar. Son unos paneles personalizablesque representan la mayoría de tareas que podemos llevar a cabo. Podemos añadir/quitar paneles y personalizar la vista general de la página para ayudarnos a encontrar rápidamente las tareas que más frecuentemente realizamos.

Uno de sus usos es la búsqueda de diversos objetos en AD.

Podemos crear usuarios nuevos:

También grupos:

O tener una visión de las propiedades en un interfaz mejorado.

Podéis experimentar con ella,

2008 R2: Automatizando tareas administrativas: powershell(3)

Trabajar en remoto con powershell.

Una de las carencias de powershell 1.0 era la falta de un interfaz para ejecutar comandos en una máquina remota, y aunque con WMI y pocos cmdlets podíamos conectar con un equipo remoto, la verdad es que había una ausencia clara de dicha característica. Así nace la característica ‘Remoting’ en Powrshell 2.0.

Como el propio nombre sugiere, es una característica diseñada para la ejecución de comandos (o scripts) en equipos remotos. Esto puede significar la ejecución de uno o varios comandos en una o miles máquinas remotas. Además, los comandos pueden ser emitidos de forma síncrona o asíncrona, uno cada vez o a través de una conexión persistente llamada runspace, e incluso programados o silenciados.

Para uitilizar Remoting hemos de tener los permisos apropiados para conectar con el equipo remoto, ejecutar powershell y ejeutar los comandos deseados. Complementariamente el equipo remoto debe tener Powershell 2.0 y WinRM instalados, además de powershell configurado para remoto.

Cuando usamos Remoting, la sesión que utilicemos para ejecutar comandos determina el entorno propio de ejecución. Los comandos pues están sujetos a las directivas de los equipos remotos, los perfiles y preferencias.

*Los comandos ejecutados contra un equipo remoto no tinen acceso a la información contenida en nuestro perfil local, así qué, los que usen funciones o alias definidos en nuestro perfil local, fallarán estrepitósamente si no están definidos en el equipo remoto.

Cómo

Básicamente Powershell mantiene una conversación que fluye entre un cliente (el equipo con la sesión de powershell) y un servidor (el equipo remoto) contra el que queremos ejecutar los comandos:

> Un comando es ejecutado en el cliente.

> El comando es transmitido al servidor.

> El servidor ejecuta el comando y devuelve su salida al cliente.

> El cliente muestra en pantalla o utiliza la respuesta devuelta.

En un nivel profundo, powershell remoting es muy dependiente de WinRM para facilitar el intercambio de comandos y respuestas entre cliente y servidor. WinRM es un componente de Windows Hardware Management, un servicio basado en web que nos habilita enumerar información y manipularla en un equipo remoto. Para el manejo de sesiones remotas, WinRM fue desarrollado según el protocolo estándar basado en SOAP denominado WS-Management. Este protocolo es muy compatible con los cortafuegos, y se desarrolló primeramente para el intercambio de información de administración entre sistemas que pueden estar basados en diversos sistemas operativos y en varias plataformas de hardware.

Cuando Powershell usa WinRM para enviar/recibir comandos/respuestas entre cliente/servidor el intercambio se realiza mediante series de mensajes XML. El primero de ellos es una solicitud al servidor, conteniendo el comando a ejecutar. Esta solicitud se envía mediante el protocolo SOAP. El servidor como respuesta ejecuta el comando en una nueva instancia de Powershell denominada runspace. Completada la ejecución el resultado va de regreso al cliente en un segundo mensaje XML, también con SOAP.

El motivo del uso de XML es porque no pueden enviarse directamente objetos .NET por la red. Así que para llevar a cabo la transmisión, los objetos se serializan dentro de series de elementos de datos XML(CliXML). En cuanto el cliente/servidor reciben la transmisión, el mensaje XML se convierte en un tipo de objeto desserializado. El objeto resultante no dura demasiado. En vez de eso, es un registro de propiedades en un momento exacto y como tal carece de cualquier método.

Requerimientos

En ambos equipos, el local y el remoto:

> Powershell 2.0 o superior.

> Microsoft .NET Framework 2.0 o superior.

> Windows Remote Management 2.0(Incluído en Windows 7 y 2008R2, hay un paquete de instalación para Vista y 2008)

Configuración

De forma predeterminada WinRM está instalado en todos los Windows Server 2008R2 como parte del propio sistema operativo. Sin embargo, no se encuentran habilitadas las conexiones remotas por cuestiones de seguridad. Podemos utilizar algunos métodos para configurar el Remoting, por ejemplo:

> Usando el cmdlet enable-psremoting (mediante la opción EJECUTAR COMO ADMINISTRADOR):

inicia el servicio WinRM y configura su inicio en automático; crea una escucha para aceptar solicitudes de cualquier IP; Añade una excepción el el cortafuegos para las comunicaciones vía WS-Management.

Habilita la configuración de las sesiones registradas de PS para recibir instrucciones desde un equipo remoto.

En caso de no estar registrada la configuración de PS, lo hace ahora.

Si los equipos son de 64 bits, también registrará, si no lo está aún, la configuración del PS32.

Quita el valor ‘denegar todos’ del descriptor de seguridad de todas als configuraciones de sesiones registradas.

Reiniciará el servicio WinRM para que tomen efecto todos los nuevos cambios.

> Desde el Administrador del Servidor:

1. Abrimos la consola
   
2. en el área resumen, clic en Configurar Administración remota del Administrador del servidor.
   
3. Siguiente, Marcar la casilla Habilitar la administración remota de este servidor desde otros equipos.
   
4. Aceptar
   

> Usando una GPO:

1. Creamos una nueva gpo (o editamos una), yo he creado una nueva.
   
2. Expandimos Configuración de equipo, Directivas, Plantillas Administrativas…, Componentes de Windows, Windows Remote Management, seleccionamos Servicio WinRM.
   
3. Clicamos en Permitir configuración automática de escucha del panel derecho, habilitamos y definimos los filtros IPv4 e IPv6 con ‘*’.
   
4. Aceptar
   
5. Después expandimos Configuración de equipo, Directivas, Configuración de Windows, Configuración de Seguridad, Firewall de Windows con seguridad avanzada.
   
6. Clic derecho en Reglas de entrada, Nueva regla.
   
7. En el asistente: Seleccionamos Predefinida y del desplegable Administración remota de registro de eventos, siguiente.
   
8. Siguiente para aceptar las nuevas reglas.
   
9. En la página de Acción: marcamos permitir la conexión y pulsamos en Finalizar.
   
10. Repetir los pasos de creación para los tipos predefinidos: Administración Remota de Servicios y Administración remota de Firewall de Windows.
    

2008 R2: Automatizando tareas administrativas: powershell(2)

Al hilo de Inicio con powershell, vamos a intentar dar algunas nociones, aunque de antemano os diré que alguien que está mucho más versado en el tema que yo puede sacaros del agluna duda en Foro scripting del WWP.

SHELL

Un Shell es un interfaz que permite a los usuarios interactuar con el Sistema Operativo. No se considera una aplicación debido a su innegable naturaleza, pero es como cualquier otro proceso en ejecución del sistema. La diferencia entre uno y otro es que el propósito del Shell es permitir a los usuarios la ejecución de OTRAS aplicaciones. En algunos S.O. (UNIX, LinuX, VMS…), el Shell es un interfaz de línea de comandos (CLI), en otros (Windows, MAC OS) es un interfaz gráfico (GUI).

Tanto CLI como GUI tienen beneficios como inconvenientes. Muchos CLI permiten potentes comandos encadenados, salidas o resultados de la aplicación de un comando hacia otro comando, se conoce como PIPELINE o entubamiento. Los GUI sin embargo, necesitan que sus comandos sean autónomos de por sí (contenidos en sí mismo). Además, la mayoría de GUI son fáciles para navegar en contra de los CLI, donde el conocimiento del shell es un requisito necesario para encadenar comandos y navegar fluídamente. Así qué, la elección de qué Shell usar depende de nuestro nivel de confort y cuál será el mejor para llevar a cabo la tarea manual.

Si alguien quiere empaparse de la Historia de los SHell,  la wikipedia.

Vista rápida de powershell

WSH se introdujo como estándar en Windows, queriéndose ofrecer como una alternativa robusta y eficiente a los scripts de DOSShell. Desafortunadamente WSH presenta muchos retos sin llegar realmente a la experiencia de Shell que UNIX y Linux ofrecen y que muchos administradores envidiaban o envidian aún…

Jeffrey Snover, que por cierto conocí en Redmon durante su primera presentación de powershell en el Microsoft MVP Global Summit 2008, es el arquitecto junto a otros del Team de powershell. Ellos han hecho posible lo que Windows pedía: un CLI fuerte, seguro y robusto para administrar el sistema. Diseñado como un shell de acceso completo a las bases de Windows mediante .NET Framework, COM y otros métodos. Proporciona también un entorno de ejecución familiar, fácil y seguro. Powershell, su nombre quiere indicar power into windows shell, la potencia en el shell de Windows. Aquéllos deseosos de automatizar tareas deben indagar en este shell, que auna la potencia de WSH  con la familiaridad de un CLI.

Powershell proporciona un lenguaje de scripting nativo potente, tanto que los scripts pueden portarse a todos los Windows sin preocupaciones de si un lenguaje particular está o no instalado. Antes, un administrador podía tener preparados scripts en WSH, Perl, Python, VBScript, JScript, u otro, para encontrarse que en el equipo a ejecutarse no tenía el intérprete instalado. Y en los de casa ya ni comentarlo. Powershell soluciona este problema, ya que no necesita intérpretes no nativos; también nos evita la búsqueda de equivalentes a comandos para realizar simples operaciones y codificarlos en archivos cmd. Por último, powershell aborda el problema de seguridad de WSH proporcionando una plataforma para un scripting seguro. Centrándose en características e seguridad como la firma de script, extensiones no ejecutables y directivas de ejecución (muy restrictivas de forma predeterminada).

Para cualquiera que necesite automatizar tareas administrativas en un sistema Windows, Powershell proporciona una inyección de potencia muy necesaria, para que administradores o técnicos de scripting en sistemas Windows se conviertan en expertos, lo que es altamente recomendable. Después de todo, powershell puede utilizarse eficientemente en la automatización de tareas de Windows, Active Directory, Terminal Services, SQL Server, Exchange Server, IIS y muchos productos que son de terceros.

Usos

* Podemos crear, eliminar, modificar y establecer permisos en archivos y carpetas.

* Listar, detener, iniciar, reiniciar e incluso modificar Servicios.

* Listar, detener e iniciar procesos.

* Usar WMI no sólo en Windows, sino en diversas plataformas como IIS o TS.

* Usar los componentes existentes de COM para realizar un extenso rango de tareas.

* Añadir y quitar roles y características.

Características de powershell

Powershell se desvía de las interfaces de administración actuales de Windows. Como tal, se ha construido desde la base para incluir una serie de características que hacen de la administración, desde la CLI y la basada en scripts, más fácil. Algunas características clave:

• 240 cmdlets (herramientas en línea de comandos)
• Un lenguaje de script diseñado para fàcil lectura y uso.
• Compatible con scripting actual, línea de comandos e interfaces de automatización, como WMI, ADSI, .NET Framework, ADO, y tantos otros.
• Sigue una estricta convención de nombres en los comandos, basada en un formato verbo-sustantivo.
• Compatible con diferentes sistemas operativos Windows, XP con SP2 o posterior, Windows Server 2003 con SP1 o posterior, Windows Vista, Windows 2008, Windows 7 y Windows 2008 R2.
• Proporciona acceso directo y exploración del Registro de Windows, del almacenamiento de certificados, y el sistema de archivos usando un conjunto común de comandos.
• Está basado en objetos, que permite a los datos ser entubados entre comandos.
• Es extensible, que permite a terceros construir sobre el mismo y extender los interfaces de powershell para administrar Windows y otras plataformas Microsoft.
• Desde su versión powershell 2.0 contiene la habilidad de administrar roles y características, AD domain services, AD rights management services, Applocker, BITS, Group Policy, IIS, etc…
• Un depurador, con el que podemos identificar errores o ineficacias en scripts, funciones, comandos y expresiones mientras están siendo ejecutadas a través de un conjunto de cmdlets de depuración o con el ISE (Integrated Scripting Environment).
• Un interfaz GUI multipestaña de desarrollo. Aquí podemos escribir, comprobar y depurar scripts. Incluye edición multilínea, tabulación, colorido sintáctico, ejecución selectiva, ayuda sensible al contexto y compatibilidad para lenguajes de derecha a izquierda.
• Trabajos en segundo plano que nos permiten ejecutar comandos y scripts asíncronamente.
• Permite incluir funciones de script, podemos crear nuestros propios cmdlets sin necesidad de compilar.
• Incluye una característica denominada Módulos, que permite paquetes de cmdlets, proveedores, funciones, variables y álias ser empaquetados y poder compartirlos con facilidad con otros.
• Se ha añadido además la compatibilidad de comandos remotos, lo que nos permite automatizar la administración de sistemas remotos mediante una consola única de Powershell.

¿Puedo ejecutar scripts powershell 1.0 en powershell 2.0?

Lo necesario

Para trabajar con powershell necesitamos entender los comandos básicos, cómo acceder a powershell y cómo trabajar desde la línea de comandos, cosa que muchos ya conoceréis.

Para acceder a Powershell:

- Inicio, todos los programas, Accesorios, Windows Powershell. Tenemos el ISE o directamente Windows powershell.

- También desde Inicio, escribimos powershell en buscar programas y archivos y ENTER.

- Finalmente podemos ir a Inicio, ejecutar, escribir CMD y ENTER, desde la línea de comandos escribimod powershell y ENTER de nuevo.

La interfaz de línea de comandos (CLI).

La sintaxis para el uso de powershell desde la CLI es muy parecido a cualquier otro Shell. El componente principal de un comando de powershell es el propio nombre del comando a ejecutar. Este comando puede ser mucho más específico mediante el uso de parámetros y argumentos para parámetros. Lo que hace que el formato sea como:

> [comando]

> [comando]-[parámetro]

> [comando]-[parámetro]-[parámetro] [argumentoX]

> [comando]-[parámetro]-[parámetro] [argumentoX],[argumentoY]

Cuando usamos powershell un parámetro es una variable que puede aceptar el comando, un script o una función. Un argumento es un valor asignado a un parámetro. Aunque estos términos son con frecuencia intercambiados, es de ayuda recordar estás definiciones.

Moverse por el CLI.

Como con todos los Shell basados en CLI, hay una serie de operaciones asociadas a diversas teclas cuando se usa la consola de powershell.

Teclas	Operación
flechas izq y der	Mueve el cursor a izquierda y derecha dentro de la línea actual del comando.
flechas  arr y aba	Mueve el cursor por la lista de comandos recientemente escritos.
Re Pág	Muestra por pantalla el primer comando en el historial de comandos.
Av Pág	Muestra por pantalla el último comando en el historial de comandos.
Inicio	Mueve el cursor al inicio de la línea de comando.
Insertar	Conmuta entre el modo insertar y el de sobreimprimir texto.
Fin	Mueve el cursor al final de la línea de comando.
Supr	Elimina el carácter en la posición actual del cursor.
Borrar	Elimina el carácter inmediatamente precedente a la posición actual del cursor.
F3	Muestra el comando anterior.
F4	Elimina un número especificado de carácteres desde el cursor actual.
F5	Se mueve atrás en el historial de comandos.
F7	Muestra una lista de los comandos escritos recientemente en un cuadro emergente dentro del shell, podemos navegar con las flechas arriba y abajo para seleccionar uno de ellos, pulsando INTRO se ejcuta de nuevo.
F8	Movimiento hacia atrás, por el historial de comandos con comandos que coincidan con el texto introducido en la línea de comandos.
F9	Pregunta por un número de comando y lo ejecuta. (Desde el historial de comandos; el número es mostrado en la lista por F7)
TAB	Autocompleta secuencias de comandos. Mayús+TAB se mueve atrás a través de una lista potencial de coincidencias.

La mayoría de lo visto en la tabla era nativo del command prompt CMD, lo que nos hace más fácil la adopción del shell de powershell.

Tipos

Cuando se ejecuta un comando en powershell el intérprete de comandos busca el nombre del comando para averiguar la tarea a realizar. Este proceso incluye determinar el tipo de comando y cómo porcesarlo. Hay cuatro tipos de comandos en Powershell: cmdlets, comandos de función, comandos de script y comandos nativos.

CMDLET

Es el primer tipo de comando, comandlet, que es parecido a los comandos de otros shells basados en CLI. La diferencia es que los cmdlets se implementan mediante las classes .NET compiladas dentro de Librerías de Enlace Dinámico (DLL) y cargadas en el runtime de powershell.Esto significa que no hay una clase fija de cmdlets desarrollados; cualquiera puede usar el SDK para desarrollar sus propios cmdlets personalizados y extender la funcionalidad de Powershell.

Un cmdlet se nombra siempre como un verbo+sustantivo separado por un guión (-). El verbo especifica la acción que el cmdlet llevará a cabo, y el sustantivo el objeto con el que operar. Por ejemplo:

Durante la ejecución de cmdlets debemos tomar en cuenta algunas consideraciones. En conjunto, Powershell fue creado de forma en que su sintáxis es tolerante y fácil. Powershell también intenta rellenar los espacios en blanco.

> Siempre se estructuran en un formato verbo+sustantivo no plural.

> Los parámetros y argumentos son posicionales: verbo+sustantivo parámetro/argumento

> Muchos de los argumentos pueden sustituirse por comodines: get-service w*

> Se permiten nombres de parámetros parciales.

Un cmdlet ejecuta un registro a la vez.

FUNCIONES

Otro tipo de comando. Estos proporcionan una forma de asignar un nombre a una lista de comandos. Son similares a las funciones y procedimientos de otros lenguajes de programación. La principal diferencia entre un script y una función es que con un script se inicia una nueva instancia del Shell y las primeras se ejecutan en la actual instancia del mismo Shell.

(Las funciones definidas en la línea de comandos tienen efecto sólo durante la sesión actual de powershell. De ámbito local y no se aplican a nuevas sesiones de powershell.)

Aunque una función definida en la línea de comandos es una forma útil de crear series de comandos dinámicamente en el entorno de powershell, estas funciones se eliminan de la memoria cuando se cierra o reinicia powershell. Por lo tanto, aunque la creación de funciones complejas dinámicamente es posible, escribirlas como scripts es más práctico. Un ejemplo e función:

En powershell 2.0 se ha añadido unacaracterística denominada funciones avanzadas. Su premisa básica es habilitar a los administradores y desarrolladores el acceso a la misma funcionalidad de un cmdlet compilado, pero directamente a través del lenguaje de script de powershell. Por ejemplo:

SCRIPTS

Tercer tipo de comandos, son comandos de Powershell almacenados en archivos ps1. La principal diferencia con las funciones es que los scripts se almacenan en disco y pueden llamarse en cualquier momento.

Se pueden ejecutar en una sesión de powershell o desde el prompt CMD. En el primer caso escribimos el nombre del script sin extensión. Al nombre pueden seguirle diversos parámetros. El shell ejecutará el primer ps1 que coincida con dicho nombre de los que se encuentran en la VARIABLE DE ENTORNO DE Powershell ($ENV).

Desde CMD, o ir al directorio donde se encuentra el script o usar el camino absoluto:

Un detalle importante sobre los scripts de powershell es sobre las restricciones de su seguridad predeterminada. Por defecto no está habilitada la ejecución de scripts.

Esto se controla con el cmdlet Set-ExecutionPolicy.

Comandos NATIVOS

El último de los tipos de comandos, un comando nativo consiste en un programa externo que el sistema puede ejecutar. Ya que para ejecutar un comando nativo hay que crear un nuevo proceso, es el menos eficiente de los tipos. Estos suelen tener sus propios parámetros para el proceso, y normalmente son distintos a powershell.

Integración con .NET

La mayoría de shell operan en un entorno basado en texto, lo que significa que hay que manipular la salida para propósitos de automatización. Microsoft sin embargo ha cambiado esto con Powershell y en lugar de transportar datos en texto plano, los recupera en forma de objetos de .NET, lo que hace posible a los comandos o cmdlets acceder a los métodos y propiedades del objeto directamente. Lo cual simplifica el uso del shell. Simplemente nos referimos a los objetos y los manipulamos según nuestras necesidades.

La reflection es una característica de .NET Framework que permite a los desarrolladores examinar objetos y recuperar sus métodos, propiedades, campos y el resto. Ya que Powershell está construido sobre .NET Framework, nos porporciona dicha característica también con el cmdlet get-member. Este cmdlet analiza un objeto o colección de objetos que le pasamos mediane el pipeline. Por ejemplo:

Los desarrolladores se refieren a este proceso como interrogación a un objeto. Puede ser muy útil para entender métodos y propiedades del objeto sin buscar en MSDN o Internet.

También hay que aprender sobre ETS(Extended Type System), las clases y métodos estáticos y el tipo de aceleradores; yo me lío bastante con tanto desarrollo

Próximamente veremos el acceso remoto y el ISE de powershell.

Directivas: Tareas administrativas 01

Antes de administrar Directivas debemos tener instaladas las herramientas, en Windows Server 2008 R2 lo están por defecto en los controladores de dominio, pero en otros sistemas deben instalarse manualmente.

Windows Server 2008 R2

Iniciamos sesión en el equipo.

Administrador del servidor, de las herramientas administrativas.

Accedemos al nodo de Características del árbol izquierdo.

Pinchamos en Agregar características del panel derecho.

Bajamos en la lista ofrecida hasta Administración de directivas y marcamos la casilla de verificación. Siguiente.

Aceptamos la selección y pinchamos en instalar.

Al finalizar la instalación cerramos la mmc.

Windows 7

Para administrar las directivas de grupo del dominio desde un Windows 7 debemos descargar e instalar como administrador las RSAT o Remote Server Administration Tools para Windows 7. Una vez lo tenemos instalado:

Iniciamos sesión en el equipo

Abrimos el Panel de Control

Programas, pinchamos en Activa o desactiva las características de Windows

Buscamos en la lista: Herramientas de administración remota del servidor y lo expandimos

Herramientas de administración de características, marcamos la casilla de Herramientas de administración de Directivas de Grupo

Aceptamos

Una vez completado cerramos el Panel de control.

Ahora ya tenemos la característica accesible desde Herramientas Administrativas. (esto también instala el módulo para powershell)

Administración de Directivas de Grupo con PowerShell

Sea desde Windows 7 o desde Windows Server 2008 R2 con las herramientas de Directiva de Grupo instaladas, podemos aprovechar diversos cmdlets de PowerShell para administrar Directivas de Grupo.

Abrimos PowerShell como administrador,

Una vez en la ventana, Import –module grouppolicy Intro

Ahora si escribimos Get-command *GP* –commandtype cmdlet obtenemos hasta 25 diferentes cmdlets de Directiva de Grupo

Para obtener ayuda sobre uno específico, Get –help get-gporeport por ejemplo.

Para obtener ejemplos, añadimos –example a la instrucción de solicitud de ayuda, por ejemplo Get –help get-gporeport –example

Herramientas para Directivas (w2008R2)

Microsoft proporciona diversas herramientas para que podamos crear y administrar directivas locales o de dominio. La versión del sistema determina la funcionalidad que se ofrece a los administradores en su uso. Por ejemplo: si creamos una directiva con la consola de 2008/2008 R2, la carpeta de Directivas utiliza las nuevas plantillas ADMX/ADML, mientras que en XP/2003 se carga la plantilla ADM original en la carpeta de Directivas.

Repasemos las herramientas:

• GPMC, La consola de administración de directivas de grupo.

La más funcional y útil de las herramientas de que disponemos para la creación y administración de las Directivas de Grupo en AD. Fue introducida después de la versión 2003; la funcionalidad incluída en los diferentes SO produce distintas opciones y resultados al crear y administrar las Directivas de Grupo.

Es un elemento de la MMC, que podemos añadir a cualquier consola personalizada. Con la proporcionada con Windows Server 2008 R2 podemos:

•  
  • Habilitar las GPO de inicio, y crearne de nuevas.
  • Crear nuevas directivas de grupo de dominio
  • Crear nuevas directivas de grupo usando las GPO de inicio como plantillas
  • Crear y configurar vínculos de directivas a Sites, Dominios y Unidades Organizativas.
  • Ver y administrar Directivas de Grupo en dominios en el bosque AD local y de confianza.
  • Realizar copia de seguridad y restaurar una o todas las directivas en un dominio
  • Realizar copia de seguridad y restaurar una o todas las GPO de inicio en un dominio
  • Importar directivas de grupo desde dominios externos y migrar configuraciones de seguridad usando tablas de migración para asegurar una importación correcta.
  • Administrar Exigido en vínculos de directiva, y habilitar/deshabilitarlos.
  • Configurar la herencia en Sites, dominios y UOs.
  • Administrar el estado de las directivas para controlar que nodos de la directiva están habilitados/deshabilitados.
  • Crear y vincular filtros WMI para Directivas de Grupo
  • Administrar el filtrado de seguridad de Directivas de Grupo
  • Administrar la delegación y administración de seguridad
  • Administrar el orden de procesamiento en contenedores con múltiples vínculos de directiva
  • Ver todos los valores configurados de las directivas de grupo existentes y la info adicional, revisión, filtrado, delegación, y crear informes de exportación de la configuración.
  • Generar informes en HTML como resumen de configuraciones y ajustes.
  • Ejecutar el modelado de directivas para ver  cómo se aplicarán a usuarios y/o equipos en contenedores específicos.
  • Ejecutar el conjunto de resultados y ver cómo se han aplicado a usuarios y/o equipos específicos.
  • …

• GPOE, Editor de objetos de Directiva de Grupo.

El editor de objetos de directiva de grupo es la herramienta que utilizamos para editar las directivas de usuario y equipo locales. Cada servidor y equipo tiene una directiva de seguridad local predeterminada. A esta directiva se accede mediante el acceso directo al elemento de la MMC de directiva local de seguridad desde Herramientas administrativas. Ahora que Vista, w7, 2008 y 2008 R2 son compatibles con múltiples directivas de grupo, el editor se utiliza para administrar o crear cualquier directiva de grupo local, aparte de la predeterminada.

El editor nos sirve para ver la configuración de seguridad, los paquetes de instalación de sfotware, directivas restrictivas, scripts de usuarios y equipos y otras.

• GPME Editor de administración de directivas de grupo.

Para administrar directivas de grupo, se usa este editor con la misma funcionalidad que el anterior (GPOE), y alguna otra añadida. Una de las diferencias es que se incluye no sólo el nodo de valores de directiva sino que también incluye el nodo de valores de preferencia sólo accesible en dominios. Este editor se instala en Vista y W7 descargando las herramientas RSAT del service pack concreto del SO. En Windows Server 2008 y 2008 R2 se instala desde Añadir características desde Administrar el Servidor.

• Editor de GPO de inicio.

El editor de directivas de inicio se usa para editar las GPO de inicio creadas por los administradores. Esta consola sólo muestra los nodos de las plantillas administrativas bajo las secciones de Configuración de usuario y Configuración de equipo de una GPO de inicio. De forma predeterminada, los valores disponibles en las secciones de las plantillas administrativas son aquéllas que pueden establecerse en una GPO de inicio. Se incluye en las Herramientas de administración remota de servidor, RSAT.

• Consola de impresión.

Se introdució por primera vez en Windows Server 2003 R2, la consola de impresión se usa para la gestión y administración de impresoras de impresoras en AD, equipos y servidores locales.Podemos ver las configuraciones, configurar controladores y sus opciones, y administrar los trabajos en un equipo particular o en el entorno de AD. También nos sirve para el despliegue de impresoras para equipos y/o usuarios usanto el nodo de despliegue y que es una función que extiende la funcionalidad de las Directivas de Grupo permitiéndonos el despliegue de impresoras a conjuntos predeterminados de usuarios y/o equipos a los qué está vinculada la directiva.

• gpupdate.exe

Es una herramienta para el símbolo de sistema que nos ayuda en la resolución de problemas de procesamiento de las Directivas y de su inicio bajo demanda. Ciertas secciones de las directivas sólo se aplicarán en el inicio de un equipo o de sesión del usuario, mientras que otras se aplicarán durante los intervalos que están programados para refrescarse. Para las configuraciones que se aplican durante el arranque del equipo o los intervalos de inicio de sesión, si la conectividad de red con los DC no está disponible en ese momento los valores no se aplicarán. Así como los equipos remotos o equipos móviles, los sistemas que están hibernados o en suspensión y aquéllos usuarios que han iniciado sesión con las credenciales cacheadas.

La herramienta pues, nos ofrece la capacidad de aplicar las directivas a equipos y usuarios de inmediato. Un uso bastante extendido es añadir gpupdate.exe al script de conexión de VPN para permitir que los valores se apliquen a equipos remotos que pertenecen a la infraestructura de AD. Algunas opciones:

gpupdate.exe /Target:{equipo|usuario} Esto permite que sólo se procese el nodo específicado de la Directiva.

gpupdate.exe /Force Esto reaplica los valores de la Directiva. No reinicia el equipo o cierra sesión de los usuarios automáticamente.

gpupdate.exe /Wait Tiempo definido para el proceso completo de la directiva, de 600 segundos a 10 minutos.

gpupdate.exe /LogOff Cierra sesión del usuario después del proceso completo de la directiva.

gpupdate.exe /Boot Reinicia el equipo después del proceso completo de la directiva.

gpupdate.exe /Sync Procesa los valores que normalmente sólo lo hacen durante el arranque del equipo o el inicio de sesión del usuario. Se requieren privilegios para reiniciar el sistema o cerrar la sesión de usuario.

• powershell

Esto requiere un estudio más profundo, pero que sepamos que MS ha introducido unos 25 cmdlets para Directivas de Grupo, que nos permiten llevar a cabo diferentes funciones desde powershell, tales como:

> Crear Directivas y Directivas de inicio.

> Crear nuevos vínculos a Directivas.

> Restaurar e importar Directivas.

> Eliminar Directivas y vínculos de directivas.

> Leer y/o establecer propiedades de una UO para que herede o bloquee las Directivas del contenedor padre.

> Renombrar Directivas.

> Crear informes de valores y configuraciones de Directiva.

> Generar informe de RSoP.

> Establecer permisos de administración de Directiva y su delegación.

> Establecer los valores y su preferencia que se almacena en el Registro.

Quizás lo importante en cuanto a powershell es saber que para que administremos o realicemos informes de cualquier Directiva, debemos conocer el GUID de la misma o el nombre exacto, y que aún hay cosas que no se pueden hacer desde powershell.

• Microsoft Desktop Optimización Pack

Contiene diversas herramientas y características extra, pero sólo está disponible para Software Assurance.

• Migrar plantillas ADM al nuevo formato ADMX

Desde sistemas anteriores a Windows Server 2008, es una herramienta que puede descargarse desde http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=15058

• GPLogView

http://blogs.technet.com/b/grouppolicy/archive/2007/02/08/gplogview.aspx

Monitorizar o generar informes en texto, xml y html.

• El todo registro del Visor de sucesos.

En Windows 7 y 2008 R2 se añaden multitud de eventos respecto a las Directivas.

R2 y las GPO -IV

Venimos de R2 y las GPO –III. Elementos de Directiva de Grupo.

GPO de inicio

La consola de administración de Directivas de grupo en Windows Server 2008 y 2008 R2 nos porporcionan una nueva característica de administración de directivas denominada GPO de inicio. GPO de inicio es parecido a las GPO corrientes, pero éstas sólo contienen configuraciones disponibles desde plantillas administrativas. Tal como podemos utilizar las plantillas de seguridad para importar y exportar los valores configurados dentro de la sección de seguridad de una directiva, las GPO de inicio pueden usarse para el relleno previo de valores configurados en las secciones de plantillas administrativas de la Configuración de Equipo y Configuración de Usuario dentro de una directiva. Después de Windows Server 2008 e incluído en 2008 R2, Microsoft liberó un conjunto de GPOs de inicio predefinidas para Windows Vista y Windows XP. Los valores predefinidos en estas GPO de inicio están basadas en información que puede hallarse en la guía de seguridad de Windows XP y Windows client publicada por Microsoft. Estas GPO de inicio particulares son directivas de sólo-lectura, pero los administradores pueden crear sus propias GPO de inicio según sus necesidades.

Valores de directiva

Los valores de directiva son simplemente las opciones configurables disponibles dentro de una directiva en particular. Estos valores se porporcionan desde las plantillas administrativas básicas, valores de seguridad, scripts, directivas basadas en QOS, y, en algunos casos, paquetes de despliegue de software. Muchos valores corresponden uno a uno con un valor y clave de Registro concreta. Dependieno de los valores en particular, distintos valores, incluído texto libre, pueden ser considerados como valores aceptables.

Los valores de directiva de grupo son normalmente configurables con uno de tres: No configurada, Habilitada y Deshabilitada. Es muy importante que los administradores entendamos no sólo la diferencia entre estos tres valores sino entender también lo que particularmente controla el valor de la directiva.

Los valores de Directiva de grupo se aplican tanto a un equipo como a un usuario. Dentro de una directiva en particular, un administrador puede hallar el mismo valor de directiva tanto en la Configuración de Equipo como en la Configuración de Usuario. En casos como este, si el valor de la directiva está configurada para ambos, el valor para el equipo sobrescribirá el del usuario si la directiva está enlazada al usuario en el equipo donde éste ha iniciado sesión.

Valores preferentes

Las directivas de grupo tienen dos nodos de valores principales, incluyendo los nodos de Equipo y Usuario. Cada uno de estos contiene dos nodos principales también, valores de directiva y valores preferentes. Las extensiones de la directiva mostrados en el nodo de preferentes proporcionan a los administradores la posibilidad de configurar muchos valores predefinidos o iniciales, y de entorno para usuarios y equipos. Una de las características más gratas de los preferentes de la directiva es la focalización a nivel de elemento, que sólo se aplica a cierta preferencia, como programar el botón de encendido, para que cierre sesión o apague el equipo, a sólo un grupo definido de usuarios o grupos dentro de la definición a nivel de elemento de la directiva. Cuando un usuario inicie sesión en un equipo y tenga aplicada esta preferencia se convertirá en el valor inicial, aunque los usuarios podrán cambiarla si así lo quieren. Una distinción importante que todos los administradores debemos hacer es qué directivas establecer y cuales valores obligar, mientras que las preferencias configuran valores iniciales y no los bloquean ante cambios.

Vínculos a objetos de Directiva de Grupo

Los vínculos de Directiva de Grupo son clave del despliegue de Directivas a un conjunto predeterminado de equipos y/o usuarios de AD. Los vínculos de directiva definen donde se aplicarán la directiva o directivas particulares, en la forma diseñada jerárquicamente de Sitios y Dominio de AD.

Las directivas pueden vincularse a Sitios, Dominios y OU’s. A su vez, una directiva única puede ser vinculada a múltiples Sitios, Dominios y OU’s en un bosque único. Esto nos permite tener flexibilidad para crear una directiva única y aplicarla a varios conjuntos diferentes de equipos y usuarios dentro del bosque de AD.

El diseño de la infraestructura de AD, Sitios, Dominios y jerarquía de OU’s, es crítica para la aplicación racional de las Directivas. Debe tenerse en cuenta una planificación cuidadosa y considerada, durante la fase de diseño del AD, con respecto a cómo se usarán las Directivas de Grupo y cómo se organizarán los objetos de usuario, grupos y equipos.

Los vínculos de Directivas pueden deshabilitarse cuando sea necesario, y ayudar a la resolución de problemas de aplicación y proceso de Directivas.

Exigir vínculos de Directiva

MS nos proporciona diversas formas para administrar su infraestructura, incluyendo configuraciones que obligan de arriba a abajo. El obligar al cumplimiento de una Directiva, lo que se conocía como ‘no anular’, es una opción de un vínculo de directiva que puede establecerse para asegurarnos que sus valores se aplicarán y mantendrán a pesar de si otra Directiva con la misma configuración y distintos valores está vinculada.

Esta función debe usarse con precaución ya que podría resultar en un funcionamiento no deseado o que el nivel de seguridad que necesita la ejecución de una aplicación o servicio se viese alterado. Antes de habilitar la obligación de cumplimiento de cualquier directiva sería deseable haberlo probado y asegurarnos que no romperá ninguna funcionalidad ni alterará políticas de regulación.

Herencia de Directivas de Grupo

Las directivas se pueden vincular al Sitio, Dominio, y múltiples niveles de OU. Cuando AD contiene Directivas vinculadas a nivel de dominio, cada OU que cuelgue del contenedor raíz del dominio heredará cualquier directiva vinculada a éste. Por ejemplo:

Tenemos dos Directivas vinculadas a nivel de dominio, la predefinida y una que he llamado restricción total, si observamos la OU predefinida de Controladores de dominio se ve:

Pero, y una OU creada aparte y denominada pruebas?:

también hereda dichas directivas.

La herencia de Directivas nos permite establecer una directiva base común a través de la infraestructura de AD, mientras podemos permitir a otros administradores aplicar de forma más granular otras directivas a más bajo nivel que se aplicarán a subconjuntos de usuarios y equipos.

Las directivas heredadas se procesan antes que las vinculadas al contenedor mismo y el último valor de directiva aplicada es el valor resultante, si hay múltiples directivas con el mismo valor configurado y contienen distintos valores, el último será el aplicado. Esto se conoce como precedencia de Directivas, y que en las imágenes anteriores vemos como se encuentran numeradas.

Impedir la herencia de directivas

Sabemos que las directivas pueden heredarse, pero AD nos proporciona también la forma de impedir esa herencia de contenedores padres a contenedores hijos. Esto es, actualmente, una opción que se aplica a nivel de dominio o UO desde la consola de administración y NO sobre una Directiva.

Dicha opción nos puede ser útil si el contenedor contiene usuarios y/o equipos que son especialmentes sensibles a la seguridad o críticos.

Orden de proceso de las Directivas

Las Directivas de grupo pueden vincularse en muchos niveles diferentes y en muchas infraestructuras de AD, múltiples directivas se vinculan en la misma OU o al mismo nivel de dominio. Esto es muy común y además se basa en una recomendación de buenas prácticas. Como las directivas se procesan UNA cada vez, las directivas vinculadas se procesan en un orden particular, comenzando por las Heredadas desde contenedores padre y seguidas por el orden de las vinculadas al contenedor. El impacto resultante de este orden de proceso es cuando múltiples directivas contienen el mismo valor configurado, la última directiva en aplicarse proporciona el valor resultante de configuración. Disponemos de la herramienta Resultant Set of Policy que nos proporciona una consola que muestra las configuraciones finales aplicadas de directiva, también se puede ejecutar el Modelado de directivas de grupo, ambos desde la consola de administración de directivas GPMC.

Ya veremos como usar ambas herramientas.

Filtrado de directivas

La aplicación de Directivas puede ser difícil y el diseño del bosque, los dominios, los sitios y la jerarquía de OUs en Active Directory juega la mayor parte en esto. Una de las más importantes consideraciones cuando diseñamos la jerarquía de OUs dentro de un dominio es entender cómo los administradores del dominio piensan administrar los equipos y usuarios del dominio con Directivas.

En muchos casos, aún con el mayor cuidado en el planeamiento de la infraestructura de AD, las Directivas se aplicarán a equipos y/o usuarios que no necesariamente requieren los valores que contienen estas. Para conocer mejor a qué equipos y usuarios en particular se aplica una directiva, Microsoft ha construido diferentes mecanismos para ayudar a filtrar, o que sólo incluya los objetos necesarios para asegurar que sólo aquéllos equipos o usuarios deseados se les aplique la directiva. Los mecanismos que controlan o filtran el cómo se aplicará una directiva son:

• Filtrado de seguridad de Directiva
• Filtrado WMI de Directiva
• Estado de Directiva para los nodos de configuración de usuario y configuración de equipo.

Filtrado de seguridad

El filtrado de seguridad de Directiva es el GRUPO en la Directiva de Grupo. Muchos administradores se sienten frustrados cuando se explica el hecho de que la Directiva de Grupo se aplica a usuarios y equipos y NO a Grupos. De hecho, el filtrado de seguridad es donde los administradores pueden definir que usuarios, equipos, o miembros de los grupos de seguridad se les aplicará la Directiva de Grupo.

De manera predeterminada, las Directivas se aplican al grupo de Usuarios autenticados, que incluye todos los usuarios y equipos del dominio. El ámbito de aplicación de la directiva es segmentada según la ubicación de los vínculos de Directiva. Puede segmentarse aún más eliminando el grupo de usuarios autenticados del filtrado de seguridad de directiva, reemplazándolo por un grupo de seguridad personalizado.

Cuando el filtrado de seguridad de una Directiva se configura para aplicarse a un grupo de seguridad personalizado, sólo los miembros de dicho grupo, sean usuarios, otros grupos u equipos, se les aplicará esta directiva particular. Por último y no menos importante, hay que mantener siempre la pertenencia al grupo actualizada, de otra fomra la aplicación de la directiva puede ser incorrecta o incompleta.

Filtrado WMI

El filtrado de Directivas WMI es un concepto de directiva introducido en Windows XP y Windows Server 2003. Un filtro WMI es una consulta que se procesa sólo por equipos y puede usarse para incluir o excluir equipos en particular de la aplicación de la directiva que contiene el filtro. Por ejemplo, un filtro WMI puede consultar aquéllos equipos con un sistema operativo versión 6.1 (Windows 7 y 2008R2). Por supuesto, es importante señalar que los filtros WMI no los procesarán Windows 2000 o sistemas antiguos. El filtrado de seguridad debe también reunir los criterios de la Directiva para ser procesada. Los filtros WMI trabajan bien cuando la jerarquía de AD es relativamente lineal, pero mantener pertenencias de equipos a grupos puede ser tedioso.

Estado de Directiva

Seguramente ya se ha mencionado alguna vez, las Directivas se aplican a equipos y usuarios. Dentro de una directiva particular, la configuración disponible está segmentada en dos nodos distintos, Configuración de Equipo y Configuración de Usuario.

Configurar o cambiar el estado de una Directiva significa la posibilidad de escoger entre cuatro posibilidades:

Esta función de la directiva puede ser muy útil para resolver problemas así como optimizar el procesado de las mismas.

Bucle invertido en proceso de directiva

El proceso en bucle invertido de una directiva permite el procesado de ambos nodos, de equipo y usuario, dentro de una directiva aún cuando el usuario no se encuentre dentro del mismo contenedor que el equipo al que se vincula la directiva.