Hoy vamos a hablar nuevamente de PowerShell aplicado a Active Directory Domain Services (AD DS). Realmente existen varias opciones cuando pensamos en administrar nuestro entorno de Directory Services desde línea de comando, he incluso desde PowerShell. Dentro de estas opciones tenemos: Snap-In de terceros, tenemos algunos scirpts de .net, tenemos modulos de terceros para PowerShell como podría ser Quest Active Directory Module for Windows PowerShell, que ya lo hemos utilizado en varios videos y demostraciones, y sino también el modulo de AD de PowerShell .
La realidad que de todas estas opciones debemos elegir la que nos resulte más cómoda, personalmente es complejo el tema y yo últimamente estoy utilizando mucho las herramientas de Quest y las propias del modulo de AD de PowerShell de Windows Server. Pero eso es solo porque me siento mas cómodo y por ende mas fácil, lo cual no quiere decir que sea la mejor opción. Es un tema bastante personal.
Me sirve de acceso al módulo de Active Directory de dos maneras. En un controlador de dominio que está ejecutando al menos Windows Server 2008 R2, que añadir la función de administración de Active Directory, y no tengo acceso al módulo de Active Directory. Puedo acceder a él de forma local en el servidor, o puedo usar la comunicación remota o la comunicación remota implícita para acceder a los cmdlets de mi estación de trabajo.
Sin embargo, es importante destacar el tema de la compatibilidad. Por ejemplo, yo utilizo Quest como les comente, pero esos scripts no son 100% compatibles, ya que si quiero implementar el mismo script en distintos clientes voy a necesitar instalar las tools, y no siempre es posible. Es por esto que muchas veces termino utilizando las default del modulo de AD de PowerShell de Windows Server. Este detalle no es menor.
También podemos instalar las Herramientas de administración remota del servidor (RSAT) en nuestra estación de trabajo; por ejemplo en mi trabajo las utilizo para administrar todo mi ambiente desde mi Windows 7 (Si Windows 7 aun, pero bueno no puedo hacer nada al respecto).
Como hemos visto en varias notas, lo que pasa con PowerShell es que mucho de ustedes le tienen miedo, recibo un montón de consultas al respecto, incluso yo muchas veces evito utilizarlo, pero realmente es increíble las cosas que podemos automatizar con el. Con el tiempo me he ido acostumbrando a el, incluso yo lo utilice primero con Exchange Server, y recuerdo haber dado una charla con el GLUE sobre la primera versión llamada MONAD.
Los cmdlets del Módulo Active Directory son fáciles de usar. Por ejemplo, para crear un nuevo usuario (TestUserName) en una unidad organizativa (OU) denominada TestOU en el dominio radians.com.ar, escribo lo siguiente:
New-ADUser -Name TestUserName -Path ‘ou=TestOU, dc=radians, dc=com, dc=ar’
O podríamos utilizar el CMDlet Set-QADGroup para modificar un atributo de un grupo o el CMDlet New-QADGroup para crear un nuevo grupo, etc., etc.
Otra posibilidad que nos brinda PowerShell es utilizarla junto con filtros ADSI, lo cual potencia mucho mas los scripts y obviamente les da muchisima mas complejidad. Por ejemplo, para setear que la contraseña nunca caduque, en el atributo de un usuario. Esta propiedad a diferencia de muchas otras propiedades de objeto de AD están contenidos en máscara de bits atributo UserAccountControl (no relacionada en modo alguno con la función de Control de cuentas de usuario de Windows). Para establecerlo necesitamos recuperar el valor actual de este atributo y utilizar OR (-bor) para calcular un nuevo valor.
$User = [ADSI] "LDAP://cn=rdilello,ou=Users,dc=radians,dc=com,dc=ar"
$UAC = $User.UserAccountControl[0] -bor 65536
$User.Put("userAccountControl",$UAC)
$User.SetInfo()
La ventaja de usar el [ADSI] type accelerator es que lo podemos usar sin importar qué versión de Windows AD DS se estemos ejecutando. No tenemos que tener el servicio de administración de AD instalado, ni necesitamos un servidor que ejecute al menos Windows Server 2008 R2. Lo único que necesitamos es que nuestro dominio cumpla con los requisitos mínimos para utilizar el módulo de Active Directory.
Por lo cual, perdámosle el miedo y empecemos a utilizar PowerShell que nos ayudara mucho en nuestras tareas diarias, y podemos utilizarlo también con otros productos Microsoft, como ser: Exchange, Azure, Office 365, Windows Server, Windows clients, etc.
Espero que les sea de utilidad. Saludos, Roberto Di Lello.
Mas Información:
- Windows Server 2012: Administrandolo con Windows PowerShell 3.0 y el Server Manager {ScreenCast}
- Los primeros pasos del Admin con PowerShell: Testing Service Health {HowTo}
- Pasando desde la linea de comando a PowerShell para Active Directory {Video}
- http://www.quest.com/activeroles-server/
- http://blogs.technet.com/b/heyscriptingguy/
- Windows PowerShell Scripting