Previous Topic Next topic Print topic


Configuring the Micro Focus Audit Emitter for SNMP V3 (deprecated)

Note: Audit Manager is deprecated and provided for backward compatibility only. We recommend that you use syslog events instead. See Enterprise Server Auditing for more information.

The first change to a standard V2 installation is to enable V3 operations.

mfaudit.emitter.snmp#agent.snmp_version = 3

Now we must select the level of security privilege that we require on our transmissions.

Whilst Authentication can be enabled or disabled at will, Privacy can only be enabled when Authentication is already enabled. So the three transmission privilege permutations are:

NoAuth No authentication or encryption of data

AuthPriv Authenticate and use private (encrypted) data

AuthNoPriv Authenticate user with no encryption of data

When configuring the SNMP Audit Emitter, this choice is held in the "privilege" setting. The following example enables both Authorisation and Privacy.

mfaudit.emitter.snmp#agent.privilege = AuthPriv

When either Privacy or Authentication and Privacy are disabled, the relevant sections of the configuration are ignored.

To provided Authorisation, a user identity is configured at the monitoring trap receiver and the issuing Emitter. Five options define a user, and a further option defines the Security EngineID that groups the user within a logical group of users.

We shall now take a look at the User options in detail.

The Username
The username is a single text string with a simple name. This name cannot contain spaces.
mfaudit.emitter.snmp#agent.security_username = fred_jones
The Hash Method
The Hash Method and Authentication Pass Phrase (the Shared Secret in cryptographic terms) are combined to form a cryptic value. This value which will be compared with the receiver's similarly configured pairing which has a matching Username and Security EngineID. A mismatch will cause the authentication attempt to be rejected.

Most installations support the MD5 hash method, and later installations may also support SHA1. If configuring a new V3 user, you should choose to use the latest hash method installed at the monitoring location that will receive the traps. The original MD5 method is the default hash method as it will currently be pre-configured in more installations than SHA1.

mfaudit.emitter.snmp#agent.hmac = MD5

The chosen hash method is applied to a configured pass phrase. The pass phrase must be at least 8 characters in length and may be spacey if the phrase is contained within a single pair of quote characters. Non-spacey passwords may omit the quote characters.

mfaudit.emitter.snmp#agent.auth_passphrase = "auth password"
The Encryption Cipher
The Privacy cipher can be either DES or AES128. Like the SHA1 hash above, AES is a recent addition to SNMP V3 and may not be in place in all installations. As a result, the default setup is to use the DES cipher. As with choosing a hash method, if you are configuring a new v3 user you should choose to use the latest cipher method that is installed at the monitoring location that will receive the traps. This should ideally be AES, however the default setting is DES as this will match the majority of installations in the field today.

The three options are DES, AES and AES128. The latter two are equivalent. It is anticipated that additions to the SNMP V3 standard will add AES192 and AES256 support in the future. When this happens AES will refer to AES128.

mfaudit.emitter.snmp#agent.cipher = DES

Exactly the same rules apply to Privacy (Cipher) pass phrases and Authentication pass phrases.

mfaudit.emitter.snmp#agent.cipher_passphrase = "crypt password"
The Security Engine ID
Several copies of a given username can exist within an SNMP installation, however only one copy can exist within the scope of any one Security Engine. So the group of five options shown above are always paired with a Security Engine ID. This is a numerical string represented in hex format. There are many long and varied methods for determining what value to use for a security engine ID and there is as yet no formal consensus. This document is not the place to examine the arguments, however in the setup you will need to choose a value to use as the Security Engine ID. This must match the receiver's Engine ID and Username's config grouping of options.

The following example would work as an initial test value, however it lacks meaning in a wider SNMP context and your network management team should assign a security Engine ID for the Audit Emitter monitoring, or advise the user of an existing Engine ID that should be used.

mfaudit.emitter.snmp#agent.security_engineID = 0x0102030405

Putting this group together we have a collection that describes the user, the user's Security Engine in which it will work, and the methods of both proving the user's identity and encrypting the audit event's data content. Taken together this is the complete configuration describing a single user.

mfaudit.emitter.snmp#agent.privilege = AuthPriv
mfaudit.emitter.snmp#agent.security_engineID = 0x0102030405
mfaudit.emitter.snmp#agent.security_username = fred_jones
mfaudit.emitter.snmp#agent.hmac = MD5
mfaudit.emitter.snmp#agent.auth_passphrase = "auth password"
mfaudit.emitter.snmp#agent.cipher = DES
mfaudit.emitter.snmp#agent.cipher_passphrase = "crypt password"
The ContextID and ContextName
The final configuration items not mentioned so far are the Security Context ID and ContextName. These are paired together in much the same fashion as the SecurityEngineID and UserName to form a restricted connection entity.

Contexts can be useful in installations where several applications will be receiving SNMP data and the users do not wish all the applications to receive all the incoming data.

By giving different applications the same SecurityEngineID and UserName configuration, but different ContextEngine and ContextName configurations, data destined for specific locations can be sent to those locations without the need to configure extra Users in the SecurityEngine domain in order to distinguish the destinations and sources.

Again, in a similar fashion to the SecurityEngineID and UserName configuration items, the ContextEngineID is expected to be a hex string, and the ContextName a character string which usually has human readable content.

mfaudit.emitter.snmp#agent.context_engineID = 0x0102030405
mfaudit.emitter.snmp#agent.context_name = primary_audit_monitor
Previous Topic Next topic Print topic