IT Support / Support foundations and endpoint boundaries / Lesson 5
Accounts, authentication, and permissions
Diagnose access failures by separating identity, entitlement, object permissions, path traversal, and approved ownership.
On this page
Lesson goals
- Distinguish successful sign-in from authorization to a resource.
- Compare simple policy and Unix-bit models without emulating native access-control engines.
Authentication and authorization answer different questions
Authentication establishes an identity under a system’s mechanism. Authorization determines what that identity may do to a particular resource. Successful sign-in does not imply permission to open every folder, install software, or reset another account. Local, organizational, cloud, and application identities may differ even when the display name looks similar. Support must verify the relevant context through the approved identity process, never by asking for a user’s password or MFA approval code. A service request is not automatically evidence of entitlement.
Express one fictional role rule clearly
The offline role mapping below permits reading for a viewer and reading plus writing for an editor. It is not a Windows DACL, a Linux permission evaluator, or a production authorization service. Its default for an unknown role is no listed permission. Real effective access can involve groups, inheritance, explicit denials, share permissions, application policy, and provider-specific conditions. Read those mechanisms in their actual platform context instead of translating a toy role label into a broad administrator grant.
permissions = {'viewer': {'read'}, 'editor': {'read', 'write'}}
role = 'viewer'
for action in ('read', 'write', 'grant-access'):
print(f'{action}={action in permissions.get(role, set())}')
read=True
write=False
grant-access=False
The viewer can read but cannot write or grant access under this declared rule. No account, group, directory, ACL, or identity system is queried or changed. The output is not an effective-permissions report from an operating system.
The requested object and path both matter
A user may have permission on a file yet lack required access through a parent path, share, application layer, or encryption context. Ownership is also not identical to unrestricted everyday access. In Windows, object ACLs, inheritance, share controls, and identity tokens require platform-specific interpretation. In Unix-style filesystems, directory search permission and selected owner/group/other class matter, with ACLs and other mechanisms adding nuance. Preserve the exact operation and path without exposing unrelated data. Do not solve one denied operation by granting full control everywhere.
A permission-bit calculation has a limited contract
The example below decodes the read bits of an invented ordinary Unix mode. It does not choose which class a real process would use, evaluate supplementary groups or ACLs, inspect parent directories, or reproduce Windows access rules. The model simply distinguishes the three declared classes and one group-write bit. This limitation is important: support should not infer effective access or run a permission-changing command from an octal number alone. Establish the selected identity, object, operation, policy, and owner first.
mode = 0o640
for name, shift in [('owner', 6), ('group', 3), ('other', 0)]:
read = bool(((mode >> shift) & 0o7) & 0o4)
print(f'{name}_read={read}')
print(f'group_write={bool((mode >> 3) & 0o2)}')
owner_read=True
group_read=True
other_read=False
group_write=False
Mode 0640 has owner/group read and no other read; the group lacks write in this fixture. The script performs integer arithmetic only and never reads a file mode or changes permissions. Native access decisions require additional context.
Escalate access changes through the resource owner
Record the exact denial, task, selected identity, resource location, relevant group or policy context, and a comparable permitted case where approved. Distinguish a stale session, wrong account, missing entitlement, path problem, or service issue before requesting a change. Access restoration and new access approval are different requests. Any reset, group modification, ownership transfer, or permission change belongs to an authorized process with audit and verification. This course uses only synthetic rules and never reads or alters real user accounts or credentials.
Common errors and fixes
Access is denied is treated as a failed password.
- Why it happens
- Authentication and object authorization were not separated.
- How to fix it
- Identify the stage and exact denied operation before choosing a recovery path.
- Prevent it next time
- Document identity and entitlement evidence independently.
A denied write is fixed by granting administrator access.
- Why it happens
- A narrow resource requirement was replaced with broad authority.
- How to fix it
- Ask the resource owner for the minimum approved access correction.
- Prevent it next time
- Keep least privilege and ownership approval in the support contract.
An octal mode is presented as a complete Windows permission report.
- Why it happens
- A limited Unix model was generalized across different authorization systems.
- How to fix it
- Use the actual platform’s effective-access evidence and scope.
- Prevent it next time
- Label every permission model with its assumptions and omissions.
Check your understanding
1. A user can sign in but cannot edit one shared document. Should support ask for their password?
Show worked solution
No. Verify the relevant identity and entitlement through the approved process and investigate the specific edit operation, path, share, and application policy. A password does not establish authorization and should not be collected in a ticket. Request any access change from the appropriate owner with the required approval.
2. Does owner_read=True prove that the current process can open the path?
Show worked solution
No. The toy calculation does not establish that the process belongs to the owner class or can traverse the parent path, and it excludes ACLs and other policy. It reports a declared bit only. Real access diagnosis needs the full platform-specific context without speculative permission changes.
Key takeaways
- Successful authentication does not imply permission for every task.
- Diagnose narrowly and route access changes through accountable owners.