3.1User accounts, rights & permissions
The essentials in 30 seconds
- Three building blocks: the account (identity), the group (shared need) and the permission (right granted on a resource via an ACL).
- Rights are assigned to groups, never to people one by one: arrivals and departures are managed by simple membership.
- Least privilege: everyone has only the strict minimum; one administrator account too many is a risk, not a comfort.
Running mini-case — Sofiane welcomes an accountant in Algiers
Sofiane, a support technician turned systems administrator in a distribution SME in Algiers, welcomes a new accountant. The temptation would be to tick ten access boxes one by one; instead he applies the logic of the section. He creates an “Accounting” group, assigns it the permissions on the accounting share, then simply adds the newcomer to that group: she inherits all the right accesses at once. He checks that no account holds unnecessary administrator rights and notes the reflex: rights go to groups, people are managed by membership.
Standalone case for this section: it returns in the lesson, the diagram, the script and the 48h challenge of section 3.1.
1. Accounts, groups, permissions — the three building blocks
Three building blocks structure access management: the user account (an identity), the group (a set of users who share a need) and the permission (what you are allowed to do on a resource, via an ACL). The golden rule fits in one sentence: you assign rights to groups, not to people one by one. Sofiane always lays these three building blocks down before handing out the slightest access.
2. Why go through groups
Giving access to “Marie”, then to “Karim”, then to “Sonia” quickly becomes unmanageable. You create an “Accounting” group, give it the rights on the accounting share, and add or remove people from the group. A newcomer instantly inherits the right accesses; a departure is settled in a single action, with no risk of forgetting a right left lying around.
3. Least privilege
The principle of least privilege: everyone has only the rights needed for their work, no more. You avoid handing out administrator rights “to be safe” — an overpowered account is a major risk if its password leaks, if the user makes a mistake or if malware takes it over. Sofiane keeps this rule as a compass on every access request.
🔎 Concrete example — 🔎 Concrete example — A newcomer in accounting
Sonia joins the SME's accounting team. Sofiane compares two ways of doing things:
X Add Sonia manually to each folder/share/app
OK Add Sonia to the "Accounting" group
-> she instantly inherits ALL the right accessesReading: the group carries the rights; you only touch Sonia's membership.
Lesson: when she leaves, removing her from the group is enough — no forgotten access is left lying around.
Section vocabulary
- User account
- Digital identity of a person, with their credentials.
Simple example: Sofiane creates an account for each newcomer.
What it is not: a group that brings several identities together.
Reflex: one person → one account.
- Group
- Set of users sharing the same access need; it carries the permissions.
Simple example: The “Accounting” group receives the rights on the accounting share.
What it is not: a right set for a single named person.
Reflex: a shared need → a group.
- Permission (ACL)
- Right granted on a resource (read, write…) via an access control list.
Simple example: Sofiane gives the group read/write on the HR folder.
What it is not: the bandwidth allocated to a workstation.
Reflex: right on a resource → ACL.
- Least privilege
- Granting only the rights strictly necessary for each person's work.
Simple example: Sofiane refuses admin “to be safe”.
What it is not: giving administrator rights to all users.
Reflex: the strict minimum → least privilege.
- Administrator account
- Account with extended rights, to be reserved and especially protected.
Simple example: Sofiane uses admin only for administration tasks.
What it is not: a standard account used day to day.
Reflex: extended rights → to be protected.
In practice — In practice — Designing a rights model
- List three departments (accounting, HR, management) and their access needs, like Sofiane.
- Create one group per need and assign it the permissions on the resources.
- Place each user in the right group(s), with no individual right.
- Check that no account has unnecessary admin rights.
Step-by-step script — setting up a department's rights like Sofiane (4 min)
1) List the resources to open (shares, applications). 2) Create a group that carries the need (e.g. “Accounting”). 3) Assign that group the permissions on each resource, at the right level (read or read/write). 4) Add the people to the group, with no individual right. 5) Check that no account keeps an unnecessary admin right.
Keep this model: arrivals and departures become a simple membership to change, with no hunt for forgotten rights.
Copy-paste template — my rights matrix
Resource -> Group -> Level (read / write)
Accounting share -> group "Accounting" -> read/write
HR share -> group "HR" -> read only
Everyone else -> no access
Rule : rights TO GROUPS ; people by membership ; least privilegeA newcomer
Sofiane adds the new employee to the right group: they inherit all their accesses at once.
A departure
Sofiane removes the person from the group: no forgotten access is left lying around.
An admin request
A department asks for administrator rights: Sofiane applies least privilege and refuses the excess.
A confidential folder
Sofiane checks that no standard account can reach the HR department's confidential data.
✓ Best practices
- Give rights to groups, not to people.
- Apply least privilege on every access request.
- Reserve and protect administrator accounts.
✗ Common pitfalls
- Assigning individual access everywhere (unmanageable).
- Handing out admin “to be safe”.
- Forgetting to remove a leaver's rights.
Key takeaways
- Account (identity), group (shared need), permission (right on a resource).
- Rights are assigned to groups; people are managed by membership.
- Least privilege: just what is needed, no more.
- One admin account too many is a risk, not a comfort.
48h challenge — apply it tomorrow
Like Sofiane, draw the rights matrix of a department: a group, the permissions it carries (read or read/write) and the people attached by membership. Check that no account holds unnecessary admin and write in one sentence why rights go to groups rather than to individuals.
- I can explain the three building blocks: account, group, permission.
- I assign rights to groups and manage people by membership.
- I apply least privilege and protect admin accounts.
Frequently asked questions
Why not simply give admin to everyone?
Because an administrator account can modify or destroy anything: a mistake, malware or a stolen password cause maximum damage there. Least privilege limits the damage and reduces the attack surface.
What happens if permissions accumulate through several groups?
Rights add up, and an explicit denial generally overrides an authorisation. Hence the value of a simple model: too many overlapping groups make access unpredictable.
As good practice, to whom are permissions on a resource assigned?