What is the user supposed to be able to do?
The required work is assigned-report reading and editing, with archive deletion and permission changes refused. Our fictional analyst, Asha, belongs to Analysts and Archive-admins. The first group supplies the two required actions. The second supplies the two unwanted ones.
Write the expected outcome for all four actions before changing a setting. Otherwise, a repair that removes every permission may look secure while preventing Asha from doing her job. A repair that preserves reading might still leave deletion available.
The exercise states that grants combine and there are no deny rules. Those mechanics are part of the question. Real products may have nested roles, denies, resource inheritance or other rules that change effective access. Use their actual documentation when working outside this invented lab.
How do I trace the source of an effective permission?
Trace the user assignment to the role or group, then the operation and resource that it grants. NIST’s RBAC background describes the underlying user, role and permission relationships; it does not define the evaluation rules of every current product.
For Asha, Analysts contributes read and edit. Archive-admins contributes delete and permission change. The effective result contains all four operations under the stated additive model. A permission matrix helps keep required access separate from current grants.
A successful authentication event does not grant every action. Review authentication, authorization and accounting if those decisions are blending together.
Why would removing a direct grant leave the problem?
Removing one grant leaves access available when another active source still supplies it. In the initial case there is no direct delete grant to remove; Archive-admins is the source of that power.
Even if you add a separate direct delete grant as a changed case, deleting only that direct grant would leave the inherited administrator grant. Conversely, removing only the administrator membership would leave the added direct grant. Trace every active source rather than choosing the most visible setting.
The narrow initial repair is to remove Asha’s unintended Archive-admins membership and retain Analysts. Do not delete a shared group to change one person’s assignment.
How do I verify that the repair meets all four outcomes?
Verify the four actions using Asha’s refreshed authorisation context. The lab requires saving the membership change and refreshing the context before making fresh requests. Old records show what happened earlier; they do not establish the result after the repair.
Record read success, edit success, deletion refusal and permission-change refusal. A different administrator account is not a substitute for testing Asha. Use the table below to predict the required results, then explain which grant supplies each action.
The response sheet also asks you to add a direct delete grant as a changed fact. Calculate the new effective row and choose the additional repair before reading the answer.
What should I learn from the permission task?
Learn to explain the assignment, operation, resource and evidence of the result. Naming least privilege is a useful start, but the worked case requires you to show which access supports the job and which source adds excessive powers.
Continue by changing a condition: the assignment expires, the resource changes, or an extra grant appears. Keep unrelated facts fixed so you can explain exactly why the answer changes. Use practice scores and changed-case reasoning to assess whether you can transfer the decision to a new problem.
