Casos de estudio

1. Problemática

Muchas veces existe un gran número de cuentas de equipo inútiles que están presentes en el servicio de directorio Active Directory. La razón es simple: en muchas empresas falta un procedimiento para deshacerse del hardware, o si bien existe para la gestión del hardware físico no existe en cambio para eliminar las cuentas de los equipos. Así, al cabo de algunos años, no es raro tener un 50% de las cuentas de equipos de más. Por lo tanto, puede volverse complicado para un administrador gestionar adecuadamente su parque de equipos. Para intentar volver a poner un poco de orden en el AD DS, desarrollaremos un script que se conectará a un controlador de dominio y recuperará la lista de cuentas de equipo. Para cada cuenta de equipo, miraremos en qué fecha se realizó el último acceso o dicho de otra manera la fecha del último inicio de sesión. Ya que efectivamente, ¡hasta las cuentas de equipo inician sesiones! Una cuenta de equipo inicia una sesión en un dominio autenticándose en el controlador de dominio, igual que un usuario. Con la diferencia de que las contraseñas de las cuentas de equipo se autogeneran.

Se genera una contraseña aleatoria la primera vez cuando un equipo se integra en el dominio. Después cambia cada...

1. Problemática

El resultado es similar al de las cuentas de equipo: los administradores están siempre al corriente cuando se trata de crear una cuenta de usuario pero nunca cuando hay que eliminarla. Esto provoca necesariamente desviaciones que pueden acabar costando caro. En efecto, el número de objetos en el directorio Active Directory Domain Services no para de crecer y los recursos son monopolizados para nada (espacio en disco que almacena los «home directories», cuentas de correo electrónico, etc.).

Por otra parte, una mala gestión de las cuentas de usuario puede causar problemas de seguridad ya que todos sabemos que una contraseña que no cambia se puede fácilmente «romper»...

2. Solución: ¡hacer limpieza!

La intención es loable pero sin un script ¡imposible! En el estudio del caso anterior, focalizamos nuestra atención sobre las cuentas de equipo. Pues sepa que la gestión de cuentas de usuario se realiza con el mismo principio, y las explicaciones del atributo LastLogon y LastLogonTimeStamp siguen siendo válidas. A saber que el atributo LastLogon no se replica entre los controladores de dominio y que LastLogonTimeStamp sí se replica pero cada catorce días aproximadamente. Para simplificarnos la vida, como para las cuentas de equipos, nos contentaremos con usar LastLogonTimeStamp; por lo tanto podremos saber en el peor de los casos la realidad con una diferencia de catorce días con la situación real de la empresa. Pero ¿es realmente importante?

El script que vamos a desarrollar juntos nos permitirá encontrar las cuentas inactivas desde un cierto número de días. Después es libre para adaptarlo y que así corresponda mejor...

1. Problemática

Cuando disponemos de un importante parque de servidores a administrar y deseamos garantizar a nuestra empresa un cierto grado de seguridad, debemos cambiar regularmente las contraseñas de las cuentas con privilegios de administración. Cuando se trata de cambiar la contraseña de una cuenta de dominio, es fácil ya que la cambiamos en un único sitio. Pero cuando se trata de cambiar la contraseña de Administrador local de cada servidor miembro del dominio, ¡es otra historia!

2. Dificultades que superar

Toda la dificultad aquí va a estar ligada al hecho de que en un parque heterogéneo de equipos funcionando con distintas versiones de sistema operativo, no todas...

1. Problemática

Tenemos insomnio porque problemas de seguridad informática nos impiden dormir, a veces las pesadillas se apoderan de nuestro sueño y nos despiertan de repente. Si esto le ocurre también, entonces lea atentamente lo que sigue...

Con la esperanza de detectar una intrusión en el sistema o simplemente para saber si se han nombrado nuevos administradores de dominio sin su autorización, puede ser extremadamente interesante vigilar la creación de cuentas en el grupo «Administradores del dominio». Deseamos por lo tanto estar advertidos por correo electrónico en cuanto se añade este tipo de cuentas, y eso en la medida de lo posible ¡en tiempo real o casi!

2. Solución

Escribir un script basado en los eventos CIM/WMI que funcione continuamente en segundo plano bajo la forma de tarea planificada (scheduled job). Este vigila la aparición de un evento particular en los logs de seguridad. Este evento es el evento de agregación de miembros en un grupo local de seguridad y lleva el ID 4728. En efecto, cuando una modificación de un grupo de seguridad tiene lugar y si se ha activado la directiva de auditoría, entonces se registran automáticamente eventos en el log de seguridad de los controladores de dominio. Este script debe por lo tanto ejecutarse sobre un controlador de dominio.

Deberemos asegurarnos de que se envíe un correo electrónico en caso de agregación de miembros al grupo «Administradores del dominio» y solo en este caso, pues en caso contrario nos ahogaremos en mensajes.

Principio de implementación

En primer lugar es necesario activar la auditoría de seguridad mediante las directivas de grupo aplicadas a los controladores de dominio. Después tendremos que hacer algunas pruebas manuales de agregación de miembros al grupo «Administradores del dominio» y observar el número de ID atribuido al mensaje de información correspondiente a la acción en el visor de eventos de seguridad de Windows.

Una vez escrito el script, lo almacenaremos...

1. Problemática

Pronto será la vuelta al colegio, y ¡vuelta al colegio es sinónimo de jaleo! Como cada año, tendremos varias centenas de cuentas de usuarios que crear para los estudiantes. Pero este año ya no será como los anteriores, ya que ¡esta vez automatizaremos la tarea! Aunque tardemos mucho tiempo en poner a punto el script, es muy probable que aun así ganemos tiempo en comparación con una operación manual. Y aunque no fuese este el caso, al menos conseguiremos una cierta satisfacción personal e intelectual. Por otra parte, estaremos seguros de que todas las cuentas se crearán exactamente de la misma forma, lo que evitará un gran número de errores manuales potenciales. Además, podremos reutilizar este script el siguiente año; lo que nos dejará tiempo para ir a la playa...

Lo ideal sería que a partir de un archivo de texto, podamos importar los usuarios así como todos los parámetros asociados; es lo que intentaremos hacer.

2. Solución

Para responder a esta problemática, lo más sencilla será crear un archivo Excel en el que cada línea contenga la descripción de una cuenta de usuario. Para ello, será necesario empezar nuestro archivo por una fila de encabezado. Cada valor de esta línea deberá llevar el nombre exacto de la propiedad a crear igual a como existe en Active Directory Domain Services.

Importaremos después el archivo así creado en PowerShell...

1. Problemática

Una mañana, su jefe viene a verle y le pide realizar un inventario de las diferentes versiones de una aplicación desplegada en un importante número de equipos. Generalmente es en este momento cuando se da cuenta de que no dispone de una herramienta de informes de aplicaciones, ni de un inventario de despliegue del software actualizado.

2. Solución

Para tratar de responder a este problema, crearemos un script que, para cada cuenta de equipo existente en Active Directory Domain Services, buscará en el registro el número de versión para una aplicación dada. Para nuestro ejemplo, cogeremos como aplicación el lector Windows Media Player.

A continuación puede ver el script resultante:

# Get-MediaPlayerVersion.ps1 
function Get-Key 
{  
  #Acceso al registro  
  $Version = (Get-ItemProperty HKLM:\SOFTWARE\Microsoft\MediaPlayer\PlayerUpgrade ` 
-Name "PlayerVersion" -ea silentlycontinue).PlayerVersion 
 
   if ($Version -eq $null) 
   { 
      $Version="No Instalada" 
   } 
   return $Version ...

1. Problemática

Acabamos de realizar una migración de nuestros servidores DNS y hemos tenido que instalar nuevos equipos para reemplazar los antiguos. Por lo tanto para finalizar esta migración, tenemos que actualizar la configuración de red de todos nuestros servidores para que el cambio sea tomado en cuenta. Nuestros servidores disponen de una configuración de red estática. Por lo tanto un script será bienvenido para automatizar este cambio de configuración. Esto evitará tener que modificar a mano la configuración de cada uno de nuestros servidores, y nos hará ganar un tiempo precioso. Es este caso de estudio, supondremos que el cortafuegos de red y los de los equipos remotos dejan pasar el protocolo ICMP así como las consultas WMI.

Aquí tiene los campos que debemos actualizar en la interfaz gráfica:

Parámetros de red a modificar

2. Solución

Usaremos WMI para interrogar y modificar remotamente los parámetros de la configuración de red.

En primer lugar, nos concentraremos en realizar una función que recupera la configuración DNS de un equipo y que devuelve un objeto personalizado. La llamaremos Get-DNSConfiguration. Después haremos una segunda función para modificar la configuración DNS y la llamaremos Set-DNSConfiguration. Ambas tomarán como entrada un parámetro para indicar el nombre del equipo sobre el que actuar.

Aquí tiene el trabajo hecho:

Función Get-DNSConfiguration

function Get-DNSConfiguration 
{ 
    [CmdletBinding()] 
    Param (   
        [Parameter(Mandatory=$true, ValueFromPipeline=$true)]   
        [String[]]$ComputerName   
    )   
   
    Process    
    {   
      foreach ($computer in $ComputerName)   
      {   ...

1. Problemática

En la empresa, las aplicaciones que utilizan certificados para securizar las comunicaciones con numerosas. Ya sean aplicaciones de trabajo (Web, etc.) o componentes de la infraestructura (agente de supervisión, de despliegue, etc.), todos son susceptibles de estar en el origen de un despliegue de certificados en los servidores. Quien dice certificado dice fecha de caducidad. Y evidentemente, darse cuenta demasiado tarde de que un certificado ha caducado no da buena imagen, sobre todo si provoca una parada de servicio. Por este motivo, le mostramos cómo PowerShell puede avisar de este tipo de desventura.

2. Solución 1: Tarea planificada local PowerShell

Para responder a esta problemática, podríamos imaginar un script ejecutado localmente en cada máquina como una tarea planificada y que devuelve el resultado en el visor de eventos o por correo electrónico. Empecemos creando nuestro script para recorrer el almacén de certificados personales del equipo local y obtener la lista de los que han caducado.

Como ya hemos visto en este libro, existe un proveedor PowerShell para recorrer los almacenes de certificados. Se trata del proveedor Cert:.

PS > Gci Cert:\LocalMachine\My 

Nos queda obtener la lista de los que tienen fecha de caducidad inferior a un límite que fijaremos a 30 días. Para ello, usaremos la propiedad NotAfter de los certificados que corresponde a la fecha final de validez 20/06/2015 en nuestro ejemplo.

Certificado con fecha de caducidad el 20/06/2015

Nuestro script empieza a tomar forma:

$FechaLimite = (Get-Date).AddDays(30) 
Gci Cert:\LocalMachine\My | Where {$_.notafter -lt $FechaLimite} 

El resultado obtenido tiene la forma siguiente:

    Directorio: Microsoft.PowerShell.Security\Certificate::LocalMachine\my 
Thumbprint                                Subject  
----------            ...

1. Problemática

Imagine el escenario donde nos encontramos en un entorno muy restrictivo. En un entorno de este calibre, deseamos delegar la gestión de algunos comandos PowerShell a una serie de personas, incluso a un grupo restringido de ellas. En efecto, no queremos que esta persona sea administrador local ya que podría acceder a datos sensibles y esto no es viable.

Para ilustrar concretamente el escenario, imaginaremos que disponemos de un servidor de impresión en el que deseamos delegar la gestión de los trabajos de impresión y únicamente los trabajos de impresión. ¿Cómo hacer esto?

2. Solución

Debemos crear una sesión de configuración (endpoint) restringida que dará acceso a los comandos de la familia PrintJob (Get-PrintJob, Remove-PrintJob, Restart-PrintJob, Resume-PrintJob, Suspend-PrintJob).

Creación del archivo de configuración

Lo primero que debemos hacer, en el servidor de impresión, es crear una configuración de sesión. Para ello, crearemos primero un archivo de configuración que importaremos en una segunda fase.

La creación de un archivo de configuración se realiza con el comando: New-PSSessionConfigurationFile. 

Aprovecharemos para indicar el autor de este archivo, una descripción, el nombre del módulo a cargar y la lista de funciones avanzadas a las cuales podremos acceder. Para terminar, gracias al parámetro -SessionType indicaremos que deseamos limitar el conjunto de comandos PowerShell al mínimo.

PS > New-PSSessionConfigurationFile `  
      -Path $home\PrintMgmt.pssc `  
      -Author 'A. Petitjean' `  
      -Description "Endpoint restringido para la gestión de los jobs de impresión" ` 
      -CompanyName "www.PowerShell-Scripting.com" `  
      -ModulesToImport PrintManagement `  
      -VisibleFunctions...