Security Management for ECLI, NETCONF, and SFTP Users

Contents

1Introduction

2

Functions and Concepts
2.1NBI User Authentication
2.2NBI User Authorization
2.3Transport Layer Security
2.4Types of Operation

3

Managed Object Model
3.1Rules for Default Roles

4

Configuration Management

1   Introduction

This document provides an overview of the management model and concepts associated with the Security Management managed area.

A managed area is represented by a group of Managed Object Classes (MOCs) within the Managed Object Model (MOM).

2   Functions and Concepts

Security Management provides a management interface to configure the following on the Managed Element (ME):

An overview of Security Management is shown in Figure 1.

Figure 1   Security Management Overview

This document assumes that the ME has already been installed and initially configured. The initial configuration includes the necessary settings for the authentication of NBI users to an LDAP server and their authorization.

Authentication is used for querying user credentials and allowing user access. Role-Based Access Control (RBAC) and Target-Based Access Control (TBAC) authorization is used to ascertain the user access rights. Authentication and authorization are performed according to the organization authorization policy.

Concerning privacy, the communication between the NBI user and the ME is encrypted with SSH. The communication between the ME and the LDAP server can be encrypted using TLS.

For more information on the LDAP interface, refer to LDAP-Based Authentication and Authorization Interface.

2.1   NBI User Authentication

Normal Access

By using username and password, the NBI user initiates a NETCONF, Ericsson Command-Line Interface (ECLI), or SFTP session over SSH to the ME and triggers a user LDAP authentication from the ME.

The LDAP authentication executes the following operations in succession:

  1. An LDAP bind to identify the ME to the LDAP server with the configured bind Distinguished Name (DN) and bind password
  2. An LDAP search, based on an LDAP filter to locate the user in the LDAP server
  3. An LDAP bind to authenticate the user to the LDAP server with the username and user-provided password before returning the authentication result

Three different LDAP profile filters are supported for search; flexible filter, POSIX® groups filter, and Ericsson roles filter. The Ericsson roles profile filter is used together with the Ericsson Operations Support System (OSS) solution.

A primary and a secondary LDAP server are supported. The LDAP authentication first tries against the primary server and then against the secondary server.

All authentication attempts, whether successful or not, are recorded in the ME security log.

A successful NBI user authentication triggers an NBI user authorization.

When the Ericsson roles profile filter is used, the LDAP authentication can be selective based on the target type. In some networks, it can be required not to let all users have the right to log on to all MEs. For example, a network can span several countries and a user can be allowed to log on to MEs in only one country. This function is part of the TBAC functionality.

Emergency Access

In situations where none of the LDAP servers is reachable or active, all LDAP authentications fail. However, local Linux users belonging to the com-emergency Linux group can authenticate locally and get complete Management Information Base (MIB) access through the ECLI and NETCONF.

This emergency access is used only during troubleshooting.

2.2   NBI User Authorization

If authenticated locally by Linux, the NBI user obtains full access rights to the ME.

If authenticated by LDAP, the NBI user access rights depend on defined authorization rules that specify the permissions to a set of resources within the ME. The authorization rules are grouped into roles. A role is equivalent to the user occupation within an organization, for example, system administrator. A user can have one or more roles.

The roles are either retrieved from the LDAP server or are custom roles defined locally on the ME. The ME supports some predefined roles, see Section 2.2.2 Default Roles. Custom roles can only be configured over the NBI.

The authorization rules are all defined locally on the ME. Therefore the NBI user authorization is a local authorization. Custom rules corresponding to customer roles can be configured over the NBI.

Authorization rules provide different access levels to the MIB and the ECLI commands. Authorization rules are defined by permission types, see Section 2.2.1 Permission Types.

When the Ericsson roles profile filter is used, the authorization can be selective based on the target type. In some networks, it can be required to let a user have different management roles on different MEs. For example, the network can span several countries and it can be needed to let a user act as "admin" in one country, but only as "operator" in another. This function is part of the TBAC functionality.

2.2.1   Permission Types

Rules for access can be specified for Managed Objects (MOs), their attributes and actions. The execution of the ECLI commands and the NETCONF operations is not subject to authorization. However, the rules affect the result of the ECLI commands and the NETCONF operations that operate on MOs.

Permission types define different levels of access to the MIB according to Table 1.

Table 1    Permission Types

Permission Type

Description

No access (NO_ACCESS)

The user has no read, write, or execute rights to the MOs, attributes, or actions

Execute (X)

The user can execute all actions in the MOM

Read (R)

The user can read MOs and get attribute values

Read and execute (RX)

The user can read MOs, get attribute values, and execute all actions in the MOM

Read and write (RW)

The user can create and delete MOs as well as get and set attribute values

Read, write, and execute (RWX)

The user can create and delete MOs, set and get attribute values, as well as execute all actions in the MOM

When a user with an authorization profile wants to access resources of the ME, the access request is authorized against matching security rules. The rules are checked in the following order:

  1. All negative rules (with the NO_ACCESS permission) are evaluated. If a match is found, access is denied.
  2. All positive rules (with X, R, RX, RW, and RWX permissions) are evaluated until a match is found; the corresponding access is granted. If no match is found, access is denied.

2.2.2   Default Roles

The ME supports the predefined default roles described in Table 2. These roles and the corresponding rules cannot be modified. The detailed permissions for each role are described in Section 3.1 Rules for Default Roles.

Table 2    Default Roles

Default Role

Description

System Administrator

Responsible for the administration of all non-security-related attributes and capabilities of an ME, including features, configuration parameters, and monitoring

System Security Administrator

Responsible for the administration of all security-related attributes and capabilities of an ME, including user accounts and authorizations

Managed Function Application Administrator

Responsible for the administration of all non-security-related attributes and capabilities of the Managed Function, including features, configuration parameters, and monitoring

Managed Function Application Operator

Can view some non-security-related attributes and capabilities of the Managed Function, including features, configuration parameters, and monitoring

2.3   Transport Layer Security

TLS is used to secure the transport layer for the LDAP protocol.

The security algorithms used by TLS are determined as a result of a cipher suite handshake between the ME and the LDAP server. A cipher suite specifies a combination of authentication, encryption, key exchange, and message authentication algorithms. The cipher suite handshake selects the strongest common cipher suite between the ME and LDAP server. The selection is made from the ME-enabled cipher suite list.

The TLS can also be used with NETCONF.

2.4   Types of Operation

Security Management supports the following operations for an administrator with the System Security Administrator role:

LDAP Authentication

Local Authorization

3   Managed Object Model

The Security Management managed area is represented in the Managed Object Model (MOM) as follows:

ManagedElement
   +-SystemFunctions
      +-SecM
         +-Tls
         +-UserManagement
            +-AuthenticationOrder
            +-AuthorizationOrder
            +-LdapAuthenticationMethod
               +-Ldap
                  +-EricssonFilter
                  +-Filter
            +-LocalAuthorizationMethod
               +-CustomRole
               +-CustomRule
               +-Role
                  +-Rule

For general information about the MOM, MOCs, MOs, cardinality, and related concepts, refer to Managed Object Model User Guide.

The Security Management MOCs are described in Table 3.

Table 3    Security Management Managed Object Class Descriptions

Managed Object Class

Description

SecM

The root of the Security Management model.

Tls

Handles the TLS properties.

UserManagement

Describes the ME target types for TBAC.

AuthenticationOrder

Used to display the order of authentication methods.

AuthorizationOrder

Used to display the order of authorization methods.

LdapAuthenticationMethod

Handles the authentication method used to verify user credentials when attempting to log on to an ME.

Ldap

Handles the primary and secondary LDAP servers.

EricssonFilter

Defines the configuration used for the Ericsson filter (applicable when the value of profileFilter is ERICSSON_FILTER).

Filter

Defines the configuration used for the flexible filter (applicable when the value of profileFilter is FLEXIBLE).

LocalAuthorizationMethod

Handles the local authorization method used to verify the user access to the ME resources.

CustomRole

Handles the authorization roles that can be assigned to users.

CustomRule

Handles the rules that define the user access control of MOs.

Role

Describes the authorization roles that can be assigned to users.

Rule

Describes the authorization rules that define the user access control to MOs.

3.1   Rules for Default Roles

The detailed permissions for the default roles are described in the following tables.

"Deny" indicates the default behavior when no permission rule is defined.

Table 4    System Administrator Permissions for Default Roles

MOM Fragment

Permission

Scope

Managed Element

RWX

The MO, its attributes, and actions

 

System Functions

 

Backup and Restore Management

The MO, its attributes, actions, and child MOs

Fault Management

File Management

License Management

Performance Management

Security Management

R

Only the MO but not the attributes (enables navigation in the ECLI)

 

Certificate Management

R

The MO, its attributes, actions, and child MOs

Software Inventory Management

RW

Software Management

RWX

System Management

IPWorks Root

RWX

The MO, its attributes, actions, and child MOs

Table 5    System Security Administrator Permissions for Default Roles

MOM Fragment

Permission

Scope

Managed Element

R

Only the MO but not the attributes (enables navigation in the ECLI)

 

System Functions

 

Backup and Restore Management

Deny

Not applicable

Fault Management

R

The MO, its attributes, actions, and child MOs

File Management

Deny

Not applicable

License Management

Performance Management

Security Management

RWX

The MO, its attributes, actions, and child MOs

 

Certificate Management

Software Inventory Management

R

Software Management

Deny

Not applicable

System Management

IPWorks Root

Deny

Not applicable

Table 6    Managed Function Application Administrator Permissions for Default Roles

MOM Fragment

Permission

Scope

Managed Element

R

Not applicable

 

System Functions

Deny

 

Backup and Restore Management

Deny

Fault Management

R

File Management

Deny

License Management

Deny

Performance Management

Deny

Security Management

Deny

 

Certificate Management

Deny

Software Inventory Management

R

Software Management

Deny

System Management

Deny

IPWorks Root

RWX

The MO, its attributes, actions, and child MOs.

Table 7    Managed Function Application Operator Permissions for Default Roles

MOM Fragment

Permission

Scope

Managed Element

R

Not applicable

 

System Functions

Deny

 

Backup and Restore Management

Deny

Fault Management

R

File Management

Deny

License Management

Deny

Performance Management

Deny

Security Management

Deny

 

Certificate Management

Deny

Software Inventory Management

R

Software Management

Deny

System Management

Deny

IPWorks Root

R

The MO, its attributes, actions, and child MOs.

4   Configuration Management

Security Management is accessed using NETCONF or the ECLI to manipulate the MIB.

The following operations, described in Operating Instructions using the ECLI, can be performed by an administrator with the System Security Administrator role:

LDAP Authentication

Local Authorization



Copyright

© Ericsson AB 2017, 2018. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    Security Management for ECLI, NETCONF, and SFTP Users