
Add and Remove an AD User from Groups with PowerShell
Before you run this
These commands add a user account to an Active Directory security or distribution group, or remove it from one, using the ActiveDirectory PowerShell module. Group membership is how most access is granted in AD, so getting it right matters: adding a user to the wrong group can hand out access it should not have, and removing a user from a group can cut off access to file shares, mailboxes, or applications immediately at their next logon or token refresh.
Privileges. You need an elevated PowerShell session (Run as administrator) running under an account with rights to modify the target group — typically a domain admin, or a delegated account with write permission on that group object. You also need the ActiveDirectory module, which ships with RSAT (Remote Server Administration Tools). On a domain controller it is already present; on a management workstation, install RSAT first.
Test first. Read each command before you run it. Do your first run against a test user and a test group you created for the purpose, not a real employee and not a privileged group like Domain Admins. Every command below supports -WhatIf, which shows what would happen without changing anything — use it.
What changes, and whether it reverses. Adding and removing membership are both reversible by doing the opposite operation, so there is no permanent data loss here. But the effect is not instant to undo in the real world: a removed user may lose access mid-session, and re-adding them still requires a new logon or token refresh to take effect. Treat privileged groups with extra care.
What I'm assuming
- A domain-joined Windows 10/11 or Windows Server management box, or a domain controller.
- Windows PowerShell 5.1 (the version that ships with Windows). The
ActiveDirectorycmdlets also work under PowerShell 7 if you import the module, but 5.1 is the mainstream case. - The
ActiveDirectorymodule is available. If it is not, install RSAT — on Windows 10/11 that is an optional feature; on Windows Server it is a feature you add. See Microsoft Learn for "Install RSAT" and the "ActiveDirectory module" for the exact steps for your OS build. - You identify users and groups by their
sAMAccountName(the pre-Windows 2000 logon name), which is the most reliable identifier for these cmdlets.
Confirm the module loads:
Import-Module ActiveDirectory # no error means it's available
Get-Command Add-ADGroupMember, Remove-ADGroupMember
Throughout, replace the obvious placeholders: jdoe is the user, Finance-ReadOnly is the group. Substitute your own real values.
See where a user stands first
Before you change anything, look at what the user is already in. This is your baseline and your undo reference.
# List every group this user is a direct member of
Get-ADPrincipalGroupMembership -Identity jdoe |
Select-Object Name, GroupCategory, GroupScope |
Sort-Object Name
Get-ADPrincipalGroupMembership returns the groups the account belongs to directly. Note that it does not expand nested membership — if the user is in a group that is itself a member of another group, only the direct one shows. That is fine for our purpose, because you add and remove direct membership.
I like to save that baseline to a file so I can compare afterward or reverse a change:
Get-ADPrincipalGroupMembership -Identity jdoe |
Select-Object -ExpandProperty Name |
Sort-Object |
Out-File "C:\path\to\jdoe-groups-before.txt"
Replace C:\path\to\ with a real folder you can write to.
Add a user to a group
The cmdlet is Add-ADGroupMember. Its first parameter is the group, and -Members is the account(s) you are adding — this trips people up, so read it carefully: you name the group, then the member.
Do a dry run first:
# -WhatIf shows the action without performing it
Add-ADGroupMember -Identity Finance-ReadOnly -Members jdoe -WhatIf
If the output describes the change you intended, run it for real:
Add-ADGroupMember -Identity Finance-ReadOnly -Members jdoe
Adding a user who is already a member is harmless — it does not error out or duplicate anything.
You can add several users at once by passing a list to -Members:
Add-ADGroupMember -Identity Finance-ReadOnly -Members jdoe, asmith, bwong
Remove a user from a group
The cmdlet is Remove-ADGroupMember. By default it prompts you to confirm before removing anyone, which is a deliberate safety net — do not reflexively suppress it.
Dry run first:
Remove-ADGroupMember -Identity Finance-ReadOnly -Members jdoe -WhatIf
Then the real removal. You will be asked to confirm; type Y (or A for yes-to-all if you passed several members):
Remove-ADGroupMember -Identity Finance-ReadOnly -Members jdoe
If you are scripting this unattended and have already tested it, you can bypass the prompt with -Confirm:$false. Only do this once you are certain of the target:
# Suppresses the confirmation prompt — use only after you've verified the scope
Remove-ADGroupMember -Identity Finance-ReadOnly -Members jdoe -Confirm:$false
A note of caution: never point a removal at a broad, unfiltered set of members. If you want to empty or trim a group, list its members first with Get-ADGroupMember and eyeball them before you act.
Verify the change
Check membership from both directions. First, from the group — is the user in it (or gone)?
Get-ADGroupMember -Identity Finance-ReadOnly |
Select-Object Name, SamAccountName |
Sort-Object Name
Then from the user, the same view you took as a baseline:
Get-ADPrincipalGroupMembership -Identity jdoe |
Select-Object -ExpandProperty Name |
Sort-Object
For an add, the group should now appear in the user's list; for a remove, it should be gone. If you saved the "before" file earlier, compare:
$before = Get-Content "C:\path\to\jdoe-groups-before.txt"
$after = Get-ADPrincipalGroupMembership -Identity jdoe |
Select-Object -ExpandProperty Name | Sort-Object
Compare-Object $before $after
Compare-Object shows only the differences: => marks what is new, <= marks what was removed. If it returns nothing, membership is unchanged.
One important operational point: AD changes replicate between domain controllers, and access tokens are built at logon. So even after the cmdlets confirm success, the affected user may need to log off and back on before the change takes effect, and if you query a different DC than the one you wrote to, replication may take a moment. If you want to be sure you are reading fresh data, target the same DC you wrote to with the -Server parameter (name your DC explicitly, e.g. -Server dc01.example.com).
Undo a change
There is no dedicated "undo" — you reverse the operation:
- To undo an add, remove the user from that group:
Remove-ADGroupMember -Identity Finance-ReadOnly -Members jdoe -WhatIf - To undo a remove, add the user back:
Add-ADGroupMember -Identity Finance-ReadOnly -Members jdoe -WhatIf
Run each with -WhatIf first, exactly as before, then without it once the output looks right. This is why the baseline file matters: if you ever removed a user from several groups and need to put them back, that saved list tells you precisely which groups to restore.
For the exact parameter sets and any options I have not covered, see Microsoft Learn for Add-ADGroupMember, Remove-ADGroupMember, Get-ADGroupMember, and Get-ADPrincipalGroupMembership — those are the four cmdlets this whole task rests on.
Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.
More about the author →Was this article helpful?
Tap a star — no sign-in needed.
Be the first to rate this article.
