PowerShell

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)

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.

<# .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", #$LogName ="Application" #$LogName ="System"

#$MinBackupSize = "209715200", # 200MB #$MinBackupSize = "204472320", # 195MB $MinBackupSize = "1024", # 1MB [String]$BackupLocal = "D:\TEMP", [String]$Backupremote = "D:\COPIALOGS" #[String]$Backupremote = "\\ADTEST04\logs\seclogs" #[String]$Backupremote = "\\srvpl01\COPIALOGS" )#End ParamBegin{ # 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.

Posted in: Herramientas, Scripting, Windows 2008 R2.

2008R2: Automatizando tareas administrativas: powershell(4)

Jul 31st, 2011 by juansa. No comments yet

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.

Posted in: Herramientas, Scripting, Windows 2008 R2.

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

Jul 29th, 2011 by juansa. No comments yet

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.

Posted in: Herramientas, Scripting, Windows 2008 R2.

Centro de Administración de Active Directory

Jul 28th, 2011 by juansa. No comments yet

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,

Posted in: Herramientas, Windows 2008 R2.

2008 R2: Automatizando tareas administrativas: powershell(3)

Jul 28th, 2011 by juansa. No comments yet

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.

Posted in: Scripting, Windows 2008 R2.

2008 R2: Automatizando tareas administrativas: powershell(2)

Jul 24th, 2011 by juansa. No comments yet

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ónflechas 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.

Posted in: Scripting, Windows 2008 R2.

Directivas: Tareas administrativas 01

Jul 5th, 2011 by juansa. No comments yet

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

 

Posted in: Directivas, Windows 2008 R2, WinR2.

Herramientas para Directivas (w2008R2)

Jun 27th, 2011 by juansa. No comments yet

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:

o Habilitar las GPO de inicio, y crearne de nuevas. o Crear nuevas directivas de grupo de dominio o Crear nuevas directivas de grupo usando las GPO de inicio como plantillas o Crear y configurar vínculos de directivas a Sites, Dominios y Unidades Organizativas. o Ver y administrar Directivas de Grupo en dominios en el bosque AD local y de

confianza. o Realizar copia de seguridad y restaurar una o todas las directivas en un dominio o Realizar copia de seguridad y restaurar una o todas las GPO de inicio en un dominio o Importar directivas de grupo desde dominios externos y migrar configuraciones de

seguridad usando tablas de migración para asegurar una importación correcta. o Administrar Exigido en vínculos de directiva, y habilitar/deshabilitarlos. o Configurar la herencia en Sites, dominios y UOs. o Administrar el estado de las directivas para controlar que nodos de la directiva están

habilitados/deshabilitados. o Crear y vincular filtros WMI para Directivas de Grupo o Administrar el filtrado de seguridad de Directivas de Grupo o Administrar la delegación y administración de seguridad o Administrar el orden de procesamiento en contenedores con múltiples vínculos de

directiva o 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.

o Generar informes en HTML como resumen de configuraciones y ajustes. o Ejecutar el modelado de directivas para ver  cómo se aplicarán a usuarios y/o equipos

en contenedores específicos. o Ejecutar el conjunto de resultados y ver cómo se han aplicado a usuarios y/o equipos

específicos. o …

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.

 

Posted in: Directivas, Impresión, Windows 2008 R2, Windows Server, WinR2.

R2 y las GPO -IV

Jun 17th, 2011 by juansa. No comments yet

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.