Creating users in SNMPv3

Edit online

This scenario shows how to create a user in SNMPv3 by manually editing the /etc/snmpdv3.conf and /etc/clsnmp.conf files.

User u1 will be created in this scenario. User u1 will be given authorization keys, but will not be given privacy keys (which are available only if you have the snmp.crypto fileset installed). The HMAC-MD5 protocol will be used to create u1's authorization keys. After u1 is configured, it will be put into a group, after which that group will have its view and access permissions defined. Finally, trap entries for u1 will be created.

Each individual value used in the /etc/snmpdv3.conf and /etc/clsnmp.conf files must not exceed 32 bytes.

Things to Consider
  • The information in this how-to scenario was tested using specific versions of AIX®. The results you obtain might vary significantly depending on your version and level of AIX.

Step 1. Create the user

  1. Decide which security protocols you want to use, either HMAC-MD5 or HMAC-SHA. In this scenario, HMAC-MD5 will be used.
  2. Generate the authentication keys by using the pwtokey command. Your output may look different based on the authentication protocol you are using and if you are using privacy keys. These keys will be used in the /etc/snmpdv3.conf and /etc/clsnmp.conf files. The command used for user u1 follows:
    pwtokey -p HMAC-MD5 -u auth anypassword 9.3.230.119
    The IP address specified is the IP address where the agent is running. The password can by any password, but be sure to save it in a secure place for future use. The output should look similar to the following:
    Display of 16 byte HMAC-MD5 authKey:          
  63960c12520dc8829d27f7fbaf5a0470            
                                              
Display of 16 byte HMAC-MD5 localized authKey:
  b3b6c6306d67e9c6f8e7e664a47ef9a0
  3. With root authority, open the /etc/snmpdv3.conf file with your favorite text editor.
  4. Create a user by adding a USM_USER entry following the format given in the file. The authKey value will be the localized authentication key that was generated using the pwtokey command. The entry for user u1 follows:
    #---------------------------------------------------------------------------
# USM_USER entries
#    Defines a user for the User-based Security Model (USM).
# Format is:
#  userName engineID authProto authKey privProto privKey keyType storageType
#
USM_USER u1 - HMAC-MD5 b3b6c6306d67e9c6f8e7e664a47ef9a0 - - L -
#----------------------------------------------------------------------------
    • userName is the name of the user. In this case, it is u1.
    • authProto must be the protocol that you used when you created the keys. In this case, it is HMAC-MD5.
    • authKey is the localized authentication key that was created using the pwtokey command.
    • privProto and privkey are not specified because we are not using the privacy keys in this scenario.
    • keyType is L because we are using the localized authentication key.
  5. Save and close the /etc/snmpdv3.conf file.
  6. Open the /etc/clsnmp.conf file on the SNMP manager with your favorite text editor.
  7. Add the new user according to the format given in the file. The entry for u1 follows:
    #----------------------------------------------------------------------------------------------------
#
# Format of entries:
# winSnmpName targetAgent admin secName password context secLevel authProto authKey privProto privKey 
#
user1  9.3.230.119  SNMPv3  u1  -  -  AuthNoPriv  HMAC-MD5  63960c12520dc8829d27f7fbaf5a0470  -  -
#----------------------------------------------------------------------------------------------------
    • winSnmpName can be any value. This value will be used when making SNMP requests using the clsnmp command.
    • targetAgent is the IP address where the agent is running, which was also used in creating the authentication keys.
    • admin is set to SNMPv3 because we will be sending SNMPv3 requests.
    • secName is the name of the user that you are creating. In this case, it is u1.
    • seclevel is set to AuthNoPriv because it is being configured to use authentication but not privacy (as a result, there are no values for privProto and privKey).
    • authproto is set to the authentication protocol that was used in creating the authentication keys.
    • authKey is the non-localized key that was generated by the pwtokey command.
  8. Save and close the /etc/clsnmp.conf file.

Step 2. Configure the group

The user must now be placed in a group. If you already have a group that is configured with all of the view and access permissions that you want to give this user, you can put this user in that group. If you want to give this user view and access permissions that no other groups have, or if you do not have any groups configured, create a group and add this user to it.

To add the user to a new group, create a new VACM_GROUP entry in the /etc/snmpdv3.conf file. The group entry for u1 follows: 
#--------------------------------------------------------------
# VACM_GROUP entries
#    Defines a security group (made up of users or communities)
#    for the View-based Access Control Model (VACM).
# Format is:
#  groupName securityModel securityName storageType
VACM_GROUP group1 USM u1 -
#--------------------------------------------------------------
  • groupName can be any name. It becomes that name of your group. In this case, it is group1.
  • securityModel is set to USM, which takes advantage of the SNMPv3 security features.
  • securityName is the name of the user. In this case, it is u1.

Step 3. Configure view and access permissions

The view and access permissions must be set for the new group that was just created. These permissions are set by adding VACM_VIEW and VACM_ACCESS entries to the /etc/snmpdv3.conf file.

  1. Decide what view and access permissions you want the new group to have.
  2. Add VACM_VIEW entries to the /etc/snmpdv3.conf file to define what MIB objects the group can access. In this scenario, group1 will have access to the interfaces, tcp, icmp, and system MIB subtrees. However, we will restrict group1's access to the sysObjectID MIB variable within the system MIB subtree. 
    #----------------------------------------------------------------
# VACM_VIEW entries
#    Defines a particular set of MIB data, called a view, for the
#    View-based Access Control Model.
# Format is:
#  viewName viewSubtree viewMask viewType storageType
VACM_VIEW group1View		interfaces	   - included -
VACM_VIEW group1View		tcp		      - included -
VACM_VIEW group1View		icmp		      - included -
VACM_VIEW group1View		system		   - included -
VACM_VIEW group1View		sysObjectID	   - excluded -
#----------------------------------------------------------------
    • viewName is the name of the view. In this scenario, it is group1View.
    • viewSubtree is the MIB subtree that you want to give access to.
    • viewType determines whether the MIB subtrees defined are included in the view. In this case, all subtrees are included, but the MIB variable sysObjectID, which is part of the system subtree, is excluded.
  3. Add a VACM_ACCESS entry to the /etc/snmpdv3.conf file to define the permissions that the group has to the MIB objects specified above. For group1, read only access is given. 
    #-----------------------------------------------------------------------------------------------------------
# VACM_ACCESS entries
#    Identifies the access permitted to different security groups
#    for the View-based Access Control Model.
# Format is:
# groupName contextPrefix contextMatch securityLevel securityModel readView writeView notifyView storageType
VACM_ACCESS  group1 - - AuthNoPriv USM group1View - group1View -
#-----------------------------------------------------------------------------------------------------------
    • groupName is the name of the group. In this case, it is group1.
    • securityLevel is the level of security that is being used. In this scenario, authentication keys are used but not privacy keys. The value is therefore set to AuthNoPriv.
    • securityModel is the security model that you are using (SNMPv1, SNMPv2c, or USM). In this scenario, it is set to USM to allow the SNMPv3 security features to be used.
    • readView determines which VACM_VIEWs the group has read access to. In this scenario, group1View is given, which gives group1 read access to the group1View VACM_VIEW entries.
    • writeView determines which VACM_VIEWs the group has write access to. In this scenario, no write access is given to group1.
    • notifyView specifies the name of the view to be applied when a trap is performed under control of the entry in the access table.
    Note: In some cases, multiple VACM_ACCESS entries for one group may be necessary. If users in the group have different authentication and privacy settings (noAuthNoPriv, AuthNoPriv, or AuthPriv) multiple VACM_ACCESS entries are required with the securityLevel parameter set accordingly.

Step 4. Configure trap entries for the user

Trap entries in SNMPv3 are created by adding NOTIFY, TARGET_ADDRESS and TARGET_PARAMETERS entries to the /etc/snmpdv3.conf file. The TARGET_ADDRESS entry will specify where you want the traps to be sent, and the TARGET_PARAMETERS entry will map the TARGET_ADDRESS information to group1.

The NOTIFY entry has been configured by default. Following is the default NOTIFY entry: 
NOTIFY notify1 traptag trap -
In this scenario, we use the value that is specified in the default entry, traptag.
  1. Add a TARGET_ADDRESS entry to specify where you want traps to be sent. 
    #-------------------------------------------------------------------------------------
# TARGET_ADDRESS
#    Defines a management application's address and parameters
#    to be used in sending  notifications.
# Format is:
#  targetAddrName tDomain tAddress tagList targetParams timeout retryCount storageType
#-------------------------------------------------------------------------------------
TARGET_ADDRESS Target1 UDP 9.3.207.107     traptag trapparms1 - - -
    • targetAddrName can be any name. In this scenario, we used Target1.
    • tAddress is the IP address where the traps for the group should be sent.
    • tagList is the name configured in the NOTIFY entry. In this scenario, it is traptag.
    • targetParams can be any value. We used is trapparms1, which will be used in the TARGET_PARAMETERS entry.
  2. Add a TARGET_PARAMETERS entry. 
    #------------------------------------------------------------------------- 
# TARGET_PARAMETERS
#    Defines the message processing and security parameters
#    to be used in sending notifications to a particular management target.
# Format is:
#  paramsName mpModel securityModel securityName securityLevel storageType
#-------------------------------------------------------------------------
TARGET_PARAMETERS trapparms1 SNMPv3  USM     u1        AuthNoPriv -
    • paramsName is the same as the targetParams value in the TARGET_ADDRESS entry, which, in this case, is trapparms1.
    • mpModel is the version of SNMP being used.
    • securityModel is the security model that you are using (SNMPv1, SNMPv3, or USM). In this scenario, it is set to USM to allow the SNMPv3 security features to be used.
    • securityName is the user name specified in the USM_USER entry, which, in this case, is u1.
    • securityLevel is set to AuthNoPriv because we are using authentication keys but not privacy keys.

Step 5. Stop and start the snmpd daemon

After making the changes the /etc/snmpdv3.conf file, stop and the start the snmpd daemon.

  1. Type the following command to stop the snmpd daemon: 
    stopsrc -s snmpd
  2. Type the following command to start the snmpd daemon: 
    startsrc -s snmpd

The new settings will now take effect.

Note: Simply refreshing the SNMPv3 agent using refresh -s snmpd will not work as it did in SNMPv1. If you make changes to the /etc/snmpdv3.conf file, you must stop and start the daemon as instructed above. The dynamic configuration function supported in SNMPv3 will not allow you to refresh.

Step 6. Test your configuration

To verify that your configuration is correct, you can run the following command on the SNMP manager . 
clsnmp -h user1 walk mib
where mib is a MIB subtree to which the user has access. In this scenario, it could be interfaces, tcp, icmp, or system. If the configuration is correct, you will see the information from the specified subtree.

If you did not get the correct output, review the steps in this document and verify that you have entered all information correctly.