Why does a RADIUS Access-Accept carry the session's authorization attributes while accounting is a separate exchange?

middlemust knowfreq 55%

answer

count the round trips
one reply, two answers
the attributes are the grant
different code, different port
records can fail on their own

basics

~20 s

RADIUS answers authentication and authorization in one round trip: the attributes inside an Access-Accept are the grant, so there is no second request. Accounting is a different exchange, with its own packet codes and normally its own port, and it can fail on its own.

solid answer

~50 s

The login exchange is one request and one reply. A positive reply is Access-Accept (Code 2), and the attributes it carries - a session limit in Session-Timeout (27), a filter name in Filter-Id (11) and so on - are the authorization. The access device never sends a second request asking what the user may do, because the answer already arrived with the decision. Accounting is deliberately not part of that: it is its own exchange, Accounting-Request (Code 4) answered by Accounting-Response (Code 5), normally to UDP port 1813 rather than UDP port 1812, and possibly to a different destination altogether. Two practical consequences follow: an accept with no attributes still grants access, with the access device's own defaults deciding the shape of the session; and an accounting destination that is down loses records while logins keep succeeding.

The login exchange is one request and one reply. A positive reply is `Access-Accept (Code 2)`, and the attributes it carries - a session limit in `Session-Timeout (27)`, a filter name in `Filter-Id (11)` and so on - **are** the authorization. The access device never sends a second request asking what the user may do, because the answer already arrived with the decision. Accounting is deliberately not part of that: it is its own exchange, `Accounting-Request (Code 4)` answered by `Accounting-Response (Code 5)`, normally to `UDP port 1813` rather than `UDP port 1812`, and possibly to a different destination altogether. Two practical consequences follow: an accept with no attributes still grants access, with the access device's own defaults deciding the shape of the session; and an accounting destination that is down loses records while logins keep succeeding.

code

pseudocode · 14 lines

pseudocode

# login exchange - one request, one reply, to UDP port 1812
Access-Request (Code 1)
    User-Name          = [email protected]
    NAS-IP-Address     = 198.51.100.7
    NAS-Port-Type      = Ethernet (15)

Access-Accept (Code 2)
    Session-Timeout    = 3600
    Filter-Id          = exhibitor-hall
    # no follow-up request: these attributes ARE the authorization

# later, and independently - to UDP port 1813, possibly elsewhere
Accounting-Request (Code 4)   ->   Accounting-Response (Code 5)
    # if this path is down, the session above is unaffected

go deeper

for a junior

Hold on to the shape: one request, one reply, and the reply already says what the session gets. Accounting is a separate conversation that happens afterwards.

for a middle

Be able to say that the attributes in the accept are the authorization, and to name the accounting exchange's own packet codes and port. Explain why an attribute-free accept is still a grant.

for a senior

Show the operational split - logins healthy while records are silent, an attribute-free accept quietly granting a device's defaults - and say how you would monitor each path on its own.

for a principal

The design question is what you are willing to lose. Welding the grant to the decision makes the login path cheap and the records path expendable; decide deliberately which of the two your controls actually depend on.

One round trip answers two questions

RADIUS merges authentication and authorization into a single exchange. The access device asks once, and the reply is final:

Access-Accept (Code 2) - the identity checked out, and here is what the session gets.
Access-Reject (Code 3) - no.
Access-Challenge (Code 11) - not yet; ask the user for more and come back.

There is no separate 'now tell me what this user may do' request in the login exchange. The attributes inside the accept are the entire grant, and the access device applies them to its own port.

A showground's temporary event network makes the shape obvious. A visiting exhibitor's staff member connects; the on-site access device asks; the exhibitor's home server answers accept and, in the same packet, says how long the session may last and which traffic policy applies. The site never learns the credential and the home organisation never touches the port.

The attributes are the authorization

This is the sentence to be able to say out loud. Interviewers ask it because candidates describe the accept as 'the password was right', which is only half of what the packet did.

In the reply	What it actually is
the packet code	the authentication decision
`Session-Timeout (27)`	how long the grant lasts
`Filter-Id (11)`	which traffic policy the access device applies
an accept with no attributes	still a grant - the access device's local defaults fill it in

That last row is where estates get surprised. An accept carrying nothing is not an error and is not a rejection; it is a successful login with a session shaped entirely by whatever the access device would have done on its own.

Accounting is a different exchange

Accounting is specified separately and behaves separately:

The access device sends an Accounting-Request (Code 4) describing the session.
The server answers Accounting-Response (Code 5) to acknowledge that it took the record.
That is the whole exchange, and it repeats independently for the life of the session.

It normally goes to UDP port 1813 while the login exchange goes to UDP port 1812, and it may be pointed at a different machine entirely - a records store rather than the policy engine. The two paths share a design and almost nothing else.

What the separation buys, and what it costs

Access does not depend on records. An unreachable accounting destination does not reject anybody. Users keep getting on the network.
Records are not proof of access, and their absence is not proof of its absence. A quiet accounting store can mean an empty network or a broken path, and the two look identical from the store.
The two can be scaled and sited differently, which is the point: one is latency-critical and on the login path, the other is volume-heavy and is not.
Reconciliation is on you. Nothing in the login exchange guarantees that a record exists for a session it granted.
The failure modes do not overlap, so an estate needs to monitor both. Watching only login success rates hides a records outage completely.

The consequence people miss

Because the grant is welded to the decision, changing what a live session may do is not something the login exchange can express. Everything it has to say was said in one packet that has already been enforced. Re-deciding an in-flight session belongs to a different mechanism on a different exchange, and the accounting stream is not it - accounting observes the session, it does not steer it.

The practical read for an operator: if you want a session's shape to change, you are either waiting for the grant to expire and be re-asked, or you are outside this exchange entirely.

## One round trip answers two questions RADIUS merges authentication and authorization into a single exchange. The access device asks once, and the reply is final: - `Access-Accept (Code 2)` - the identity checked out, **and** here is what the session gets. - `Access-Reject (Code 3)` - no. - `Access-Challenge (Code 11)` - not yet; ask the user for more and come back. There is no separate 'now tell me what this user may do' request in the login exchange. The attributes inside the accept are the entire grant, and the access device applies them to its own port. A showground's temporary event network makes the shape obvious. A visiting exhibitor's staff member connects; the on-site access device asks; the exhibitor's home server answers accept and, in the same packet, says how long the session may last and which traffic policy applies. The site never learns the credential and the home organisation never touches the port. ## The attributes are the authorization This is the sentence to be able to say out loud. Interviewers ask it because candidates describe the accept as 'the password was right', which is only half of what the packet did. | In the reply | What it actually is | |---|---| | the packet code | the authentication decision | | `Session-Timeout (27)` | how long the grant lasts | | `Filter-Id (11)` | which traffic policy the access device applies | | an accept with no attributes | still a grant - the access device's local defaults fill it in | That last row is where estates get surprised. An accept carrying nothing is not an error and is not a rejection; it is a successful login with a session shaped entirely by whatever the access device would have done on its own. ## Accounting is a different exchange Accounting is specified separately and behaves separately: 1. The access device sends an `Accounting-Request (Code 4)` describing the session. 2. The server answers `Accounting-Response (Code 5)` to acknowledge that it took the record. 3. That is the whole exchange, and it repeats independently for the life of the session. It normally goes to `UDP port 1813` while the login exchange goes to `UDP port 1812`, and it may be pointed at a different machine entirely - a records store rather than the policy engine. The two paths share a design and almost nothing else. ## What the separation buys, and what it costs - **Access does not depend on records.** An unreachable accounting destination does not reject anybody. Users keep getting on the network. - **Records are not proof of access, and their absence is not proof of its absence.** A quiet accounting store can mean an empty network or a broken path, and the two look identical from the store. - **The two can be scaled and sited differently**, which is the point: one is latency-critical and on the login path, the other is volume-heavy and is not. - **Reconciliation is on you.** Nothing in the login exchange guarantees that a record exists for a session it granted. - **The failure modes do not overlap**, so an estate needs to monitor both. Watching only login success rates hides a records outage completely. ## The consequence people miss Because the grant is welded to the decision, changing what a live session may do is not something the login exchange can express. Everything it has to say was said in one packet that has already been enforced. Re-deciding an in-flight session belongs to a different mechanism on a different exchange, and the accounting stream is not it - accounting observes the session, it does not steer it. The practical read for an operator: if you want a session's shape to change, you are either waiting for the grant to expire and be re-asked, or you are outside this exchange entirely.

A server can authenticate a visiting user but holds no session policy for them. What does it send, and what happens?
It sends an `Access-Accept (Code 2)` with no policy attributes, which is a successful login. The access device then shapes the session from its own local defaults. That is often more generous than intended, which is why an estate that relies on the server for policy should treat an attribute-free accept as a configuration gap rather than a clean result.
The accounting destination has been unreachable for an hour. What can you still say about who was on the network?
Very little from the records themselves. Logins continued, because the login exchange does not depend on accounting, so the network may have been busy while the store stayed empty. Absence of records is not evidence of absence of sessions, and the only way to tell the two apart is to monitor the accounting path separately.
Why does an Access-Challenge (Code 11) not carry the session's authorization attributes?
Because it is not a decision. A challenge says the server needs more input before it can decide, so the exchange continues and nothing has been granted yet. Only a positive decision carries a grant, which is why the attributes ride on the accept and nowhere else.

saying these in an interview costs you the question

RADIUS sends a second request to fetch authorization
An Access-Accept only means the password was correct
If accounting fails, the user is dropped
Accounting travels on the same exchange as the login
An accept with no attributes is a protocol error

Why does a RADIUS Access-Accept carry the session's authorization attributes while accounting is a separate exchange?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

One round trip answers two questions

The attributes are the authorization

Accounting is a different exchange

What the separation buys, and what it costs

The consequence people miss

▾common follow-ups3 questions

▾red flags5 flags

One round trip answers two questions

The attributes are the authorization

Accounting is a different exchange

What the separation buys, and what it costs

The consequence people miss

answer

go deeper