Your firewall, sensor and access-control consoles authenticate admins against the same corporate directory as email — what does an intruder holding one group membership reach?

## How a console decides who is an admin Network devices and security appliances are usually not identity systems. They are configured to forward an administrative logon to a device-administration AAA service — RADIUS or TACACS+ are the two protocols normally used for this — which evaluates the credential against a directory and returns a result plus an attribute that the device maps to a privilege level. The device's local account list is kept as a fallback, not as the normal path. The consequence is easy to state and easy to miss: **the console's trust boundary is wherever that directory's authority ends.** Which network may reach the management interface is a separate fence, and it is the one people usually build; whose directory the console believes is the fence that decides who is an administrator once a packet gets there. ## What one group membership actually reaches If the firewall, the intrusion sensor and the access-control policy engine are all bound to the same directory, one group membership is administrative authority over three different planes at once: | Console bound to the directory | What the group membership can rewrite | | --- | --- | | Firewall | Which flows are permitted between zones | | Intrusion sensor / prevention | What is inspected, and whether matches block or only log | | Access-control policy engine | Which devices are admitted to which segment | No filter has been evaded to get any of this. The intruder authenticated. If the estate also uses that directory for ordinary staff logons, then the distance between a phished mailbox account and the policy plane is one group membership — and group membership is a write operation somewhere in the directory, which is why an intruder with directory write authority is a management-plane problem, not just an identity problem. ## The claim direction that matters A successful console logon proves a credential was accepted, not that the engineer was present and not that the action was authorised. This is the same discipline as anywhere else in defence, and it decides what your evidence is worth: if the only record of who administered a firewall is the firewall's own account log, you are relying on the device to testify about a session held by an account with authority over the device. ## What separation costs, honestly The usual designs and their prices: - **A distinct device-administration identity per engineer, in its own directory.** Strongest, most expensive: a second lifecycle process, a second strong-authentication enrolment, and a real risk that the second directory is administered less carefully than the first because nobody looks at it daily. - **Same directory, separate accounts and separate groups for device administration.** Cheaper, and it stops a compromised everyday account from being an admin — but it does not stop an intruder who can write group memberships in that directory. - **Local accounts only, no directory binding.** Removes the shared-fate problem and replaces it with shared secrets on every device, no central revocation, and a joiner/leaver process that people will not follow. Every one of these needs break-glass: a local account on each device for the case where the AAA path is unreachable. That account is standing administrative power sitting on the device forever, so it has to be vaulted, rotated, alerted on when used, and reviewed — and the frequency of its use is a useful signal about whether your primary path is healthy. ## Fallback posture is a decision, not a default When the AAA path is down, a device either falls back to local accounts or refuses administrative logons. Both are defensible and the choice belongs to whoever will be woken up. What is not defensible is not knowing which one your estate does, because you will discover it during the incident where you most need to log in. ## The wrong answer to aim at The answer a competent engineer gives and should not is *"the consoles are on a management VLAN, so this is handled."* Network reach and identity reach are two different fences. The management VLAN decides which packets may arrive at the interface; it says nothing about whose directory the device believes. And the intruder does not need to arrive from the office LAN — a foothold on any workstation that already reaches the management VLAN, plus a directory account carrying the right group, satisfies both fences at once. A candidate who names both questions, and prices the separation rather than asserting it, is answering at the level this is asked.