{"id":2642,"date":"2014-11-13T01:10:47","date_gmt":"2014-11-13T04:10:47","guid":{"rendered":"http:\/\/www.radians.com.ar\/blog\/?p=2642"},"modified":"2018-01-16T17:12:43","modified_gmt":"2018-01-16T20:12:43","slug":"potenciando-nuestro-active-directory-domain-services-ad-ds-con-powershell-howto","status":"publish","type":"post","link":"https:\/\/www.radians.com.ar\/blog\/?p=2642","title":{"rendered":"Potenciando nuestro Active Directory Domain Services (AD DS) con PowerShell {HowTo}"},"content":{"rendered":"

\"www.radians.com.ar<\/a> Hoy vamos a hablar nuevamente de PowerShell aplicado a Active Directory Domain Services (AD DS<\/em>). Realmente existen varias opciones cuando pensamos en administrar nuestro entorno de Directory Services desde l\u00ednea 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\u00eda ser Quest Active Directory Module for Windows PowerShell<\/font>, que ya lo hemos utilizado en varios videos y demostraciones, y sino tambi\u00e9n el modulo de AD de PowerShell .<\/p>\n

La realidad que de todas estas opciones debemos elegir la que nos resulte m\u00e1s c\u00f3moda, personalmente es complejo el tema y yo \u00faltimamente 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\u00f3modo y por ende mas f\u00e1cil, lo cual no quiere decir que sea la mejor opci\u00f3n. Es un tema bastante personal.<\/p>\n

Me sirve de acceso al m\u00f3dulo de Active Directory de dos maneras. En un controlador de dominio que est\u00e1 ejecutando al menos Windows Server 2008 R2, que a\u00f1adir la funci\u00f3n de administraci\u00f3n de Active Directory, y no tengo acceso al m\u00f3dulo de Active Directory. Puedo acceder a \u00e9l de forma local en el servidor, o puedo usar la comunicaci\u00f3n remota o la comunicaci\u00f3n remota impl\u00edcita para acceder a los cmdlets de mi estaci\u00f3n de trabajo. <\/p>\n

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.<\/p>\n

Tambi\u00e9n podemos instalar las Herramientas de administraci\u00f3n remota del servidor (RSAT) en nuestra estaci\u00f3n 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). <\/p>\n

Como hemos visto en varias notas, lo que pasa con PowerShell es que mucho de ustedes le tienen miedo, recibo un mont\u00f3n de consultas al respecto, incluso yo muchas veces evito utilizarlo, pero realmente es incre\u00edble 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\u00f3n llamada MONAD.<\/p>\n

Los cmdlets del M\u00f3dulo Active Directory son f\u00e1ciles de usar. Por ejemplo, para crear un nuevo usuario (TestUserName) en una unidad organizativa (OU) denominada Tes<\/strong>tOU<\/strong> en el dominio radians.com.ar, escribo lo siguiente:<\/p>\n

New-ADUser -Name TestUserName -Path ‘ou=TestOU, dc=radians, dc=com, dc=ar’<\/font><\/p>\n

O podr\u00edamos utilizar el CMDlet Set-QADGroup<\/font> para modificar un atributo de un grupo o el CMDlet New-QADGroup<\/font> para crear un nuevo grupo, etc., etc.<\/p>\n

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\u00f1a nunca caduque, en el atributo de un usuario. Esta propiedad a diferencia de muchas otras propiedades de objeto de AD est\u00e1n contenidos en m\u00e1scara de bits atributo UserAccountControl (no relacionada en modo alguno con la funci\u00f3n 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.<\/p>\n

$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()<\/font><\/p>\n

La ventaja de usar el [ADSI]<\/strong> type accelerator<\/font><\/font> es que lo podemos usar sin importar qu\u00e9 versi\u00f3n de Windows AD DS se estemos ejecutando. No tenemos que tener el servicio de administraci\u00f3n de AD instalado, ni necesitamos un servidor que ejecute al menos Windows Server 2008 R2. Lo \u00fanico que necesitamos es que nuestro dominio cumpla con los requisitos m\u00ednimos para utilizar el m\u00f3dulo de Active Directory.<\/p>\n

Por lo cual, perd\u00e1mosle el miedo y empecemos a utilizar PowerShell que nos ayudara mucho en nuestras tareas diarias, y podemos utilizarlo tambi\u00e9n con otros productos Microsoft, como ser: Exchange, Azure, Office 365, Windows Server, Windows clients, etc.<\/p>\n

Espero que les sea de utilidad. Saludos, Roberto Di Lello.<\/p>\n

Mas Informaci\u00f3n:<\/h4>\n