test

Solaris System Management Agent Administration Guide

Understanding VACM Tables

In determining whether access should be granted to a message, VACM uses four tables:

Each of these VACM tables handles a particular part of the access mechanism. Each table can be remotely configured using the VACM MIB. The VACM MIB is defined in RFC 3415 at http://www.ietf.org/rfc/rfc3415.txt.

The VACM determines whether a request that has been authenticated by the SMA's USM is authorized to access the MIB object that is contained in the request. The snmpvacm utility is an SNMP application for basic maintenance of an SNMP agent's VACM tables. You need to have write access to the snmpvacm MIB table to use the snmpvacm utility. For more information, see the snmpvacm(1M) man page.

This section describes each of the VACM tables, including how the tables are indexed and what each row contains.

Context Table

The vacmContextTable table stores the contexts that are available locally. A context is the selector of management information. A single managed object can be in several different contexts. For example, consider a single module designed to monitor the status of a printer. For a network with several printers, multiple instances of this module can be implemented, with each instance containing a unique printer name. The printer name in this case is the context.

A single SNMP entity can have access to several contexts.

The vacmContextTable table is indexed by a contextName. Each of its rows gives the context name in the form of a unique, readable string, vacmcontextName.

The System Management Agent looks in the vacmContextTable for the contextName found in the scopedPDU. For information on the scopedPDU, see SNMP Versions. If the System Management Agent does not find the contextName of a particular message in the vacmContextTable, access is denied. In this case, a return value of noSuchContext is returned.

If the contextName exists, access checking continues, as shown in Figure 4–2. An example of typical entries in a vacmContextTable is shown in Example 4–1.

Example 4–1 Creating Typical Context Table Entries

Some typical vacmContextTable entries, created by a module, are:


SNMP-VIEW-BASED-ACM-MIB::vacmContextName."fileX" = STRING: fileX
SNMP-VIEW-BASED-ACM-MIB::vacmContextName."fileY" = STRING: fileY

The contextNames in this example are fileX and fileY.

Contexts are further explained in the Solaris System Management Agent Developer’s Guide. To illustrate the concept of contexts, a demo module is supplied with the System Management Agent. This demo module shows the importance of contexts for implementing multiple instances of a module. For more information, see Implementing Multiple Instances of a Module in Solaris System Management Agent Developer’s Guide.

Security to Group Table

The vacmsecurityToGroupTable table stores group information. A group name is given to a group of users and is used when managing their access rights. A group contains SecurityModel and a SecurityName value pairs. The resulting pair can only map to at most one group. The vacmSecurityToGroupTable table is indexed by the following:

Each of the rows in the vacmSecurityToGroupTable table contains the following:

vacmSecurityModel

An SNMPv3 security model, in this case USM. For further information on USM, see Using USM for Authentication and Message Privacy. By using the com2sec token, SNMPv1 and SNMPv2c security models can be used. For more information about the com2sec token, see the snmpd.conf(4) man page.

vacmSecurityName

With USM, the vacmSecurityName is identical to userName. Represents a user in a format that is independent of the security model. By using the com2sec token, SNMPv1 and SNMPv2c security names can be used. For more information on the com2sec token, see the snmpd.conf(4) man page.

vacmGroupName

A readable string. Indicates the group that is associated with this entry.

The SecurityName is obtained by the msgSecurityModel specifier when a message is successfully authenticated and decrypted. The System Management Agent searches for this msgSecurityModel specifier and associated SecurityName in the vacmSecurityToGroupTable table. If the msgSecurityModel specifier and associated SecurityName are not found in the vacmSecurityToGroupTable, then access is denied. In this case, a return value of noSuchGroupName is returned.

If an entry is found, then the corresponding groupName is returned. Access checking continues, as shown in Figure 4–2.

Typical entries in a vacmsecurityToGroupTable are shown in Example 4–2.

Example 4–2 Creating Typical Security to Group Table Entries

Create a group for two previously created users that are named user2 and user5. In this example, the users are placed in a newly created group that is named grpnam1. Choose from one of two methods:

View Tree Family Table

The vacmViewTreeFamilyTable table stores all collections of view subtree families. These collections are called MIB views. A MIB view is an OID subtree value, which is the family name, together with a bitstring value, which is the family mask. The family mask identifies which sub-identifiers of the family name are in the MIB view. A mask is a list of hex octets, which separated by either “.” or “:” The default is “ff”.

In a MIB view, each view subtree family has a type. The type determines if the view subtree family is included in the MIB view. A managed object instance is contained within a MIB view only if both of these statements are true:

If the configured value of the mask is too short to check these statements, the value is implicitly extended by a series of ones. A view family subtree with a mask of zero bits therefore corresponds to a mask of all ones, which in turn corresponds to one MIB subtree.

The vacmViewTreeFamilyTable table is indexed by:

viewName

Specified by the access right selected in the vacmAccessTable table. Used for access checking.

An OID of a MIB subtree

The OID of the PDU is compared to the MIB view.

Each of the rows in the vacmViewTreeFamilyTable table contains:

vacmViewTreeFamilyViewName

The name of the MIB view.

vacmViewTreeFamilySubtree

OID subtree. The OID subtree couples with a mask to make MIB view subtrees.

vacmViewTreeFamilyMask

Bitstring mask. The bitstring mask couples with an OID subtree to make MIB view subtrees.

vacmViewTreeFamilyType

The type determines whether the view subtree family is included in the MIB view.

If the MIB view does not contain the OID searched for, access is denied. In this case, a return value of notInView is returned. Otherwise, where the MIB view does contain the correct OID, access is granted. In this case a value of accessAllowed is returned.

The overall flow chart for this VACM algorithm is illustrated by Figure 4–2. In this diagram, the guideline terms suggested by the RFC are given for clarity:

securityName and securityModel

Indicate who requires access.

contextName

Determines where access is granted.

securityLevel and securityModel

Determines how access is granted.

viewType

Can be read, write or notify. Determines why a particular level of access is required by a group or user.

Object type, or OID of the managed object

Indicates what type of management data is checked.

Instance of the managed object

Combines with the object type to deliver which particular instance is checked to be in the MIB view. This decision is yes/no.

Figure 4–2 Overall Flow Chart for VACM

Flow diagram shows access checking process for VACM tables.

Example 4–3 shows typical entries in a vacmViewTreeFamilyTable.

Example 4–3 Creating Typical View Tree Family Table Entries

You can create a view in two ways:

Access Table

The vacmAccessTable table stores each group's access rights. Each group can have multiple access rights. The most secure access right is chosen. The vacmAccessTable table is indexed by:

groupName

Returned from the lookup into the vacmSecurityToGroupTable table.

contextPrefix

The valid contextName matched within the vacmContextTable table.

securityModel

Specified in the message's msgSecurityModel parameter.

securityLevel

Specified in the message's msgFlags parameter.

Each of the rows in the vacmAccessTable table contains:

vacmGroupName

The group's name. This group has one or multiple access rights.

vacmAccessContextPrefix

The contextName must match the value of vacmAccessContextPrefix. See vacmAccessContextMatch.

vacmAccessSecurityModel

Indicates the security model that must be used to get access rights.

vacmAccessContextMatch

If vacmAccessContextMatch is set to exact, then the contextName must exactly match the value of the vacmAccessContextPrefix object.

If vacmAccessContextMatch is set to prefix, the contextName can match the first several characters of the vacmAccessContextPrefix object. This contextName is the name already matched within the vacmContextTable table.

vacmAccessSecurityLevel

Indicates the lowest security level necessary for having access to this access right. For information about security levels, see Where VACM Security Information Is Contained.

vacmAccessReadViewName

Authorized MIB viewName for read access. If vacmAccessReadViewName is empty, no active view exists for read access.

vacmAccessWriteViewName

Authorized MIB viewName for write access. If vacmAccessWriteViewName is empty, no active view exists for write access.

vacmAccessNotifyViewName

Authorized MIB viewName for notify access. If vacmAccessWriteViewName is empty, no active view exists for notify access.

If an access right is not found, access is denied. In this case, a return value of noAccessEntry is returned.

When an access right is selected, then the viewName indicated by that access right is selected. This viewName is determined by the PDU. If the SNMP operation in the PDU is a GETNEXT or GET operation, the vacmAccessReadViewName string is used. If the SNMP operation in the PDU is a TRAP operation, the vacmAccessNotifyViewName string is used. If the viewName is not configured, access is denied. In this case, a return value of noSuchView is returned.

If the access right is selected with a correctly configured viewName, access checking continues, as shown in Figure 4–2. Example 4–4 shows typical access table entries.

An additional example, Example 4–5, shows how to check that the users set up in this example and previous examples exist and are registered in VACM tables.

Example 4–4 Creating Typical Access Table Entries

You can create access table entries in two ways:

Example 4–5 Checking That Users Exist in the VACM Tables

Using the information in Example 4–3 and Example 4–4, check that the SNMPv3 user, user2, created in Example 4–2, exists. Validate the access entries already created for user2, by checking and setting values for the user. Use the snmpget and snmpset commands, once with encryption and once with no encryption. This method illustrates that the access entry for user2 is the minimum security level required, defined as auth= 2. The method also illustrates that priv can be used as well, since that level is more secure.

Use the snmpget command to check that the new user exists, with the DES option set for encryption. A context, -n fileX, is specified:


# snmpget -v3 -u user2 -a MD5 
-A my_password -l authPriv -x DES -X my_password
-n fileX localhost 1.3.6.1.4.1.42.2.2.4.4.6.1.1.0

This command validates one of the access entries that you set up for user2. The options that are associated with use of the snmpget command are described in the snmpcmd(1M) man page.

The snmpget command retrieves the following information:


SNMPv2-SMI::enterprises.42.2.2.4.4.6.1.1.0 = INTEGER: 111

In this returned output, 111 is an integer that is stored in the specified OID.

Similarly, snmpget command can be used to check that the new user exists, without the DES option set. If you do not set the DES option, no encryption is requested. This example shows that the user, user2, can execute an operation not in a context:


# snmpget -v3 -u user2 -a MD5 
-A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.3.0

The snmpget command retrieves the following information about system uptime:


DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (5375) 0:00:53.75

Try to set a new value for sysLocation:


# snmpset -v3 -u user2 -a MD5 
-A my_password -l authPriv -x DES -X my_password 
localhost 1.3.6.1.2.1.1.6.0 s "new val"

In this command, the s indicates “string”. The OID is sysLocation. The value being added to the sysLocation is new val.

Note that user2 has full access rights to the context (authPriv) for DES. The password is my_password. The following is returned:


SNMPv2-MIB::sysLocation.0 = STRING: new val

Confirm these settings with the snmpget command:


# snmpget -v3 -u user2 -a MD5 
-A my_password -l authPriv -x DES -X my_password localhost 1.3.6.1.2.1.1.6.0


SNMPv2-MIB::sysLocation.0 = STRING: new val

Try the same command without the DES encryption set:


# snmpset -v3 -u user2 -a MD5 
-A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.6.0 s "new val2"

The same result is successfully returned:


SNMPv2-MIB::sysLocation.0 = STRING: new val2
 

# snmpget -v3 -u user2 -a MD5 
-A my_password -l authNoPriv localhost 1.3.6.1.2.1.1.6.0


SNMPv2-MIB::sysLocation.0 = STRING: new val2

This output shows that the user has write access to MIB-II.

If user2 has been defined in the snmptrapd.conf file, then start the SNMP trap daemon using the snmptrapd command:


# /usr/sfw/sbin/snmptrapd

Also, use the snmpinform command to send an INFORM-PDU trap. The snmpinform command validates that the user, user2 or user2, can generate notifications. Notifications can be generated if you perform a cold start. A cold start generates a notification, or a “trap.” The user can see this trap in the /var/log/snmpd.log file.


# /usr/sfw/sbin/snmpinform  -v3 -u user2 -a MD5
 -A my_password -l authNoPriv localhost 42 coldStart.0

For more information, see the snmptrapd.conf(4) and snmpinform(1M) man pages.

Troubleshooting Problems With VACM Tables

When creating VACM table entries, ensure that you configure access rights correctly for your users and user groups. Incorrectly configured access rights can lead to access being denied to key users.

Avoid creating large numbers of groups of users. Large numbers of groups can be difficult to administrate. Troubleshooting problems when you have created very large numbers of different user groups can become unmanageable.

When working with VACM tables, return values can include the following messages:

noSuchContext

This value is returned if the System Management Agent does not find the contextName of a particular message in the vacmContextTable. Access is denied. Check the context table entries. Ensure that these entries are correctly configured. Has each user got a context? For more information, see Context Table.

noSuchGroupName

Thisvalue is returned if the msgSecurityModel specifier and associated SecurityName are not found in the vacmSecurityToGroupTable. Access is denied. Check the security to group table entries. Ensure that these entries are correctly configured. Has each user got a group name? Have users been entered into the table correctly? For more information, see Security to Group Table.

notInView

This value is returned if the MIB view does not contain the OID searched for. Access is denied. For more information, see View Tree Family Table.

noAccessEntry

This value is returned if an access right is not found. Access is denied. Have you correctly set up the mask? Although each group can have multiple access rights, only the most secure access right is selected.

Is the vacmAccessContextMatch parameter set to exact? If the vacmAccessContextMatch parameter is set to exact, the contextName must be an exact match. Try setting the vacmAccessContextMatch value to prefix if appropriate. For more information, see Access Table.

Note –

Badly configured VACM tables can subject the network to unauthorized, possibly malicious access. Ensure that you check your VACM table configurations in a test environment before implementing these configurations on your network devices.

For more information on VACM, see RFC 3415 at http://www.ietf.org/rfc/rfc3415.txt.

The MIB definitions for VACM can be found at /etc/sma/snmp/mibs/SNMP-VIEW-BASED-ACM-MIB.txt.