Windows Server 2025 / How to Create AD Users, Groups, and Organizational Units

AD users, groups, and organizational units serve different purposes. Use OUs for administration and policy scope, then place users in security groups that receive resource permissions. This makes access changes easier to review than assigning every user separately.

Plan dedicated lab OUs

Under ad.example.test, create Lab with LabUsers, LabGroups, Workstations, and Servers. Keep these separate from default Users and Computers containers. Do not arbitrarily move built-in administrative accounts, service identities, or controllers out of Domain Controllers.

Design OUs around delegation and policies, not merely a copy of the organization chart. Excessive nesting complicates tracing. Keep accidental-deletion protection on new OUs.

Create the user and group in the GUI

1. Open dsa.msc on DC1 or an authorized RSAT PC.
2. Create Lab and the four child OUs.
3. Create labuser1 in LabUsers with a unique initial password and the appropriate change-at-next-logon requirement.
4. Create GG_LabUsers as a global security group in LabGroups.
5. Add labuser1 and confirm membership from both group and user properties.

Use a security group for resource permissions rather than a distribution group. Scope depends on membership and the domains where it will be used; this single-domain lab begins with Global. See New-ADGroup.

Reproduce the configuration with PowerShell

Use the following alternative only before creating those names in the GUI. Run on DC1 or an authorized PC with the AD module. Inspect an existing object’s purpose instead of overwriting it:

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'

Review OU creation and user creation parameters. A password rejected by policy can leave an account in an unexpected state; check errors and Enabled.

Move computer objects and test the standard user

Use the Move action to place CLIENT1 in Lab\Workstations and FS1 in Lab\Servers, confirming neither is a controller. Query the locations and user state:

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

Sign out of CLIENT1, sign in as labuser1@ad.example.test, change the initial password if required, and verify whoami. No file permissions have been assigned to this group yet, so share access failure alone does not indicate failed group creation.

User and computer settings follow their respective object locations. Moving a user does not move that user’s PC object.

Review the effect of membership changes and deletion

Existing sessions can retain old tokens. Compare AD membership with whoami /groups after signing out and back in. Before renaming or deleting users and groups, inspect dependent application and file permissions.

For cleanup, move needed objects to suitable locations and review policy links and delegation. Accidental-deletion protection is deliberate, not a generic error to bypass. Remove protection only for an intentionally selected OU after review, and do not recursively delete the whole Lab tree.