Chapter 8 — Directories and accounts

Chapter 8 — Directories and accounts

Lesson map

Lesson 08 published. Map, example, EX022.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 What the directory does"]
  N2["8.2 Accurate data"]
  N3["8.3 Service and shared accounts"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX022"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 What the directory does"]
  N2["8.2 Accurate data"]
  N3["8.3 Service and shared accounts"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]

[Learning outcomes]
    |
    v
[8.1 What the directory does]
    |
    v
[8.2 Accurate data]
    |
    v
[8.3 Service and shared accounts]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX022]

Learning outcomes

You will (1) explain what a directory does; (2) keep account data accurate; (3) manage service and shared accounts.

8.1 What the directory does

The cloud directory is Fernhill's central list of accounts, groups and sign-in rules. Other services trust it to confirm who is signing in, and administrators use it to create, change and disable accounts. Kai explains to the practice manager that the directory is only as good as its data: if job titles or clinics are wrong, rules and reports based on them will be wrong too. Keeping the directory accurate is therefore an access control task, not just tidy administration.

8.2 Accurate data

Kai compares the directory export with the HR list using his script. He finds 6 accounts whose clinic differs from HR, 4 with no job title, and 3 people in HR with two directory accounts each. He agrees with HR that HR is the source of truth for clinic and role, and with IT that the directory will be corrected monthly from the HR list. Duplicate accounts are merged or removed after checking which one each person actually uses. The monthly correction is itself a short runbook step with a named owner.

8.3 Service and shared accounts

Some accounts are not people: a scanner account that emails documents, a booking system integration and a shared reception mailbox. Kai lists each non-person account with an owner, purpose and how its credentials are stored. Shared sign-in accounts for reception are replaced with individual accounts plus fast user switching, so actions can be traced to a person. Service accounts that remain are given only the permissions they need, and their owners review them at each access review. Unowned service accounts are disabled after a warning period if nobody claims them.

Worked example

Comparing directory and HR finds 6 clinic mismatches, 4 missing titles and 3 duplicate people; 5 non-person accounts receive owners.

Synthetic case. Accounts and counts are synthetic.

Errors and limits

Shared sign-in accounts make actions untraceable to individuals.

Exercises

• EX022 — Source of truth. Which system is the source of truth for clinic and role? Rubric: 3 = HR;; 2 = HR list;; 1 = directory;; 0 = none.
• EX023 — Duplicates. How many people had two directory accounts? Rubric: 3 = 3;; 2 = three;; 1 = 6;; 0 = none.
• EX024 — Shared reception fix. What replaces shared reception sign-in accounts? Rubric: 3 = individual accounts with fast user switching;; 2 = individual;; 1 = one password;; 0 = none.

Synthesis

Accurate directory data and owned non-person accounts underpin every access rule and review.

Continue studying — chapter 08 of 30

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →