Active Directory is where identity lives in SysDesks: simulated user accounts, security and distribution groups, and computer objects, organized into organizational units the way a real domain is. It is the console behind almost every account-access ticket — locked accounts, expired passwords, group membership requests, and attribute updates.
Working an account in Active Directory
- Open Active Directory from the sidebar and search for the requester by exact name or email — never work from a similar-looking account.
- Open the account and read its state before changing anything: Enabled, Locked, Password Expired, the bad-password count, and Last Sign-In are all tracked as real fields, not decoration.
- Check group memberships if the ticket concerns access to a resource — membership in the right security group is what actually grants that access in the simulation.
- Make the specific change the ticket authorizes: unlock, reset with a required change at next sign-in, update an approved attribute, or adjust group membership.
- Confirm the account now reflects the corrected state.
The distinction between unlocking and resetting matters mechanically, not just procedurally: unlocking clears the lockout counter without touching the password, while resetting changes the credential itself. A ticket's resolution conditions check for the specific change that's actually needed — resetting a password on an account that only needed unlocking will not satisfy a condition that's checking for the account's lock state, because the underlying problem it describes was never actually the password.
Things worth knowing
- A high bad-password count paired with a very recent lockout time usually means something is still trying the old credential automatically — a saved password on a phone or a mapped drive — and the account will lock again shortly after you unlock it unless that source is found.
- Some groups and OUs are marked privileged and are intentionally outside standard delegation. Requests touching them are meant to be escalated, and that escalation is a correct outcome the scoring model recognizes, not a failure to solve the ticket yourself.
- Group and attribute changes you make are real, persisted state — they show up immediately if you reopen the same account, and they're what a related ticket's resolution condition checks against.
Directory work in SysDesks also covers new-hire provisioning and attribute-update tickets, where the resolution condition checks that the account you create or the fields you update match exactly what the ticket specifies — the correct organizational unit, the correct title or department, the correct phone extension. These are graded on precision: an account created in the wrong OU is not treated as equivalent to the right one, the same way it would not be in a real directory service.
Groups in Active Directory come in two types — security groups, which actually grant access to something, and distribution groups, which are just mailing lists with no access implication — and each carries a scope of global, universal, or domain local. This distinction matters on tickets that ask you to add someone to a group: adding a user to the wrong kind of group, or to a group with the wrong scope for what's being requested, does not satisfy a resolution condition that's checking for genuine access being granted, the same way it wouldn't in a real environment.
Computer objects also live in Active Directory alongside user and group objects, and they're what ties a physical device record in Asset Management to a domain identity — whether a machine is domain-joined, workgroup, or Azure AD joined is visible from its computer object, and it's part of what some directory-linked tickets check. Every change you make through Active Directory, whether to a user, a group, or a computer object, is logged to an audit history attached to that object, which is what a real domain controller would do and what lets a ticket's documentation requirement be checked against an actual trail of what happened rather than only your own notes.