A domain administrator signs in to a user's laptop to fix a ticket - why does tiering forbid it?

## The rule, stated precisely The tier model assigns every asset and every account to a level of trust: - **Tier 0** - identity infrastructure: domain controllers, the directory itself, and any account or system that can control them. - **Tier 1** - servers and business applications. - **Tier 2** - workstations and the accounts that use them. The rule is not "be careful with domain administrator". It is directional and absolute: **a credential may be used only on a host at its own tier or higher.** Control flows down - tier 0 may manage tier 2 - but the credential must never be presented to the lower-trust machine. ## Why the direction matters When a logon creates a session on a host, that host must be able to act for the account for as long as the session lives. It follows that the administrator of that host is inside the boundary of that authentication: he controls the machine that is holding the ability to act, and a credential used on a machine you do not control is a credential you have given away. Windows makes the distinction visible through logon types. An interactive logon at the console is type 2 and a remote-desktop session is type 10 (RemoteInteractive); both create a session on the target. A network logon is type 3 - the account proves itself to a service on the target and no interactive session is created, so in the general case nothing reusable is left behind on that machine. The tier rule is essentially a rule about which logon types a high-trust account is permitted to perform against a low-trust host. This is also why the intuitive fixes miss. A 40-character password typed into a machine the adversary administers is his; strength was never the property under attack. A second factor at the logon prompt proves a human started the session; it says nothing about who else has administrator authority on the machine where the session lands. ## What the intruder does with it Put the affiliate on the laptop: code running with local administrator rights, tempo as his constraint, days rather than months to reach enough of the estate to be paid. Without tiering, he does not need to find a route out of the laptop at all - he can wait for one to arrive. Better still, he can induce it. Break something visible, raise a ticket, and the estate's own support process sends a privileged credential to the machine he owns. He converts one workstation into whatever that credential is administrator on, and he does it inside an approved, expected, routine workflow. That is the asymmetry to state in an interview: every other movement technique costs him work, and this one costs him a phone call. ## Making it removable without breaking support The reason tiering fails in real estates is that it is proposed as a prohibition and not as a redesign. Three moves keep the work possible: **A tier-2 support account.** Service-desk engineers get an account that is administrator on workstations and nothing else. It can be used on a laptop freely, because when the laptop is owned, all the intruder has gained is administrator on workstations he mostly already has ways to reach - and crucially not on servers or the directory. Nothing about the support workflow changes except which account is typed. **A privileged administrative workstation for the tiers above.** Tier-0 and tier-1 work is done from a dedicated, hardened machine that does no mail and no browsing, so the high-trust credential is only ever used on a high-trust host. Administrators dislike this until they understand the alternative is that their credential inherits the trustworthiness of the worst machine they have ever logged on to. **Management paths that do not deliver a session.** Where a high-tier system must act on a low-tier host, prefer mechanisms that authenticate to a service on the target rather than creating an interactive session there. ## The failure modes to name Tiering collapses quietly, and the collapses look like this: a break-glass account that is administrator everywhere and gets used routinely; a monitoring or backup service account running as tier 0 but installed on tier 1 and tier 2 hosts; a nested group that makes a tier-2 support group indirectly a member of something tier 1; and the enforcement gap - a tier model written in a document but never expressed as a logon restriction, so nothing actually stops the logon it forbids. If you can only make one point about tiering, make this one: a tier model that is not enforced at the point of logon is a naming convention. ## The boundary of the claim Tiering does not evict the intruder from the laptop, does not reduce what he can do to that user's own data or sessions, and does not shorten his access to the machine. It removes exactly one thing: the arrival of a credential worth more than the host it arrives on.