Windows User Accounts, Groups, and Permissions

Windows User Accounts, Groups, and Permissions

Why Access Control Matters

Every computer that more than one person uses needs a way to separate what each person can see and do. Windows enforces that separation through user accounts, groups, and permissions. Getting this right is a core IT support skill and a tested objective on the CompTIA A+ Core 2 exam. Mistakes—leaving a guest account with too many rights, or forgetting to set a lockout policy—are how real systems get compromised.

User Account Types

Windows recognizes several local account types:

• Administrator accounts can install software, change system settings, and manage other accounts. Use them only when elevated privileges are genuinely needed.
• Standard user accounts can run applications and change their own settings but cannot make system-wide changes. This is the correct account type for everyday work.
• Guest accounts are highly restricted and disabled by default in modern Windows. They should stay disabled unless there is a specific, documented reason to enable them.

You manage local accounts through Computer Management > Local Users and Groups or through the `lusrmgr.msc` console. The Settings app can also create accounts but exposes fewer options.

Groups and Why You Use Them

Assigning permissions directly to individual user accounts does not scale. Instead, place users into groups and assign permissions to the group. When someone's role changes, you move them between groups rather than hunting through every resource to update individual rights.

Windows ships with built-in groups (Administrators, Users, Guests, and others). You can also create custom local groups in Local Users and Groups to match your organization's roles—for example, Staff and Managers.

To add a user to a group: open the group's Properties, click Add, and type the account name. Use Check Names to confirm spelling before clicking OK.

NTFS Permissions

NTFS (New Technology File System) is the file system used on virtually all Windows system drives. NTFS tracks an Access Control List (ACL) on every file and folder. The ACL contains Access Control Entries (ACEs)—one for each user or group that has been granted or denied a specific right.

Key NTFS permission levels for folders:

| Level | What it allows |

|---|---|

| Full Control | Read, write, delete, change permissions, take ownership |

| Modify | Read, write, delete files; cannot change permissions |

| Read & Execute | Open and run files |

| Read | Open files; cannot change them |

| Write | Create and modify files; cannot delete |

To set NTFS permissions, right-click the folder, choose Properties > Security > Edit. Add the group, then check or uncheck the boxes. Use Deny sparingly—an explicit Deny overrides any Allow, even one inherited from another group.

Inheritance means subfolders automatically receive the permissions of their parent. You can break inheritance on a specific subfolder when you need tighter control.

Note on "Read & Write but not Delete": NTFS does not have a single checkbox labeled "no delete." To approximate this, grant the Write and Read & Execute permissions at the folder level but do not grant Modify or Full Control. Because the Delete permission is included in Modify but not in Write alone, users can create and edit files but cannot delete them. Test this with actual logins to confirm behavior before relying on it in production.

Local Security Policy

The Local Security Policy console (`secpol.msc`) lets you enforce password rules and account lockout behavior on a standalone machine. Key settings under Account Policies:

• Password must meet complexity requirements – When enabled, Windows requires a mix of character types (uppercase, lowercase, digits, symbols) and prohibits passwords that contain the account name.
• Minimum password length – Sets the fewest characters a password must have. Industry guidance typically recommends at least eight characters; many organizations now require longer passphrases.
• Account lockout threshold – The number of consecutive failed logon attempts before Windows locks the account. A threshold of three to five attempts is common. Set it to zero and lockout is disabled—never leave it at zero on a shared or networked machine.
• Account lockout duration – How many minutes the account stays locked before resetting automatically. Setting this to zero means an administrator must manually unlock the account.

Document every setting you configure in your lab log, including the reason for each choice. Being able to explain why a policy exists is as important as knowing how to set it.

Safety and Best Practices

This lab involves no electrical hazards beyond standard PC operation. Follow your program's rules for handling lab equipment. More relevant here is logical safety:

• Never use an Administrator account for routine tasks—apply the principle of least privilege.
• Always log off or lock the screen (`Win + L`) before stepping away from a machine.
• Do not store lab passwords in plain text; use the lab log only as the instructor directs.
• Confirm changes by testing with the affected accounts, not by assuming the settings took effect.

Putting It Together

In today's lab you will create accounts and groups, apply layered NTFS permissions, configure a local security policy, and verify everything works by logging in as each test account and attempting both permitted and restricted actions. Each step directly maps to CompTIA A+ Core 2 objectives covering operating system features and security best practices.