4.3             Solaris Systems SMP version 1 and 2

1.      Disable SNMPDX

2.      Enable SNMP

3.      Change the SNMP default community name to <current site community name> (for SNMP v1, v2. SNMPv3 do not need community name)

4.      Change the sysobjectid to 1.3.6.1.4.1.42.2.1.1 located in the /ect/init.d/init.sma file

5.      Restart SNMP services

6.      Create an Orion userid and password for Application  SSH connection

4.4     Solaris SNMP version 3 configuration

1. Stop snmpdx and snmpd. Make sure to disable snmpdx. It’s not longer needed.
2. Edit snmpd.conf SNMP configuration file located in  /etc/sma/snmp/
   1. add the following information:

·        “access  <user_name> “” usm priv exact any any any”

·        “agentaddress <x.x.x.x>:161” (This will force to use a dedicated IP and port number for SNMP. You can use other port than the SNMP default one)

·        “rouser <user_name> priv”

3. Edit snmpd.conf SNMP configuration file located in  /var/sma_snmp/
   1. add the following information: “createUser <user_name> MD5 <passphrase> DES

4. Enable snmpd

5. End

-------------------------------------------------------------------------------------------------------

Explanation:

1)         Configuration Item:  access <user_name>  usm priv exact any any any

            Explanation:  The “access” directive goes in (/etc/sma/)snmpd.conf.  In this case:

Ø      “<user_name>” is the security name.  In SNMPv3 it is the same as the name of the ‘user’ account that will be granted access.

Ø      The context is blank (i.e. “”).  Even a blank space in this position would indicate that the context was “a blank space.”  The context limits access to a particular subset of information within the MIB.  If it doesn’t match the context configured on the management server “exactly,” access will be blocked (see “exact” below).

Ø      “usm” signifies that access will be permitted using the User Security Model only; that is the SNMPv3 security model.

Ø      “priv” is the security level.  SNMPv3 has the option of using no security (noauth), authorization only (auth), or authorization AND privacy encryption (priv).  The use of privacy encryption requires the use of authorization.

Ø      “exact” specifies that the context of the incoming Protocol Data Unit (PDU) must match the allowed context exactly.  (The only other choice is, “prefix.”)

Ø      “any any any” specifies the views to be used for read (Get*), write (SET), and notify (TRAP/INFORM) access.  In this case we’re allowing any view... although we are going to configure our user with read-only access later anyway... could be locked down tighter?  If anyone can find more information on this it might be helpful.

2)         Configuration Item:  rouser <user_name> priv

            Explanation:  The “rouser” directive goes in (/etc/sma/)snmpd.conf.  In this case:

Ø      “rouser” establishes <user_name> as a read-only user account.

Ø      “<user_name>” is the security name of the user.

Ø      “priv” is the security level.  It mandates the use of both authentication and encryption (privacy) for all transactions.

3)         Configuration Item:  agentaddress x.x.x.x:161

            Explanation:  The “agentaddress” directive goes in (/etc/sma/)snmpd.conf.  In this case:

Ø      “agentaddress” specifies the address and port that the agent will listen on for communications from the manager.

Ø      “x.x.x.x” will be the Out Of Band (OOB) IP ... ONLY ... of the system being configured.

Ø      “161” is the UDP port that the system will listen on.  (UDP/162 is normally used for traps, but we’re not configuring any traps at this time.)

4)         Configuration Item:  “createUser <user_name> MD5 <passphrase> DES”

            Explanation:  The “createUser” token goes in (/var/sma_snmp/)snmpd.conf.  It is used only during the initial setup of the service.  It is read during service startup and its information is converted to encrypted values and stored in this file for comparison during later transactions.  The unencrypted values are then removed from the file so that they are not being stored plaintext.  In this case:

Ø      “<user_name>” is the security name of the user being created.

Ø      “MD5” is the hashing algorithm (HMAC-MD5) that will be used for authorization.

Ø      “<passphrase>” is the authorization passphrase that will be used by the algorithm to hash the security name for safekeeping.  The other option is SHA, but our systems do not all support it at this time (at least mine doesn’t... I tried to switch to SHA but it just kept on using MD5!).

Ø      “DES” is the symmetric encryption algorithm that will be used to ensure privacy (confidentiality) during data transfer between the agent (client) and manager (server).  There are no other supported options at this time.

Ø      Finally, if one wished to use a different passphrase for privacy than for authorization, one would place it after “DES.”  Otherwise the system will assume that one wishes to use the same passphrase for both.  In our case we leave it blank and let it default to the same passphrase.

-------------------------------------------------------------------------------------------------------

Note: The auth and priv passphrases, whether they are the same or not, must meet the requirements for “service accounts.”  They must be:

1) At least 15 characters long

2) Changed annually (or upon the departure of a sys admin that entered the pass-phrase)

3) Be complex:  A mix of upper case letters, lower case letters, numbers, and special characters, including at least one of each.

-------------------------------------------------------------------------------------------------------

SMA's service log is located here -- /var/svc/log/application-management-sma\:default.log.
However the default log file of snmpd is /var/log/snmpd.log (and that’s where one finds errors during initialization, access, etc...)

According to snmp_config(4), the snmpd (snmp daemon) search order is as follows:

/etc/sma/snmp/

/usr/sfw/lib/

~/.snmp/

Note:  The /etc/sma/snmp/snmp.conf file, if it exists (i.e. if it was created when running the “snmpconf” setup script), can be removed after setup so that the usm passphrase isn’t stored in plain text on the system.  In fact, if the snmpconf setup script isn’t used during setup, the file will never be created.

“group” and “ro/rwcommunity” (name/string) are used for SNMPv1 and SNMPv2C.  They are not required for our implementation and should not be included in the configuration.