In an Active Directory or workload-identity estate, why is stepping sideways the same operation as stepping up?
answer
- kernels enforce levels, directories attach sets
- unordered entitlements have no up
- one operation: hold a credential, present it
- administrator is an object, not an altitude
- reusable secret plus entitlement gates the move
basics
~20 sBecause authorisation there attaches to each identity as an unordered set of entitlements, with no enforced gap between peers. Every step, across or up, is the same act: obtain a credential and authenticate with it.
solid answer
~50 sPrivilege levels are a property of a single machine. A kernel maintains an enforced gap between an unprivileged context and an administrative one and polices it. A directory has no such gap between two accounts: each simply carries whatever entitlements someone attached to it, and those sets are not ordered, so there is no defined `up`. The operation an operator performs is therefore identical in both cases — acquire something that authenticates as the target identity (a password, a hash, a ticket, a token, a key) and present it. Whether that identity is nominally junior or senior changes nothing about the mechanism, only about what becomes reachable afterwards. The same is true of workload identity: a cluster service account or a cloud role attached to a workload is just another peer with its own set. That is why an estate can harden the user-to-administrator boundary on every host and still be wide open — the interesting move never touches that boundary.
go deeper
Know that a directory account's power comes from what is attached to it, not from a rank, and that using another account means having something that authenticates as it.
Be ready to contrast a kernel-enforced boundary with an unordered entitlement set and to state the single operation both directions reduce to. This is the mechanics tier and the interviewer wants the mechanism named.
Show the operational consequence: an estate can pass every host-hardening check and still hand over production, because the move that matters never crosses the boundary that was hardened.
Own the framing shift — exposure is measured per entitlement and per reusable secret, not per admin count, and reporting that counts privileged accounts will keep describing an estate that is not the one you have.
## Two different models of authorisation The word *privilege* is doing double duty, and the confusion at the heart of this question comes from that. **Model one: an enforced level.** On one machine, the operating system maintains a small number of ordered contexts and enforces movement between them. Non-root and root. An unprivileged token and an elevated one. The ordering is real, the boundary is code, and crossing it without permission requires either a defect or a primitive that was configured wrongly. This is the model everybody learns first, and it is where the ladder metaphor is honest. **Model two: an attached entitlement set.** A directory, and equally a cloud or cluster identity system, does something quite different. It stores identities and attaches things to them: group memberships, rights over other objects, permissions on resources, roles. Two identities are not at levels; they hold *sets*. Those sets are not ordered, and typically not even comparable — one account can create users while another can read the customer database, and neither is above the other in any sense the system implements. ## What follows immediately If there is no ordering, there is no "up". The verb the operator performs against any identity in model two is always the same: **hold something that authenticates as it, and authenticate**. That is one operation. Applied to a peer it is called lateral movement; applied to an account someone considers senior it is called escalation; the machine cannot tell the difference because there is no difference at the mechanism level. Note what this does *not* say. It does not say the directory is badly designed, and it does not say every account is equally useful. It says the classification a human applies afterwards — sideways or upward — is not tracking anything the system enforces. ## "Administrator" is an identity, not an altitude A highly privileged directory account is not sitting on a higher floor. It is an object with an unusually generous set attached, reached by exactly the same authentication operation as any other object. That is why the strongest-sounding boundary in an estate is frequently the weakest thing about it: it is a *naming* boundary that an operations team believes in, not an enforced one. ## Workload identity does the same thing, with less ceremony A cluster service account bound to a pod, or a cloud role assumed by a build job, is an identity whose credential is materialised automatically for whatever code is running there. Two workloads in the same estate are peers. If one of them holds a right the other does not, then reaching the first workload's identity is exactly as valuable as "escalating", and involves no escalation. Role-assumption chains push this further: a chain of assumptions is a sequence of perfectly ordinary, fully authorised operations that ends somewhere with far more entitlement than it began. ## The consequences an interviewer wants to hear 1. **Host hardening does not bound the estate.** Preventing an unprivileged user from becoming a local administrator on four hundred machines is real work with real value, and it constrains none of the moves described above. 2. **The unit of exposure is the entitlement, not the account tier.** Asking "who is an admin?" measures the wrong thing; asking "what does this identity reach, and what else can obtain its credential?" measures the right one. 3. **The step has no size.** People expect an escalation to feel like an event — an exploit, a crash, a defect. Here it is an authentication that succeeds, indistinguishable in kind from the tens of thousands of authentications that succeed every hour for legitimate reasons. 4. **The two properties that actually gate the move** are that a *reusable* secret exists, and that the identity holding it is entitled to something worth having. Take away reusability, or take away the entitlement, and the move stops existing. Neither of those lives on the host where the ladder was hardened. ## What is out of scope for this answer How an operator *discovers* which peer identity is worth taking, and which remote channels carry the credential to a target, are separate subjects with their own mechanics. This question is only about why the two directions of movement are one operation. Keep the answer at that level and you will sound precise rather than vague. ## A compact way to say it "A kernel enforces levels; a directory attaches sets. Levels are ordered so crossing one is an event, sets are not ordered so moving between them is just authentication. In an estate, the escalation *is* the lateral move."
- Does that mean privilege escalation is a meaningless idea in a directory estate?It stays meaningful on each host, where the kernel really does enforce a boundary. What stops being meaningful is using it to reason about the estate: between two directory or workload identities there is no enforced gap, so the interesting movement never registers as escalation and any planning that watches only for escalation misses it.
- How does role assumption in a cloud account fit this picture?It is the clearest case. Each assumption is an authorised operation performed by an identity that was granted permission to perform it, and a chain of them can end with far more entitlement than it started with. Nothing in the chain is an elevation in the kernel sense, which is exactly why chains grow unexamined.
- Why does hardening local administrator rights on every host not bound this?Because the move it prevents is not the move being used. Local elevation constrains what a compromised process can do on one machine; the estate-level step is an authentication as another identity that already holds the entitlement, and it works identically whether or not the operator is a local administrator anywhere.
A hotel with keys cut per guest rather than per floor. There is no higher floor to climb to; there is only a key ring that opens more doors than yours, and taking it is the same act as using your own.
saying these in an interview costs you the question
- Describes a directory as having privilege levels the system enforces
- Thinks escalation always requires an exploit or a defect
- Believes admin-tier separation bounds what one credential reaches
- Cannot say what the operation actually is: authenticate as someone else
- Treats workload identities as configuration rather than as accounts