Creación y actualización de usuarios desde CSV de RRHH con PowerShell

Cuando el departamento de RR. HH. envía listados de altas, bajas y cambios de personal cada semana, lo último que le apetece a un administrador es estar creando cuentas a mano en Active Directory o Microsoft 365. Automatizar la creación y actualización de usuarios desde un archivo CSV con PowerShell es una forma muy eficaz de ahorrarse trabajo repetitivo, reducir errores humanos y tener el directorio siempre al día.

En entornos híbridos o totalmente en la nube, la idea es la misma: partir de una fuente de datos, normalmente RR. HH., y que los usuarios se creen, actualicen o deshabiliten sin casi intervención manual. PowerShell, junto con cmdlets como New-ADUser, New-MsolUser o New-MgUser e Import-Csv, pone todo lo necesario encima de la mesa para construir desde un simple script hasta un flujo completamente automatizado integrado con SharePoint, bases de datos o ficheros planos.

Conceptos básicos: de RR. HH. al directorio con CSV y PowerShell

La base de todo el proceso es muy sencilla: RR. HH. mantiene un listado estructurado de personas y sus datos (nombre, apellidos, cuenta, departamento, etc.), y desde TI se aprovecha esa información para crear o modificar cuentas de usuario. El formato de intercambio más práctico suele ser un archivo CSV (valores separados por comas u otro delimitador).

Un CSV no es más que un fichero de texto plano donde cada línea representa un usuario y cada columna, un atributo. La primera línea del archivo contiene los nombres de las columnas, que usaremos como propiedades en PowerShell. Es crucial que estos encabezados coincidan con los parámetros o propiedades que vayamos a usar en los cmdlets, por ejemplo, GivenName, Surname, SamAccountName, UserPrincipalName, Department, etc.

Por la parte de PowerShell, la pieza clave es el cmdlet Import-Csv, que lee el archivo y genera un objeto por cada fila. A partir de ahí, podemos encadenar esos objetos en un pipeline hacia cmdlets como New-ADUser, New-MsolUser o New-MgUser, o recorrerlos con un bucle foreach para tener más control sobre la lógica de negocio (validaciones, comprobaciones previas, asignación de grupos, etc.).

Antes de empezar a crear usuarios como si no hubiera un mañana, conviene preparar el entorno. En un dominio on-premises necesitamos tener instalado y habilitado el módulo ActiveDirectory (Windows Server 2008 R2/2012 o superior). En entornos Microsoft 365/Azure AD podemos trabajar con el módulo clásico MSOnline o, mejor aún, con el nuevo módulo Microsoft Graph PowerShell.

Creación masiva de usuarios en Active Directory on-premises con New-ADUser

En un entorno de Directorio Activo clásico, la herramienta más flexible para aprovisionar cuentas es el módulo de Active Directory con PowerShell. El cmdlet New-ADUser permite crear desde una única cuenta hasta miles de usuarios, con un nivel de detalle de atributos muy difícil de conseguir con interfaces gráficas como ADUC o ADAC.

La sintaxis de New-ADUser es extensa, con más de 60 parámetros, pero en la práctica solemos trabajar siempre con un subconjunto. Propiedades como Name, GivenName, Surname, SamAccountName, UserPrincipalName, Path, Enabled, AccountPassword y otras similares cubren la mayoría de escenarios de alta de usuario. Para el resto de atributos menos habituales tenemos el parámetro -OtherAttributes.

Algo importante a recordar es que, si creamos un usuario con los parámetros mínimos, la cuenta se crea en el contenedor predeterminado “Users”, está deshabilitada, no tiene contraseña y pertenece al grupo Domain Users. Si queremos que la cuenta sea funcional desde el primer momento, hay que establecer una contraseña válida, habilitarla y, normalmente, configurar algunos otros datos básicos como OU, departamento o ciudad.

En lugar de rellenar todos los parámetros a mano cada vez, es habitual definir una especie de “plantilla” de usuario. Esa plantilla puede ser literalmente una cuenta de AD que copiamos mediante el parámetro -Instance o un objeto que rellenamos con los valores comunes y pasamos a New-ADUser. De este modo, podemos clonar propiedades como grupos, oficina, departamento o atributos personalizados sin reescribirlos en cada comando.

Preparar el archivo CSV para Active Directory

Para crear cuentas en masa con New-ADUser, lo primero es construir correctamente el CSV. Lo más cómodo suele ser usar Excel, LibreOffice Calc o similar. En la primera fila colocamos los nombres de las propiedades que queramos usar (sin el guion que aparece en los cmdlets). Por ejemplo, si en PowerShell vamos a usar -GivenName, en el CSV la columna debe llamarse GivenName.

En cada fila siguiente, añadimos los datos de un usuario respetando las columnas. Es importante que el archivo se guarde codificado en UTF-8 y con un delimitador estándar. Si usamos coma, Import-Csv funcionará sin parámetros extra, pero si usamos punto y coma u otro símbolo, debemos especificarlo con -Delimiter. Algo así como:

Import-Csv «C:\UsuariosEmpresa.csv» -Delimiter «;»

Los campos mínimos para un alta básica suelen ser SamAccountName, GivenName, Surname, UserPrincipalName y Password. Otros campos como City, Department, Company, OU, teléfono o atributos de extensión se pueden añadir como columnas adicionales e incluiremos su uso en el script cuando nos interese.

Script típico para crear usuarios de AD a partir de CSV

Un esquema muy habitual para crear usuarios on-prem desde un CSV es el siguiente: importar los datos, generar el UPN y construir el nombre completo, asignar contraseña segura y establecer propiedades adicionales (ciudad, ruta de OU, expiración de contraseña, etc.).

Por ejemplo, podríamos leer un archivo C:\UsuariosEmpresa.csv y para cada registro generar el UPN basándonos en una columna Cuenta y en el dominio, construir el nombre completo y crear el usuario en una OU concreta:

Import-Csv «C:\UsuariosEmpresa.csv» | ForEach-Object {
$upn = $_.Cuenta + «@empresa.local»
$uname = $_.Nombre + » » + $_.Apellidos
New-ADUser -Name $uname -Surname $_.Apellidos -SamAccountName $_.Cuenta -UserPrincipalName $upn -City $_.Provincia -Path «OU=Usuarios,DC=empresa,DC=local» -AccountPassword (ConvertTo-SecureString $_.Password -AsPlainText -Force) -Enabled $True -PasswordNeverExpires $True -PassThru}

En este ejemplo, cada fila del CSV contiene, como mínimo, las columnas Cuenta, Nombre, Apellidos, Provincia y Password. Además de crear el usuario, se establece una contraseña en texto plano que convertimos a cadena segura con ConvertTo-SecureString, se habilita la cuenta y se marca la contraseña como no expirable.

Si necesitamos más atributos, basta con añadir columnas en el CSV (por ejemplo, Department, Company, Office) y extender el comando New-ADUser con parámetros como -Department $_.Departamento. Incluso podemos añadir el usuario a uno o varios grupos en el mismo proceso usando Add-ADGroupMember, siempre que nos aseguremos de que las cuentas existan antes de intentar agregarlas.

Importación masiva sencilla con pipeline directo

Cuando los datos del CSV están ya preparados con nombres de columna que coinciden con los parámetros de New-ADUser, podemos usar una forma aún más compacta: pasar directamente el resultado de Import-Csv a New-ADUser. Por ejemplo:

Import-Csv .\usuarios.csv | New-ADUser

En este caso, cada columna se asigna automáticamente al parámetro correspondiente, aunque no podremos forzar propiedades comunes para todas las cuentas salvo que las indiquemos explícitamente. Lo habitual es enriquecer este pipeline con opciones adicionales:

Import-Csv .\usuarios.csv | New-ADUser -Enabled $True -AccountPassword (ConvertTo-SecureString -AsPlainText «Usuario.123» -Force) -Path «CN=Users,DC=empresa,DC=local»

Con esta variante, además de crear las cuentas según los campos del CSV, todas arrancan habilitadas, con una contraseña común y en una ruta de AD predeterminada. Es muy útil cuando queremos un alta inicial homogénea para todos los empleados de una misma oleada.

Uso de atributos avanzados y tipos especiales de usuario

New-ADUser no se limita a los atributos más conocidos. Con el parámetro -OtherAttributes podemos asignar valores a casi cualquier atributo de esquema, incluyendo atributos de extensión como extensionAttribute1-15 o campos personalizados como carLicense.

Además, no todos los usuarios de AD tienen por qué ser de clase user. En algunos escenarios de integración con aplicaciones heredadas o LDAP, puede ser útil crear objetos de clase inetOrgPerson. Esto se consigue con el parámetro -Type inetOrgPerson en New-ADUser, manteniendo el resto de propiedades como en una cuenta estándar.

En cuanto a la contraseña, podemos optar por crear el usuario inicialmente sin contraseña y luego usar Set-ADAccountPassword y Enable-ADAccount, o bien especificar la contraseña en la creación y habilitar la cuenta con sus flags adecuados. En entornos corporativos se suele exigir que el usuario cambie la contraseña en el primer inicio de sesión, opción que podemos activar con propiedades de la cuenta o cmdlets adicionales.

También es muy útil la técnica de crear un nuevo usuario basado en otro existente. Mediante Get-ADUser obtenemos el usuario “plantilla”, seleccionamos las propiedades que nos interesan y las guardamos en un objeto. Después, utilizamos New-ADUser con el parámetro -Instance apuntando a ese objeto, ajustando únicamente los atributos que deban ser únicos (como SamAccountName, UPN o correo).

Automatizar altas desde RR. HH. y listas de SharePoint

En muchas organizaciones, RR. HH. mantiene una lista de incorporaciones, bajas y cambios en SharePoint Online o en una lista de Microsoft 365. Un escenario muy típico consiste en exportar manualmente esa lista a CSV, pasarla al servidor on-prem y ejecutar un script de PowerShell para crear las cuentas. Este enfoque funciona, pero obliga a que alguien esté pendiente de esa exportación periódica.

Para avanzar hacia una automatización total, se puede plantear un flujo donde el propio SharePoint o Power Automate genere el CSV y/o dispare el script de PowerShell. En un entorno híbrido, la secuencia suele ser: la lista de RR. HH. se actualiza, el flujo genera el archivo con la estructura que espera nuestro script, ese archivo se deja en un recurso compartido y un script programado en un servidor con el módulo de Active Directory se encarga de procesarlo.

En esta automatización conviene prever algunos puntos delicados. Debemos comprobar si el usuario ya existe para evitar duplicados, manejar cambios de departamento u OU (que podrían implicar mover el objeto en AD con Move-ADObject) y distinguir entre altas, actualizaciones y bajas. En lugar de un único CSV “plano”, RR. HH. puede incluir una columna “Acción” con valores como Alta, Modificación o Baja para que el script actúe en consecuencia.

Cuando el entorno es híbrido, las cuentas se crean en el AD on-prem y luego se sincronizan hacia Azure AD/Microsoft 365 a través de Azure AD Connect. Por tanto, toda la lógica de alta inicial suele residir en el directorio local. Una vez sincronizadas, ya podemos completar atributos propios del entorno cloud (licencias, grupos M365, buzones, etc.).

Para quienes quieran evitar desarrollar demasiada lógica a medida, existen soluciones específicas, como Netwrix Directory Manager, que permiten sincronizar automáticamente los datos de RR. HH. con Active Directory y Azure AD. Estas herramientas se conectan a múltiples orígenes (CSV, bases de datos SQL u Oracle, etc.) y proporcionan una interfaz gráfica y trabajos de sincronización programables para crear, actualizar y desaprovisionar usuarios con menos scripting manual.

Creación y actualización de usuarios en Microsoft 365 y Azure AD desde CSV

Cuando el foco está en la nube, la filosofía es la misma pero con otras herramientas. Podemos trabajar con el módulo MSOnline o, preferentemente, con el módulo Microsoft Graph PowerShell, que es el estándar moderno para gestionar Microsoft 365 y Entra ID (Azure AD).

En ambos casos, partimos también de un archivo CSV que incluye las propiedades necesarias. En la gestión cloud cobra especial importancia el UserPrincipalName, la licencia y el UsageLocation, dado que determinan cómo inicia sesión el usuario y qué servicios tiene habilitados.

Para conectarse con Microsoft Graph PowerShell, necesitamos una cuenta con rol adecuado (por ejemplo, Administrador de usuarios o Administrador global) y conceder los permisos necesarios al módulo. De forma típica, nos conectamos así:

Connect-MgGraph -Scopes «User.ReadWrite.All»

Una vez establecida la conexión, ya podemos usar cmdlets como New-MgUser, Get-MgUser o Set-MgUserLicense para dar de alta usuarios, consultar sus datos y asignar licencias. Igual que con AD on-prem, la combinación Import-Csv + foreach nos dará un control detallado del proceso.

Requisitos de propiedades para usuarios de Microsoft 365

Al crear usuarios en Microsoft 365, hay propiedades que son obligatorias y otras opcionales pero muy recomendables. DisplayName y UserPrincipalName son necesarias, mientras que GivenName, Surname, Password, LicenseAssignment y UsageLocation completan el perfil funcional.

El DisplayName es el nombre que verán otros usuarios en Outlook, Teams o SharePoint. El UserPrincipalName es el identificador de inicio de sesión, generalmente en formato . El UsageLocation es el código de país ISO 3166-1 alpha-2 (por ejemplo, ES, US, FR), y condiciona las licencias que se pueden asignar por cuestiones regulatorias.

Si no especificamos una contraseña al crear la cuenta, el sistema asignará una contraseña aleatoria visible en el resultado del comando. En muchos proyectos se prefiere establecer una contraseña controlada y forzar el cambio en el primer inicio, por lo que conviene incluir una columna Password en el CSV o construirla según un patrón interno.

La asignación de licencias puede hacerse en el momento del alta o en un segundo paso. Cada licencia se identifica por un SkuId o por un SkuPartNumber, como SPE_E3, SPE_E5, ENTERPRISEPACK, etc. Podemos obtener la lista de SKUs disponibles en el tenant con Get-MgSubscribedSku (Graph) o Get-MsolAccountSku (MSOnline).

Crear usuarios en Microsoft 365 con Microsoft Graph PowerShell

Para dar de alta un usuario individual con Graph, necesitamos crear primero un objeto de contraseña y luego llamar a New-MgUser con todos los parámetros. El PasswordProfile define la contraseña inicial y si el usuario debe cambiarla en el siguiente inicio de sesión (según propiedades asociadas).

Un ejemplo simplificado sería:

$PasswordProfile = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphPasswordProfile
$PasswordProfile.Password = «contraseñaSegura123»
New-MgUser -DisplayName «Juan Pérez» -GivenName «Juan» -Surname «Pérez» -UserPrincipalName «juanp@contoso.onmicrosoft.com» -UsageLocation «ES» -MailNickname «juanp» -PasswordProfile $PasswordProfile -AccountEnabled $true

Para la creación masiva, seguimos el mismo patrón basado en CSV. Construimos un archivo con columnas como UserPrincipalName, FirstName, LastName, DisplayName, UsageLocation, MailNickname y, opcionalmente, alguna información adicional. Luego importamos el archivo y recorremos cada fila con un foreach.

Podemos, por ejemplo, fijar una contraseña común para todos los usuarios o generar una aleatoria por cada uno. En el primer caso, bastaría con definir un PasswordProfile con una contraseña fija y reutilizarlo en cada iteración. Después del alta, podemos asignar licencias con Set-MgUserLicense, obteniendo antes el Sku correspondiente (por ejemplo, SPE_E5) mediante Get-MgSubscribedSku.

Creación masiva con MSOnline y archivo de resultados

Si preferimos el módulo MSOnline, la lógica es parecida. Conectamos al tenant con Connect-MsolService, indicando las credenciales de una cuenta con permisos para gestionar usuarios. Después, importamos el CSV y lo recorremos generando cada usuario con New-MsolUser.

En el CSV podemos incluir columnas como UserPrincipalName, FirstName, LastName, DisplayName, UsageLocation, City, Password, Department. El campo UserPrincipalName representa el correo de inicio de sesión, mientras que Password definirá la contraseña inicial. Una vez cargado el archivo, podemos ejecutar una instrucción del tipo:

Import-Csv -Path C:\datos\users.csv | foreach {New-MsolUser -DisplayName $_.DisplayName -FirstName $_.FirstName -LastName $_.LastName -UserPrincipalName $_.UserPrincipalName -UsageLocation $_.UsageLocation -Password $_.Password -City $_.City -Department $_.Department} | Export-Csv -Path C:\datos\result.csv -NoTypeInformation

Aquí, además de crear los usuarios, redirigimos la salida hacia un segundo CSV con el resultado, que incluirá información como la contraseña generada (si no se especificó una), el estado de la operación y otros datos. Este archivo es muy útil como comprobante para RR. HH. o para los técnicos que tengan que entregar las credenciales a los nuevos empleados.

Si queremos ver rápidamente todas las cuentas creadas en el tenant, podemos usar Get-MsolUser. De forma equivalente, con Microsoft Graph usaríamos Get-MgUser, y en un AD on-prem, Get-ADUser -Filter * para listar todos los usuarios del dominio.

Creación y eliminación de usuarios locales en masa con PowerShell

No todas las automatizaciones se refieren a Active Directory o Microsoft 365. En algunos entornos de laboratorio o equipos aislados puede interesar crear cuentas de usuario locales en masa. Aunque el concepto es el mismo, en lugar de New-ADUser se usan cmdlets como New-LocalUser y Add-LocalGroupMember.

El flujo de trabajo vuelve a repetirse: creamos un archivo usuarios.csv con columnas como nombre y contra, donde “nombre” es el nombre de la cuenta local y “contra” la contraseña inicial. Importamos el CSV con Import-Csv y, mediante un bucle foreach, vamos construyendo cada cuenta.

La contraseña no puede introducirse en texto plano, así que se convierte con ConvertTo-SecureString indicando que viene como texto plano y que se fuerce la conversión. Luego se pasa a New-LocalUser para que se cree la cuenta con esa contraseña segura, marcando opciones como -AccountNeverExpires y -PasswordNeverExpires si nos interesa, y añadiendo el usuario a grupos locales con Add-LocalGroupMember.

Un script típico podría tener esta estructura: importar CSV, recorrer cada fila con foreach, convertir la contraseña y crear el usuario, añadiéndolo a un grupo llamado, por ejemplo, “usuarios”. Guardamos el script (por ejemplo, creaciondeusuarios.ps1), lo ejecutamos en PowerShell ISE con privilegios de administrador y verificamos el resultado con el cmdlet Get-LocalUser.

El mismo enfoque permite la eliminación masiva de cuentas locales. Basta con reutilizar el CSV, pero en lugar de crear usuarios, llamamos a Remove-LocalUser dentro del bucle foreach, pasando el nombre de la cuenta a borrar. Con unas pocas líneas, podemos limpiar rápidamente usuarios de prueba o cuentas temporales que ya no son necesarias.

Buenas prácticas y herramientas adicionales para la sincronización con RR. HH.

A medida que la organización crece, la provisión de cuentas se convierte en un proceso continuo: nuevas altas, cambios de puesto, movimientos entre departamentos, permisos que hay que ajustar y bajas por salida de la empresa. Hacer todo esto a mano es una receta para errores y retrasos, por lo que tiene sentido profesionalizar y automatizar al máximo este flujo.

Una buena práctica es definir claramente qué sistema es la “fuente de la verdad”. En muchos casos, el sistema de RR. HH. es la referencia, y los directorios (AD, Azure AD, Microsoft 365) son consumidores de esa información. Trabajar con CSV es una solución sencilla, pero se puede ir un paso más allá conectando directamente PowerShell a bases de datos SQL u Oracle, o usando herramientas de terceros que hagan esta sincronización de forma bidireccional.

Soluciones como Netwrix Directory Manager permiten, por ejemplo, que los datos de RR. HH. se sincronicen automáticamente con Active Directory, Azure AD y Microsoft 365. Estos productos suelen ofrecer asistentes gráficos donde se definen orígenes (CSV, SQL, Oracle) y destinos (AD, Azure AD, buzones, contactos), así como reglas para crear, actualizar o deshabilitar cuentas en función de cambios detectados en la fuente.

Al diseñar esta integración hay que pensar en todo el ciclo de vida del usuario. No basta con crear la cuenta: hay que mantenerla actualizada (cambios de apellidos, traslados entre departamentos, ascensos) y, muy importante, desactivarla cuando el trabajador abandona la organización. Además, los permisos en grupos de seguridad y de distribución deben reflejar en todo momento el puesto real de la persona, para minimizar riesgos de exceso de privilegios.

También conviene prestar atención a la calidad del dato: un CSV mal formado, con delimitadores incorrectos, codificación errónea o columnas desalineadas puede provocar errores difíciles de localizar. Es recomendable validar los ficheros antes de procesarlos en producción, realizar pruebas en entornos de laboratorio y llevar un registro (logging) de todas las operaciones realizadas para poder auditar cambios y revertir errores si algo se tuerce.

Con una combinación adecuada de buen diseño del CSV, scripts de PowerShell bien estructurados y, si hace falta, herramientas especializadas de sincronización, es posible tener un proceso bastante redondo: RR. HH. prepara o actualiza los datos, y a partir de ahí el alta, modificación y baja de usuarios se produce prácticamente sola, tanto en Active Directory on-premises como en Microsoft 365 y otros sistemas conectados. Esto se traduce en menos tareas rutinarias para los administradores, menos errores de tecleo y una seguridad mucho más ajustada a la situación real de cada usuario.