Windows Server 2025 / Cómo crear usuarios, grupos y unidades organizativas en Active Directory

Los usuarios, grupos y unidades organizativas de Active Directory (AD) cumplen funciones distintas: la cuenta identifica al usuario, la unidad organizativa (OU) organiza la administración y el ámbito de directivas, y el grupo de seguridad recibe permisos sobre recursos. En este laboratorio creará labuser1 y GG_LabUsers dentro de OU dedicadas. Agregar el usuario al grupo no concede acceso a archivos hasta que se asignen permisos a ese grupo.

Planifique las OU del laboratorio

En el dominio ad.example.test ya operativo, cree la OU Lab y, dentro, LabUsers, LabGroups, Workstations y Servers. Conserve exactamente estos nombres para que coincidan con los comandos. Separe los objetos del laboratorio de los contenedores predeterminados Users y Computers. No traslade cuentas administrativas integradas, identidades de servicio ni los controladores de dominio de su ubicación Domain Controllers de forma arbitraria. Trabaje en DC1 o en un equipo de administración autorizado con las herramientas de Active Directory y derechos de creación y modificación en las ubicaciones previstas.

Diseñe las OU según la delegación administrativa y las directivas necesarias, sin copiar mecánicamente un organigrama. Una jerarquía demasiado profunda dificulta localizar el origen de configuraciones y permisos. La guía de diseño de OU explica esos criterios. Mantenga activada la protección contra eliminación accidental de las nuevas OU; no equivale a una copia de seguridad ni sustituye un plan de recuperación.

Cree el usuario y el grupo con la interfaz gráfica

1. En DC1 o en el equipo autorizado con herramientas RSAT de Active Directory, abra dsa.msc. Compruebe que el dominio seleccionado sea ad.example.test y que utiliza una cuenta con permisos para administrar los objetos del laboratorio.
2. Haga clic derecho en ad.example.test → Nuevo → Unidad organizativa y cree Lab con protección contra eliminación accidental. Dentro de Lab, repita Nuevo → Unidad organizativa para LabUsers, LabGroups, Workstations y Servers; revise la jerarquía antes de continuar.
3. En LabUsers, elija Nuevo → Usuario. Use Lab User One como nombre completo y labuser1 como nombre de inicio de sesión, con el sufijo ad.example.test. Introduzca y confirme una contraseña inicial única conforme a la política, solicite el cambio en el próximo inicio de sesión y revise que no deje la cuenta deshabilitada. No desactive requisitos de contraseña para terminar el ejercicio.
4. En LabGroups, elija Nuevo → Grupo y escriba GG_LabUsers. Seleccione ámbito Global y tipo Seguridad, confirme y revise las propiedades; no elija Distribución.
5. En las propiedades de GG_LabUsers, abra Miembros → Agregar, seleccione labuser1 y confirme la identidad encontrada antes de guardar. Compruebe que aparece en Miembros y, desde las propiedades del usuario, que Miembro de incluye GG_LabUsers.

Elija un grupo de seguridad para asignar permisos a recursos; un grupo de distribución se destina a listas de correo y no sirve para ese control de acceso. El ámbito determina qué miembros puede contener y dónde puede utilizarse: este laboratorio de un solo dominio empieza con Global. Consulte New-ADGroup y la explicación de tipos y ámbitos de grupos de seguridad. La ubicación de GG_LabUsers en LabGroups no añade por sí sola miembros ni permisos.

Reproduzca la configuración con PowerShell

El bloque siguiente es una alternativa a la creación gráfica, no un paso para repetirla. Ejecútelo en Windows PowerShell en DC1 o en un equipo autorizado con el módulo ActiveDirectory instalado y comunicación con el dominio. Compruebe que no existen esos objetos antes de empezar. Si ya existen, revise ubicación, identidad y propósito en lugar de eliminarlos, sobrescribirlos o repetir el bloque completo. Los valores DC=ad,DC=example,DC=test y OU=Lab forman rutas del directorio, no carpetas del disco. Read-Host -AsSecureString solicita la contraseña inicial sin escribirla en el código; no la guarde en texto plano en el informe:

Import-Module ActiveDirectory
$domainPath = 'DC=ad,DC=example,DC=test'
$labPath = 'OU=Lab,' + $domainPath
New-ADOrganizationalUnit -Name 'Lab' -Path $domainPath -ProtectedFromAccidentalDeletion $true
foreach ($ouName in 'LabUsers','LabGroups','Workstations','Servers') {
    New-ADOrganizationalUnit -Name $ouName -Path $labPath -ProtectedFromAccidentalDeletion $true
}
$initialPassword = Read-Host 'Initial password for labuser1' -AsSecureString
New-ADUser -Name 'Lab User One' -SamAccountName 'labuser1' -UserPrincipalName 'labuser1@ad.example.test' -Path ('OU=LabUsers,' + $labPath) -AccountPassword $initialPassword -Enabled $true -ChangePasswordAtLogon $true
New-ADGroup -Name 'GG_LabUsers' -GroupCategory Security -GroupScope Global -Path ('OU=LabGroups,' + $labPath)
Add-ADGroupMember -Identity 'GG_LabUsers' -Members 'labuser1'
Get-ADGroupMember -Identity 'GG_LabUsers'

La referencia de creación de OU explica -Path y la protección contra eliminación accidental. Los parámetros de New-ADUser distinguen el nombre del objeto Lab User One del inicio de sesión labuser1 y del nombre principal labuser1@ad.example.test. -Enabled $true solicita habilitar la cuenta y -ChangePasswordAtLogon $true exige cambiar la contraseña al iniciar sesión. La última consulta del bloque debe incluir labuser1 entre los miembros directos de GG_LabUsers; no demuestra que el usuario haya iniciado sesión o tenga acceso a una carpeta.

Si la política rechaza la contraseña, New-ADUser puede haber creado el objeto aunque la cuenta no quede habilitada. Revise el error y Enabled antes de continuar: no dé por hecho que todo se revirtió ni vuelva a crear el mismo usuario. En Usuarios y equipos de Active Directory, localice labuser1, establezca una contraseña válida mediante Restablecer contraseña y habilite la cuenta cuando corresponda, conservando el cambio al próximo inicio de sesión. La referencia para restablecer una contraseña de AD describe la alternativa administrativa. No use una contraseña vacía ni desactive la política para forzar la habilitación.

Mueva los equipos y pruebe el usuario estándar

Antes de mover equipos, confirme en la consola que existen cinco OU en la estructura prevista: Lab y sus cuatro hijas. Revise que labuser1 está en LabUsers y GG_LabUsers en LabGroups, con categoría Seguridad y ámbito Global, y que la consulta de miembros devuelve el usuario esperado. Si falta una parte, corrija el paso concreto según el error real; que una línea posterior responda no garantiza que todas las anteriores hayan tenido éxito.

Use únicamente los objetos de equipos que ya pertenezcan al dominio. Si CLIENT1 aún no está unido, complete antes la práctica de incorporación del cliente al dominio. FS1 solo aparecerá si lo incorporó como servidor miembro; si todavía no existe en AD, omita su movimiento y su consulta en vez de crear un objeto para ocultar el error. En Usuarios y equipos de Active Directory, haga clic derecho en el objeto correcto y seleccione Mover: CLIENT1 debe quedar en Lab\Workstations y FS1 en Lab\Servers. Confirme que ninguno es un controlador, anote su ubicación anterior y revise el efecto de las directivas de destino antes de moverlo. Después consulte ubicación y estado:

Get-ADComputer -Identity 'CLIENT1' | Select-Object Name,DistinguishedName
Get-ADComputer -Identity 'FS1' | Select-Object Name,DistinguishedName
Get-ADUser -Identity 'labuser1' -Properties Enabled | Select-Object SamAccountName,Enabled,DistinguishedName

DistinguishedName debe mostrar OU=Workstations,OU=Lab para CLIENT1 y, si existe como miembro, OU=Servers,OU=Lab para FS1, seguidos por DC=ad,DC=example,DC=test. Para labuser1, compruebe SamAccountName, Enabled True y la ruta OU=LabUsers,OU=Lab. Después guarde el trabajo y cierre la sesión en CLIENT1; no se limite a bloquearla. Elija Otro usuario, entre como labuser1@ad.example.test, cambie la contraseña inicial cuando se solicite y ejecute whoami: debe identificar AD\labuser1. Este grupo aún no tiene permisos de archivo asignados; un acceso denegado a un recurso compartido no demuestra por sí solo que el grupo se haya creado mal.

Las configuraciones de usuario y equipo se evalúan según las ubicaciones de sus respectivos objetos y las directivas aplicables. Mover labuser1 no mueve el objeto CLIENT1, y colocar GG_LabUsers en una OU no coloca allí a sus miembros. Si un movimiento tiene un efecto no previsto, revise los vínculos y herencia de directivas, y valore devolver solo ese objeto a la ubicación anterior registrada. No mueva otros objetos para intentar compensar el resultado.

Revise los cambios de pertenencia y la limpieza

Las sesiones existentes pueden conservar información anterior de grupos en su token de acceso, el objeto que representa el contexto de seguridad de la sesión o proceso. La documentación sobre tokens de acceso explica que incluye los grupos del usuario. Tras un cambio, guarde el trabajo, cierre la sesión y vuelva a iniciarla como labuser1; compare whoami /groups con la pertenencia en AD y con Get-ADGroupMember. Abrir otra ventana dentro de la sesión antigua no sustituye esa nueva autenticación. Antes de renombrar o borrar usuarios y grupos, revise dependencias en aplicaciones y permisos de archivos.

Mantenga los objetos para las siguientes prácticas. Si decide limpiar el laboratorio, inventaríe primero los objetos necesarios, sus ubicaciones, vínculos de directivas, delegación y permisos dependientes. Mueva los objetos que deban conservarse a un destino adecuado antes de plantear eliminar una OU. La protección contra eliminación accidental es intencionada: quite esa protección solo de una OU seleccionada y revisada expresamente, sin desproteger ni borrar recursivamente todo Lab. Registrar un error de acceso no justifica eliminar la jerarquía o modificar cuentas administrativas ajenas al ejercicio.