Create, modify, and unlock user accounts in Active Directory. Understand OUs, groups, and permissions. Every corporate IT role requires AD skills — this is non-negotiable.
Active Directory (AD) is Microsoft's directory service for managing users, computers, groups, and policies in an enterprise network. Every corporate Windows environment uses it. As a Tier 2 tech, you'll use Active Directory Users and Computers (ADUC) to handle the majority of user account tasks.
Think of AD as the single source of truth for: who someone is, what groups they belong to, what resources they can access, and what policies apply to their computer. One account, controlled centrally.
| AD Object | What It Is | Common Tasks |
|---|---|---|
| User Account | Identity for a person; has username, password, attributes | Create, disable, unlock, reset password, modify attributes |
| Computer Account | Represents a domain-joined machine | Move to correct OU; disable when decommissioned |
| Security Group | Collection of users; used to assign permissions | Add/remove members; determine access rights |
| Distribution Group | Email distribution list; no security permissions | Add/remove for email routing |
| OU (Org Unit) | Container to organize objects; GPOs apply at OU level | Move users to correct OU for correct GPO application |
| GPO | Group Policy Object; applies settings to users/computers | Link/unlink GPOs; troubleshoot policy application with gpresult |
| Task | When | Tool |
|---|---|---|
| Unlock account | User locked out after too many bad passwords | ADUC → right-click user → Unlock Account |
| Reset password | User forgot password or security reset required | ADUC → right-click user → Reset Password |
| Create user account | New hire onboarding | ADUC → right-click OU → New → User |
| Disable account | Employee offboarding or leave of absence | ADUC → right-click user → Disable Account |
| Add to security group | User needs access to a resource | ADUC → user Properties → Member Of → Add |
| Check account expiry | User can't log in despite correct password | ADUC → user Properties → Account tab |
| Move user to OU | Department change; incorrect GPO being applied | ADUC → right-click user → Move |
Before resetting any account password, verify the caller's identity using your organization's verification procedure (employee ID, manager confirmation, security questions). Social engineering attacks frequently target the help desk with requests to reset passwords for accounts the attacker doesn't own. No verification = no reset, regardless of how convincing the caller sounds.
Account lockout policies are configured in Group Policy. When a user enters the wrong password more than the configured threshold (commonly 5 attempts), the account locks. This prevents brute-force attacks but also creates a common help desk ticket.
The most frequent cause of repeated lockouts isn't the user forgetting their password — it's a phone or tablet that has the old password cached and keeps trying to authenticate against Exchange or VPN. When you unlock the account and it locks again in 10 minutes, ask the user: "Do you have email set up on your phone? When did you last change your password?" The phone is almost always the culprit.
Use this procedure for account lockouts, password resets, new user creation, and account modifications. Identity verification is mandatory before any account change.
Before making any account change: verify identity per your organization's policy (employee ID, manager approval, challenge questions, or ticket submitted through authenticated portal). Document the verification method in your ticket. Never skip this step. For password resets, require the user to be present at their machine if possible.
Open Active Directory Users and Computers (dsa.msc or from Admin Tools). Use Action → Find (or Ctrl+F) to search for the user by name or username. Enable "Advanced Features" from the View menu if you need to see all tabs. Right-click the found account to see all available actions.
To unlock: right-click user → Unlock Account (or go to Properties → Account tab → check "Unlock account"). To reset password: right-click user → Reset Password → set temporary password → check "User must change password at next logon." Communicate the temporary password to the user securely (never via unsecured email).
If the user can't log in despite a correct password: open user Properties → Account tab. Check: Account is locked out (checkbox), Account expires date, Logon hours restrictions, and "Account is disabled" checkbox. Also check the General tab for notes or account description that may indicate intentional restriction.
To add user to a security group: open user Properties → Member Of tab → Add. Type the group name and click Check Names. To add multiple users to a group at once: find the group in ADUC → Properties → Members tab → Add. Document which groups were added and why in the ticket. Group membership changes take effect at next login (or when gpupdate /force is run).
Navigate to the appropriate OU → right-click → New → User. Fill in: First name, Last name, User logon name (UPN format), and pre-Windows 2000 logon name (SAMAccountName). Set initial password → check "User must change password at next logon." After creation, immediately add the user to required security groups and verify the OU placement is correct for proper GPO application.
For departing employees: right-click account → Disable Account. Do NOT delete immediately — maintain for 30–90 days per your retention policy (files and email access may be needed). Move the disabled account to a dedicated "Disabled Accounts" OU. Remove from all security groups. Note departure date in the Description field. Escalate if mailbox access or data export is needed.
| Task | Right-Click Menu | Notes |
|---|---|---|
| Unlock account | Unlock Account (or Account tab) | Check for repeated lockouts afterward |
| Reset password | Reset Password | Always set "must change at next logon" |
| Disable account | Disable Account | Move to Disabled OU; don't delete yet |
| Add to group | Properties → Member Of → Add | Takes effect at next login |
| Force policy update | N/A — run on user's PC | gpupdate /force in elevated CMD |
| Field | Your Entry |
|---|---|
| Account Action | |
| Identity Verified | |
| Change Made | |
| Groups Modified | |
| User Notified |
"How do you handle a user who is repeatedly getting locked out of their Active Directory account?"
First I unlock the account in ADUC. Then — rather than just closing the ticket — I investigate the root cause. The most common cause of repeated lockouts is cached credentials on a mobile device that keeps trying to authenticate with an old password. I ask the user if they have email, VPN, or any work apps on their phone and when they last changed their password. If they changed it recently and have a phone, I guide them to update the mail settings on the device. If it persists, I use the Microsoft Lockout and Recovery tool (LockoutStatus or Event Viewer on the DC) to identify which machine is triggering the lockouts.
"What is an OU in Active Directory and why does it matter where a user account is placed?"
An OU (Organizational Unit) is a container in Active Directory used to organize objects like users, computers, and groups. The critical reason placement matters is Group Policy Objects (GPOs) — policies that control settings, software deployment, and security configuration — apply based on OU membership. A user in the Finance OU gets Finance policies; a user incorrectly placed in the IT OU gets IT policies, which may give them access or restrictions they shouldn't have. When creating a new user account, always confirm the correct OU with the manager or HR to ensure proper policy application from day one.
"A caller says they're an executive and urgently need a password reset. You can't verify their identity through normal channels. What do you do?"
I do not reset the password without verification, regardless of who the caller claims to be. Social engineering attacks specifically exploit urgency and authority — claiming to be an executive is a classic technique. I explain politely but firmly that our security policy requires identity verification before any account changes, and that this policy protects everyone, including them. I offer alternative verification paths: have their manager call in to confirm, or have them come to the help desk in person with an ID. If they are who they say they are, they will understand the policy. If they continue to pressure me to bypass it, I escalate to my supervisor — not bypass the policy.