Every messy directory started with accounts created in a hurry. This page covers the small disciplines of user creation - naming, the first-logon password change, and the fields nobody fills until an audit forces them to.
Creating a user takes thirty seconds. Creating the two hundredth user in a directory where the first fifty were made with five different naming styles takes an afternoon of detective work. The account itself is simple; the discipline around it is the whole game. Below: the naming rule, why User must change password at next logon is non-negotiable, and which profile fields are worth the extra twenty seconds.
The checkbox at the bottom is the important part - the password you set should live for exactly one logon.
Choose a pattern your whole company can guess from a name alone - firstname.lastname is the most common for a reason. Decide the awkward cases on day one, not when they arrive:
rahul.sharma and rahul.sharma2 (or add a middle initial) - pick one stylesvc-backup so they never get mistaken for peopleA naming rule feels like bureaucracy until the day you must find one account among six similar names during an incident.
The password you type during account creation is known to two people - you and the new joiner. Tick User must change password at next logon and within one working day it is known to exactly one. In PowerShell this is -ChangePasswordAtLogon $true. Share the starter password in person or on a call, never in a WhatsApp forward that lives forever, and never reuse the same starter password for every joiner - a pattern one ex-employee knows is a pattern everyone can guess.
Department, title, manager and office look optional. They are the fields that answer real questions later: who approves this person, which team is this account in, is this account even still needed. Thirty seconds now versus a phone call per account during the yearly review. The Description field earns its keep for shared and service accounts - write what the account is for and who owns it.
New accounts land wherever you were standing in the console - often the default Users container, where no OU policy and no delegation applies. Create the account inside its department OU, or move it immediately. In scripts, the -Path parameter does this: New-ADUser -Name "Rahul Sharma" -SamAccountName "rahul.sharma" -Path "OU=Accounts,OU=Delhi Office,DC=office,DC=local" -Enabled $true -ChangePasswordAtLogon $true. An account created in the wrong place quietly misses policies and shows up in every audit as an exception.
For roles that repeat - sales executives, support engineers - keep one disabled template account per role with the right OU and group memberships, and use ADUC's Copy action for new joiners. Honest caution: copying carries group memberships, which is the point, but check the copy before enabling it - a template that silently collected extra groups over the years hands every new joiner more access than the role needs.
The full OU, user and group creation process - live on a real domain controller, step by step.
▶️ Watch Full VideoLeave the account disabled until their first working day, then enable it. An enabled account with a known starter password sitting unused for two weeks is an open door with a name on it.
Ideally yes - one identity string everywhere removes a whole class of confusion. Set the UserPrincipalName to match the email pattern from the start; changing UPNs later is possible but touches sign-ins in several places.
No - a shared account destroys accountability. When something changes or breaks, the log shows the account, not the person. Individual accounts with group-based access cost nothing extra and keep the audit trail honest.