VACM configuration

The full flexibility of the VACM, for example allowing access to two or more distinct OID subtrees, or different access requirements for reading and writing, is available using four configuration directives - com2sec, group, view and access. The directives essentially define who has access and what they have access to using four directives. The first two directives (comsec2sec and group) define the who, while the last two (view and access) define the what.

Maps an SNMPv1 or SNMPv2c community string to a security name. As it defines the community and maps it to a security name, rocommunity/rwcommunity directives are not required when using the directive.

SECNAME is the security name to be defined.

SOURCE is as defined for the rocommunity/rwcommunity directives above.

COMMUNITY defines the community name to be mapped to the security name. The same community string can be specified in several separate directives with different source tokens, and the first source/community combination that matches the incoming request will be selected. Various source/community combinations can also map to the same security name.

CONTEXT if defined (using -Cn), means that the community string will be mapped to a security name in the named SNMPv3 context. Otherwise the default context ("") will be used.

Example:

Creating three SNMPv1/v2c community names (private, public and ltd), where private and ltd only allow requests from the machine on which the SNMP Agent is running (note lines beginning with a # in snmpd.conf are treated as comments):

Maps a security name (in the specified security model) into a named group. Several group directives can specify the same group name, allowing a single access setting to apply to several users and /or community strings. Note that groups must be set up for the two community-based models separately - a single com2sec directive will typically be accompanied by two group directives.

Example:

Creating three groups (grp_private, grp_public, grp_limited) for three USM users (user1, user2 and user3) and the three communities shown in the com2sec example above:

Defines a named view - a subset of the overall OID tree. This is most commonly a single subtree, but several view directives can be given with the same view name (VNAME), to build up a more complex collection of OIDs. An optional mask can also be specified, providing a means of indicating which parts of the OID must be matched.

VNAME is the view being modified.

included | excluded allows you to define whether the view includes or excludes the subtree, allowing the definition of a more complex view (for example, by excluding certain sensitive objects from an otherwise accessible subtree).

MASK is an optional list of hex octets (separated by '.' or ':') whose bits indicate which OID sub-identifiers to match against. So for example if we assume we have on OID with 11 sub-identifiers (.1.3.6.1.x.y.z.table.entry.column.1) where the last four relate to a table, an entry, a column and index 1, specifying a MASK value of " FF.A0 " (1111111110100000) maps to this OID as follows:

This mask means all parts of the OID except the column must match, therefore defining a view to any column of the first row of the table.

By including and excluding various aspects of the full OID tree, it is possible to define fine grained visibility within a view’s definition.

Example:

Creating five views where vw_sysContact only has access to the system.sysContact.0 OID, vw_nCipher only has access to the MIB, vw_global has access to the full OID tree, vw_nCipher_stats only has access to nCipher.nC-series.statistics and vw_nCipher_admin only has access to nCipher.nC-series.administration:

Maps from a group of users/communities (with a particular security model and minimum security level, and specific context) to one of three views, depending on the request being processed.

GROUP is a group name defined by the group directive and specifies the group that access is being defined for.

CONTEXT specifies the context for the access (the default context is the empty string ""). The context of incoming requests must match against the context either exactly or by prefix, as specified by the choice of exact | prefix made in this directive.

any, v1, v2c, or usm define the security model to which this definition relates.

noauth | auth | priv define the security level to which this definition relates. For v1 or v2c access, this will need to be noauth as these protocols do not support authentication.

exact | prefix specify how CONTEXT should be matched against the context of the incoming request, either an exact match to CONTEXT, or prefixed by CONTEXT.

READ, WRITE and NOTIFY specifies the view to be used for GET*, SET and TRAP/INFORM requests (although the NOTIFY view is not currently used). The keyword none is used if there is to be no access for that type of request.

Example:

Specifying that: