On a shared terminal-server address, how do you attribute one flow to one user?

## Why the address is not enough A virtual-desktop or terminal-server farm collapses hundreds of people onto a handful of source addresses. A mapping table keyed on address can hold exactly one name per address, so the question is not *which user is on 10.44.7.19* - it is *which of the three hundred users on 10.44.7.19 opened this particular connection*. Everything the leaf turns on follows from that: identity has to be carried at a finer granularity than the address, or it is not carried at all. ## Source-port-range attribution The standard mechanism is to slice the host's ephemeral port space. An agent running on the multi-user host: 1. detects a session starting and which user owns it 2. reserves a block of source ports for that session and constrains the session's outbound connections to it 3. reports the binding (address, port range, user, session) to the enforcement point 4. releases the block when the session ends The firewall then attributes a flow by looking up its **source port** inside the ranges bound to that address. Two people on the same host get different rules because their connections are born in different port blocks. An abridged table looks like this: (see the accompanying fragment) ## What defeats it **A source-port rewrite anywhere in between.** If any device between the host and the enforcement point performs address or port translation, the ports the firewall observes are not the ports the agent allocated. Attribution does not merely degrade - it can land a flow inside the *wrong* user's range, which is worse than no answer, because the log now confidently names an innocent person. The enforcement point must sit on the same side of any translation as the port allocation, or the translating device itself must carry the identity forward. **Traffic that never had a session.** A scheduled task, a backup job, a monitoring agent or anything running as a machine or service account has no interactive session, therefore no allocated block, therefore no user. Those flows come from unallocated ephemeral ports and fall to the unknown-user rule. In practice this is the traffic that first exposes whatever your unknown-user posture really is, and it should be handled with explicit rules of its own instead of being left to the catch-all. **Exhaustion and churn.** A block per session is a finite resource. A host with a larger shift than the port space was provisioned for will fail to allocate, and the sessions that miss out are attributed to nobody. Long-lived sessions that outlive an allocation, and reconnects that pick up a recycled block, both produce brief windows where the binding and reality disagree. **Hosts you cannot instrument.** The mechanism requires software on the host. An appliance-like multi-user system, a vendor-managed jump host or anything outside your build pipeline gives you one address and no names at all. ## The adversary this is really about Sub-address attribution improves policy, but it does not authenticate anything. It reports what the host says about its own sessions. An intruder who obtains execution on that shared host - through a hijacked session, a stolen desktop token, or simply another account on the same box - makes connections that fall inside some allocated range, and the enforcement point applies **that user's** permissions and writes **that user's** name into the record. The firewall has no way to disagree; it never saw a person, only a port number and a claim. The consequences for you are two: - **Policy.** The blast radius on a multi-user host is the union of what any session on it may reach, unless you also constrain the host itself. Treat a shared host as a place where a foothold buys somebody else's entitlements, and size the rules for that. - **Evidence.** A firewall log naming a user for traffic from a shared host is a derived claim resting on the host's own session isolation. Before that name goes into a report, corroborate it against the host's session records. If you cannot, say so plainly rather than letting the log carry more weight than it can hold. ## What you are buying The honest summary: you deploy and maintain an agent everywhere, spend ephemeral port space, accept blind spots on hosts you cannot instrument, and accept that the whole scheme is void behind a translation hop - and in return you get user-level policy and user-level logging on the machines where the largest number of people share the fewest addresses. On a farm serving shift workers, that trade is usually worth making. It is only dangerous when somebody forgets it is a trade and starts treating the resulting log line as proof.