For CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.2, you need to know how Windows accounts and groups shape real security outcomes. In day-to-day support tickets, a shared PC can expose data, a wrong admin setting can raise malware risk, and extra permissions can break the rule of least privilege. Getting this right means fewer lockouts, fewer infections, and faster fixes when users can't sign in or access files.
This section focuses on Windows users and groups in practical terms. You'll learn the differences between a local account and a Microsoft account, including when each makes sense on a work PC. You'll also review the common roles you'll see on the exam and on the job: standard account, Administrator, Guest user, and power user.
By the end, you should be able to look at a short scenario and pick the safest account type and role. You'll also practice applying basic Windows security settings so the user can work, while the system stays protected.
Access Control Basics
For CompTIA A+ 220-1202, Domain 2.0, Objective 2.2, you need to explain how Windows decides who can do what on a PC. The core idea is simple: accounts identify people, groups collect accounts, and Windows checks both when it grants access to files, settings, and system actions. Once you see the pattern, many support tickets become predictable, and faster to fix.
Users, groups, permissions, and rights: the quick mental model
Think of a Windows account as an ID badge, and a group as a badge bundle. Windows does not guess what a user should be allowed to do. Instead, it checks the user's identity and group memberships, then applies the rules it finds.
Two rule types matter most:
- Permissions control access to objects, mainly NTFS files and folders (and also printers, registry keys, and more). For example, NTFS permissions decide whether you can read a folder, change files, or delete items.
- User rights (also called user rights assignments) control system-level actions. For example, they determine who can log on locally, shut down the system, or install drivers.
This difference helps you troubleshoot quickly. If someone can sign in but cannot open a folder, that points to permissions. If someone can open files but cannot install a driver, that points to a user right (or admin approval through UAC).
Group membership can grant both, depending on how the PC is configured. If you add a user to Administrators, you usually grant broad rights (like installing drivers) and also access to many protected locations. On the other hand, adding a user to a group that has NTFS access to a folder only affects that folder, not the whole system.
Here's a short example you can use to keep it straight:
- Folder access example (permissions): A user needs access to
C:\Shared\Budgets. You add their account (or a group they are in) to that folder's NTFS ACL with Read or Modify. They can now open and edit files there, but nothing else changes. - Install software example (rights): The same user tries to install an app that requires an admin prompt. NTFS folder access does not help. They need admin approval, or membership in a group that grants the necessary rights.
Quick check: When the problem is about a specific folder or file, think permissions. When it's about a system action, think user rights and group membership.
Default local groups you will see on Windows
Windows includes built-in local groups so you can assign common roles without creating custom settings from scratch. In real support work, you will see a few groups repeatedly. The exact list and tools can vary by Windows edition (for example, Home vs Pro), so focus on what each group is meant to do.
Administrators is the most powerful local group. Members can install most software, change security settings, manage other users, and access many protected areas. In practice, techs use it for IT staff accounts or for a temporary elevation when troubleshooting. Still, adding everyday users here increases malware risk and makes audits harder.
Users is the default for standard accounts. Members can run installed apps, use printers, and save data in their profile. However, they cannot change system-wide settings that affect other users. This group supports the principle of least privilege, because most office tasks do not require admin rights.
Guests is designed for very limited access. Many modern Windows setups keep Guest disabled or hidden. When it appears, treat it as high risk on shared systems because it often breaks accountability. If a shared PC needs occasional access, a standard account with clear ownership is usually safer.
Power Users is a legacy group from older Windows versions. It exists mainly for compatibility. On current Windows versions, it should not be your first choice for granting extra ability. If someone asks for "power user access," clarify what they actually need, such as installing one approved app or accessing one folder.
Remote Desktop Users allows sign-in through Remote Desktop (RDP) when RDP is enabled. It does not automatically grant admin rights. This group is useful when a user needs remote access to their own workstation, but it also needs careful review because RDP increases attack exposure if mismanaged.
Backup Operators may appear in some environments. Traditionally, it supports backup and restore tasks without full admin membership. If you see it, confirm the real requirement and policy, because backup tools and modern admin practices often handle this differently.
Practical rule: Add users to the smallest group that solves the problem, then grant folder access separately when needed. Avoid using Administrators as a shortcut.
Where techs check and change membership
When a user cannot access a resource or complete a task, you often need to confirm two things: the user's account type and their group memberships. Windows provides several places to view and adjust this, and the best option depends on the edition and what you have permission to use.
Start with the Settings app. Under Accounts, you can check whether the user is a standard user or an administrator, and you can manage basic sign-in options. Settings is quick, but it does not expose every local group in a detailed way.
Next, use Computer Management when available. On Windows Pro and higher, Local Users and Groups (often opened through lusrmgr.msc) provides a clear view of local users, local groups, and group membership. This is where techs commonly confirm whether someone belongs to Administrators, Remote Desktop Users, or a custom group created by an organization. On some editions, the snap-in is missing, so you may need another method.
Control Panel still shows up in many workflows, especially on older systems or in exam scenarios. User Accounts can confirm account roles and support basic changes. It is also common in environments that rely on older documentation.
Command line tools also matter for exam awareness and for remote or scripted work:
net userhelps you view or manage local user accounts at a high level.net localgrouphelps you view group membership and add or remove members.
Even if you do not use these commands daily, understanding what they do improves your troubleshooting speed. It also helps when a GUI option is unavailable, or when you need to support a device over a limited session.
In practice, group changes should be deliberate. After you adjust membership, confirm the result by signing out and back in (or by testing access) because some permissions and rights apply fully only after a refreshed logon session.
Sign-in Choices
For CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.2, you need to choose between a local account and a Microsoft account based on the situation. This choice affects recovery options, data separation, and how easy it is to manage access on shared PCs. In practice, the "best" sign-in is the one that fits the device's purpose and the organization's risk tolerance.
A helpful way to think about it is simple: a local account keeps identity tied to one PC, while a Microsoft account ties identity to Microsoft's cloud services and can follow the user across devices. The table below summarizes the differences you are most likely to troubleshoot.
| Feature | Local account | Microsoft account |
|---|---|---|
| Where the credentials live | On the PC's local security database | Linked to Microsoft's online identity service |
| Best fit | Kiosks, labs, offline systems, tightly controlled endpoints | Personal devices, multi-device users, users prone to lockouts |
| Password recovery | Limited, requires local methods | Online recovery options reduce lockouts |
| Sync and Store apps | Limited, no built-in account sync | Settings sync, Microsoft Store sign-in, OneDrive integration |
| Data separation risk (work vs personal) | Lower by default | Higher if used on shared or work PCs |
The key takeaway is that sign-in is not just convenience. It is a security boundary and an operations decision.
Local accounts: simple control, fewer cloud links
A local account exists only on a single Windows PC. Windows stores its credential data in the local security database (commonly managed through the system's security accounts framework). As a result, the account does not depend on an internet connection or a cloud identity provider to function. That independence matters in environments where reliability and predictability beat convenience.
Many workplaces prefer local accounts for kiosks, training labs, and offline systems. In a kiosk, you often want a "single-purpose" user that cannot roam and cannot bring cloud storage into the workflow. In a school lab, local accounts can reduce complexity when devices re-image often. On an isolated network, local sign-in remains available even when external services are blocked.
Local accounts also support clear boundaries between users because each PC controls its own list of accounts and group memberships. This is useful when you need tight control over who can log on locally, who can use Remote Desktop, and which folders users can access. Still, the admin workload grows fast because you must manage each machine separately.
Password reset options are more limited with local accounts, so planning matters:
- If a user forgets the password, a local administrator can reset it, but that change can break access to some user-protected data (for example, encrypted items).
- A password reset disk can help, but only if the user created it ahead of time and kept it safe.
- Without a reset disk or another admin account, recovery can turn into a longer repair process.
Auditing also changes with local accounts. On shared systems, accountability can weaken if staff reuse one local login. Therefore, you should prefer named accounts when audit trails matter, even on standalone PCs. Windows can log local sign-in events, but the quality of your evidence depends on unique users and consistent policy.
Operational note: If a device must stay offline and still remain accountable, use local named accounts, not a shared "lab" login.
Microsoft accounts: sync, recovery, and device features
A Microsoft account connects the Windows sign-in to an online identity. The practical benefit is continuity: users can recover access and carry some settings from one device to another. For support teams, this often means fewer tickets that end with, "I forgot my password."
Password recovery is one of the strongest arguments for Microsoft accounts.