Chapter 63 — Enterprise identity and access

In one sentence

The identity provider is now the organisation's crown jewel — compromise it and every federated system falls with it — so enterprise identity work is hardening the IdP itself, securing any legacy directory behind it, generalising Part 7's just-in-time access pattern to all infrastructure via privileged access management, and closing the joiner-mover-leaver lifecycle gaps that quietly accumulate standing risk.

Where we are

Part 7 Ch 49 built just-in-time access governance for data. Part 6 Ch 39 covered SAML/OAuth attacks against individual applications. This chapter is the identity layer that sits above both: the SSO provider federating everything, the directory behind it, and the enterprise-wide privileged-access discipline that generalises Ch 49's pattern.

How it works

Hardening the IdP itself — it is now the highest-value target in the organisation:

   Every application federated to a single IdP (Okta, Entra ID, Ping
   Identity, or similar) INHERITS that IdP's compromise -- a Golden-
   SAML-class event (Part 6 Ch 39) at the IdP is, functionally, a
   compromise of every downstream application simultaneously.
   [ ] IdP ADMIN accounts require PHISHING-RESISTANT MFA (WebAuthn/
       passkeys, G1 Ch 46) without exception -- this is the single
       highest-value account class to protect in the entire
       organisation.
   [ ] the admin CONSOLE itself is access-restricted (network-level
       where possible, e.g. only from a managed-device/VPN context) and
       every admin action is logged to the HIGHEST-PRIORITY telemetry
       source in your Part 8 pipeline -- an IdP admin-log anomaly should
       page someone faster than almost anything else you monitor.
   [ ] a BREAK-GLASS account for the IdP ITSELF (distinct from any
       application-level break-glass, Part 7 Ch 49) -- if the IdP is
       unavailable or compromised, you need a path back in that doesn't
       depend on the IdP working. Store its credentials offline/
       physically secured, test it periodically, and alert immediately
       on any use.
   [ ] CONDITIONAL ACCESS / risk-based authentication (below) configured
       at the IdP level protects every downstream application at once,
       rather than requiring each application to implement its own
       risk-scoring.

Directory security — Active Directory, still common behind many enterprise IdPs:

   Many organisations' cloud IdP is SYNCHRONISED from an on-premises
   Active Directory (via Entra Connect / similar) -- meaning AD's own
   security posture directly determines the cloud identity layer's
   trustworthiness too. Baseline hardening:
     [ ] a TIERED ADMINISTRATION MODEL (Microsoft's Tier 0/1/2):
           Tier 0 = domain controllers and identity infrastructure itself
           Tier 1 = servers
           Tier 2 = workstations
         with the STRICT rule that an admin credential for a LOWER tier
         must NEVER be usable to escalate to a HIGHER tier (e.g. a
         workstation-admin credential should never also work as a
         domain-controller admin) -- this is the same "blast-radius
         containment" principle as Part 2's IAM permission boundaries and
         Part 4's Kubernetes RBAC scoping, applied to the directory.
     [ ] LAPS (Local Administrator Password Solution) -- randomised,
         UNIQUE local administrator passwords per machine, rotated
         automatically -- defeats the classic "one shared local admin
         password reused across the whole fleet" pattern that turns one
         compromised workstation into lateral movement across all of
         them.
     [ ] protect and periodically ROTATE the krbtgt account (the Kerberos
         ticket-granting-ticket service account) -- its hash is what
         makes GOLDEN TICKET forgery (below) possible; a stale, never-
         rotated krbtgt is a standing, severe risk.
     [ ] DISABLE legacy protocols (NTLMv1, unconstrained Kerberos
         delegation) that enable many of the classic attack paths below.

AD attack paths — enough literacy to have an informed conversation, even though deep AD pentesting is outside this guide's scope (Ch 69):

   KERBEROASTING     request a Kerberos service ticket for any account
     with a registered Service Principal Name (SPN); the ticket is
     encrypted with that SERVICE ACCOUNT'S PASSWORD HASH -- crack it
     OFFLINE, with no further interaction needed. Mitigation: long,
     random service-account passwords, or Group Managed Service Accounts
     (gMSA, which rotate automatically and are effectively immune).
   AS-REP ROASTING   accounts configured with "do not require Kerberos
     pre-authentication" can have their hash requested and cracked
     offline similarly, with no valid credentials needed at all.
     Mitigation: don't disable pre-auth unless there's a specific,
     understood reason.
   DCSYNC            an account with DOMAIN REPLICATION rights (e.g.
     `GetChangesAll`, normally reserved for domain controllers themselves)
     can impersonate a domain controller and pull EVERY password hash in
     the domain, including krbtgt -- a direct route to Golden Tickets
     (below). Mitigation: strictly limit replication-rights grants,
     monitor for replication requests originating from NON-domain-
     controller hosts (a strong, specific detection signal).
   GOLDEN / SILVER TICKETS   forge Kerberos tickets using a stolen
     krbtgt hash (Golden -- unrestricted, any user, any privilege, any
     service, for as long as the hash is valid) or a stolen SERVICE
     account hash (Silver -- scoped to that one service) -- both provide
     PERSISTENT, hard-to-detect access surviving normal password resets
     (a Golden Ticket survives until krbtgt is rotated TWICE).
     Mitigation: the tiered model + LAPS + krbtgt rotation above, plus
     detection for anomalous ticket lifetimes/encryption-type patterns.
   PASS-THE-HASH / PASS-THE-TICKET   reuse a captured password hash or
     Kerberos ticket directly, without ever knowing the plaintext
     password -- the direct reason the tiered model (above) matters: if
     tiers are properly separated, a hash/ticket captured at a lower tier
     simply doesn't work at a higher one.
   BLOODHOUND (the direct AD analogue of Part 1/2/4's PMapper/KubeHound)
     is the standard tool for GRAPHING these attack paths across a real
     domain -- the SAME attack-path methodology from Part 1 Ch 1, applied
     to Active Directory specifically. If your organisation runs AD, this
     is worth running (with authorisation, per G1 Ch 0.6) at least once
     to see your own actual exposure, even if deep AD offense/defense is
     otherwise outside this guide's scope.

Cloud-hybrid identity risk — where AD and the cloud IdP meet:

   The AD-CONNECT (or equivalent) SYNC ACCOUNT is a uniquely
   high-value target: compromising it can grant an attacker the ability
   to affect BOTH the on-premises directory AND the cloud tenant it
   synchronises to.
   PASSWORD HASH SYNC vs PASS-THROUGH AUTHENTICATION is a real
     architectural trade-off (hash sync means the cloud IdP CAN
     authenticate independently if on-prem AD is unavailable, at the cost
     of the hash existing in the cloud too; pass-through keeps
     authentication decisions on-prem, at the cost of an on-prem outage
     also breaking cloud sign-in) -- know which your organisation uses
     and why.
   FEDERATION TRUST (e.g. ADFS) compromise is DIRECTLY the Golden SAML
     scenario from Part 6 Ch 39 -- the token-signing key for federated
     sign-in is exactly the kind of asset that chapter's "protect it like
     a root CA" guidance applies to.

Lifecycle management — Joiner/Mover/Leaver, automated from a single source of truth:

   PROVISIONING/DEPROVISIONING driven AUTOMATICALLY from the HR system
   (the authoritative source of "this person is employed, in this role,
   as of this date") rather than manual, ad-hoc account creation/removal
   -- SCIM (System for Cross-domain Identity Management) is the standard
   protocol for propagating these lifecycle events automatically across
   every connected SaaS application, not just the core IdP.
   THE "MOVER" CASE IS THE MOST COMMONLY NEGLECTED: joiner (new hire) and
   leaver (termination) processes usually get real attention; an
   employee CHANGING TEAMS/ROLES internally often keeps their OLD
   access indefinitely because no "offboarding" trigger ever fires for an
   internal move -- this is EXACTLY Part 7 Ch 49's worked-example finding
   (the engineer who rotated teams and kept stale access), generalised
   here as a structural, enterprise-wide lifecycle-management gap rather
   than something recertification alone should have to catch after the
   fact.

Privileged Access Management (PAM) — Part 7 Ch 49's JIT pattern, generalised to ALL infrastructure/admin access:

   Tools: CyberArk, HashiCorp Boundary, Teleport, BeyondTrust -- providing,
   across servers, network devices, databases, and cloud consoles broadly
   (not just the data-specific access Part 7 Ch 49 focused on):
     CREDENTIAL VAULTING   no human ever directly knows the actual
       privileged password/key -- either a check-out/check-in model, or
       (better) fully JIT-GENERATED, short-lived credentials issued per
       session and auto-expired (the same principle as G1 Ch 49's dynamic
       secrets and Part 2's IAM temporary sessions, applied to
       human-operator infrastructure access specifically).
     SESSION RECORDING/PROXYING   every privileged session is logged and,
       for the most sensitive systems, fully recorded/replayable -- the
       SAME control this guide has now applied at the data layer
       (Part 7 Ch 49), the CI/CD layer (implicitly, via pipeline audit
       logs, Part 3), and now the general infrastructure-admin layer.
   This chapter and Part 7 Ch 49 are the SAME underlying principle
   (least standing privilege, time-boxed access, full session
   accountability) applied at two different layers -- data access there,
   infrastructure/directory access here -- and a mature program runs BOTH
   through a consistent, ideally SHARED, tooling and governance approach
   rather than as separate initiatives with separate tools and separate
   review cycles.

Conditional access and device trust — identity plus context, not identity alone:

   CONDITIONAL ACCESS (Entra Conditional Access, Okta's equivalent)
   dynamically adjusts AUTHENTICATION REQUIREMENTS based on real-time
   signals: is this device COMPLIANT/managed (an MDM-attested posture
   check, not just "is this the right password"), is the source IP/
   location consistent with this user's normal pattern (directly the
   PREVENTIVE complement to Ch 53's UEBA, which is DETECTIVE -- conditional
   access tries to stop the anomalous sign-in before it succeeds; UEBA
   catches the pattern if it gets through anyway), is the IP address
   itself known-risky (reputation feeds, again connecting to Ch 53's
   threat-intelligence enrichment).
   DEVICE TRUST as an access-control INPUT, not just user identity: even
   correct credentials plus correct MFA from an UNMANAGED, non-compliant
   device can be denied access to the most sensitive systems -- treating
   "what is this request coming from" as a first-class signal alongside
   "who is this request claiming to be."

Worked example

Closing the mover gap with automated lifecycle management, generalised from Part 7's specific finding.

   Part 7 Ch 49's worked example found ONE stale grant (an engineer who
   moved from payments to marketing, still in the payments-restricted
   group) via QUARTERLY RECERTIFICATION -- a detective control, catching
   the gap after the fact, once per quarter.

   THE ENTERPRISE-WIDE FIX (this chapter): rather than relying on
   recertification to eventually catch every such case, SecureShop wires
   its HR system (the single source of truth for role/team) directly to
   its IdP via SCIM, with an explicit "MOVER" event type (distinct from
   joiner/leaver) that AUTOMATICALLY:
     1. removes group memberships tied to the OLD team/role the moment HR
        records the change (not waiting for the next recertification
        cycle).
     2. provisions memberships for the NEW team/role automatically, so
        the employee isn't blocked from their new work while waiting on
        manual IT ticket processing.
     3. logs the automated transition to the SAME Part 8 telemetry
        pipeline, so an unusually large batch of automated moves (a
        reorg) or an unexpected MANUAL override of the automated process
        is itself visible and reviewable.

   RESULT: the SAME class of finding Part 7 Ch 49 caught reactively,
   once per quarter, is now PREVENTED structurally, in near-real-time,
   for every future internal move across the whole organisation -- and
   recertification (Part 7 Ch 49) remains as the BACKSTOP for whatever
   this automated pipeline still misses (a role change HR records
   informally before it's official, a group membership granted outside
   the SCIM-managed set entirely), exactly the same "structural control
   plus periodic review as backstop" pattern used throughout this Part.

Practice (75 min)

Review your own (or a lab/hypothetical) organisation's IdP admin-account protection: is phishing-resistant MFA enforced without exception for admin roles? Is there a tested, offline break-glass path?
If you have access to (or can simulate) an Active Directory lab environment, run BloodHound against it and review at least one full attack path it surfaces — compare the experience directly to Part 1's PMapper/KubeHound exercises.
Design a SCIM-driven joiner/mover/leaver automation for a hypothetical HR system integration: what events fire for each case, and what happens automatically vs what still requires human review.
Set up (or review) conditional access policies for one real or lab IdP: require a compliant/managed device for access to one sensitive application category, and confirm access is denied from an unmanaged device even with correct credentials and MFA.
Map this chapter's PAM pattern against Part 7 Ch 49's JIT data-access pattern — identify where your organisation (or your lab setup) could share tooling/governance between the two rather than running them as separate initiatives.

Common mistakes

IdP admin accounts without phishing-resistant MFA. The single highest- value target in the organisation, frequently under-protected relative to its actual blast radius.
No break-glass path for the IdP itself. If the IdP is unavailable or compromised, a recovery path that depends on the IdP working is not a recovery path.
Treating AD hardening as irrelevant because "we're cloud-first." Many cloud IdPs sync from an on-prem directory; that directory's security posture is inherited, not bypassed.
A shared local administrator password across the fleet. Turns one compromised workstation into fleet-wide lateral movement; LAPS exists specifically to prevent this.
Provisioning/deprovisioning as a manual, ticket-driven process. The mover case especially falls through manual processes; automate from HR as the source of truth.
PAM built as a separate initiative from Part 7 Ch 49's data-access governance, duplicating tooling and review processes for what is fundamentally the same principle applied to a different layer.
Conditional access configured for user identity/location alone, ignoring device trust. Correct credentials from a compromised or unmanaged device are still a real risk.

Check yourself

Why is the identity provider described as the organisation's crown jewel, and what two specific hardening measures follow directly from that?
What is the tiered administration model (Tier 0/1/2) and what rule must never be violated across tiers?
Describe Kerberoasting and Golden Ticket attacks in one sentence each, and name the mitigation for each.
Why is the "mover" case in joiner/mover/leaver lifecycle management specifically prone to being neglected, and what structural fix addresses it?
How does this chapter's PAM pattern relate to Part 7 Ch 49's JIT data-access pattern — same principle or different?
Conditional access vs UEBA (Ch 53) — which is preventive and which is detective, and why do you need both?

End of Part 9 — Milestone check

I can design SDLC security gates (SAST/SCA/DAST/IaC) mapped to the right pipeline stage, and roll out a PR-blocking gate without an engineering revolt
I can prioritise a real vulnerability backlog using CVSS, EPSS, KEV, reachability, exposure, and asset criticality — and produce a defensible top-N from thousands of findings
I know the offensive-testing maturity progression (VDP -> bounty -> pentest -> red team) and can explain why each order matters
I can distinguish genuine compliance evidence from compliance theater, and map this guide's own artifacts onto a real framework's controls
I can build a risk register, choose metrics that matter over vanity metrics, and translate a real technical finding into a quantified, fundable business case
I understand why the IdP is the organisation's highest-value target, the Tier 0/1/2 model, the core AD attack paths, and how PAM generalises Part 7's JIT pattern enterprise-wide