Desactivar y mover cuentas de equipo a una OU determinada

En ocasiones, puede resultar de utilidad desactivar varias cuentas de máquina y moverlas a una OU determinada. Por lo cual a continuación vamos a ver cómo hacer esto con la ayuda de PowerShell.

Nota: Ya se debe contar con un archivo .txt que contenga el listado de las cuentas de máquina

Lo primero que debemos hacer es crear una OU a la cual moveremos las cuentas de equipo, la cual he llamado OldComputers. Después de tener creada la OU y tener listo el archivo txt con los nombres de las máquinas debemos ejecutar el siguiente código de PowerShell

Nota: Si requiere encontrar máquinas en las cuales no se haya iniciado sesión desde hace determinado tiempo, puede consultar este post, tal vez le sea de utilidad para generar el archivo txt de entrada

Después de ejecutar el código las máquinas listadas en el archvo serán desactivadas y posteriormente movidas a la OU que especificamos.

Cuentas de equipo que no han iniciado sesión después de una fecha determinada

Una de las tareas más frecuentes cuando se está administrando Active Directory bien sea por temas de mantenimiento, auditoria, entre otros...es la identificación de cuentas de equipo antiguas, de máquinas inexistentes, algunas de ellas pueden ser fáciles de identificar porque la máquina se retiró del dominio y se encuentra des-habilitada, pero muchas otras se encuentran activas y no sabemos si están siendo utilizadas o no, es en ese momento cuando nos surge la pregunta ¿Cómo encuentro las cuentas de máquina en las cuales no se ha iniciado sesión hace determinado tiempo?. Bien pues vamos a ver cómo utilizar PowerShell para encontrarlas, en el ejemplo a continuación se generará un archivo CSV que contiene las cuentas de máquina donde no se ha iniciado sesión desde hace más de un año (365 días).

Si verificamos el valor de la variable $fecha podemos ver la fecha que se evaluará, y cualquier fecha que sea menor a la fecha indicada será lo que se exporte al archivo CSV

Con lo cual el resultado será un archivo CSV que contiene todas las cuentas de equipo cuyo atributo lastLogonTimestamp sea menor al dato de la variable fecha, que para esta caso es: miércoles, 22 de junio de 2016 9:28:33 a. m.

El resultado: un archivo CSV que contiene el nombre del host y la fecha del último logon

Gracias por la atención y como siempre, espero les sea de utilidad.

Instalación de Active Directory en Windows Server 2016

A continuación vamos a ver los pasos para instalar Active Directory en Windows Server 2016, en realidad se trata de una tarea básica que ya hemos hecho en versiones anteriores, simplemente lo hago con el fin de ver si existe algún cambio, y además para escribir algunos otros artículos sobre AD en Windows Server 2016, así que veamos el paso a paso.

De igual forma que en Windows Server 2012 no existe el dcpromo, así que agregamos el rol directamente desde Server Manager.

Leemos las recomendaciones antes de instalar como por ejemplo tener el servidor actualizado y hacemos clic en Next

En tipo de instalación dejamos marcada la primer opción (que es la predeterminada) y hacemos clic en Next

Seleccionamos el servidor y hacemos clic en Next. Es una buena oportunidad para revisar la dirección IP y el nombre del servidor.

En roles de servidor, marcamos Active Directory Domain Services, si solicita características adicionales las agregamos, y luego hacemos clic en Next

En características dejamos las que se encuentran marcadas, por ejemplo podemos ver la consola de directivas de grupo y las consolas de administración.

Por fin algo diferente, la siguiente ventana nos muestra a parte de unas recomendaciones, podemos ver información sobre Azure Active Directory y contiene enlaces para obtener más información así como también un enlace con información para configurar Office 365 con Azure AD Connect

Por último la confirmación de la configuración elegida, y la opción para reiniciar de manera automática el servidor si se requiere.

Al finalizar la instalación, y de la misma manera que en Windows Server 2012, aparece la opción para promover el servidor como controlador de dominio, hacemos clic para empezar.

El asistente para promover el servidor no cambia para con respecto a la versión anterior, lo primero elegir el tipo de despliegue, en este caso crearemos un nuevo bosque llamado itpros-dc.local

A continuación  podemos seleccionar el nivel funcional, mínimo Windows Server 2008, la opción para el servicio DNS, GC, RODC y la contraseña del modo de restauración de servicios de directorio (DSRM). 

En Opciones DNS hacemos clic en Next para continuar.

En nombre NetBIOS dejamos el nombre sugerido y hacemos clic en Next

Seleccionamos las clásicas rutas de bases de datos, logs y SYSVOL y hacemos clic en Next

Una última revisión a la configuración elegida y hacemos clic en Next

Verificamos que se cumplan todos los prerequisitos y hacemos clic en Install

Al finalizar y después de reiniciar ya tenemos instalado nuestro controlador de dominio en Windows Server 2016, como podemos ver ni hay ningún cambio en la instalación, todo sigue igual que antes, en otros artículos explicaré lo que se ha incluido nuevo en los servicios de dominio de Active Directory.

Grupo de estudio: Active Directory virtual

Este trimestre, en la comunidad ITPros-DC lanzamos nuestro primer grupo de estudio virtual, la oportunidad fue para Active Directory. La primer sesión se llevó a cabo el pasado jueves 1 de septiembre, este grupo a diferencia de los presenciales se lleva a cabo entre semana, los grupos de estudio presenciales si continúan los sábados.

Se ha creado un Meetup donde todos mantendremos al tanto del desarrollo del grupo . Las sesiones están siendo llevadas a cabo gracias a la tecnología de Citrix GoToTraining

Durante esta primera sesión vimos los siguientes temas:

Fundamentos de Active Directory (base de datos, Dominios, árboles, bosques, GC)
Instalación y puesta en marcha de un controlador de dominio.

Bien, la cita es el próximo jueves a las 8:00 pm. Los espero!

Configuración de inicio de sesión con Azure AD Connect

Hoy en día es bastante común utilizar Azure AD Connect para sincronizar las identidades locales con Azure AD con el fin de poder utilizar el inicio de sesión único o SSO con Office 365 particularmente, y una de las primeras tareas que debemos llevar a cabo es la configuración de un UPN "ruteable" en Internet y que efectivamente coincida con el nombre de dominio verificado en el directorio en Azure.

En este post vamos a ver las opciones que incorpora el asistente de instalación de Azure AD Connect para facilitarnos el proceso de configuración.

Si el asistente detecta que el UPN de nuestras identidades locales no coinciden con el que se encuentra en el directorio de Azure mostrará la siguiente advertencia:

Como se puede apreciar el asistente claramente indica que no es posible iniciar sesión en Azure AD con las mismas credenciales locales (on-premises), lo cual es cierto ya que mi dominio local se llama itpros-dc.loc y mi dominio registrado en Azure AD es cesarherrada.com tal como se muestra en la imagen a continuación:

Veamos solo el recuadro principal para mejor comprensión.

En la columna de la izquierda tenemos los UPN que el asistente encontró, si se están preguntando porque aparte de mi UPN local itpros-dc.loc muestra el UPN cesarherrada.com. Ocurre de este modo debido a que tengo configurado a nivel de Active Directory dicho UPN, veamos cómo se hace esto:

Abrimos la consola Active Directory Domains and Trusts y hacemos clic derecho sobre la raìz y seleccionamos Properties

En la siguiente ventana podemos agregar el sufijo UPN que necesitemos, en mi caso he agregado el UPN cesarherrada.com

Después de hacer esto, nuestro dominio consta de más de un sufijo UPN, lo cual también nos permite cambiarlo directamente sobre los usuarios,tal como se muestra a continuación:

Con esto podemos cambiar el UPN de nuestros usuarios y establecer uno valido en Internet, lo cual vamos a requerir por ejemplo si queremos sincronizar las identidades para usar las mismas locales en Office 365 por ejemplo. Si desea saber más sobre la sincronización de identidades con Office 365 puede consultar el siguiente artículo: Identidad sincronizada con Office 365

Y ahora si, teniendo claro esto, entendemos porqué muestra dos sufijos UPN la tabla del asistente de instalación de AD Connect, y también podemos ver que el UPN cesarherrada.com lo muestra como Verified en Azure AD mientras que el UPN itpros-dc.loc aparece en estado Not Added. Ahora comprendamos mejor el significado de estos estados:

Verified: Esto significa verificado, es decir; encontró que el UPN que vamos a usar cuenta con un dominio verificado en Azure AD, verificado significa que hemos comprobado la propiedad de ese dominio y por lo tanto podemos hacer uso del mismo, en este caso no es necesaria ninguna acción y es lo que generalmente deseamos que aparezca en el asistente-

Not Verified: Esto significa que el asistente encontró un dominio en Azure AD que coincide con el UPN pero aún no ha sido verificado, lo cual significa que debemos completar el proceso de verificación para poder usar dicho dominio, si no lo hacemos el UPN que se establecerá en la nube tendrá el sufijo ".onmicrosoft.com", 

Not Added: Azure AD Connect no encontró un dominio en Azure AD que coincida con el UPN que tenemos, como se puede apreciar, este es precisamente mi caso con el sufijo itpros-dc.loc, claramente este es mi sufijo local no ruteable en Internet, por ende no tengo ningún dominio configurado en Azure AD que coincida con este nombre, y tampoco lo vamos a hacer, para ello he agregado un sufijo UPN adicional que sí coincide con mi nombre de dominio público cesarherrada.com 

Ahora bien, la primera pantalla que puse de AD Connect es la que aparece cuando nos vamos con la configuración Express, pero si elegimos la opción personalizada tendremos la opción de elegir un atributo diferente al UPN, como por ejemplo la dirección de correo electrónico.

Si deseamos usar un atributo alternativo, tenemos que tener en cuenta ciertas restricciones especialmente si vamos a usar Office 365. Por lo cual recomiendo leer el siguiente articulo: Configuring Alternate Login ID

Bien, esto es todo por ahora, y como siempre espero les sea de utilidad.

Agregar contactos a un grupo de Active Directory con PowerShell

Si depronto te has visto en la necesidad de poblar un grupo con objetos de tipo contacto por ejemplo para crear una lista de distribución y deseas usar el cmdlet Add-ADGroupMember te puedes encontrar con el siguiente mensaje de error:

En la imagen anterior utilice lo siguiente para intentar agregar un contacto a un grupo de distribución.

Add-ADGroupMember "Test Group" -Members "CN=testContact,OU=Contacts,OU=Usuarios,DC=lab,DC=loc"

Con lo anterior deseo: Agregar el contacto testContact al grupo Test Group

El cmdlet en este caso no sirve, dado que solo trabaja con principales de seguridad, es decir, objetos que contengan identificador de seguridad (SID), y los objetos tipo contacto no lo tienen.

Por lo cual debemos recurrir a VBScript utilizando ADSI

$contact = [adsi]"LDAP://CN=Test Group,OU=Group,OU=Usuarios,DC=lab,DC=loc"
$contact.Member.Add("CN=testContact,OU=Contacts,OU=Usuarios,DC=lab,DC=loc")
$contact.psbase.CommitChanges()

Para lo anterior abrimos Windows PowerShell ISE y pegamos las líneas de código anteriores, después de ejecutar tenemos el siguiente resultado:

Después de esto efectivamente tenemos ya el contacto e nuestro grupo de distribución.

Esto es todo, y como siempre espero les sea de utilidad.

Activación basada en Active Directory

A partir de Windows Server 2012 tenemos la posibilidad de realizar activación de las máquinas del dominio a través de Active Directory, lo cual significa que una vez unamos los equipos al dominio, al iniciar sesión la máquina se activará de manera automática sin ningún tipo de intervención, los objetos de activación son almacenados en AD, los equipos permanecerán activados mientras sean miembros del dominio, para poder hacer uso de este rol de servidor, es necesario que se cumplan los siguientes requisitos:

1. Nivel funcional del bosque debe ser Windows Server 2012 o posterior
2. Solo funciona con máquinas Windows 8, Windows 8.1, Windows Server 2012 y Windows Server 2012 R2

Es importante aclarar que si en el entorno existen máquinas con versiones de sistema operativo diferentes a la soportada por Active Directory Based-Activation (ADBA) se debe seguir utilizando un servidor KMS para la activación de las mismas.

Ahora veamos el paso a paso de la instalación.

En Server Manager abrimos instalar roles y características y seleccionamos Volume Activation Services y hacemos clic en Next

Agregamos todas las características sugeridas

En la pantalla Volume Activation Services hacemos clic en Next

y luego clic en Install

Al finalizar la instalación podemos abrir de manera inmediata el asistente haciendo clic en Volume Activation Tools

A continuación seleccionamos Active Directory-Based Activation y hacemos clic en Next

Ahora ingresamos la clave KMS para la activación y opcional-mente el nombre para mostrar que llevará el objeto de activación en Active Directory, luego hacemos clic en Next

Seleccionamos el método de activación de la clave KMS, para este ejemplo lo haré en línea y hacemos clic en Commit

Aparecerá un mensaje que nos indica que se creará un objeto de activación en Active Directory. Hacemos clic en Yes

Atención en la siguiente pantalla, pregunta que se deseamos eliminar objetos de activación debemos hacer clic en Next, en caso contrario hacer clic en Close, como en este caso estamos es creando el objeto debemos hacer clic en Close

Y listo, esto es todo...

Ahora cualquier equipo con la versión soportada del sistema operativo una vez se una al dominio será activado de manera automática, si el equipo ya se encuentra en el dominio y simplemente deseamos activar, basta con ejecutar slmgr.vbs /ato desde una consola de comandos.

Un saludo, y como siempre espero sea de utilidad.

Acceso denegado al intentar deshabilitar SID Filtering

Si está ha creado una relación de confianza entre dos bosques de Active Directory y recibe el siguiente mensaje de error al intentar quitar el filtrado de SID:

Access is denied. The command failed to complete successfully

Debe hacer lo siguiente para solucionarlo:

En el servidor de destino, en este caso el que se indica en el parámetro /domain editar la directiva Default Domain Controllers Policy y expandir la siguiente ruta:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Y allí, buscar y habilitar la directiva: Network access: Allow anonymous SID/Name translation

Después de hacer el cambio, ejecutamos gpupdate /force en el controlador de dominio, y al volver al bosque de origen e intentar quitar el filtrado de SID vemos que funcionará sin problema.

Y esto es todo. Como siempre espero que esta información resulte de utilidad para alguien.

Error de contraseña en migración de passwords con ADMT

Si se encuentra utilizando ADMT para migrar usuarios y sus contraseñas, probablemente haya instalado la herramienta PES (Password Export Server) y al escribir la contraseña de la llave de cifrado recibe el siguiente mensaje de error:

The supplied password does not match this encryption key's password. ADMT´s Password Migration Filter DLL will not install without a valid encryption key.

Para solucionar este error, simplemente debemos abrir una consola de comandos (cmd.exe) elevada ***administrador*** y ejecutar el instalador de PES utilizando la herramienta msiexec como se muestra a continuación:

msiexec -i "instalador.msi"

Donde instalador es el nombre que tenga tu paquete de instalación, en mi caso fue de la siguiente forma:

Se abrirá el asistente y cuando lleguemos a la parte de la contraseña, la escribimos:

Y después de hacer clic en el botón OK veremos que ya no aparece el mensaje de error, en su lugar el asistente continuará.

Como siempre, espero sea de utilidad esta información!