Chapter 10 — Privileged and service accounts
Lesson map
Lesson 10 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Finding them"]
N2["10.2 Separate admin accounts"]
N3["10.3 Service accounts"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Finding them"]
N2["10.2 Separate admin accounts"]
N3["10.3 Service accounts"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]
[Learning outcomes]
|
v
[10.1 Finding them]
|
v
[10.2 Separate admin accounts]
|
v
[10.3 Service accounts]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) identify privileged and service accounts; (2) separate admin accounts; (3) store service credentials safely.
10.1 Finding them
Tomas lists every account with administrative rights: two directory admins, the dental records admin, the payroll admin and the device management admin. He also lists service accounts: the scanner that emails documents and an integration that sends appointment reminders. He finds that both IT staff use their daily email accounts as directory admins. That means any phishing email that captured their sign-in would also capture administrator control, which is the most important single risk in the directory. He confirms the list with the practice manager before changing anything.
10.2 Separate admin accounts
Tomas creates separate admin accounts for both IT staff, used only for administration, protected with hardware keys and limited to managed devices. Their daily accounts lose admin roles. He keeps one emergency admin account with a long random password and a hardware key stored in the practice safe, used only if normal admin access fails, and its use triggers an alert. This follows the principle that administrator rights should not sit on accounts exposed to everyday email and browsing. The change is recorded.
10.3 Service accounts
Service accounts cannot use interactive multi-factor authentication, so Tomas restricts what they can do. The scanner account can only send email, and only from the practice network. The reminder integration uses an application credential with permission only to read appointment times. Credentials are stored in the password manager with an owner and renewal date. Each service account is reviewed at every access review, since unused service accounts are easily forgotten yet often have broad permissions. Tomas confirms each restriction with a test before recording it as done.
Worked example
Admin roles move to separate key-protected accounts; an emergency account is sealed in the safe; two service accounts are restricted and owned.
Synthetic case. Accounts and settings are synthetic.
Errors and limits
Using daily email accounts as admins exposes administrator control to ordinary phishing.
Exercises
- EX037 — Main risk. What was the main admin risk found? Rubric: 3 = daily email accounts used as admins;; 2 = combined;; 1 = vague;; 0 = none.
- EX038 — Emergency account. Where is the emergency key stored? Rubric: 3 = the practice safe;; 2 = safe;; 1 = desk;; 0 = none.
- EX039 — Scanner limit. What can the scanner account do? Rubric: 3 = send email only, from the practice network;; 2 = send;; 1 = everything;; 0 = none.
- EX040 — Service storage. Where are service credentials stored? Rubric: 3 = password manager with owner and renewal date;; 2 = manager;; 1 = note;; 0 = none.
Synthesis
Separate admin accounts and narrowly scoped service accounts contain the most powerful access.
Continue studying — chapter 10 of 18
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →