In device-administration AAA, what does a named TACACS+ method list order, and why does each service get its own?
answer
- local configuration, never on the wire
- one named list per service
- ordered, and walked in order
- login, exec and commands asked separately
- order written as user-authentication-order
basics
~20 sA method list is a named, ordered sequence of the sources a network device may ask about one service - the login, the exec session, commands at a privilege level - and the device walks it until one source returns a decision.
solid answer
~50 sA method list is device-side configuration, not a wire structure: a name, the one service it is bound to, and an ordered sequence of methods the device walks until a method returns a decision. Services are listed separately because they are separately answerable - the login itself, the exec or shell session behind it, and command authorization at a given `priv-lvl` can each point at a different sequence, so a device can take logins from the device-administration server while answering command authorization from somewhere else, or the reverse. RFC 7317's `ietf-system` model expresses the order as `/sys:user-authentication-order`, for example `[ tacacs-plus, local-users ]`, and RFC 9105 adds the `tacacs-plus` identity and the ordered server list behind it. Order is trial order, which is why the device's own user database is normally the last entry rather than the first.
code
pseudocode · 19 linesuser-authentication-order := [ tacacs-plus, local-users ]
method list "login" := [ tacacs-plus, local-users ]
method list "exec" := [ tacacs-plus, local-users ]
method list "command, priv-lvl 15" := [ tacacs-plus, local-users ]
server list (ordered by the operator, keyed on name):
server "north":
address = <site-north>
port = 49
server-type = authentication, authorization
timeout = 5 seconds
single-connection = false
server "south":
address = <site-south>
port = 49
server-type = authentication, authorization
timeout = 5 seconds
single-connection = falsego deeper
Recall that a method list is a named, ordered list of sources a network device can ask about one service, and that the device works down it rather than asking all of them.
Explain why login, the exec session and command authorization each carry their own list, and how the order is expressed as an authentication order plus an ordered list of servers behind the TACACS+ entry.
Show that you know order is trial order, that a local entry placed first silently removes the central record from the path, and that the two orderings - methods and hosts - are not the same list.
Weigh how much of an estate's administrative access should depend on one central plane, and what a vendor-neutral statement of this wiring is worth when the fleet spans several vendors.
## What a method list actually is A **method list** is device-side configuration. Nothing in it travels on the wire. TACACS+ itself defines packets and exchanges; the method list is the network device's own answer to a different question - *which source do I ask, and in what order, when this particular service needs a decision?* It has three parts: a **name**, the **service** it is bound to, and an **ordered sequence of methods**. A method is a place a decision can come from: the configured device-administration servers reached over TCP port 49, the device's own local user database, or a password held on the terminal line. The word *method* is overloaded on this branch and is worth pinning down. `authen_method` is a field inside an authorization REQUEST recording how the user was authenticated. `authen_type` names the credential form the authentication exchange used. Neither is a method list. The method list is purely local, and it is what decides whether a TACACS+ packet is sent at all. It is also worth naming which plane this is. Device-administration AAA answers *who may administer this box, and what may they type on it*. The admission decision that lets a physical port or a wireless client onto the network in the first place is a different plane, with different protocols, different devices and different failure modes. ## Why each service gets its own list The services are listed separately because they are separately answerable, and an estate usually wants different answers for them. | Service the list is bound to | The decision being asked for | Why it is asked on its own | |---|---|---| | login | may this person open an administrative session on this device at all? | one decision per session, and the only one that must survive a bad day | | exec or shell session | may the authenticated person have a session, and with what starting privilege? | it can be answered locally even when the login was answered centrally | | commands at a privilege level | may this person run this command, now, on this device? | one exchange per command typed, so its cost and its failure profile differ sharply from the login's | Because the lists are independent, a device can be wired so that logins are central and command authorization is not, or so that one privilege level is authorized centrally and another is not. That flexibility is the reason the lists are named and bound per service rather than being one global setting. ## Where the order is actually expressed RFC 7317's `ietf-system` model holds `/sys:user-authentication-order`, a list of authentication method identities in the order the device will try them - `[ tacacs-plus, local-users ]` being the common shape. RFC 9105 augments that model with the TACACS+ vocabulary the order refers to: - `/system/tacacs-plus/server` is a server list **ordered by the operator** (`ordered-by user`) and keyed on `name`; - each entry carries `address`, `port` (49 by default) and `shared-secret`; - `server-type` says which of the three exchanges - authentication, authorization, accounting - that host will be asked about; - `timeout`, in seconds, bounds how long the device waits on that entry before moving on; - `single-connection` (false by default), `source-ip` or `source-interface`, and `vrf-instance` complete the entry. So there are two orderings in play and they do different jobs. The method list orders *classes of method*. The server list orders *hosts within the TACACS+ class*. A login that ends up at the second configured server has not left the first method; it has simply exhausted the first host inside it. ## Walking the list 1. The device asks the first method in the list for that service. 2. If the method returns a decision - on an authentication exchange, a REPLY status of PASS or FAIL - the device applies it and stops. 3. If the method returns no decision, because the host is unreachable, because the wait exceeded `timeout`, or because the REPLY status was ERROR, the device moves to the next entry. 4. If the sequence runs out with no decision, nothing in the list has answered, and what the device does then is a local configuration choice rather than something the exchange settled. The list is walked, not polled: entries are tried in sequence, and nothing is asked in parallel or scored against anything else. ## What a method list does not settle - It does not decide what the server says. The argument-value pairs an authorization REPLY carries, and what the device does with them, belong to the authorization exchange. - It does not set how strong the per-server key is or how often it changes; the entry simply names one. - It does not alter the wire format. Two devices with identical servers and different method lists produce different traffic only because they ask different questions, not because the packets differ. - It is a concept, not a dialect. Every vendor spells it differently on a command line; the concept - a named, ordered, per-service sequence - is what an interviewer is asking about.
- Does the method list travel to the TACACS+ server in any packet?No. It is purely local to the network device. The server sees an authentication START, an authorization REQUEST or an accounting REQUEST and answers it; it has no view of which list produced the question, what came before it, or what the device will try next. Two devices pointed at the same server with different method lists behave differently.
- What does `server-type` on a configured server do that the method list does not?The method list names the class of method to try. `server-type`, in RFC 9105's `/system/tacacs-plus/server` list, says which of the three exchanges - authentication, authorization, accounting - a given host is willing to be asked about, so one ordered list of hosts can route different services to different servers.
- Why is the device's own user database normally the last entry rather than the first?Because order is trial order. A local entry first means the device answers from its own database and the central server is never consulted, so the central record of who may administer the estate stops being authoritative. Last means it is reached only when no earlier method returned a decision.
saying these in an interview costs you the question
- Thinks the method list is negotiated with the server.
- Says the order of entries in the list does not matter.
- Believes one method list covers login, exec and commands.
- Assumes the device asks every method and compares answers.
- Treats the method list as one vendor's command-line syntax.