Shore Up
A single blank identity card being filled in by hand and slid into one labeled drawer of a filing cabinet, with the other drawers left shut.
WindowsSecurity

Create a Single Active Directory User with PowerShell, Step by Step

Ketan Aagja7 min read

Before you run this

This guide creates one new user account in Active Directory using the New-ADUser cmdlet: it writes a new user object into an organizational unit you choose, sets a password, and enables the account for sign-in. That's a change to your live directory, so treat it as one.

  • You need elevated rights. Run PowerShell as Administrator, and your account must have permission to create user objects in the target OU — typically a Domain Admin, or an account with delegated "Create User objects" rights on that OU. The ActiveDirectory PowerShell module must be installed (it ships with the AD DS role on a domain controller, and via RSAT on an admin workstation).
  • Test first. Read the script before you run it. Try it in a lab domain or against a throwaway test OU before you use it on production. Creating one test user and deleting it costs nothing and confirms your rights and syntax.
  • What it changes, and what's reversible. This adds an object; it does not modify or delete anything existing, so the create step is low-risk. The account it makes is real and will accept logons once enabled — don't leave a test account sitting enabled with a weak password. Deleting a user later (the undo at the end) is effectively irreversible unless you have the AD Recycle Bin enabled or a system-state backup, so handle Remove-ADUser with the same care.

Assumed environment: Windows Server 2019/2022 (or a Windows 10/11 admin workstation with RSAT), Windows PowerShell 5.1, and a single AD domain named example.com. Adjust names and paths to match yours. If you run PowerShell 7, the AD module works there too via the compatibility layer, but 5.1 is the boring, guaranteed path.

Load the module and confirm you can talk to AD

Open an elevated PowerShell prompt and import the module. On a domain controller it's already present; on a workstation it comes from RSAT.

Import-Module ActiveDirectory

# Sanity check: this should return your domain without error
Get-ADDomain example.com

If Get-ADDomain returns your domain details, you have the module and a working connection. If it errors on the module name, install the AD DS tools (RSAT) first — see Microsoft Learn, "Install RSAT," for the exact feature name on your OS.

Decide the values before you type the command

New-ADUser has one required parameter, -Name, but a usable account needs a few more. Settle these first so you're not improvising at the prompt:

  • Name — the object's common name (CN), e.g. Jane Doe.
  • SamAccountName — the pre-Windows 2000 logon name, e.g. jdoe. Keep it short and unique.
  • UserPrincipalName — the modern logon, e.g. jdoe@example.com.
  • Path — the distinguished name of the OU the user goes in, e.g. OU=Staff,DC=example,DC=com. If you omit -Path, the user lands in the default Users container, which is usually not what you want.

Everything in angle-bracket style below (example.com, OU=Staff,DC=example,DC=com, Jane, Doe, jdoe) is a placeholder — replace it with your real values.

Set the password securely

Don't hard-code a password as plain text in a script. Prompt for it as a SecureString at runtime:

# You'll be prompted; the password is never shown or stored in the script
$Password = Read-Host -AsSecureString "Enter a password for the new user"

The password you type must satisfy your domain's password policy (length and complexity), or New-ADUser will reject it.

Create the user

Here's the standard command. I've written each parameter on its own line with a trailing backtick for readability. Substitute your values.

New-ADUser `
  -Name "Jane Doe" `                                  # CN of the object
  -GivenName "Jane" `
  -Surname "Doe" `
  -DisplayName "Jane Doe" `
  -SamAccountName "jdoe" `                            # pre-2000 logon, must be unique
  -UserPrincipalName "jdoe@example.com" `             # UPN logon
  -Path "OU=Staff,DC=example,DC=com" `                # target OU (DN)
  -AccountPassword $Password `
  -ChangePasswordAtLogon $true `                      # force reset on first sign-in
  -Enabled $true `                                    # account active immediately
  -Description "Created via PowerShell" `
  -WhatIf

Notice the -WhatIf on the last line. With it there, the command shows what it would do and creates nothing:

What if: Performing the operation "New" on target "CN=Jane Doe,OU=Staff,DC=example,DC=com".

That is your dry run. Read the target DN — make sure it's the OU you intended. When it looks right, remove the -WhatIf line and run the command again for real.

A few notes on the parameters:

  • -Enabled $true makes the account immediately usable. If you'd rather stage it and enable it later, set -Enabled $false and turn it on with Enable-ADAccount when you're ready.
  • -ChangePasswordAtLogon $true is standard for a handoff to a real person. It can't be combined with a password that's set to never expire.
  • Any attribute you don't set (title, department, office, manager) can be added later with Set-ADUser. Only set what you're sure of now.

If you want optional attributes like email or job title, they have their own parameters — check Microsoft Learn, "New-ADUser," for the exact names before adding them rather than guessing. Common well-established ones are -EmailAddress, -Title, -Department, and -Office.

Verify it worked

Pull the account back and check the fields you care about:

Get-ADUser -Identity "jdoe" -Properties DisplayName,EmailAddress,Enabled,Description |
  Format-List Name,SamAccountName,UserPrincipalName,Enabled,DistinguishedName

Confirm three things:

  1. Enabled is True (or False if you staged it).
  2. DistinguishedName shows the user in the OU you targeted, e.g. CN=Jane Doe,OU=Staff,DC=example,DC=com.
  3. UserPrincipalName is what you expect.

You can also open Active Directory Users and Computers (dsa.msc), browse to the OU, and see the new object there — a quick visual double-check.

To confirm the logon actually works, have the user sign in (or test with runas), which also triggers the forced password change if you set it.

Undo: remove the account

If this was a test user, or you got a value wrong and want to start clean, remove it. Do the dry run first:

Remove-ADUser -Identity "jdoe" -WhatIf

Read the output, confirm it names the exact user you mean, then run it for real. Without -Confirm:$false it will prompt you before deleting:

Remove-ADUser -Identity "jdoe"

Deletion is not casually reversible. If the AD Recycle Bin is enabled in your forest you can restore a recently deleted object; otherwise recovery means an authoritative restore from backup. For a fresh test account that's no loss, but never point Remove-ADUser at a real person's account without being certain — and never script a bulk removal without a filter and a -WhatIf first.

Where to go next

Once one user is solid, the same cmdlet scales: read a CSV of new hires with Import-Csv and pipe it into New-ADUser in a loop. The parameters are identical — you've already learned the hard part here. For the authoritative parameter list and accepted values, keep the "New-ADUser" and "Set-ADUser" pages on Microsoft Learn open while you work.