Directory

When someone signs in to a work computer, the computer hands the attempt to a server and waits for an answer. That server is a domain controller, and the database it answers from is Active Directory. One account works on every machine in the building because it lives on that server, which puts a login failure on the account and the server that answers for it.

Domain

A set of users, computers and resources sharing one authentication database. Written like a DNS name, for example example.com.

Domain controller

A server holding a copy of that database and answering sign-in requests. There are normally at least two, and they replicate to each other.

AD DS

Active Directory Domain Services, the Microsoft product providing all of the above. When a job posting says "Active Directory", this is what it means.

LDAP

Lightweight Directory Access Protocol, the protocol used to query the directory. On a first-line desk you meet it in error messages; configuring it belongs to another team.

Kerberos

The protocol that issues the ticket proving who you are once the password has been accepted. Same again: recognize the name and what it does.

The directory holds more than people. Anything the domain needs to know about gets a record, and four object types cover almost everything you will meet.

The console is Active Directory Users and Computers. Nobody says that out loud. Everyone says ADUC, and everyone launches it by pressing Win+R and typing the name of the snap-in file.

dsa.msc

The console ships on every domain controller, and on a healthy network first-line staff hold no logon rights there, so it goes on your own machine as part of RSAT, the Remote Server Administration Tools: Settings, then System, then Optional features, then add "RSAT: Active Directory Domain Services and Lightweight Directory Services Tools". From an elevated PowerShell prompt it is one line.

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

If that fails, the machine is usually pointed at an internal update server that has not been told to offer optional features, which is a question for whoever runs patching.

Your everyday account is an ordinary user account, and most organizations issue a second, separate one for administrative work. runas launches the console as that account while you stay signed in as yourself.

runas /user:EXAMPLE\adm-jsmith "mmc dsa.msc"

Advanced Features is under View. Without it the console hides several containers and, more usefully, hides the Attribute Editor tab, which shows the raw attribute names behind every field on every other tab. When a senior tech tells you to "check the attribute", that tab is where they mean.

Find a person in ADUC, double-click them, and you get a properties dialog with somewhere around fifteen tabs. Three carry nearly everything a first-line ticket needs.

General

Who the person is, as a human. First name, last name, display name, description, office, telephone number, email address, web page. This is the tab that answers "is this the right Chen?".

Account

The tab that actually does work. Both logon names live here, along with the Unlock account checkbox, the account options, logon hours, the list of workstations the account may sign in to, and the account expiry date.

Member Of

Every group the account belongs to, plus its primary group. When a ticket says someone cannot open a share, this is the tab you are going to, and comparing it against a colleague who can open the share is the fastest diagnosis in the job.

Windows and Active Directory are trademarks of Microsoft Corporation. ServiceDesk Simulator is not affiliated with, endorsed by, or sponsored by them.

Four separate controls sit on the Account tab and beginners conflate them constantly. Each refuses a login in its own way.

Unlock account is a checkbox on the Account tab, separate from the password field. A locked account is one the lockout policy switched off after too many wrong attempts, and clearing that lock is its own action. If you reset a locked account's password and hand the person a temporary one, they will try it, it will be refused, and they will call back angrier. Unlock, then reset if the password was also the problem, and tell them which of the two you did.

Note which direction that checkbox works in. ADUC clears a lockout, and creating one is the policy's job, done on its own after a threshold of wrong passwords, so every locked account you meet at work has a story behind it. Reading that story, five failed attempts at 08:55 against forty overnight, is usually the difference between a user who fumbled their new password and an account somebody is guessing at.

A ticket arrives from "John Smith". You search for John Smith, find nothing useful, and conclude the account is missing. You searched with the wrong one of his names, and the directory holds at least four.

sAMAccountName

The short logon name, jsmith, sometimes written EXAMPLE\jsmith. Hard limit of twenty characters, still enforced for backward compatibility, and it cannot contain characters like / \ [ ] : ; | = , + * ? < >. This is the one ADUC labels "pre-Windows 2000" on the Account tab.

userPrincipalName

The long logon name, jsmith@example.com, universally shortened to UPN. It looks exactly like an email address and is frequently a different string from the person's mailbox address. The part before the @ is free to differ from the short name. UPNs exist largely as the escape hatch from the twenty-character cap.

displayName

What chat, mail and your ticket queue show. John M. Smith. It is the name a ticket gives you, and the one you search with last.

distinguishedName

The full path of the object in the directory, always shortened to DN. Unique, and the only one of the four that tells you where the account sits.

CN=John Smith,OU=Sales,OU=Users,DC=example,DC=com

Since Windows 2000 a user can sign in with either logon name, which is exactly why users cannot tell you which one they use. It is also why the useful question after "my username doesn't work" is what they typed, character for character. Half of those tickets close themselves on the answer.

When you cannot find someone, you are usually searching with the wrong one of their names. Search on the surname alone and read the results. It is faster than guessing at a logon format, and it shows you the near-misses, which is how you catch the two Chens before you reset the wrong one.

Two of the four object types carry more than their name suggests, and both come up in tickets that look like something else.

A computer is a record you can open, the same way a person is. Search for the hostname in ADUC and you get its own properties: which OU it sits in, its description, its operating system, and controls to disable or reset it. The machine holds an account and a password of its own, rotated every thirty days without anybody watching, and that account is what proves the machine to the domain. When the two ends stop agreeing, usually because the machine was rolled back to an older snapshot, you get "the trust relationship between this workstation and the primary domain failed", which is a fault on the computer object, whoever happens to be sitting at the machine. Knowing the object exists is what stops you resetting a password for two hours.

Groups carry two settings that sit behind the list of names, and an interviewer may well ask for both.

Type

A security group grants permissions. A distribution group is a mailing list and grants nothing. The names look identical in a list, so somebody added to the distribution group with the right-sounding name still cannot open the share, and the ticket comes back.

Scope

Domain local, global or universal, which decides where the group can be used and what it may contain. The pattern to recognize is people into a global group, the global group into a domain local group, and the permission on the domain local group.

Nesting

A group can be a member of another group, and rights flow down. So somebody can hold a permission nobody granted them directly, which is why "why can this person open that" is answered by walking the chain.

A new membership takes effect at the person's next sign-in. Group membership is written into the Kerberos ticket issued at logon, and that ticket stands until the next one is issued. So the honest close on an access ticket is: I have added you, sign out and back in, then try it. Skip that sentence and they test it immediately, it fails, and you both spend the afternoon looking for a fault that is not there.

Real first-line job postings contain the phrase "within delegated permissions", and what those permissions are is a decision somebody at your company made. Rights in Active Directory are handed out over specific containers for specific tasks, through the Delegation of Control Wizard. The tasks themselves are ordinary first-line work: resetting a password, unlocking an account, forcing a change at next logon, adding and removing group memberships. Access requests are one of the highest-volume ticket types on any service desk, and the desk is normally the team that fulfills them.

Where it stops is the part that varies, and it varies enormously. Some desks, smaller companies and managed service providers especially, delegate reset and unlock across the whole directory, executives and IT staff included, because there is nobody else to do it at eight in the morning. Some fence first line to staff accounts and keep privileged ones behind a separate team. Plenty sit in between, where you hold the right and policy still asks for a second approver, or a manager's written approval, before you use it on a sensitive account. All three are real arrangements, and which one you have walked into is a question for your first week. Whichever it is, every change you make is written down: a real directory logs the action, the object it landed on and the admin account behind it, which is most of why that second account exists.

The one caution that holds on every desk is about risk. Resetting a second factor hands whoever calls next a working credential, so it is the action to slow down on regardless of whose account it is. The MGM breach in The phone was exactly this: a help desk talked into resetting multi-factor authentication for someone who turned out to be an attacker. Verify who is actually on the line before you clear a second factor, and hand the request on if you cannot.

The same reasoning is why any organization thinks about this at all, and it is worth understanding. Helpdesk accounts are among the most phished accounts anywhere, because everybody knows what they can do. A company that tiers its delegation is limiting what a stolen helpdesk account is worth; a company that does not has decided the speed is worth more. Both are real positions. Either way the job is the same: use what you were given, on requests you have verified, and hand on the rest.

Read before you write. Open the record and answer four questions in order before your hand goes anywhere near a button.

An admin console has no undo. Every action you take in one is applied immediately and stands. Select the wrong Chen and the wrong Chen stays reset, because a directory acts on the click and asks nothing. Read the record, confirm the person, then act.

Deep dive, optional on a first read. Nothing later in this module leans on this page. Come back to it once the tabs and the four controls that refuse a login feel automatic.

You will be asked about PowerShell in an interview for a first-line role, and the honest scope is small: four cmdlets from the ActiveDirectory module that come up constantly, which you should be able to say out loud without looking them up.

Get-ADUser jsmith -Properties LockedOut,PasswordExpired

That is the read, and it carries the trap that catches everyone exactly once. Get-ADUser returns a small default set of properties, and lockout state sits outside it. An attribute missing from the output is an attribute you asked the directory to leave out. -Properties is the fix, and -Properties * while you are learning is a reasonable habit.

Search-ADAccount -LockedOut -UsersOnly | Unlock-ADAccount

Search-ADAccount finds accounts by state, which is how you answer "is it just me or is everyone locked out this morning". It takes -LockedOut, -AccountDisabled, -PasswordExpired and -AccountExpired. Piping it straight into Unlock-ADAccount is a real thing people do after a bad password-policy change, but run the search on its own first and read the list.

Unlock-ADAccount -Identity jsmith

Set-ADAccountPassword -Identity jsmith -Reset

Those two are the write half, separate on purpose, the same way the checkbox and the password field are separate in the console. A reset is normally paired with Set-ADUser jsmith -ChangePasswordAtLogon $true so the person picks their own password the moment they get in and the temporary one you read out over the phone stops being a credential. The -Identity parameter accepts the short name, the DN, the GUID or the SID, the two identifiers the directory generates for the account itself, which is the practical reason it is worth being able to read a DN.

Now the direction of travel. Most organizations run on-premises Active Directory and cloud identity side by side and synchronize between them, and a 2026 job posting will ask for both by name. Two more words to recognize: Microsoft Entra ID is the current name for Azure AD, and an administrative unit is the cloud's answer to an OU, the thing cloud admin roles get scoped to.

The cloud reset failure is worth knowing, because it looks like a success. Reset a synced user in the Microsoft 365 admin center and the password changes in Entra ID and stays there: that portal writes to the cloud directory only. So the person signs in to mail with the new password and into their laptop with the old one, which still works, and calls back saying you broke something. The Entra admin center does write back, for federated and password hash synchronized users, where somebody has turned writeback on. The on-premises reset avoids the whole question.

In this simulator the console is at Tools, then Directory, and the panel header says the same word. It holds 88 seeded accounts, a working slice of a company the in-world documentation puts at around five hundred people. It is the tool most of the access tickets in the queue are worked in.

It is one screen where ADUC is a tree plus a dialog. On the left, All Users lists every account by display name with the username underneath. Search users... at the top filters that list on display name, username or email address, so a surname is enough. Pick somebody and the record opens to the right, with a column of tab names in the middle under the heading Manage.

There are five tabs and no more. Profile is the account record. Groups is what ADUC calls Member Of. Licenses is the software assigned to the person. Devices is the machine they were issued. Authentication holds the account state, the four action buttons, and the identity check you are expected to run before using them.

The state of an account is readable in two places, both on Authentication. Under Authentication methods you get MFA status and Password expired. In the Actions row, the second button swaps its own label: it reads Unlock Account on a locked account and Lock Account on a healthy one. The button is telling you the state before you press it, and the fourth button does the same thing for enabled and disabled. Those two places are the whole readout.

Profile is split into two headings. Identity carries Display Name, Username, Title, Employee ID, Email and Phone. Organization carries Department, Manager, Last Login and Account expires. Every one of those is a real directory attribute wearing a friendlier label. Most you read on ordinary tickets and should be able to name in an interview; a handful are edge cases and cloud concepts you only need to recognize, split out below as a deep dive.

One row under Identity appears only sometimes. Aliases is drawn when the account carries an extra mail address, and every seeded account starts on a single address, so the row turns up once you have created one. You create one through Change Name & Email, the same editor a legal name change ticket sends you to: the new address becomes the primary one, and where the ticket asks you to keep the old address it goes on as an alias so mail sent to it still arrives.

A legal name change is one of the jobs that arrives without a written procedure behind it, here and on a real desk. When that happens you follow the closest policy you can find, ask the requester for anything the record leaves open, and escalate if the change reaches past what your seat is allowed to do.

Interview must-know

Deep dive

The Groups tab shows Group memberships as a table of group name and an action to remove each one, plus an Add to group... dropdown underneath. Domain Users is the primary group, so the console keeps it where it is. Real AD holds on to a primary group the same way.

The other three are quick. Licenses lists Assigned licenses with a dropdown to add one. Devices shows Registered devices, meaning the machine assigned to that person and its asset tag, plus the Drive Encryption Recovery Key, masked until you reveal it. Authentication you have already met.

Every seeded account carries a real OU path behind it. A Sales record sits at OU=Sales,OU=Users,DC=servicedesk-simulator,DC=com, built the way part one taught you to read one, so the company under this panel has the shape a real domain has, behind tabs that draw a slice of it.

Two of the buttons on a record are there to give you something to practice on, and it is worth knowing which two.

Lock Account is the first. Part one made the point that in real AD the policy is what creates a lockout and ADUC is what clears it. Here the second action button flips to Lock Account on a healthy record, which is how you manufacture a locked account any time you want one to work on. Press it, then unlock it in the order part one gave you and watch what each control actually changed.

Disable Account is the second, and it has a longer tail than people expect. None of the 88 accounts starts disabled, so the only disabled account in this company is one you made, and it stays that way until you enable it again. The person it belongs to may raise a ticket asking why they cannot sign in, which is the four-questions habit coming back at you as homework.

Two fields read the same on every record and are worth reading anyway, because they are half of what a healthy account looks like: Account expires says Never for all 88, and MFA status says Enrolled for all 88. Part one has the states on the other side of both, the contractor whose end date arrived and the account whose second factor has to be reset, and those are the ones worth being able to name.

One thing about this panel is a deliberate choice: your account holds every action here over all 88 records, executives included. That is a real configuration, and on plenty of desks it is the one you will be handed. Part one is where the variation lives, and it is a question about your employer: password resets, unlocks, group membership and the device view are ordinary first-line tasks wherever you end up.

A ticket asking you to reset the CEO's password before the board meeting is asking one thing: did you check who was asking. The Identity Verification section on the Authentication tab is how you answer it.