Your exchange tier needs directory, resolution and certificate validation — why duplicate those inside it rather than let a possibly-compromised tier host query the interior copies?

## The question behind the question An exchange tier is not just the partner-facing applications. Those applications need somewhere to authenticate their own service accounts, somewhere to resolve names, and some way to decide whether a certificate presented by a partner is still valid. Each of those is a dependency, and each has exactly two answers: open a path inward to the interior copy, or stand up a copy in the tier. Interviewers ask it because the tempting answer — "we allow just directory and DNS inward, they're read-only" — quietly dismantles the boundary the rest of the design paid for. ## What each hole actually gives an intruder **Directory.** An interior directory is a reconnaissance database with an authentication front door. Authenticated reads return user accounts, group membership, service accounts, computer objects and the descriptions people put in them. An intruder on a tier host with a permitted path to it can map the organisation without moving laterally at all, and the queries look exactly like the ones the tier's applications make, because the path was sanctioned. Worse, it is an authentication surface: every credential the intruder collects in the tier can now be tested against it. **Name resolution.** An interior resolver knows the internal namespace, which is a map of the estate: service names, environment names, host naming conventions. It is also a service inside the boundary that will process arbitrary input from an untrusted zone on demand. **Certificate validation.** A path inward to an interior issuing authority or its revocation endpoints is a smaller prize but the same shape — a live interior service reachable from a zone you declared untrusted. In every case the argument "but it's read-only" confuses *what the service does for us* with *what it answers for them*. ## The duplicated design - **A separate directory for the tier**, holding only the service accounts and groups the tier's own applications need, with no trust relationship back to the interior. Compromise of that instance yields the tier's own accounts, which the intruder already had on the host, and nothing about the interior. - **A resolver in the tier**, authoritative for the tier's own names and forwarding everything else outward to public resolution — never to the interior resolver. The internal namespace is simply not present in the tier. - **Local trust and revocation.** The tier validates partner certificates against a trust store it holds, with revocation material published *outward* to a location the tier can read locally. - **Reference data pushed, not pulled.** Where the tier legitimately needs a subset of interior data (a partner list, a product catalogue), the interior pushes a read-only copy outward on its own connection. This is the same inversion the whole tier runs on: the interior always dials. Notice that every synchronisation path in this list is interior-initiated, so the duplication is *compatible* with the boundary rule rather than in tension with it. That is the point that makes the design coherent instead of a pile of exceptions. ## The bill, stated honestly A senior answer does not pretend duplication is free: - **A second patch cycle** for each duplicated service, on hosts that are internet-adjacent and therefore the ones you least want behind on patches. - **A second backup and restore path**, and a second restore you have to have actually rehearsed. - **Two certificate lifecycles**, with renewals in the tier that nobody remembers because the interior team owns the calendar. - **Drift, which is the interesting one.** A disabled account, a rotated password policy, a revoked certificate — each propagates to the tier only as fast as the push you built. On the day propagation fails, the tier is the place still accepting what the interior has already rejected, and nobody notices because nothing broke. Age monitoring on the replication is not optional; a replica that stops updating must be louder than a replica that never existed. - **Duplicate identities to reconcile.** Two directories means two places an account can exist, and joiners-and-leavers processes that were written for one. ## Where the line honestly sits Not everything gets duplicated. The test is what the interior copy would answer to a hostile caller. A service that answers questions about the estate (directory, internal resolution) or that holds authentication authority is duplicated with a scoped subset. A dependency that can be inverted into an interior-initiated push or collection is inverted instead of duplicated, because a push costs less than a second running service. And a dependency that is neither — one that genuinely needs a live interior answer inside a partner request — is the case that becomes the tier's single, narrowly built inward exception, argued on its own merits rather than smuggled in under the word "infrastructure". That framing is what an interviewer is listening for: duplication is not dogma, it is the price you accept for the dependencies whose interior copy would answer an intruder's questions honestly.