In TACACS+, how does a network device ask whether an operator may move to a higher privilege level?

seniorshould knowfreq 36%

answer

escalation is a second login
one field names the service
the requested level rides in the header
no earlier session is required
what it permits is decided elsewhere

basics

~20 s

By opening a second authentication session. The device sends a fresh START with authen_service set to TAC_PLUS_AUTHEN_SVC_ENABLE and the level it wants in the header's priv_lvl field. The protocol requires no earlier successful login for it.

solid answer

~40 s

Privilege escalation is not a separate exchange type in TACACS+ — it is another authentication. The device opens a new session with a START whose authen_service is TAC_PLUS_AUTHEN_SVC_ENABLE and whose priv_lvl field carries the level being requested, and the sequence then runs exactly like a login: GETPASS, a CONTINUE, then PASS or FAIL. The credential presented may be a different one from the login credential. The important property is what the protocol does not require: it places no prerequisite on this request, so it may be made independently of any earlier authentication in that terminal session. A server must therefore identify and decide afresh rather than infer that the requester already proved anything. What the level then permits is settled by the separate authorization exchange.

Privilege escalation is not a separate exchange type in TACACS+ — it is another **authentication**. The device opens a new session with a START whose `authen_service` is `TAC_PLUS_AUTHEN_SVC_ENABLE` and whose `priv_lvl` field carries the level being requested, and the sequence then runs exactly like a login: `GETPASS`, a CONTINUE, then `PASS` or `FAIL`. The credential presented may be a different one from the login credential. The important property is what the protocol does **not** require: it places no prerequisite on this request, so it may be made independently of any earlier authentication in that terminal session. A server must therefore identify and decide afresh rather than infer that the requester already proved anything. What the level then permits is settled by the separate authorization exchange.

code

pseudocode · 18 lines

pseudocode

device -> server: AUTHEN START
    action         = TAC_PLUS_AUTHEN_LOGIN
    priv_lvl       = TAC_PLUS_PRIV_LVL_ROOT
    authen_type    = TAC_PLUS_AUTHEN_TYPE_ASCII
    authen_service = TAC_PLUS_AUTHEN_SVC_ENABLE
    user           = "deck-engineer"
    port           = "tty10"

server -> device: AUTHEN REPLY
    status     = TAC_PLUS_AUTHEN_STATUS_GETPASS
    flags      = TAC_PLUS_REPLY_FLAG_NOECHO
    server_msg = "Enable password: "

device -> server: AUTHEN CONTINUE
    user_msg = <what the operator typed>

server -> device: AUTHEN REPLY
    status = TAC_PLUS_AUTHEN_STATUS_PASS

go deeper

for a junior

Remember that asking for more privilege on the device means authenticating again, to the same central server, rather than the device deciding on its own.

for a middle

Name the two fields: authen_service set to the enable value, and the requested level carried in the header's priv_lvl. Then say the sequence runs like any other authentication.

for a senior

Demonstrate the gap that bites in production: nothing links the escalation to the earlier login, so a shared administrative credential leaves an audit trail with a level change and nobody's name attached to it.

for a principal

Weigh per-operator administrative credentials against a shared one across a whole fleet. The trail is the benefit; the cost is a second secret per engineer, a second prompt loop on every slow link, and a rotation job that has to reach every device.

Escalation is another authentication, not a different exchange

When an operator on a network device asks to move from a routine level to an administrative one, the device does not send an authorization request asking "may this person go higher?". It opens a new authentication session. The START differs from a login START in two fields:

authen_service is set to TAC_PLUS_AUTHEN_SVC_ENABLE instead of TAC_PLUS_AUTHEN_SVC_LOGIN;
priv_lvl in the header carries the level being asked for — the named bounds run from TAC_PLUS_PRIV_LVL_MIN through TAC_PLUS_PRIV_LVL_USER up to TAC_PLUS_PRIV_LVL_ROOT, which is the same value as TAC_PLUS_PRIV_LVL_MAX.

Everything else is the machinery already in place. The server answers GETPASS, usually with TAC_PLUS_REPLY_FLAG_NOECHO set; the device returns the typed value in a CONTINUE; the server answers PASS or FAIL. The same status enumeration applies, including ERROR with its obligation to treat the host as unreachable.

The property candidates miss: there is no prerequisite

The protocol imposes no prerequisite on an enable request. It may be requested independently of any earlier authentication. Nothing in the packet proves that whoever is at the terminal line logged in successfully a minute ago, and nothing in the exchange links the two sessions.

That has direct consequences:

A server must not infer identity from context. If it answers an enable request by checking only that authen_service is ENABLE and that a shared enable credential matched, then anyone who reaches that terminal line gets the level, authenticated login or not.
The credential may be a different one. A deployment can require an administrative credential distinct from the login credential, and the protocol supports that naturally because this is a separate authentication.
The device is asking, not asserting. The number in priv_lvl is a request. A PASS says the requester authenticated for that request; it is not the device announcing what the operator already holds.

What the exchange settles and what it does not

Question	Settled by the enable authentication?
Did someone authenticate for this escalation request?	Yes — `PASS` or `FAIL`
Which operator was it?	Only to the extent the START's user field and the server's policy establish it
Was that operator already logged in?	No — the protocol links nothing
What may they now type at that level?	No — the authorization exchange decides that
What record is kept of it?	No — accounting is its own exchange

The fourth row is the boundary that matters most in an interview. A successful enable authentication does not by itself grant a command. The priv-lvl value that a server returns as an argument-value pair, and the per-command decisions that follow, belong to the authorization exchange with its own REQUEST and RESPONSE and its own status values.

Why this is a senior question

The mechanics are small. The judgment is in the gap between "the protocol allows an unsolicited escalation request" and "our server treats escalation as a continuation of the login". Real deployments sit in that gap:

A shared administrative credential turns an identified login into an anonymous escalation, and the accounting trail an auditor reads later shows a level change with no person attached to it that the authentication exchange can vouch for.
Requiring a per-operator administrative credential keeps the trail intact, at the cost of a second credential every engineer must hold — and, on a link where every round trip is slow, a second full prompt loop before anything can be typed.
A server that keys its escalation decision on the identity in the START's user field is only as good as the device's honesty about that field, which is a reason for the decision to rest on the credential presented rather than on the name supplied.

The sequence in one line each

The operator, already at a routine level, asks the device for administrative access.
The device opens a new authentication session: START, authen_service = TAC_PLUS_AUTHEN_SVC_ENABLE, priv_lvl = the level wanted.
The server prompts with GETPASS and TAC_PLUS_REPLY_FLAG_NOECHO.
The device returns the value as user_msg in a CONTINUE.
The server answers PASS or FAIL — or ERROR, which is not an answer at all.
What the operator may then run is decided command by command, elsewhere.

## Escalation is another authentication, not a different exchange When an operator on a network device asks to move from a routine level to an administrative one, the device does not send an authorization request asking "may this person go higher?". It opens a **new authentication session**. The START differs from a login START in two fields: - `authen_service` is set to `TAC_PLUS_AUTHEN_SVC_ENABLE` instead of `TAC_PLUS_AUTHEN_SVC_LOGIN`; - `priv_lvl` in the header carries the level being asked for — the named bounds run from `TAC_PLUS_PRIV_LVL_MIN` through `TAC_PLUS_PRIV_LVL_USER` up to `TAC_PLUS_PRIV_LVL_ROOT`, which is the same value as `TAC_PLUS_PRIV_LVL_MAX`. Everything else is the machinery already in place. The server answers `GETPASS`, usually with `TAC_PLUS_REPLY_FLAG_NOECHO` set; the device returns the typed value in a CONTINUE; the server answers `PASS` or `FAIL`. The same status enumeration applies, including `ERROR` with its obligation to treat the host as unreachable. ## The property candidates miss: there is no prerequisite The protocol **imposes no prerequisite on an enable request**. It may be requested independently of any earlier authentication. Nothing in the packet proves that whoever is at the terminal line logged in successfully a minute ago, and nothing in the exchange links the two sessions. That has direct consequences: 1. **A server must not infer identity from context.** If it answers an enable request by checking only that `authen_service` is ENABLE and that a shared enable credential matched, then anyone who reaches that terminal line gets the level, authenticated login or not. 2. **The credential may be a different one.** A deployment can require an administrative credential distinct from the login credential, and the protocol supports that naturally because this is a separate authentication. 3. **The device is asking, not asserting.** The number in `priv_lvl` is a request. A `PASS` says the requester authenticated for that request; it is not the device announcing what the operator already holds. ## What the exchange settles and what it does not | Question | Settled by the enable authentication? | |---|---| | Did someone authenticate for this escalation request? | Yes — `PASS` or `FAIL` | | Which operator was it? | Only to the extent the START's user field and the server's policy establish it | | Was that operator already logged in? | No — the protocol links nothing | | What may they now type at that level? | No — the authorization exchange decides that | | What record is kept of it? | No — accounting is its own exchange | The fourth row is the boundary that matters most in an interview. A successful enable authentication does not by itself grant a command. The `priv-lvl` value that a server returns as an argument-value pair, and the per-command decisions that follow, belong to the authorization exchange with its own REQUEST and RESPONSE and its own status values. ## Why this is a senior question The mechanics are small. The judgment is in the gap between "the protocol allows an unsolicited escalation request" and "our server treats escalation as a continuation of the login". Real deployments sit in that gap: - A shared administrative credential turns an identified login into an anonymous escalation, and the accounting trail an auditor reads later shows a level change with no person attached to it that the authentication exchange can vouch for. - Requiring a per-operator administrative credential keeps the trail intact, at the cost of a second credential every engineer must hold — and, on a link where every round trip is slow, a second full prompt loop before anything can be typed. - A server that keys its escalation decision on the identity in the START's user field is only as good as the device's honesty about that field, which is a reason for the decision to rest on the credential presented rather than on the name supplied. ## The sequence in one line each 1. The operator, already at a routine level, asks the device for administrative access. 2. The device opens a **new** authentication session: START, `authen_service = TAC_PLUS_AUTHEN_SVC_ENABLE`, `priv_lvl` = the level wanted. 3. The server prompts with `GETPASS` and `TAC_PLUS_REPLY_FLAG_NOECHO`. 4. The device returns the value as `user_msg` in a CONTINUE. 5. The server answers `PASS` or `FAIL` — or `ERROR`, which is not an answer at all. 6. What the operator may then run is decided command by command, elsewhere.

What must a device-administration server not infer from an enable request?
That the requester already authenticated. The protocol places no prerequisite on the request, so the START may arrive with no successful login behind it. The server has to identify and decide on this request's own merits, which is why a shared administrative credential with no per-operator identity is such a weak arrangement.
Is the number in the priv_lvl field of an enable START a grant?
No — it is what the device is asking for. A `PASS` says only that someone authenticated for that request. What the level actually permits is decided by the separate authorization exchange, where the server returns `priv-lvl` as an argument-value pair and rules on the commands themselves.
Why might a deployment require a different credential for escalation than for login?
Because the two decisions have different blast radii, and this is a separate authentication, so the protocol supports separate credentials without any special mechanism. The cost is a second credential per engineer and a second full prompt loop — noticeable on a slow link, where each turn is a round trip.

saying these in an interview costs you the question

Calls escalation an authorization exchange rather than an authentication
Assumes an enable request proves the operator already authenticated
Thinks the requested level is granted by the device, not requested
Says a successful enable authorises the commands that follow
Believes the enable credential must be the login credential

In TACACS+, how does a network device ask whether an operator may move to a higher privilege level?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Escalation is another authentication, not a different exchange

The property candidates miss: there is no prerequisite

What the exchange settles and what it does not

Why this is a senior question

The sequence in one line each

▾common follow-ups3 questions

▾red flags5 flags

Escalation is another authentication, not a different exchange

The property candidates miss: there is no prerequisite

What the exchange settles and what it does not

Why this is a senior question

The sequence in one line each

answer

go deeper