Provisioning identity, account types, single sign-on and federation

Objective 4.5 is identity and access management, and it is a "given a scenario" objective: you will be handed a situation and asked which identity control fits it. This lesson takes the life of an account: creation, account type, trust across systems, the model that decides its access, and the review that notices when that access is wrong. MFA and passwords are the next lesson.

Why this matters

Identity is the boundary of a modern estate. Once users, data and applications left the building, the network edge stopped being the place where trust was decided, and the account took its place. That is why zero trust (lesson 4 for the principle, lesson 24 for the architecture) is built on identity signals, and why an attacker's first objective is almost always a credential.

The exam asks about account types, access models and federation protocols by what each is for.

The lesson

Provisioning and de-provisioning, and the account nobody closed

Provisioning creates an identity and grants it access; de-provisioning removes both. The life cycle in between -- joiners, movers, leavers -- is where the failures live.

• Joiners. Access is granted from a defined role, not by copying an existing user. "Make them like Sarah" is how excess access spreads, because Sarah holds rights from three previous jobs.
• Movers. The commonest failure in the objective: someone changes role and gains new access without losing the old. Over a career that builds accounts with remarkable combined privilege and quietly defeats separation of duties. The control is that a role change triggers a re-grant from the new role, not an addition to the old one.
• Leavers. Access is revoked when the departure is known, not at the end of the notice period. De-provisioning must reach past the directory: SaaS applications outside single sign-on, shared credentials the person knew, VPN certificates, API keys they created, and accounts they held in partners' systems.

Orphaned accounts -- accounts with no current owner -- are what failed de-provisioning leaves behind. They are a standing target, because nobody notices unusual activity on an account nobody uses. Finding them is a reconciliation between the directory and the HR system. The durable fix is to drive provisioning and de-provisioning from the HR record automatically, which lesson 38 returns to.

User, privileged, service, third-party and break-glass emergency accounts

Different kinds of account carry different risks, and the exam expects you to treat them differently.

• User accounts are for one named person doing ordinary work. They should hold no administrative rights; if that person also administers systems, they get a separate privileged account rather than elevated rights on the everyday one, so that reading email and browsing never happen with admin power.
• Privileged accounts can change systems, security settings or other accounts. Scope matters here. A global privileged account has authority across the whole directory or cloud tenant -- a domain administrator, a tenant global administrator -- and its compromise is compromise of the estate. A local privileged account is an administrator on one machine. Local admin accounts look minor, but if every machine shares one local admin password, one stolen hash opens all of them; Windows LAPS gives each machine its own rotated password. Keep global admins few, named, and on the strongest MFA.
• Service accounts are non-human identities that run applications, scheduled jobs and integrations. They are usually over-privileged, have passwords nobody rotates because something might break, lose their owner when their creator leaves, and cannot do interactive MFA. Inventory them, give each an owner, scope them to least privilege, deny interactive logon, and where possible use managed identities with no static password.
• Third-party accounts belong to vendors, contractors and partners. They should be named to a person, time-limited to the contract or the job, limited to the systems in scope, monitored, and switched off by default between support sessions. A permanently enabled vendor account with a shared password is a classic supply chain entry point.
• Emergency access (break-glass) accounts exist for the day normal administration fails: the identity provider is down, MFA is broken, or every admin is locked out. They are deliberately few, have very strong credentials held under dual control (for example, split between two sealed records), are excluded from the policies that could lock them out, and alert on every use, after which the credential is changed.

Identity proofing, federation, and SAML, OAuth and LDAP at exam depth

Identity proofing establishes that a person is who they claim to be before an account exists. Authentication proves you hold a credential; proofing proves the credential went to the right human in the first place. It happens at onboarding, and it happens again -- usually more weakly -- at password or MFA reset, which is why the help desk is a voice-phishing target. A reset procedure that does not rely on facts an attacker can look up is the control.

Single sign-on (SSO) lets a user authenticate once and reach many applications. Federation extends that trust across organisational boundaries, so an identity from one organisation is accepted by another. The identity provider (IdP) authenticates the user and issues an assertion or token; the service provider or relying party accepts it and grants access.

• SAML -- XML-based assertions, the long-standing enterprise choice for browser-based SSO into business and SaaS applications.
• OAuth 2.0 -- an authorisation framework, not an authentication one. It lets an application obtain limited, scoped, revocable access to a resource on a user's behalf without ever receiving their password. The ideas to hold are scopes (what the token may do), tokens that expire, and consent. OpenID Connect is the layer that adds authentication on top of it, which is what most "sign in with..." buttons use.
• LDAP -- the protocol for querying and updating a directory, the store of identities, groups and attributes. Active Directory is the common directory, using Kerberos tickets for authentication. Use LDAPS (or StartTLS), never plain LDAP, because a simple bind sends the password in clear text.

The distinction the exam wants: SAML is enterprise browser SSO, OAuth delegates access without sharing the password, LDAP is how you talk to the directory. If a scenario describes letting an application read your calendar without giving it your password, the answer is OAuth.

SSO cuts both ways: one strong credential with MFA and one place to revoke, but compromise of the IdP is compromise of everything behind it, and a stolen session token skips authentication entirely.

Access control models: role, rule, time-based, mandatory, discretionary and just-in-time

• Discretionary (DAC) -- the resource's owner decides who gets access. Flexible, and only as careful as each owner.
• Mandatory (MAC) -- the system enforces access from labels and clearances, and owners cannot override it. Rigid, used in high-assurance environments, and implemented on Linux by SELinux (lesson 29).
• Role-based (RBAC) -- permissions attach to roles and people are given roles. Manageable and auditable, and it makes joiners, movers and leavers tractable. Its failure is role explosion, where exceptions multiply roles until the model simplifies nothing.
• Rule-based -- access follows rules an administrator sets and applies to everyone the same way, regardless of who they are. Firewall rules are the everyday example.
• Time-based -- access allowed only in defined windows: working hours for a finance system, a maintenance window for a vendor. Cheap, and effective for anything with no legitimate out-of-hours use.
• Just-in-time (JIT) -- nobody holds the access by default; it is requested, approved, granted for a short period and then removed automatically. It replaces standing privilege, and lesson 37 covers it for admin rights.

Attribute-based control, deciding from attributes of user, resource and context, still underpins conditional access but is no longer a model this objective centres on.

Access policies and access reviews, and the permission that outlived the job

Access policies come in two layers, and the exam may ask which is which.

• Administrative or business policies are the organisation's decisions in writing: who approves access to payroll, that privileged access needs a second approver, that contractors expire with their contract, that duties are separated.
• Logical or technical policies are those decisions enforced by systems: the group membership, conditional access rule, ACL or time window that makes the business rule true without anyone remembering it.

A business policy with no technical enforcement is a hope; a technical rule with no business policy behind it is a guess.

Access reviews (also called recertification) are the periodic check that each person still needs each permission. A manager or system owner is shown who has what and must confirm or remove each item. They are the control for the mover problem and for the permission that outlived the job: the analyst who moved to sales but still reads the incident tracker. Reviews work when privileged and sensitive access is reviewed more often, removal is the default for anything not confirmed, and the reviewer can see what each permission grants. Approving 400 lines in a minute is a signature, not a control.

Keep two ideas separate: least privilege limits how much access an identity holds; separation of duties splits an action so no single identity can complete it alone. Offering one where the other is needed is a common distractor.

What to take into the exam

• The mover who keeps old access is the commonest provisioning failure; access reviews are its control, and leavers lose access when the departure is known.
• Global privileged accounts span the estate, local ones a single machine; break-glass accounts are few, dual-controlled, and alert on every use.
• Service and third-party accounts need an owner, least privilege and an expiry.
• SAML is enterprise browser SSO, OAuth delegates access without the password, LDAP queries the directory; SSO concentrates risk in the IdP.
• DAC = owner, MAC = system labels, RBAC = role, rule-based = same rule for all, time-based = when, JIT = granted only for now.
• Administrative policy states the rule; technical policy enforces it.