Windows access control is built from several security boundaries that solve different problems.

NTFS permissions control access to files and folders on NTFS volumes.

Share permissions control access through a Windows network share.

User Account Control (UAC) limits how administrative privileges are used interactively.

EFS encrypts selected files and folders for authorized user identities.

BitLocker encrypts entire volumes.

The current CompTIA A+ Core 2 exam expects technicians to distinguish file permissions, encryption, privilege boundaries, and Windows security settings. These controls work together, but they are not interchangeable.

NTFS permissions protect files and folders

NTFS permissions determine which users and groups can perform actions such as:

• read
• write
• modify
• read and execute
• list folder contents
• full control

Permissions are represented through access control entries associated with the object.

A deeper look at NTFS provides background on why NTFS supports Windows security features that simpler removable-media file systems do not.

For administration, the most important rule is to assign permissions to groups where practical rather than maintaining many one-off user entries.

Inheritance can simplify or complicate access

Folders can pass permissions to child files and subfolders.

That inheritance makes large directory trees manageable.

It can also create confusion.

A user may have access because:

• permission is inherited from a parent
• the user belongs to a group with permission
• several groups contribute different rights
• an explicit deny overrides an allow
• inheritance was disabled on one child object

When access is unexpected, do not look only at the permission line that has the user’s name.

Review the complete effective access path.

Share permissions apply to network-share access

Windows shares have their own permission layer.

Common share permissions include:

• Read
• Change
• Full Control

When a user accesses a shared folder across the network, both the share permissions and the underlying NTFS permissions matter.

A common administrative approach is to keep share permissions relatively broad and enforce detailed authorization through NTFS permissions.

The exact design depends on the environment.

The key troubleshooting principle is that network access can fail because either layer is too restrictive.

If a user can open the folder locally but not through \\server\share, compare share and NTFS permissions.

Effective access is the combined result

A user’s actual access can come from several sources:

• direct permission
• group membership
• inherited permission
• share permission
• NTFS permission
• explicit deny

Windows provides tools for evaluating effective access because the answer is often not obvious from one property sheet.

Windows NTFS permissions use access control lists (ACLs) to express permit and deny decisions on objects such as files and folders.

When troubleshooting, test with the exact affected account rather than assuming a group membership has already refreshed everywhere.

UAC is a privilege boundary, not a file permission

User Account Control helps prevent applications from silently using administrative privileges.

An administrator can sign in and still run normal applications with a standard user token.

When an action requires elevated privileges, Windows can display a UAC consent or credential prompt.

This protects the workstation from the assumption that every process launched by an administrator should automatically receive full administrative rights.

UAC does not replace NTFS permissions.

A process can be elevated and still be denied access to a file if the underlying access-control policy does not permit it.

Likewise, a standard user can have explicit permission to edit a file without becoming a local administrator.

Least privilege starts with standard-user operation

Microsoft recommends standard-user operation for everyday work where possible.

Administrative rights should be used only for tasks that require them.

This reduces the damage that can occur when:

• a malicious document launches code
• a browser process is compromised
• a user runs an untrusted installer
• a support tool is abused

The support technician should not solve every access problem by adding the user to the local Administrators group.

That converts a narrow permission issue into a broader security problem.

Encryption boundaries: EFS protects files, BitLocker protects volumes

Encrypting File System, or EFS, can encrypt individual files and folders on supported NTFS volumes.

EFS encryption is tied to certificates and keys associated with authorized user identities.

That makes it useful when selected files need encryption without encrypting the whole disk.

EFS introduces recovery requirements.

If the user’s private key is lost and no recovery path exists, the data can become inaccessible even though the file still exists.

Technicians should understand that copying an EFS-encrypted file, changing its ownership, or resetting a user’s password does not magically recreate the decryption key.

Back up EFS certificates and recovery information where the organization uses EFS.

BitLocker protects the volume rather than individual files

BitLocker is full-volume encryption.

It protects data at rest if a drive or device is stolen or removed.

On modern Windows devices, BitLocker can work with the TPM and platform security to protect the volume encryption key.

The access problem it solves is different from NTFS.

If an attacker steals the drive and tries to read it offline, NTFS permissions are not a strong protection because the attacker can use another operating system or tool.

BitLocker encrypts the underlying volume so offline access requires the proper key.

BitLocker relies on modern symmetric and asymmetric encryption concepts, but Windows administrators still need to manage recovery keys and boot-time recovery events correctly.

Recovery-key management is part of BitLocker security

A BitLocker-protected PC can enter recovery after selected changes involving:

• TPM state
• firmware
• boot configuration
• security settings
• hardware changes

The recovery key should be stored through the organization’s approved process.

A support technician should verify recovery-key availability before:

• firmware changes
• motherboard replacement
• some boot repairs
• selected recovery-environment actions

A perfectly secure encrypted drive is not useful if the business cannot recover it after legitimate maintenance.

Windows authorization becomes easier to troubleshoot when you distinguish identity, access control, elevation, and encryption. NTFS and share permissions decide whether an authenticated identity can access an object. UAC decides how an administrator token is used interactively. EFS and BitLocker protect data cryptographically when normal access control is not enough. A failure in one layer should not be “fixed” by weakening another.

For NTFS, group membership and inherited access can make the visible permission list misleading. A user might receive Read from one group and Modify from another; Windows evaluates the resulting access rather than a single line in the ACL. Explicit Deny entries deserve special attention because they can override an Allow that looks correct. Before adding Full Control, determine which identity is being evaluated and whether the permission is inherited from a parent folder.

Network shares add another boundary. A user accessing a folder locally is governed by NTFS permissions, while a user reaching the same data through SMB is subject to both share and NTFS controls. The effective network access cannot exceed what either layer permits. That is why a technician should test the same user through the same access path that is failing rather than assuming a successful local test proves the share is configured correctly.

Encryption adds recovery obligations. BitLocker protects against offline access to a lost or stolen drive, but it can also interrupt support work after firmware, TPM, boot-policy, or hardware changes if the recovery key is unavailable. EFS ties file decryption to user certificate material, so copying encrypted files or rebuilding a profile without preserving the required certificate can create a data-access incident. Security controls are only operationally safe when recovery material is protected and retrievable by authorized staff.

EFS and BitLocker can coexist for different threat models

EFS and BitLocker solve different scopes.

BitLocker

• whole volume
• protects against offline theft or disk removal

EFS

• selected files/folders
• identity-oriented file encryption

An organization can use both.

For example, BitLocker protects the laptop if stolen, while EFS adds a separate protection boundary for selected files.

Do not assume full-disk encryption makes every logged-in user authorized to read every file.

File permissions and EFS can still create separate controls.

A good test plan uses the affected user’s actual token rather than an administrator account. Confirm group membership, log off and back on if group membership changed, test the same local or network path, and use Windows effective-access tools where available. If access is still wrong, remove accidental permissions carefully instead of layering new Allow entries until the problem becomes impossible to reason about. Clear permission design is itself a security control because administrators can explain why a user has access and how that access will change when roles change.

Trace effective access before changing permissions

When a Windows access problem occurs, ask:

Can the user reach the path at all? Check share/network access.

Can the user open the object? Check NTFS and effective permissions.

Does the task require elevation? Check UAC and administrative rights.

Is the file encrypted with EFS? Check certificate/private-key availability.

Is the volume locked with BitLocker? Check volume state and recovery information.

Troubleshoot from identity to access path to encryption. Change the smallest boundary that is actually causing the failure instead of granting broad rights or disabling security controls. Re-test after sign-out when token membership or inherited access has changed.