Operating Instructions 14/1543-CSH 109 067/10 Uen C

Security, OAM User Gaining Privilege Failed
Ericsson Centralized User Database

Contents


1 Introduction

This document provides the description and troubleshooting steps to take for the Security, OAM User Gaining Privilege Failed alarm.

1.1 Alarm Description

This alarm is raised when an Operation and Maintenance (OAM) user attempts to raise their access permissions with a su or sudo command, and the command fails due to a wrong password.

The possible alarm causes and the corresponding fault reasons, fault locations, and impacts are described in Table 1.

Table 1   Alarm Causes

Alarm Cause

Description

Fault Reason

Fault Location

Impact

An OAM user has unsuccessfully tried to increase their access permissions using su or sudo command.

Authorization Fault.

An OAM user has unsuccessfully tried to increase their access permissions using su or sudo command.

Operating System.

OAM user is not authorized to execute action issued with su or sudo.
Note: An alarm can appear as a result of the maintenance activity.

The alarm attributes are listed and explained in Table 2.

Table 2   Alarm Attributes

Attribute Name

Attribute Value

Auto Cease

No

Module

SECURITY(11)

Error Code

7

Timestamp First

Date and time when the alarm was raised for the first time.

Repeated Counter

Number which indicates how many times the alarm was raised.

Timestamp Last

Date and time of the most recent alarm raised.

Resource ID

.1.3.6.1.4.1.193.169.11.7. <IP> . <usernameLength> . <usernameASCIICode>

Alarm Model Description

OAM User Privilege Raise Failed, Security.

Alarm Active Description

Security: OAM User Privilege Raise Failed @ <IP> by user <username> to <other username>

ITU Alarm Event Type

securityServiceOrMechanismViolation (10)

ITU Alarm Probable Cause

authenticationFailure (600)

ITU Alarm Perceived Severity

(6) – Warning

Originating Source IP

Node IP where the alarm was raised.

Sequence Number

Number which indicates the order in which alarms were raised.

In Table 2, the indicated variables are as follows:

  • <usernameLength> : The number of characters in the user name.

  • <usernameASCIICode> : A series of dot-separated numbers where each number corresponds to the ASCII code of each character in the user name. For example:

    79.97.109.85.115.101.114 for OamUser.

  • <IP> : The IP address of the blade or Virtual Machine (VM), where user privilege raise was attempted.

  • <username> : The name of the user in text.

  • <other username> : The privileged username in text.

For further information about attribute descriptions, refer to CUDB Node Fault Management Configuration Guide.

1.2 Prerequisites

This section provides information on the documents, tools, and conditions that apply to the procedure.

1.2.2 Tools

Not applicable.

1.2.3 Conditions

Not applicable.

2 Procedure

If the alarm is raised, perform the following steps:

Steps

  1. Make backup copies of the log files to preserve evidence of the (attempted) intrusion.
  2. Examine the security log file to determine the source of the intrusion. For more information about logging information in CUDB, refer to CUDB Node Logging Events.
  3. If the log file analysis indicates that an unauthorized operation was successful, seek further advice in order to secure the system again. For more information about security configuration in CUDB, refer to CUDB Security and Privacy Management.
  4. Once system security has been reestablished, refer to CUDB Node Fault Management Configuration Guide to manually clear the alarm.
  5. If the alarm does not cease, contact the next level of maintenance support. Further actions are outside the scope of this Operating Instruction.

After This Task

Further actions are outside the scope of this Operating Instruction.

Legal |© Ericsson AB 2016-2018