What does a firewall's user-to-address mapping actually prove about who sent a packet?
answer
- the packet has no name in it
- a lookup, not a header field
- the table is a lease with an expiry
- someone else on that address inherits it
- the firewall trusted a third party's claim
basics
~20 sOnly that some identity source associated that address with a user earlier, and the association has not yet expired. The packet itself carries no identity, so whoever is using that address next inherits the name.
solid answer
~50 sNothing about the packet. A packet carries a source address and no identity at all; the name comes from a separate table the firewall builds from an identity source it trusts - an agent on the host, an off-path subscription to the directory's authentication servers, or a portal the user logged into. That table asserts one thing: at some earlier moment this address was associated with this user, and that association has not timed out. If the address is shared, reassigned, or borrowed by an intruder sitting on the same multi-user host, policy still resolves to the mapped name and your logs still print it. A rule written against a username is really a rule against an address that a table currently labels with that username, and the control is only as strong as the labelling - which you had to deploy and operate to get at all.
go deeper
Be ready to say plainly that packets carry no user name and that the firewall is doing a table lookup. Know the three ways the table gets filled: an agent, a feed from the authentication servers, or a portal login.
Explain the entry as a lease with a learned time and an expiry, and name the three ways it goes wrong: a shared address, a reassigned address, and traffic with no user behind it at all.
Show that you treat a user name in a firewall log as second-hand and corroborate it from the host before anybody acts on it. Be able to say which hosts in your estate you cannot install an agent on and what that costs you.
Own the framing that this is an inference layer with an expiry bolted onto an address decision, and be clear about what you will and will not let it be used as evidence for.
## The wire carries no identity An IP packet has a source address. It does not have a user. Nothing in the headers, and nothing a firewall can read out of an ordinary TCP or UDP flow, says which human is behind it. So when a policy line reads `allow finance-group to payroll`, the enforcement point is not reading identity off the wire - it is doing a lookup: source address to user, user to group, group to rule. That lookup answers from a **mapping table** the device maintains. Every entry is essentially a lease: - an address - a user name - where the mapping was learned from - when it was learned - when it expires That is the whole assertion. Read literally: *at time T, source S told me this address belonged to this user, and I have not yet decided that claim is stale.* ## Where the mapping comes from - and what each one costs you There are three common ways to manufacture it, and none of them is free: **An agent on the host.** Software on the endpoint or on a multi-user host reports who is logged in, and on shared hosts can go further and claim a range of source ports per session. Highest fidelity, but you must install, version-match and monitor it on every machine that matters, and any host you cannot install on is a permanent hole. **An off-path feed from the authentication infrastructure.** The firewall subscribes to logon activity from the servers that authenticate users and derives address-to-user from it. Nothing to install on endpoints, but it is second-hand, it lags, it only sees users who authenticate against that infrastructure, and it learns nothing about a device that never joined the domain. **A portal.** Unmapped traffic is intercepted and the user is asked to log in before it proceeds. This is the fallback for contractors, guests and unmanaged devices - and the price is a login page in the middle of somebody's workflow, a re-authentication interval to argue about, and a mapping that dies with the browser session and never covers non-browser traffic. In every case the firewall did **not** authenticate anybody. It trusted a third party's assertion and cached it. That is a meaningful difference from a system that challenges the user itself. ## The three ways the assertion goes wrong **Sharing.** A terminal-server or virtual-desktop host puts hundreds of people behind one source address. Without per-session attribution, the mapping names one of them and all of them get that person's rules. An intruder who lands on that host inherits whatever identity the address is carrying at that moment - both the permissions and, more insidiously, the name that appears in your logs. **Reassignment.** Addresses change hands: a DHCP lease expires, a VPN pool re-issues, a desktop pool recycles. If the mapping outlives the handover, the new occupant is policed and logged as the old one. **Absent identity.** A scheduled task running as a machine or service account has no interactive session, so no logon event and no port range. Its traffic maps to nobody and falls to whatever your unknown-user rule says - which is why that rule ends up carrying production traffic nobody designed for it. ## Direction of the claim Get this right and most of the leaf follows. A mapping proves an **association was recorded**, not that a person was at a keyboard. A firewall log line naming a user is therefore second-hand evidence: it repeats what the identity source said, filtered through a timeout you chose. It is a good lead. It is not, by itself, proof of who did something - especially from a shared host, where the host's own session records are the primary source and the firewall's view is a derived one. ## What you get for the price All of that said, the mapping is worth paying for. Address-based rules cannot follow a user between a desk, a laptop and a virtual desktop, cannot express `contractors may not reach this` without maintaining address lists by hand, and produce logs that require a second investigation just to name a person. The mapping buys policy and evidence in terms of people instead of terms of numbers. You simply have to hold in your head that it is an inference layer with an expiry date bolted onto an address-based decision, and design the failure behaviour on that basis rather than on the comfortable assumption that the firewall knows who is there.
- A firewall log says user s.okafor reached a blocked site at 14:02, and HR wants to act on it. What do you tell them?That the line repeats what the identity source claimed earlier, not what the firewall observed. Give them the mapping's provenance - which source learned it, when, and whether the address is shared. If it is a terminal server or a virtual desktop, the host's own session records are the primary evidence and the firewall entry is a lead that must be corroborated before anybody's name goes in a report.
- When would you build the mapping from a portal instead of an agent?When you cannot install on the device - contractors, guests, unmanaged or personally owned machines. The price is real: a login interruption in the path, a re-authentication interval that annoys people if short and goes stale if long, a mapping tied to a browser session that does not cover a native client's traffic, and no coverage at all for a second device the same person picks up.
- A scheduled job on a server runs as a service account. What user does its traffic map to?Usually none. There is no interactive logon and no session, so no mapping is produced and the flow falls to the unknown-user rule. Machine and service traffic should get explicit rules of its own - by address, or by a deliberately mapped account - so that the catch-all rule is not quietly carrying production.
It is a visitor badge tied to a desk rather than to a person. The badge says who was sitting there when it was issued; whoever sits down next is treated as that person until somebody collects the badge.
saying these in an interview costs you the question
- Says the firewall itself authenticated the user
- Treats a username in a firewall log as proof of who was at the keyboard
- Assumes one address means exactly one user
- Thinks traffic from the address keeps the mapping fresh
- Forgets the mapping has to be manufactured by something you deploy and run