skip to content

Using SNMPv3's VACM, how would you give a NOC group read-write access and an automation account read-only access to interface objects only?

level: seniorimportance: nice to knowfreq 10%

answer

  1. users join groups
  2. access row: context, model, level
  3. three view names per row
  4. longest matching subtree decides
  5. out of view looks absent

basics

~20 s

Map each USM user to a VACM group, give the group an authPriv access row naming read, write and notify views, and build views from included and excluded OID subtrees. The automation group gets an interfaces-only read view and no write view.

solid answer

~40 s

VACM (RFC 3415) works through four tables. `vacmSecurityToGroupTable` maps `<securityModel, securityName>` to a group - USM is model 3. `vacmAccessTable` holds one row per group, context, security model and **minimum** security level, naming a read, a write and a notify view. `vacmViewTreeFamilyTable` builds each view from **included** and **excluded** subtrees; when several match an object, the one with the most sub-identifiers decides. `vacmContextTable` lists the contexts. For the NOC: group `noc`, a row at `authPriv` whose read and write views include `internet` (1.3.6.1) but exclude the USM and VACM MIBs, so operators cannot create users or widen views. For automation: group `automation`, a row at `authPriv` whose read view includes only `interfaces` (1.3.6.1.2.1.2) and `ifMIB` (1.3.6.1.2.1.31), with empty write and notify views. Out-of-view Gets return `noSuchObject`; the automation account's Sets get `authorizationError`.

go deeper

for a junior

Recall that SNMPv3 restricts what a user can see by putting it in a group whose views list the allowed parts of the OID tree.

for a middle

Explain the four VACM tables, the read, write and notify views on an access row, and why the row's level is a minimum.

for a senior

Design the two accounts end to end, predict noSuchObject, noAccess and authorizationError for each case, and keep the security MIBs out of operators' write views.

for a principal

Decide how far to split groups and contexts across a large estate, balancing least privilege against view sprawl that nobody can audit.

## The model in one sentence The **View-based Access Control Model** (`VACM`, RFC 3415) never grants rights to a user: it maps users to **groups**, grants groups **views** per **context** and **security level**, and checks every object identifier against the chosen view. It assumes the user was already authenticated by the security model - USM, in this setting. Everything below comes from RFC 3415's tables and RFC 3416's operation rules; how an implementation exposes those tables in its own configuration syntax varies, but the decisions it makes are these. ## The four tables | Table | Indexed by | Holds | |---|---|---| | `vacmContextTable` | `contextName` | the contexts this agent serves; `""` is the default | | `vacmSecurityToGroupTable` | security model, security name | one `groupName` | | `vacmAccessTable` | group, context prefix, security model, security level | read, write and notify view names | | `vacmViewTreeFamilyTable` | view name, subtree | `included` or `excluded`, plus an optional mask | Three details decide most designs: - **The level in an access row is a minimum.** RFC 3415 selects rows whose `vacmAccessSecurityLevel` is "less than or equal to the requested securityLevel". A row at `authNoPriv` therefore also serves `authPriv` requests; a row at `authPriv` serves nothing weaker. - **Contexts can match exactly or by prefix.** `vacmAccessContextMatch` is `exact` by default; `prefix` lets one row cover every context starting with a string. - **The most specific subtree wins.** When several view entries match an object, the one whose subtree has the most sub-identifiers decides inclusion or exclusion; a tie between wildcarded entries goes to the lexicographically greatest. ## Building the two accounts Assume two USM users: `noc-ops` and `poller`. 1. **Groups.** Map (USM, `noc-ops`) to group `noc` and (USM, `poller`) to group `automation`. 2. **Views.** - `noc-all`: include `internet` (1.3.6.1); exclude `snmpUsmMIB` (1.3.6.1.6.3.15) and `snmpVacmMIB` (1.3.6.1.6.3.16). - `if-only`: include `interfaces` (1.3.6.1.2.1.2) and `ifMIB` (1.3.6.1.2.1.31), which hold `ifTable` and `ifXTable`. 3. **Access rows**, both in the default context with `exact` matching: | Group | Model | Minimum level | Read view | Write view | Notify view | |---|---|---|---|---|---| | `noc` | USM (3) | `authPriv` | `noc-all` | `noc-all` | `noc-all` | | `automation` | USM (3) | `authPriv` | `if-only` | (empty) | (empty) | Excluding the USM and VACM MIBs matters because those tables are themselves writable over SNMP: `usmUserTable` rows are read-create, and a group that can write the VACM tables can widen its own views. Keep that capability for a separate administrative group. ## What each user sees The answers differ by operation, and each one is specified: - **Get outside the read view.** RFC 3416 treats the object as not accessible by this request; the varbind comes back as `noSuchObject`, so the agent does not even confirm the object exists. - **GetNext or GetBulk.** They return the next object *accessible by this request*, so a walk of the whole tree by `poller` simply sees nothing but interface objects. - **Set by the NOC user on an excluded object.** The object is not in the write view (`notInView`), so RFC 3416 returns error-status `noAccess` with the error-index of that varbind. - **Set by the automation user.** Its write view name is empty, which RFC 3415 reports as `noSuchView`; RFC 3413 turns that into error-status `authorizationError` with error-index 0. - **Any request at `authNoPriv`.** No row's minimum is met, so the check fails with `noAccessEntry` and the reply is `authorizationError`. - **A user with no group.** `noGroupName`, also `authorizationError`. ## Mistakes to avoid - **Writing rights per user.** VACM has no per-user rows; adding a second poller means one more line in the group table, not another view. - **Setting the access row's level too low.** A `noAuthNoPriv` row hands its views to any request that merely names a user in that group. - **Assuming excluded beats included.** Precedence is by specificity; an included subtree deeper than an exclusion re-admits its objects. - **Forgetting the notify view.** RFC 3413 checks a notification against the notify view of the target's security name; with an empty one, targets using that group receive nothing. - **Using masks where a subtree will do.** The family mask wildcards sub-identifiers - for example to admit one row's columns across a table - but every wildcard widens the view in ways that are harder to audit.

  • Why does an SNMPv3 Get for an object outside the user's read view return noSuchObject rather than an error?
    RFC 3416 defines Get, GetNext and GetBulk in terms of variables *accessible by this request*, which is the MIB view VACM selected. An object outside it is treated as if it did not exist, so its varbind gets the `noSuchObject` exception. That is deliberate: a refusal would confirm the object is there.
  • A NOC user's SNMPv3 request at authNoPriv is refused although its group has an access row; why?
    The row's `vacmAccessSecurityLevel` is `authPriv`, and VACM only selects rows whose level is less than or equal to the request's. `authNoPriv` is below `authPriv`, so no row matches, the check returns `noAccessEntry`, and the command responder answers with error-status `authorizationError` and error-index 0.
  • Why exclude the USM and VACM MIB subtrees from the NOC group's write view?
    Security configuration is managed through SNMP itself: `usmUserTable` rows can be created and keys changed through `usmUserAuthKeyChange`, and the VACM tables define who sees what. A group that can write there can add users or widen its own views, so give that power to a separate, tightly held administrative group.

saying these in an interview costs you the question

  • VACM views are assigned directly to each SNMPv3 user.
  • An access row's security level must match the request exactly.
  • Reading an object outside the view returns authorizationError.
  • When included and excluded subtrees overlap, the exclusion always wins.
  • A VACM view must list every table instance one by one.