Sun Microsystems
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next 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 Previous     Contents     Index     Next Next