sun.com | docs.sun.com | How To Buy | My Sun | Worldwide Sites |  |

| Previous Contents Index Next
### Format of the Trap Group The trap group specifies the hosts to which the agent will send traps if the `InetAddressAcl` mechanism is used. This group contains one or more trap community definitions.
    trap = {
       community1
       community2
       ...
       communityN
    }
Each community definition defines the association between a set of hosts and the SNMP community string in the traps to be sent to them. Each trap definition has the following format:
    {
       trap-community = trapCommunityName
       hosts = trapHostList
    }
The trapCommunityName item specifies a single SNMP community string. It will be included in the traps sent to the hosts specified in the `hosts` item. SNMPv3 does not use the community string, so use IP addresses or the context name instead. The trapHostList item specifies a comma-separated list of hosts. Each host must be identified by its name or complete IP address. When the SNMP protocol adaptor is instructed to send a trap using the `InetAddressAcl` mechanism, it will send a trap to every host listed in the trap community definitions. If a host is present in more than one list, it will receive more than one trap, each one identified by its corresponding trap community. ## SNMPv3 User-Based Access Control The user-based access control implemented by SNMPv3 is based on contexts and user names. The users, contexts and associated security information controlling access to the agents in an SNMP session are defined in the `nma.uacl` file. Example 4-2 Example `nma.uacl.template` File
    acl = {
    # {
    # context-names = TEST-CONTEXT
    # access = read-write
    # security-level = authNoPriv
    # users = defaultUser
    # }
    }
- In the `nma.uacl` file, you define the following: A list of context names, separated by commas. You can define a null context by declaring `context-names = null` The access level, which can be either `read-write` or `read-only` The security level, as follows:
  `noAuthNoPriv` | No security mechanisms activated
  `authNoPriv` | Authentication activated, with no privacy
  `authPriv` | Both authentication and privacy activated
A list of authorized users, separated by commas; an asterisk (`*`) opens access to all users. By uncommenting the `acl` block in Example 4-2, you would limit access to MIBs in the `TEST-CONTEXT` context only, and grant read-write access to the user `defaultUser`. The security level in the file must also match that of user `defaultUser`. Therefore, any non-authenticated requests, any request with different security levels, or any requests from a user other than `defaultUser`, would be rejected. ## Configuring SNMPv3 Security Under SNMPv1 and SNMPv2, agents act as information servers, and IP-based access control is used to protect this information from unauthorized access. The SNMPv3 protocol provides much more sophisticated security mechanisms, implementing a user-based security model (USM). This model allows both authentication and encryption of the requests sent between agents and their managers, as well as user-based access control. Note - The default NMA configuration is an example of an SNMPv3 configuration. Modify the security parameters to fit your security requirements. You can add and remove users in the `nma.security` file as specified in Managing Users in Security Files. ### Engine ID Secure SNMPv3 communication requires that the SNMP engine ID, which is generated by the NMA for each node, is used to communicate with the NMA. The SNMP engine ID is unique for the SNMP domain. It is a hexadecimal string calculated from a concatenation of the following properties of the NMA on each node: Node CGTP address Communication port number IANA number. By default this is `42`. The engine ID is stored in the `nma.security` file of each NMA. The engine ID may be substituted for another engine ID. ### Context Name The NMA MIB is not registered under the scope of any context. ### Managing Users in Security Files Every user that has access to an agent is represented by a `userEntry` line in each of the agent's security files. You configure the `userEntry` as follows, with the parameters separated commas: `userEntry=engine ID,user name,security name,authentication algorithm,authentication key, privacy algorithm,privacy key,storage type,template` The only mandatory parameters are the engine ID and the user name. All the other parameters are optional. The possible values for the parameters are as follows:
Engine ID | A local or remote SNMP engine, defined in one of the following ways: The string `localEngineID`, to denote the local engine A hexadecimal string, for example, `0x8000002a05819dcb6e00001f95` A human-readable string used to generate an engine ID, providing any or all of the host name, port, and IANA number.
User name | Any human-readable string
Security name | Any human-readable string
Authentication algorithm | The following algorithms are permitted: `usmHMACMD5AuthProtocol` `usmHMACSHAAuthProtocol` `usmNoAuthProtocol`
Authentication key | Any text password or any hexadecimal key starting with `0x`; for example, `0x0098768905AB67EFAA855A453B665B12`, of size: 0 to 32 inclusive for HMACMD5 0 to 40 inclusive for HMACSHA
Privacy algorithm | The following algorithms are permitted: `usmDESPrivProtocol` `usmNoPrivProtocol` If no algorithm is specified, the default is `usmNoPrivProtocol`.
| Any text password or any hexadecimal key starting with `0x`; for example, `0x0098768905AB67EFAA855A453B665B12`, of size 0 to 32 inclusive If a hexadecimal string is provided, it must be a localized key
Storage type | A value of 3 denotes non-volatile, meaning that the user entry is flushed in the security file; any value other than 3 will be rejected, throwing an `IllegalArgumentException`
template | Can be either `true` or `false`: If `true`, the row is a template, not seen from USM MIB. This kind of user is used when cloning users. The default is `false`.
Previous Contents Index Next

Copyright 1994-2004 Sun Microsystems