Vous êtes sur la page 1sur 84

User Management

USER GUIDE

4/1553-CXA 118 03/2-V3 Uen B


Copyright

© Ericsson AB 2016. 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.

Abstract

This document describes the user management function in terms of central user
management and Troubleshooting (TS) user management of users accessing
to an AXE node. It also describes the configuration management of Lightweight
Directory Access Protocol (LDAP) and the certificate management.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Contents

Contents

1 General 1
1.1 Revision Information 1
1.2 Concepts 1
1.3 Scope 4
1.4 Introduction 4

2 How to use 21
2.1 First APG Configuration 21
2.2 LDAP Certificates Administration 33
2.3 MML Authority Handling 49
2.4 Troubleshooting User Policy Management 51
2.5 Troubleshooting User Account Administration 53
2.6 Actions on Alarms 59

3 Configuration 61
3.1 AXE Node Roles and Rules 61
3.2 LDAP Server Configuration 72

Glossary 77

Reference List 79

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


User Management

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

1 General

1.1 Revision Information


Changes in APG43L 3.2

Other than editorial changes, this document has been revised as follows:
• 4/1553-CXA 118 03/2-V3 Uen
0 Rev. B
• New command version added in Table 11.
0 Rev. A
• Document number changed from 4/1553-CXA 118 03 Uen.
• Term ‘‘COM CLI’’ is replaced by ‘‘ECLI’’. And the reference, User
Guide Common OaM Command Line Interface, at Reference List
on page 79, is changed to User Guide Ericsson Command-Line
Interface.
• New pictures style for all class diagrams.
• New command back added in Table 11.
• Range of attribute maximumAccountAge extended from 1-14 to
1-30; Section 2.4.2 on page 52 updated.

1.2 Concepts
CA trusted certificate
A CA trusted certificate is the certificate of the trusted
certification authority. It is a file containing an X.509
standard based certificate in Privacy Enhanced Mail
(PEM) or Distinguished Encoding Rules (DER) format.
It has to be installed in APG in order for it to trust
certificates signed by that specific CA.

Certificate In cryptography, a certificate (also known as a digital


certificate or identity certificate) is an electronic
document which uses a digital signature to bind a public
key with an identity, information such as the name of
a person or an organization, their address, and so
forth. The certificate can be used to verify the identity of
person or an organization.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 1


User Management

Certification Authority
Certification Authority (CA) is an entity that issues
signed digital certificates. The digital certificate certifies
the ownership of a public key by the named subject of
the certificate. This allows others (relying parties) to rely
upon signatures or assertions made by the private key
that corresponds to the public key that is certified. In
this model of trust relationships, a CA is a trusted third
party that is trusted by both the subject (owner) of the
certificate and the party relying upon the certificate.

CMPv2 IAK The Certificate Management Protocol (CMP)v2 Initial


Authentication Key (IAK) is a protocol for managing
Public Key Infrastructures (PKI) based on X.509v3
certificates. Protocol messages are defined for
certificate creation and related management.

CSA Certificate Signing Authority (CSA) provides Certification


Authority (CA) and Registration Authority (RA) function.

Lightweight Directory Access Protocol


Lightweight Directory Access Protocol (LDAP) is a
client-server protocol for accessing directory services.
LDAP provides a central mechanism for maintaining
system configuration and policy information. This lets
clients configure and manage multiple systems with
a single set of user identity configuration information.
LDAP server maintains an organized structure of user
and group account information.

LDAP referral LDAP referral is the mechanism by which an LDAP


server returns a reference, a referral, to another LDAP
server which may contain further information, instead
of returning a result.

node credential A node credential is a file containing a client X.509


standard based certificate and the corresponding client
private key. In more detail, a client X.509 standard
based certificate and the corresponding client private
key are used by APG to communicate with the LDAP
server in order to establish a trust relationship.

Proxy Account Proxy Account, or proxy agent or proxy client, is an


LDAP user authorized to bind (login) to the LDAP server
and lookup the users object in LDAP directory. This
needs to be defined in the OSS LDAP server and then
used in the APG configuration.

2 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

Public Key Infrastructure


A Public Key Infrastructure (PKI) is a set of hardware,
software, people, policies, and procedures needed
to create, manage, distribute, use, store, and revoke
digital certificates. The PKI creates digital certificates
which map public keys to entities, securely stores these
certificates in a central repository and revokes them if
needed

Registration Authority
A Registration Authority (RA) is an authority in a network
that verifies user requests for a digital certificate and
tells the CA to issue it.

role A role is a container for a set of system-defined


authorization rules that define permissions to access
system resources and perform certain operations. When
a role is assigned to an Operation and Maintenance
(OaM) user or a role alias it is tagged with a target,
which means that the role is only applicable for the OaM
user when nodes matching the target is accessed.

role alias A role alias is a container for a set of roles stored in the
LDAP server and each role stored in the role alias is
tagged with a target. When a role is assigned to an OaM
user then all roles stored in the role alias are implicitly
assigned to the user. Role alias nesting is not allowed,
so a role alias may not contain another role alias.

Role-Based Access Control


Role-Based Access Control (RBAC) is an approach to
restrict system access to authorized users. It uses roles
and authorization rules concepts. Each role has a set
of authorization rules defining permissions to access to
system resources and perform certain operations. Each
user acquires the authorization rules through the role
(or roles) the user belongs to.

Secure Sockets Layer


Secure Sockets Layer (SSL) is a cryptographic protocols
that provide communication security over the network.

target A target is the logical identifier of a node or a group of


nodes in the network. It distinguishes the particular AXE
node from others in the network as well as provides
the possibility to group nodes according to their logical
function and/or other criteria such as geographical
location. It is possible to create layered and overlapping
groupings of nodes using targets as multiple targets can
be assigned to an AXE node.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 3


User Management

Target-Based Access Control


Target-Based Access Control (TBAC) is an approach to
restrict system access to authorized users. It is based
on target concept which controls both which nodes a
user has access to and also which roles the user is
assigned when accessing a node. Each node stores
a list of targets.

1.3 Scope
This User Guide is written as an aid for the configuration and operation of user
management of an AXE node with APG43L. It copes the following topics:

• Central User Management.

• Troubleshooting User Management.

The content of following User Guides are prerequisite for this document:

• AXE Security Management, Reference [10].

• Ericsson Command-Line Interface, Reference [12].

• How to Access an AXE, Reference [13].

• Managed Element Management, Reference [14].

• Managed Object Model, Reference [15].

1.4 Introduction
User Management functions consists of central user management and
troubleshooting user management.

Central user management encompasses, as per Section 1.4.1 on page 5:

• The configuration of APG interworking with an LDAP server acting as a


central user repository database in the customer network.

• The authentication and authorization of users via the central LDAP server
using both TBAC and RBAC approaches.

Troubleshooting (TS) user management encompasses, as per Section 1.4.2


on page 16:

• The management of TS user accounts

• The authentication and the authorization of TS users.

The user authentication and authorization is performed when a user establishes


an Adjunct Processor (AP) session, Man-Machine Language (MML) session,
Network Configuration (NETCONF) session, File Transfer (FT) session, and

4 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

TS session with an AXE node. User Guide How to Access an AXE, Reference
[13], describes the way to open such sessions towards an AXE node.

1.4.1 Centralized User Management


Centralized user management refers to the management of OaM users that
access to the AXE node to perform OaM activities in AP session, MML session,
NETCONF session and FT session.

Centralized user management requires a central LDAP server where users are
defined and assigned to specifics AXE nodes and with specific roles according
to TBAC and RBAC approaches.

An AXE node can consist of one APG, in a Single-APG configuration, or two


APGs, in a Dual-APG configuration. In case of Dual-APG configuration the
central LDAP server is intended to be used by both APGs.

1.4.1.1 LDAP Configuration

Central user management requires an LDAP server, relative CA(s) and a set
of configuration in each of connected APG and LDAP server. The LDAP and
CA(s) servers solution is included in the Ericsson Operation Support System
(OSS) and its respective configuration is coped in Node Centralized User
Management Integration Guide for OSS-RC, Reference [17].
However it is also possible to use an own LDAP server within the customer
network and Section 3.2 on page 72 describes the configuration to get it
working with APG. Note that such a separate LDAP server solution is not
working with Ericsson OSS.

APG configuration includes:

• Installing certificates on each connected APG making each one trusted


into customer network.

• The configuration of connected APG(s) as LDAP client.

Installation of certificates can be performed in two alternative procedures:

1. Offline enrollment.

This procedure requires manual installation of the following certificates


previously obtained from the CA per each connected APG:

• one node credential certificate.

• one CA trusted certificate.

2. Online enrollment.

This procedure requires two CAs, one for the LDAP server and another one
acting as enrollment server, supporting the protocol CMPv2 IAK. It implies

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 5


User Management

manual installation of two CA trusted certificates previously obtained


from the two CAs, and the automatic installation of the node credential
certificate obtained via protocol messages exchange between the CA
server, supporting protocol CMPv2 IAK, and the APG. Renewal can be
configured to be automatic as well.
The procedure applies per each connected APG.

This procedure allows the customer to reduce the costs for managing
node credential certificates, increasing security and removing the risk of
undesired certificate expiration, so it is the recommended procedure to use.

Note: The online enrollment of node credential certificate for APG is


supported from Ericsson OSS-Radio Core (RC) 16A and Ericsson
Network Management (ENM) 16B releases onwards, but any other CA
server that support the protocol CMPv2 IAK in the customer network
can be used; an example of this server is the Enterprise Java Bean
Certificate Authority (EJBCA) built on Java technology. The installation
and configuration of this server is out of scope of this document and it
is demanded to the customer security administrator.

The configuration to be done on each connected APG is done through the


Managed Object Models (MOMs) having CertM and UserManagement as
root Managed Object Class (MOC) (see Figure 1 and Figure 2) and via AP
command ldapdef.

SecM is the root MOC for User Management function MOM.

CertM is the root MOC for Certificate Management function MOM and
encompasses the management of node credentials and trusted certificates
needed to configure a secure connection with LDAP.

Figure 1 Certificate Management Function MOM

The MOC CertMCapabilities is system created and must not be changed.

The MOC EnrollmentAuthority represents a CA or RA for certificate enrollment


and contains related information.

The MOC EnrollmentServer represents a configured CA enrollment server.

The MOC EnrollmentServerGroup represents a group of CA enrollment servers


that can be used to offer load balancing.

The MOC NodeCredential represents a node credential and contains


information about the corresponding certificate.

The MOC TrustCategory represents a group of trusted certificates that can be


referenced by users.

6 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

The MOC TrustedCertificate represents a CA trusted certificate and contains


information about the corresponding certificate.

In offline enrollment procedure only NodeCredential and TrustedCertificate


MOCs require to be configured.

In online enrollment procedure NodeCredential, TrustedCertificate,


EnrollmentServerGroup, EnrollmentServer and EnrollmentAuthority MOCs
require to be configured.

The MOC UserManagement is the entry class for the LDAP configuration (see
Figure 2).

Figure 2 User Management Function MOM

The MOs AuthenticationOrder=1 and AuthorizationOrder=1 are system created


and pre-configured at installation time. They must not be changed.

The MO LdapAuthenticationMethod=1 is the entry class of the MOM aiming


to configure the LDAP related settings represented by the attributes in MOs
Ldap=1 and EricssonFilter=1.
In particular:

• the attribute administrativeState in the MO LdapAuthenticationMethod=1


allows enabling the central user management via LDAP server.

1.4.1.2 Authentication and Authorization

An OaM user establishing an AP session, MML session, NETCONF session


or FT session with the AXE node is authenticated through the central LDAP
server. The authentication process mainly verifies provided user credentials
with information stored in the LDAP, in particular the target(s) assigned to the
OaM user, called user target list. If the intersection between the user target list
and the target(s) defined on the node is not empty, and user credentials are
correct, then the OaM user can have access to the node; otherwise connection
is refused.

The user target list is defined via the LDAP attribute ericssonUserAut
henticationScope containing all associated target types; and via the
LDAP attribute ericssonUserAuthorizationScope written in the format
<target>:<role>, where each role is qualified with a target type. Within
an Ericsson OSS LDAP, the role qualification is mandatory for any new user
defined into OSS 16A release onwards.

The node target list, referred as COM Target in Ericsson OSS LDAP, is
defined via attribute targetType located in MO UserManagement=1. At least

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 7


User Management

the ManagedElementId value must be assigned to the node target list as


described in Table 6 of Section 2.1.4 on page 29.

Note: The attribute nodeType, located in MO Ldap=1, is deprecated. It is


still supported, but it is recommended to use the attribute targetType
instead.

When the OaM user has been authenticated, the roles that are assigned to the
user depend on the value of the attribute version in the MO EricssonFilter=1.
If attribute version is equal to 1 then the roles (both directly and implicitly via
role alias) associated to each target into intersected target list, and the roles not
qualified with any target, are assigned to the user.
If a role is qualified with character ‘‘*’’ such target is considered like any other
target so not considered like a wildcard.

For example, if node target list is equal to ‘‘SOUTH, WEST’’, the user
authentication target list is equal to ‘‘SOUTH, EAST’’ and the user authorization
target list is defined like SOUTH:role1, EAST:role2, *:role3, role4, the
roles role1 and role4 are assigned to such user after a successful login.

If attribute version is equal to 2 then the roles (both directly and implicitly via
role alias) associated to each target into intersected target list are assigned
to the user; and all roles that have not been tagged with any target in the
intersected target list are discarded.
If a role is qualified with character ‘‘*’’ such target is considered like a wildcard,
so such role is assigned to the user regardless the intersected target list
contents.

For example, if node target list is equal to ‘‘SOUTH, WEST’’, the user
authentication target list is equal to ‘‘SOUTH, EAST’’and the user authorization
target list is defined like SOUTH:role1, EAST:role2, *:role3, role4, the
roles role1 and role3 are assigned to such user after a successful login.

It is recommended to set the attribute version to 2 once all users defined on


LDAP server have been associated to roles with a qualifying target.

The assigned roles define the authorization level the OaM user has in terms
of capability to access to node resources: MOM items, AP commands, APG
file system.

Note: In a Dual-APG configuration, in case AP2 is not connected to customer


OaM network, the authentication of a user on AP2 is done using the
LDAP server configuration of AP1.

The roles and the corresponding authorization levels supported by


APG are predefined in the Local Authorization function MOM which
LocalAuthorizationMethod is the root MOC (see Figure 3).

8 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

Figure 3 Local Authorization Function MOM

The MOC LocalAuthorizationMethod is pre-configured at installation time and


must not be changed.

The MOC Role represents the roles that a user can be assigned to.

There are 20 predefined and not changeable roles in the AXE node:

• SystemAdministrator

• SystemSecurityAdministrator

• SystemReadOnly

• EricssonSupport

• CpRole0 ... CpRole15 (Predefined CP roles)

Roles have a containment relationship to the rules. The MOC Rule represents
the authorization rules to define access control to system resources. Rules are
expressed in terms of Read, Write, or eXecute (RWX) permissions on each
system resource, for example the following rule defines full access control
to MO SystemFunctions=1:

Rule=Top_2
permission=RWX
ruleData="ManagedElement,SystemFunctions"

Each role has its own set of authorization rules that cannot be changed. A user
can be associated to more than one role acquiring the union of authorization
rules of each specific role. For more details about each role and associated
authorization rules see Section 3.1 on page 61.

1.4.1.3 Authorization in AP Session

The authorization of a OaM user establishing an AP session is based on


authorization rules assigned to roles the user belongs to. Such rules define the
access control to MOs and AP commands. See Section 3.1 on page 61.

1.4.1.4 Authorization in MML session

The authorization of an OaM user establishing an MML session is handled


by the MML authorization system and it is different depending on Single-CP
System or Multi-CP System configuration, as per value of the attribute
systemType.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 9


User Management

1.4.1.4.1 MML Authorization in a Single-CP System

The MML authorization in a Single-CP System is based on the association


between an OaM user and Command Category (COCA) groups, by using a
CP user code, as shown in Figure 4.

10 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

Figure 4 MML Authorization in a Single-CP System

MML commands and DBS table are grouped, according to function, into 256
standard COCA groups, that are integer values from 0 to 255. Each MML
command is assigned to a COCA group by default and the association can be

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 11


User Management

changed through a specific MML command in an MML session. Each DBS table
is assigned to two COCA groups by default with read and write permission.

COCA groups are allocated to CP user groups through a specific MML


command. There are 16 CP user groups and each one can be associated to
more COCA groups.

CP users, identified by CP user codes, are assigned to CP user groups via a


specific MML command. A CP user can be assigned to one CP user group only
and is authorized to execute any MML command or access to any DBS table
which COCA group is included in that CP user group.

By default, the CP user ADMINISTRATOR belongs to CP user group 0 and CP


user group 0 is associated to COCA groups 0-64: this means that CP user
ADMINISTRATOR can execute any MML command and access to any DBS
table which COCA number is in the range 0-64.

An OaM user to get the MML authorization must have a valid MML authority
profile consisting of an association between the predefined CP role of the OaM
user and a CP user.
MML authority profile can be created as per details specified in Section
1.4.1.4.3 on page 15.

Figure 5 shows an example of MML authority profiles defined in Single-CP


System.

Figure 5 MML Authority Profile in Single-CP System

12 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

OaM user Eva belongs to CP role CpRole0 that is associated to CP user


ADMINISTRATOR by default. This means Eva can execute any MML command
and access to any DBS table which COCA group is in the range 0-64. Similarly,
OaM user Bill belongs to CP roles CpRole1 and CpRole2 but it has the
MML authorization level of CP user CPUSER1. Each predefined CP role can be
associated to one and only one CP user code. On the other hand an OaM user
can belong to more than one CP role at the same time, so when this happens,
after target filtering has been applied, only one of the CpRole<i> is used in APG
and it is the one that is closest to the top of the ordered list below:

1. CpRole0

2. CpRole1

3. CpRole10

4. CpRole11

5. CpRole12

6. CpRole13

7. CpRole14

8. CpRole15

9. CpRole2

10. CpRole3

11. CpRole4

12. CpRole5

13. CpRole6

14. CpRole7

15. CpRole8

16. CpRole9

Thus for user Bill who is assigned CpRole1 and CpRole2, see Figure 5, the
APG selects CpRole1 as it is found closer to the top of the list than CpRole2.

1.4.1.4.2 MML Authorization in a Multi-CP System

The MML authorization in a Multi-CP System is based on the association


between an OaM user and COCA groups as shown in Figure 6.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 13


User Management

Figure 6 MML Authorization in a Multi-CP System

MML commands and DBS table are grouped, according to function, into 256
standard COCA groups, that are integer values from 0 to 255. Each MML
command is assigned to a COCA group by default and the association can be
changed through a specific MML command in an MML session. Each DBS table
is assigned to two COCA groups by default with read and write permission.

An OaM user to get the MML authorization must have a valid MML authority
profile consisting of an association between the predefined CP role of the OaM
user and a list of COCA groups.
MML authority profile can be created as per details specified in Section
1.4.1.4.3 on page 15.

Such a user is acting as a regular user, meaning that is able to


perform normal OaM activities. If the user belongs to a CP role and
SystemAdministrator, he can act as an expert user, meaning that is
aware of how the system works and is able to perform advanced OaM activities.
A regular user can open an MML session only in case Cluster Operation Mode

14 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

is set to Normal Mode. Refer to User Guide AXE Equipment Management,


Reference [11], for more information on how to handle Cluster Operation Mode,
and to User Guide Alphanumeric Device Management, Reference [1], for more
information on MML commands handling.

Figure 7 shows an example of MML authority profiles defined in Multi-CP


System.

Figure 7 MML Authority Profile in Multi-CP System

OaM user Eva belongs to CP role CpRole0 that is associated to the whole set
of COCA groups, from 0 to 255, by default. This means Eva is a regular user
that can execute any MML command and access to any DBS table in an MML
session opened in Normal Mode. Similarly, OaM user Bill belongs to CP
roles CpRole1 and CpRole2 so Bill can execute any MML command and
access to any DBS table which COCA group is in the range 2-80 or equal to
90,100; this means that the MML authority profile of user Bill is the union of
authorities associated to each CP role Bill belongs to.

1.4.1.4.3 MML Authority Profile

The creation of the MML authority profile for an OaM user is done through the
MML Authorization function MOM which MmlAuthorizationM is the root MOC.
Figure 8 shows the MML Authorization function MOM.

Figure 8 MML Authorization Function MOM

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 15


User Management

The MOC MmlRole allows to create an MML authority profile consisting of an


association between:

• A predefined CP role and a CP user, in a Single-CP System.

• A predefined CP role and a list of COCA groups, in a Multi-CP System.

The association is done by setting attributes mmlRoleId and mmlProfile in a


new instance of MOC MmlRole. CpRole0 is associated by default to CP user
ADMINISTRATOR, in a Single-CP System, and to COCA groups 0..255, in a
Multi-CP System. This association is not visible in the model and cannot be
changed.
See Section 2.3.1 on page 49 for more information.

1.4.1.5 Authorization in NETCONF Session

The authorization of a OaM user establishing a NETCONF session is based on


authorization rules assigned to roles the user belongs to. Such rules define the
access control to MOs. See Section 3.1 on page 61.

1.4.1.6 Authorization in File Transfer Session

The authorization of a OaM user establishing a FT session is based on


authorization rules assigned to roles the user belongs to. Such rules define the
access control to file system resources like directories and files. See Section
3.1 on page 61.

1.4.1.7 LDAP Server Unavailability

When LDAP server become unavailable, an OaM user is not able to login APG
anymore. In this case one of the following access types can be used:

• A TS user, as per description in Section 1.4.2 on page 16.

• A cached OaM user (if available) is the same OaM user defined on LDAP
server for which password, target and role are temporary cached on APG
so that authentication and authorization is done locally on APG. The
caching capability is disabled by default and can be enabled on demand
by contacting Ericsson customer support. If enabled, caching is performed
for each OaM user successfully logged in APG at least once having LDAP
server connectivity available. Refer to User Guide How to Access an AXE ,
Reference [13], for more information on type of sessions a cached OaM
user can open.
Caching can be enabled only on AP1 either in a Single-APG or in Dual-APG
configuration. So in a Dual-APG configuration accessing to AP2 is not
granted.

16 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

1.4.2 Troubleshooting User Management


Troubleshooting user management refers to the management of TS users
that access to the AXE node to perform advanced troubleshooting operations
in a TS session like first configuration after APG installation or APG recovery
scenarios; refer to User Guide How to Access an AXE , Reference [13], for
more information on how to open a TS session.

TS user can also open AP session, MML session, NETCONF session and FT
session to operate in case of communication problems towards LDAP server.

TS users can also access to the AXE node through a Local Craft Terminal
(LCT) directly connected to APG to execute on-site operations needed in case
of disaster events or Hardware (HW) maintenance. Access through LCT is also
allowed to user root and this is the only way root user can access to APG
being remote login for user root disabled.

1.4.2.1 TS User Policy Management

TS user policy management is handled through the TS User Policy Management


function MOM which LocalTsUsersPolicyM is the root MOC, see Figure 9.

Figure 9 TS User Policy Management Function MOM

That MOC allows specifying the set of security settings for TS users such as
password policies.

1.4.2.2 TS User Accounts Administration

TS user accounts administration is done through AP commands addtsuser,


removetsuser, listtsuser, modtsuser and pwdresettsuser. These
commands are allowed only to the predefined TS administrator user tsadmin
in a TS session except for commands listtsuser and modtsuser which
can be executed by both TS users and tsadmin.

When AP command addtsuser is given the policies for the newly created TS
user specified in MO LocalTsUsersPolicyM apply.

TS administrator user is the only predefined APG account. TS administrator


user password never expires; after three failed login attempts, configured to
have five seconds delay between two failed login attempts, the account is
locked for five minutes and then automatically unlocked. TS administrator user
can only open TS sessions to administer TS user accounts and is not allowed
to open any AP session, MML session, NETCONF session and FT session.

It is very important to assign a strong password to the TS administrator


account. As this account should be used only in exceptional circumstances, the
password should be as complex as possible and, for safety, written down in a
document that is stored in a safe place. It is also important to keep a history of

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 17


User Management

its password changes, because if the system is restored with an old backup,
the passwords are also restored to the passwords that were valid at the time
when the backup was taken.

1.4.2.3 TS Users Authentication and Authorization

TS users authentication and authorization is based on an OS built-in


mechanism using files for storing user and group configuration information. A
TS user establishing a TS session with the AXE node is authenticated locally
through local stored files.

The authentication process also gets the User Identity (UID) and Group
Identity (GID) associated to the user. UIDs and GIDs provide an authorization
mechanism at the individual file level through access permissions RWX that are
set on files, folders and commands.

1.4.2.4 Authorization in TS Session

The authorization of a TS user establishing a TS session is based on


authorization rules to:

• Execute OS commands. All OS commands not requiring root authority are


allowed. It is also possible to switch to root user in case it is needed to
execute OS command with root authority.

• Execute all AP commands.

1.4.2.5 Authorization in AP Session

A TS user can establish an AP session to operate in case of LDAP


communication problems. In such emergency cases TS user has full access
control to all MOs and AP commands.

1.4.2.6 Authorization in MML Session

A TS user can establish a MML session to operate in case of LDAP


communication problems. In such emergency cases the default MML authority
for the TS user depends on type of system and on how TS user has been
created.
In Single-CP System the TS user has the same MML authority of CP user
ADMINISTRATOR, that means able to give all MML commands belonging to
COCA groups 0-64.
In Multi-CP System, the TS user is able to give all MML commands.

It is possible to deny such default MML authority to a TS user as per description


in Section 2.5.1 on page 53.

18 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


General

1.4.2.7 Authorization in NETCONF Session

A TS user can establish a NETCONF session to operate in case of LDAP


communication problems. In such emergency cases TS user has full access
control to all MOs.

1.4.2.8 Authorization in File Transfer session

A TS user can establish a FT session to operate in case of LDAP communication


problems. In such emergency cases TS user has full access control to all files
and folders.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 19


User Management

20 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

2 How to use

2.1 First APG Configuration


This section and related sub-sections describe how to configure the APG(s)
as LDAP client during the first APG configuration.

The communication between APG(s) and LDAP server is a trusted and secured
connection relying on CA trusted certificate, node credential and LDAP server
certificate. Such communication is encrypted enabling LDAP over SSL
(LDAPS).

Note: Creation and installation of LDAP server certificate is out of scope from
this document, as it does not require any configuration on APG.

The LDAP server is included in the Ericsson OSS and respective configuration
is described in User Guide Node Centralized User Management
Integration Guide for OSS-RC, Reference [17].
However it is also possible to use an own LDAP server within the customer
network in case a non Ericsson OSS is used; see Section 3.2 on page 72 for
more information on how to configure it.

First APG configuration consists of the following steps:

1. Ask network security administrator for obtaining CA trusted certificate(s)


depending on chosen enrollment procedure and number of APGs.

2. Ask network security administrator for obtaining node credential(s)


depending on chosen enrollment procedure and number of APGs.

3. Create a TS user account. This is done by TS administrator user that is


the only user able to log in to APG after installation. See Section 2.5.1
on page 53.

4. Install CA trusted certificate(s), using an AP session with TS user


credentials. See Section 2.1.1 on page 21.

5. Install APG node credential(s), using an AP session with TS user


credentials.

• See Section 2.1.2 on page 24 for offline enrollment procedure.

• See Section 2.1.3 on page 26 for online enrollment procedure.

6. Configure APG as LDAP Client using an AP session with TS user


credentials. See Section 2.1.4 on page 29.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 21


User Management

2.1.1 Install CA Trusted Certificate

Depending on the network configuration and the chosen enrollment procedure,


one or two CA trusted certificates must be installed.

• Only the CA trusted certificate for LDAP server, in case of offline enrollment
procedure.

• The CA trusted certificate for LDAP server and the CA trusted certificate
for the server, supporting the protocol CMPv2 IAK, acting as enrollment
server, in case of online enrollment procedure.

Once the CA trusted certificate(s) are obtained, it has to be transferred to the


APG file system on folder /certificates; refer to Operational Instruction
AP, File, Transfer, Reference [6], for more details.

To install a CA trusted certificate, the action installTrustedCertFromUri in CertM


MO is used specifying the input parameters described in Page 22. The action
creates a new TrustedCertificate MO with certificateContent attribute filled out
according to the content of the installed certificate file.

Table 1 Parameters of the Action installTrustedCertFromUri


Parameter Description
uri It is the Uniform Resource Identifier (URI) for the
name of CA trusted certificate file.
The CA trusted certificate file must be stored into
folder certificates of APG file system or in
some of its sub-folders. It should be expressed in
the form:
file:///certificates/[<sub
folder>/]<certificate name>.
uriPassword It is the URI password. It has to be set to NULL
string.
fingerprint It is the fingerprint. It has to be set to NULL string.

After the installation of the CA trusted certificate for LDAP server, either offline
or online enrollment procedure, a TrustCategory MO has to be created with the
attribute trustedCertificates valued to the DN of the MO representing
the CA trusted certificate for LDAP server. This MO is used during procedure
for configuring APG as LDAP client, see Section 3.2 on page 72 for more
information.

Note: Creation of TrustCategory MO is not required after the installation of


the CA trusted certificate for the enrollment server.

The Operational Instruction AP, Certification Authority Trusted Certificate and


Node Credential, Install, Reference [2], describes the procedure to install a CA
trusted certificate on APG(s).

22 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

2.1.1.1 Example - Offline Enrollment

This example shows how to install the CA trusted certificate for LDAP server,
cacert.pem, in case of offline enrollment procedure.

The file cacert.pem is expected to be into folder /certificates on APG


file system. A TS user logged into an AP session is required.
>show
ManagedElement=CEMSS07
>configure
(config)>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1
(config-CertM=1)>installTrustedCertFromUri cacert.pem NULL NULL
true
(config-CertM=1)>show
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
additionalInfo
"TrustedCertificate=1"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2012-10-17T11:34:56"
timeActionStarted="2012-10-17T11:34:56"
timeOfLastStatusUpdate="2012-10-29T21:34:52"
CertMCapabilities=1
TrustedCertificate=1
(config-CertM=1)>TrustCategory=1
(config-TrustCategory=1)>trustedCertificates="ManagedElement=CEMSS07,SystemFunctions=1,SecM=
(config-TrustCategory=1)>commit
(TrustCategory=1)>

2.1.1.2 Example - Online Enrollment

This example shows how to install the CA trusted certificate for LDAP
server, cacert.pem, and the CA trusted certificate for enrollment server,
enrollmentCacert.pem, in case of online enrollment procedure.

The files cacert.pem and enrollmentCacert.pem are expected to be


into folder /certificates on APG file system. A TS user logged into an
AP session is required.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 23


User Management

>show
ManagedElement=CEMSS07
>configure
(config)>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1
(config-CertM=1)>installTrustedCertFromUri cacert.pem NULL NULL
true
(config-CertM=1)>show
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
additionalInfo
"TrustedCertificate=1"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2012-10-17T11:34:56"
timeActionStarted="2012-10-17T11:34:56"
timeOfLastStatusUpdate="2012-10-29T21:34:52"
CertMCapabilities=1
TrustedCertificate=1
(config-CertM=1)>TrustCategory=1
(config-TrustCategory=1)>trustedCertificates="ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,C
(config-TrustCategory=1)>commit -s
(config-TrustCategory=1)>up
(config-CertM=1)>installTrustedCertFromUri enrollmentCacert.pem NULL NULL
true
(config-CertM=1)>show
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
additionalInfo
"TrustedCertificate=2"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2015-02-19T16:44:44Z"
timeActionStarted="2015-02-19T16:44:44Z"
timeOfLastStatusUpdate="2015-02-19T16:44:44Z"
CertMCapabilities=1
TrustCategory=1
TrustedCertificate=1
TrustedCertificate=2
(config-CertM=1)>

2.1.2 Install Node Credential via Offline Enrollment Procedure

Node credential is provided through PKCS#12 container file. Once the


PKCS#12 file is obtained, it has to be uploaded on the APG file system, on
folder /certificates; refer to Operational Instruction AP, File, Transfer,
Reference [6], for more details.

To install the node credential via offline enrollment procedure, a new


NodeCredential MO under CertM=1 MO has to be created, leaving the attribute
subjectName empty. After that, the action installCredentialFromUri under newly
created NodeCredential MO has to be executed with parameters listed in
Table 2.

24 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

Note: The attribute subjectName can be either left empty or filled with X.501
DN, used as subject field when certificate has been created.

Table 2 Parameters of the Action installCredentialFromUri


Parameter Description
uri It is the URL for the name of PKCS#12 container file.
The PKCS#12 container file must be stored into folder
certificates of APG file system or in some of its
sub-folders. It should be expressed in the form:
file:///certificates/[<sub folder>/]<PK
CS#12 file name>.
uriPassword It is the URI password. It has to be set to NULL string.
credentialPassw It is the password for decrypting the PKCS#12
ord container file.
fingerprint It is the fingerprint. It has to be set to NULL string.

The Operational Instruction AP, Certification Authority Trusted Certificate and


Node Credential, Install, Reference [2], describes the procedure to install a
node credential on APG(s) with offline enrollment procedure.

2.1.2.1 Example

This example shows how to install the node credential certificate file
cert.p12 with ericsson as credentialPassword parameter value. The
file has to be expected into folder /certificates on APG file system. A TS
user logged into an AP session is required.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 25


User Management

>show
ManagedElement=CEMSS07
>configure
(config)>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1
(config-CertM=1)>show
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=1
actionName="SystemCreated"
result=SUCCESS
resultInfo=""
state=FINISHED
timeActionCompleted="2012-10-17T11:34:56"
timeActionStarted="2012-10-17T11:34:56"
timeOfLastStatusUpdate="2012-10-29T21:34:52"
CertMCapabilities=1
TrustedCertificate=1
(config-CertM=1)>NodeCredential=1
(config-NodeCredential=1)>commit -s
(config-NodeCredential=1)>installCredentialFromUri cert.p12 NULL ericsson NULL
true
(config-NodeCredential=1)>up
(config-CertM=1)>show
localFileStorePath="certificates"
userLabel="Certificate Management"
userLabel="SystemCreated"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
additionalInfo
"TrustedCertificate=1"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2012-10-17T11:34:56"
timeActionStarted="2012-10-17T11:34:56"
timeOfLastStatusUpdate="2012-10-29T21:34:52"
CertMCapabilities=1
TrustedCertificate=1
NodeCredential=1
(config-CertM=1)>

2.1.3 Install Node Credential via Online Enrollment Procedure


The online enrollment procedure for node credential installation requires an
enrollment server supporting the CMPv2 IAK protocol. If this server is part of
Ericsson OSS refer to User Guide Node Centralized User Management
Integration Guide for OSS-RC, Reference [17], for more details.

Note: The online enrollment of node credential certificate for APG is supported
from Ericsson OSS-RC 16A and ENM 16B releases onwards.

As preliminary configuration, an EnrollmentAuthority MO with an


EnrollmentServerGroup MO and at least one EnrollmentServer MO must be
created.

The EnrollmentAuthority MO should be created under CertM=1 MO by


setting the attribute enrollmentCaCertificate with the DN of an existing
TrustedCertificate MO representing the CA trusted certificate for the online
enrollment server as per procedure described in Section 2.1.1 on page 21.

26 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

The EnrollmentServerGroup MO should be created under CertM=1 MO and


a new EnrollmentServer MO should be created in it, by setting the attributes
protocol and uri. The enrollmentAuthority attribute has to be set
to the DN of the previously created EnrollmentAuthority MO; the protocol
attribute has to be set to value CMP, that is the protocol type used for online
enrollment; the uri attribute has to be set according the enrollment server
configuration.

Once the EnrollmentServerGroup MO has been defined, a NodeCredential MO


under CertM=1 MO should be created by setting the attributes listed in Table 3.

Table 3 NodeCredential MOC Main Attributes


Attribute Description
enrollmentAuthorit It is the DN of the previously created
y EnrollmentAuthority MO used for online
enrollment.
enrollmentServerGr It is the DN of the EnrollmentServerGroup MO
oup representing the enrollment server group used for
online enrollment.
expiryAlarmThresho It is the number of days used to calculate the date
ld (optional) of the alarm indicating the coming expiry of the
certificate.
The alarm severity is raised to MINOR, A3, in
case the remaining time to expiry is reduced to the
one third of the configured threshold.
The alarm severity is raised to MAJOR,A2, in case
the remaining time to expiry is reduced to the one
tenth of the configured threshold or one week.
The alarm is cleared and a certificate not available
alarm is raised when the certificate expires.
See Section 2.6.1 on page 59 for more information.
Default value is 30 days.
keyInfo It is the key type and length that is used for the
enrollment.
E.g. It should be expressed in the form:
RSA_2048, that corresponds to 2048-bit long
key generated for the Rivest Shamir Adleman
(RSA) algorithm.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 27


User Management

renewalMode It is the node credential certificate renewal mode


(optional) for online enrollment.
If configured to AUTOMATIC, no manual action is
required for renewal. This is the recommended
setting.
Default value is MANUAL.
subjectName It is the X.501 DN to be used in the subject field of
the requested certificate.

Finally, to initiate the online enrollment procedure the action


startOnlineEnrollment under NodeCredential MO should be run by
specifying the initial shared password between APG and the CA enrollment
server.

The Operational Instruction AP, Certification Authority Trusted Certificate and


Node Credential, Install, Reference [2], describes the whole procedure to install
a node credential on APG(s) via online enrollment procedure.

2.1.3.1 Example

This example shows how to install the node credential via online enrollment
procedure. A CA trusted certificate for the enrollment server represented by
TrustedCertificate=2 MO is already installed on APG; the URI for the enrollment
server is http://141.137.47.159:8080/ejbca/publicweb/cmp; while
mypassword is the password used to exchange the node credential certificate
with the server. Automatic certificate renewal mode is set. A TS user logged
into an AP session is required.

28 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

>show
ManagedElement=CEMSS07
>configure
(config)>ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1
(config-CertM=1)>EnrollmentAuthority=1
(config-EnrollmentAuthority=1)>enrollmentCaCertificate="ManagedElement=CEMSS07,SystemFunctio
(config-EnrollmentAuthority=1)>commit -s
(config-EnrollmentAuthority=1)>up
(config-CertM=1)>EnrollmentServerGroup=1
(config-EnrollmentServerGroup=1)>commit -s
(config-EnrollmentServerGroup=1)>EnrollmentServer=1
(config-EnrollmentServer=1)>protocol=CMP
(config-EnrollmentServer=1)>uri="http://141.137.47.159:8080/ejbca/publicweb/cmp"
(config-EnrollmentServer=1)>commit -s
(config-EnrollmentServer=1)>top
(config)>ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1,NodeCredential=1
(config-NodeCredential=1)>enrollmentAuthority="ManagedElement=CEMSS07,SystemFunctions=1,SecM
(config-NodeCredential=1)>enrollmentServerGroup="ManagedElement=CEMSS07,SystemFunctions=1,Se
(config-NodeCredential=1)>subjectName="CN=node123,OU=apg,O=ericsson,L=pagani,ST=italia,C=IT"
(config-NodeCredential=1)>keyInfo=RSA_2048
(config-NodeCredential=1)>renewalMode=AUTOMATIC
(config-NodeCredential=1)>commit -s
(config-NodeCredential=1)>startOnlineEnrollment mypassword
true
(config-NodeCredential=1)>show
NodeCredential=1
certificateState=VALID
enrollmentAuthority="ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1,EnrollmentAu
enrollmentServerGroup="ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1,Enrollment
keyInfo=RSA_2048
renewalMode=AUTOMATIC
subjectName="CN=CEMSS07"
certificateContent="CN=CEMSS07"
extensionContent
"X509v3 Authority Key Identifier:keyid:E8:07:E5:0F:0A:6E:B7:8B:80:D9:5E:E4:9A:4B:A0
"X509v3 Basic Constraints:CA:FALSE"
"X509v3 Extended Key Usage:TLS Web Client Authentication, E-mail Protection"
"X509v3 Key Usage:Digital Signature, Non Repudiation, Key Encipherment"
"X509v3 Subject Alternative Name:DNS:CEMSS07.eri.ericsson.se"
"X509v3 Subject Key Identifier:FF:7F:C2:4C:DF:43:A3:61:69:8D:BA:EC:2A:7E:C1:38:08:1
issuer="C=SE,O=EJBCA Sample,CN=AdminCA1"
keyUsage="Digital Signature, Non Repudiation, Key Encipherment"
publicKey="C5:76:E8:84:EB:BF:13:90:68:40:E4:B3:1E:0E:EA:AF:06:DF:89:B2:45:6E:6A:16:DA:
publicKeyAlgorithm="RSA"
serialNumber="5C:FF:AC:B4:35:7F:F9:A2"
signatureAlgorithm="sha1WithRSAEncryption"
validFrom="2015-02-19T14:41:09Z"
validTo="2017-02-18T14:41:09Z"
version="Version 3"
enrollmentProgress
actionId=0
actionName="startOnlineEnrollment"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the online service"
state=FINISHED
timeActionCompleted="2015-02-19T17:42:10Z"
timeActionStarted="2015-02-19T17:42:09Z"
timeOfLastStatusUpdate="2015-02-19T17:42:10Z"
(config-NodeCredential=1)>

2.1.4 Configure APG as LDAP Client

This section describes how to configure the APG as LDAP client in order to
establish a secure connection with the LDAP server once CA trusted certificate
and APG node credential have been installed as per, Section 2.1.1 on page 21
and Section 2.1.3 on page 26.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 29


User Management

The procedure applies for each connected APG, in a Single-APG or Dual-APG


configuration.

In Ericsson OSS LDAP server, anonymous binding is disabled. APG must be


configured to use a proxy agent account to bind to the LDAP naming service.
In case of non Ericsson OSS LDAP server the proxy agent account might be
optional.
A proxy agent is a special type of account with read-only privileges. The
purpose of the proxy agent account is to ensure that APG is using an account
that is trusted by the LDAP server. The proxy agent account is referred to as
the bind DN. Whenever an attempt is made to search the LDAP naming service
the proxy agent account is used to bind to the directory service to perform the
search. For example, when a user attempts to log in to APG, the proxy agent
account is used to perform the search for the user details in the LDAP server
and then returns the details to APG.

The attributes in the MO Ldap=1, see Table 4, should be set in accordance


with the LDAP server configuration.

Table 4 Ldap MOC Attributes


Attribute Description
baseDn It is the base DN to use when performing LDAP
operations; it is the root, within the LDAP server
directory schema, where users and groups are
defined. The base DN must be specified in an LDAP
DN format, for example: dc=example,dc=com.
bindDn (optional) It is the bind DN to use for the proxy agent
authentication towards the LDAP server.
bindPassword It is the password to use for the proxy agent
(optional) authentication towards the LDAP server.
ldapIpAddress It is the IP address of the primary LDAP server.
fallbackLdapIpAddre It is the IP address of the fallback LDAP server to be
ss (optional) used when the primary one is not reachable.
In a Dual-APG configuration, where AP2 is not
connected to the customer OaM network and the
user authentication is performed using LDAP server
information of AP1, the fallback LDAP server is not
used so user authentication fails on such AP2 if
primary LDAP server is not reachable.
nodeCredential The node credential certificate used for authenticating
APG against the LDAP server. It specifies the DN of a
NodeCredential MO previously created in Certificate
Management function MOM as per Section 2.1.2 on
page 24, in case of offline enrollment, or Section 2.1.3
on page 26, in case of online enrollment.

30 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

trustCategory The set of CA certificate(s) trusting the APG and


LDAP server. It specifies the DN of the TrustCategory
MO previously created in Certificate Management
function MOM as per Section 2.1.1 on page 21.
useReferrals (false It can be set to true/false to enable/disable LDAP
by default) referral mechanism. When set to true, the ME follows
referrals. Referrals can be used for authentication
and authorization only if the referral URI refers back
to a directory tree within the same LDAP server
instance; otherwise, access is denied for referred
user accounts.
Referral mechanism is used to support Multi-OSS
(MOSS) with global domain handling. The User Guide
COMInf SUN Directory Server, System,
Reference [18], provides more details on such
handling.
nodeType It is marked as deprecated in the sense that it is still
(deprecated) supported. The usage of the attribute targetType, see
Table 6, is recommended for new settings or changes
into node target list.

Note: The Ericsson OSS LDAP server is able to interwork with APG
either using the FQDN or the IP address; such information is set
into the attributes ldapIpAddress, for primary LDAP server, and
fallbackLdapIpAddress, for fallback LDAP server. In case FQDN is
used, also the AP command ldapdef must be given to allow APG to
resolve FQDN with corresponding IP address.
The use of IP addresses is always recommended with the Ericsson
OSS LDAP server in case the support of MOSS is enabled; in such
case the AP command ldapdef is not needed.

The attributes in MOC EricssonFilter, see Table 5, should be set depending on


customer user management profile.

Table 5 EricssonFilter MOC Attributes


Attribute Description
roleAliasesBaseDn It is the base DN used to store role alias information, if
(optional) it is handled into LDAP server. The role alias base DN
must be specified in an LDAP DN format. For example
ou=rolealias,ou=com,dc=example,dc=com.
version It selects the Ericsson filtering behavior of qualified
and not qualified roles for the user authorization.
Its default value is 1 for new APG installation or
Operating System Upgrade (OSU). It is recommended
to be set to 2.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 31


User Management

The attribute targetType in the MO UserManagement=1, see Table 6, is


required to be set in accordance with the target types of customer network.

Table 6 UserManagement MOC Attributes


Attribute Description
targetType It is the node target list that must at least contain the
value of attribute managedElementId of the AXE ME.
The targets stored in this list must correspond exactly
(including case) to the corresponding targets used
in the LDAP server for granting access. If the user
target list in the LDAP server is “BSC” and the node
target list contains “bSC” then they are not considered
to be equal.

Note: In a Dual-APG configuration, in case AP2 is not connected to


customer OaM network, only the attributes baseDn, see Table 4, and
targetType, see Table 6, should be set on AP2. The same base DN
value used for AP1 must be used for AP2 as well.

Finally, the attribute administrativeState in the MO LdapAuthenticationMethod=1


is required to be set for enabling the centralized user authentication via LDAP
server.

The Operational Instruction AP, LDAP Client, Configure, Reference [7],


describes the actions to configure APG(s) as LDAP client in both cases after
first installation and when an LDAP server parameter changes.

2.1.4.1 Example

This example shows how to configure an APG named CEMSS07 as


LDAP client of a primary LDAP server having the pair 10.44.77.13,
atclvm101.athtem.eei.ericsson.se as IP address and FQDN, and the
pair 10.44.77.16, atclvm102.athtem.eei.ericsson.se as fallback
LDAP server IP address and FQDN. CA trusted certificate, represented
by a TrustedCertificate MO with TrustedCertificateId=1,
and APG node credential, represented by a NodeCredential MO with
NodeCredentialId=1, are used to establish a secure connection with that
LDAP server. The LDAP servers are configured to have dc=example,dc=com
as base DN and ou=rolealias,ou=com,dc=example,dc=com as role
aliases base DN. OSS customer network supports global domain handling.
A TS user logged into an AP session is required.

32 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,UserManagement=1,LdapAuthenticationMetho
(Ldap=1)>config
(config-Ldap=1)>baseDn="dc=example,dc=com"
(config-Ldap=1)>bindDn="cn=comproxy,ou=proxyagent,ou=com,dc=example,dc=com"
(config-Ldap=1)>bindPassword=Password cleartext
(config-Ldap=1)>ldapIpAddress=10.44.77.13
(config-Ldap=1)>fallbackldapIpAddress=10.44.77.16
(config-Ldap=1)>useReferrals=true
(config-Ldap=1)>trustCategory="ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1,Trust
(config-Ldap=1)>nodeCredential="ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1,Node
(config-Ldap=1)>EricssonFilter=1
(config-EricssonFilter=1)>roleAliasesBaseDn="ou=rolealias,ou=com,dc=example,dc=com"
(config-EricssonFilter=1)>version=2
(config-EricssonFilter=1)>up
(config-Ldap=1)>up
(config-LdapAuthenticationMethod=1)>up
(config-UserManagement=1)>targetType="CEMSS07,BSC,London"
(config-UserManagement=1)>LdapAuthenticationMethod=1
(config-LdapAuthenticationMethod=1)>administrativeState=UNLOCKED
(config-UserManagement=1)>commit
(UserManagement=1)>

2.2 LDAP Certificates Administration


Administration of LDAP certificates means:

• Remove CA trusted certificates and APG node credentials. See Section


2.2.1 on page 33 and Section 2.2.2 on page 35.

• Certificate supervision. See Section 2.2.3 on page 36.

• Renew an APG node credential. See Section 2.2.4 on page 36.

Note: Renewal of CA trusted certificates is out of scope from this


document. The customer network security administrator should
ensure to introduce new CA trusted certificates, when they expire,
preserving uninterrupted OaM connectivity.

• Change node credential enrollment procedure. See Section 2.2.5 on page


39.

2.2.1 Remove CA Trusted Certificate


A CA trusted certificate, not in use anymore, can be removed.

To remove the CA trusted certificate, the action removeTrustedCert under the


CertM MO should be used.

The Operational Instruction AP, Certification Authority Trusted Certificate and


Node Credential, Remove, Reference [3], describes the procedure to remove
the CA trusted certificate.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 33


User Management

2.2.1.1 Example

This example removes a CA trusted certificate represented by MO


TrustedCertificate=1, in case that it is the CA trusted certificate of the
LDAP server

>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1
(CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
additionalInfo
"TrustedCertificate=3"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2015-05-17T13:21:44Z"
timeActionStarted="2015-05-17T13:21:44Z"
timeOfLastStatusUpdate="2015-05-17T13:21:44Z"
CertMCapabilities=1
EnrollmentAuthority=1
EnrollmentServerGroup=1
NodeCredential=1
TrustCategory=1
TrustedCertificate=1
TrustedCertificate=2
(config-CertM=1)>TrustCategory=1
(config-TrustCategory=1)>show
TrustCategory=1
trustedCertificates
"ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustedCertificate=1"
((config-TrustCategory=1)>up
(config-CertM=1)>up
(config-SecM=1)>UserManagement=1
(config-UserManagement=1)>LdapAuthenticationMethod=1
(config-LdapAuthenticationMethod=1)>Ldap=1
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:XG2Kghp80VE1KR/3493KwYr1zKRgS+cA"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,NodeCredential=
nodeType
"apg.pagani"
profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory=1"
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>no trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,
(config-Ldap=1)>commit -s
(config-Ldap=1)>up
(config-LdapAuthenticationMethod=1)>up
(config-UserManagement=1)>up
(config-CertM=1)>no TrustCategory=1
(config-CertM=1)>commit -s
(config-CertM=1)>removeTrustedCert TrustedCertificate=1
true
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"

34 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

reportProgress
actionId=0
actionName="removeTrustedCert"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="the TrustedCertificate instance removed"
state=FINISHED
timeActionCompleted="2015-06-22T15:33:05Z"
timeActionStarted="2015-05-17T13:21:44Z"
timeOfLastStatusUpdate="2015-06-22T15:33:05Z"
CertMCapabilities=1
EnrollmentAuthority=1
EnrollmentServerGroup=1
NodeCredential=1
TrustedCertificate=2
(config-CertM=1)>

2.2.2 Remove Node Credential


An APG node credential, not in use anymore, can be removed.

The Operational Instruction AP, Certification Authority Trusted Certificate and


Node Credential, Remove, Reference [3], describes the procedure to remove a
node credential.

2.2.2.1 Example

This example removes node credential which is represented by MO


NodeCredential=1, that represents the node credential certificate used for
the LDAP authentication.
>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,UserManagement=1,LdapAuthenticationMetho
(CertM=1)config
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,NodeCredenti
nodeType
"MSCALL"
profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>no nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,Cert
(config-Ldap=1)>commit -s
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeType
"MSCALL"

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 35


User Management

profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory=1"
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>up
(config-LdapAuthenticationMethod=1)>up
(config-UserManagement=1)>up
(config-SecM=1)>CertM=1
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2015-06-19T15:42:51Z"
timeActionStarted="2015-05-27T09:28:50Z"
timeOfLastStatusUpdate="2015-06-19T15:42:51Z"
CertMCapabilities=1
NodeCredential=1
TrustCategory=1
TrustedCertificate=1
(config-CertM=1)>no NodeCredential=1
(config-CertM=1)>commit -s
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2015-06-19T15:42:51Z"
timeActionStarted="2015-05-27T09:28:50Z"
timeOfLastStatusUpdate="2015-06-19T15:42:51Z"
CertMCapabilities=1
TrustCategory=1
TrustedCertificate=1
(config-CertM=1)>

2.2.3 Certificate Supervision


APG supervises the validity of the node credential certificate helping customer
to be informed in advance when it is going to expire or it is expired.
APG does not monitor CA trusted certificates and their supervision and renewal
is left to customer network security administrator and related procedure is out of
scope of this document.

See Section 2.6.1 on page 59 for more information.

36 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

2.2.4 Renewal of Node Credential

2.2.4.1 Offline Enrollment Procedure

A being expired APG node credential, originally installed via offline enrollment
procedure, can be renewed.

The new APG node credential should be first uploaded on the APG file system,
in the folder /certificates; refer to Operational Instruction AP, File,
Transfer, Reference [6], for more details.

To renew the node credential, the action installCredentialFromUri in the MO


NodeCredential, representing the being renewed certificate, can be executed
using input parameters listed in Table 7.

Table 7 Parameters of the Action installCredentialFromUri


Parameter Description
uri It is the name of PKCS#12 container file.
The PKCS#12 container file must be stored
into folder certificates of APG file
system or in some of its sub-folders. If the
specified PKCS#12 container file is located
in folder certificates, the name of the
file should be specified. If the specified
certificate is stored in a sub-folder, the full
path should be specified in the form:
file:///certificates/<sub
folder>/<PKCS#12 file name>.
uriPassword It is the password for container file and it has
to be set to NULL string.
credentialPassword It is the password for decrypting the
PKCS#12 container file.
fingerprint It is the fingerprint and it has to be set to
NULL string.

The Operational Instruction AP, Node Credential Renewal, Initiate, Reference


[8], describes the procedure to renew a node credential.

In case a node credential is being expired the alarm AP, CERTIFICATE


MANAGEMENT, FAULT with problem text CERTIFICATE IS ABOUT TO
EXPIRE is raised, see Section 2.6.1 on page 59 for more information.

2.2.4.1.1 Example

This example shows how to renew a node credential, originally installed via
offline enrollment procedure.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 37


User Management

>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1
(CertM=1)>show
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
additionalInfo
"TrustedCertificate=1"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2015-03-04T14:17:32Z"
timeActionStarted="2015-03-04T14:17:32Z"
timeOfLastStatusUpdate="2015-03-04T14:17:32Z"
CertMCapabilities=1
NodeCredential=1
TrustCategory=1
TrustedCertificate=1
(CertM=1)>NodeCredential=1
(NodeCredential=1)>installCredentialFromUri cert.p12 NULL ericsson NULL
true
(NodeCredential=1)>

2.2.4.2 Online Enrollment Procedure

A being expired APG node credential, originally installed via online enrollment
procedure, can be renewed. This can be achieved via manual or automatic
procedure depending on the value of attribute renewalMode.

In case the attribute renewalMode is equal to AUTOMATIC, the renewal of the


node credential certificate starts automatically before the certificate is going to
expire according to the formula:

renewal time = CertTime - Threshold - 7 days

Where:

• CertTime is the node credential certificate expiry date as per sub-attribute


validTo in the attribute certificateContent.

• Threshold is the numbers of days defined in the attribute


expiryAlarmThreshold.

In case the automatic renewal fails the alarm AP, CERTIFICATE


MANAGEMENT, FAULT with problem text ONLINE CERTIFICATE
ENROLLMENT OR RENEWAL FAILED is raised, see Section 2.6.1 on page 59
for more information.

In case the attribute renewalMode is equal to MANUAL the action


startOnlineEnrollment in MO NodeCredential has to be manually
executed; the Operational Instruction AP, Node Credential Renewal, Initiate,
Reference [8], describes the procedure to renew a node credential.

38 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

In case the node credential is being expired the alarm AP, CERTIFICATE
MANAGEMENT, FAULT with problem text CERTIFICATE IS ABOUT TO
EXPIRE is raised, see Section 2.6.1 on page 59 for more information.

2.2.4.2.1 Example

This example shows how to renew a node credential, originally installed


via online enrollment procedure, in case the manual renewal procedure is
configured, that means having the attribute renewalMode equal to MANUAL.
>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1,NodeCredential=1
(NodeCredential=1)>startOnlineEnrollment NULL
true
(NodeCredential=1)>show
NodeCredential=1
certificateState=VALID
enrollmentAuthority="ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1,EnrollmentAu
enrollmentServerGroup="ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1,Enrollment
keyInfo=RSA_2048
subjectName="CN=CEMSS07"
certificateContent="CN=CEMSS07"
extensionContent
"X509v3 Authority Key Identifier:keyid:E8:07:E5:0F:0A:6E:B7:8B:80:D9:5E:E4:9A:4B:A0
"X509v3 Basic Constraints:CA:FALSE"
"X509v3 Extended Key Usage:TLS Web Client Authentication"
"X509v3 Key Usage:Digital Signature, Non Repudiation, Key Encipherment"
"X509v3 Subject Key Identifier:5F:92:59:B4:91:53:8B:01:84:A7:13:E7:53:F2:98:2D:1B:F
issuer="C=SE,O=EJBCA Sample,CN=AdminCA1"
keyUsage="Digital Signature, Non Repudiation, Key Encipherment"
publicKey="AD:7D:EF:ED:5F:53:7D:5F:3F:95:8E:D3:2E:12:E1:A6:1E:EA:7C:F9:A6:83:B4:EC:8C:
publicKeyAlgorithm="RSA"
serialNumber="58:83:5D:41:2F:B5:02:23"
signatureAlgorithm="sha1WithRSAEncryption"
validFrom="2015-04-15T07:17:01Z"
validTo="2017-04-15T07:17:01Z"
version="Version 3"
enrollmentProgress
actionId=0
actionName="startOnlineEnrollment"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the online service"
state=FINISHED
timeActionCompleted="2015-04-15T08:38:39Z"
timeActionStarted="2015-04-15T08:38:38Z"
timeOfLastStatusUpdate="2015-04-15T08:38:39Z"
(NodeCredential=1)>

2.2.5 Change Node Credential Enrollment Procedure


From Offline to Online

The enrollment procedure for an APG node credential certificate can be


changed from offline to online so to allow its automatic renewal.

To do that following logical steps should be performed:

• Configure and make available into APG network a CA enrollment server.


This is to be secured by customer network security administrator.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 39


User Management

• Identify the node credential certificate, originally installed via offline


enrollment procedure, and remove it as per procedure described in Section
2.2.2 on page 35.

• Obtain the CA trusted certificate for the CA enrollment server and install it,
as per procedure described in Section 2.1.1 on page 21.

• Install node credential certificate via online enrollment procedure, as per


procedure described in Section 2.1.3 on page 26 .

• Modify APG configuration to use the new installed certificates, as per


procedure described in Section 2.1.4 on page 29.

Note: These steps require TS user credentials.

The Operational Instruction AP, Certificate Management, Node Credential


Enrollment Procedure, Change, Reference [4], describes in details how to
change the enrollment procedure from offline to online assuming that the being
used LDAP server is still the same.
If LDAP server parameters change, for example its IP address, then an APG
reconfiguration is required, as described in Section 2.1.4 on page 29, and
existing certificates should be removed first.

From Online to Offline

The enrollment procedure for an APG node credential certificate can be


changed from online to offline, but in this case it is not allow the automatic
renewal, only the manual renewal, of the node credential certificate.

To do that following logical steps should be performed:

• Identify the node credential certificate, originally installed via online


enrollment procedure, and remove it as per procedure described in Section
2.2.2 on page 35.

• Remove the CA trusted certificate for the CA enrollment server as per


procedure described in Section 2.2.1 on page 33

• Remove the attributes associated with online enrollment procedure,


enrollment authority, enrollment server group and enrollment server.

• Install node credential certificate via offline enrollment procedure, as per


procedure described in Section 2.1.3 on page 26 .

• Modify APG configuration to use the new installed certificates, as per


procedure described in Section 2.1.4 on page 29.

Note: These steps require TS user credentials.

The Operational Instruction AP, Certificate Management, Node Credential


Enrollment Procedure, Change, Reference [4], describes in details how to
change the enrollment procedure from online to offline assuming that the being
used LDAP server is still the same.

40 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

If LDAP server parameters change, for example its IP address, then an APG
reconfiguration is required, as described in Section 2.1.4 on page 29, and
existing certificates should be removed first.

2.2.5.1 Example - From Offline to Online

This example show how change node credential enrollment procedure from
offline to online in case of LDAP server is the same used in the initial offline
procedure.
The information related to CA enrollment server and the related CA trusted
certificate and node credential are required as input. In this example they are:

• CA trusted certificate for enrollment server: Enrollmentcacert.pem.

• Key type and length of the algorithm used to create the certificate:
RSA_2048.

• Subject name: CN=opi3.

• CA enrollment server URI: http://141.137.47.159:8080/ejbca


/publicweb/cmp.

• Password needed to interact with the CA enrollment server to obtain the


node credential certificate via protocol: password.

The CA trusted certificate for LDAP server is already installed on APG and it is
represented by MO TrustedCertificate=1 MO.

First the reference of node credential from LDAP configuration, as per


value of attribute nodeCredential, is removed under MO Ldap=1. Then the
node credential certificate can be removed from APG by removing the MO
NodeCredential=1 under CertM=1.

Afterwards, the trusted certificate for CA enrollment server, represented by


file Enrollmentcacert.pem, is installed and TrustedCertificate=2
is the MO representing it. Procedure requires to create the MO
EnrollmentAuthority=1 and to assign the DN of being installed trusted
certificate to attribute enrollmentCaCertificate.
The EnrollmentServerGroup=1 and EnrollmentServer=1 are also created
to host all information related to CA enrollment server.

Then a new node credential certificate is installed via online procedure by


using the action startOnlineEnrollment, after creating a NodeCredential=1
MO having the previously created EnrollmentAuthority=1 and
EnrollmentServerGroup=1 as reference, and setting the subject name,
CN=opi3, into attribute subjectName, the algorithm type used to create
the certificate, RSA_2048, into attribute keyInfo, and the renewal mode,
AUTOMATIC, into attribute renewalMode.

Finally, the installed node credential certificate represented by


NodeCredential=1 MO is associated to APG LDAP configuration by setting
the attribute nodeCredential to related DN.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 41


User Management

>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,UserManagement=1,LdapAuthenticationMethod=1
(Ldap=1)>configure
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,NodeCredential=
nodeType
"MSCALL"
profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory=1"
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>no nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1
(config-Ldap=1)>commit -s
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeType
"MSCALL"
profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory=1"
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>up
(config-LdapAuthenticationMethod=1)>up
(config-UserManagement=1)>up
(config-SecM=1)>CertM=1
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
additionalInfo
"TrustedCertificate=1"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2015-05-12T10:14:54Z"
timeActionStarted="2015-05-12T10:14:54Z"
timeOfLastStatusUpdate="2015-05-12T10:14:54Z"
CertMCapabilities=1
NodeCredential=1
TrustCategory=1
TrustedCertificate=1
(config-CertM=1)>no NodeCredential=1
(config-CertM=1)>commit -s
(config-CertM=1)>installTrustedCertFromUri Enrollmentcacert.pem NULL NULL
true
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0

42 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

actionName="installTrustedCertFromUri"
additionalInfo
"TrustedCertificate=2"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2015-06-09T16:18:00Z"
timeActionStarted="2015-06-09T16:18:00Z"
timeOfLastStatusUpdate="2015-06-09T16:18:00Z"
CertMCapabilities=1
TrustCategory=1
TrustedCertificate=1
TrustedCertificate=2
(config-CertM=1)>TrustedCertificate=2
(config-TrustedCertificate=2)>show
TrustedCertificate=2
certificateState=VALID
certificateContent="C=SE,O=EJBCA Sample,CN=AdminCA1"
extensionContent
"X509v3 Authority Key Identifier:keyid:E8:07:E5:0F:0A:6E:B7:8B:80:D9:5E:E4:9A:4B:A0
"X509v3 Basic Constraints:CA:TRUE"
"X509v3 Key Usage:Digital Signature, Certificate Sign, CRL Sign"
"X509v3 Subject Key Identifier:E8:07:E5:0F:0A:6E:B7:8B:80:D9:5E:E4:9A:4B:A0:07:80:1
issuer="C=SE,O=EJBCA Sample,CN=AdminCA1"
keyUsage="Digital Signature, Certificate Sign, CRL Sign"
publicKey="A3:12:A4:CC:13:96:23:F0:6E:36:DB:C7:1E:51:29:91:A9:76:61:D9:60:78:7E:04:F8:
publicKeyAlgorithm="RSA"
serialNumber="0A:11:1F:B0:83:2D:A9:18"
signatureAlgorithm="sha1WithRSAEncryption"
validFrom="2014-03-27T08:07:43Z"
validTo="2024-03-24T08:07:43Z"
version="Version 3"
(config-TrustedCertificate=2)>up
(config-CertM=1)>EnrollmentAuthority=1
(config-EnrollmentAuthority=1)>enrollmentCaCertificate="ManagedElement=ITSAAPEVO111,SystemFu
(config-EnrollmentAuthority=1)>up
((config-CertM=1)>EnrollmentAuthority=1
(config-EnrollmentAuthority=1)>show
EnrollmentAuthority=1
enrollmentCaCertificate="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,Tru
(config-EnrollmentAuthority=1)>commit -s
(config-EnrollmentAuthority=1)>up
(config-CertM=1)>EnrollmentServerGroup=1
(config-EnrollmentServerGroup=1)>EnrollmentServer=1
(config-EnrollmentServer=1)>show
EnrollmentServer=1
(config-EnrollmentServer=1)>protocol=CMP
(config-EnrollmentServer=1)>uri="http://141.137.47.159:8080/ejbca/publicweb/cmp"
(config-EnrollmentServer=1)>commit -s
(config-EnrollmentServer=1)>up
(config-EnrollmentServerGroup=1)>up
(config-CertM=1)>NodeCredential=1
(config-NodeCredential=1)>subjectName="CN=opi3"
(config-NodeCredential=1)>keyInfo=RSA_2048
(config-NodeCredential=1)>renewalMode=AUTOMATIC
(config-NodeCredential=1)>enrollmentAuthority="ManagedElement=ITSAAPEVO111,SystemFunctions=1
(config-NodeCredential=1)>enrollmentServerGroup="ManagedElement=ITSAAPEVO111,SystemFunctions
(config-NodeCredential=1)>commit -s
(config-NodeCredential=1)>startOnlineEnrollment password
true
(config-NodeCredential=1)>show
NodeCredential=1
certificateState=VALID
enrollmentAuthority="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,Enrollm
enrollmentServerGroup="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,Enrol
keyInfo=RSA_2048
renewalMode=AUTOMATIC
subjectName="CN=opi3"
certificateContent="CN=opi3"
extensionContent
"X509v3 Authority Key Identifier:keyid:E8:07:E5:0F:0A:6E:B7:8B:80:D9:5E:E4:9A:4B:A0
"X509v3 Basic Constraints:CA:FALSE"
"X509v3 Extended Key Usage:TLS Web Client Authentication, E-mail Protection"
"X509v3 Key Usage:Digital Signature, Non Repudiation, Key Encipherment"

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 43


User Management

"X509v3 Subject Alternative Name:DNS:update3.eri.ericsson.se"


"X509v3 Subject Key Identifier:80:21:D8:A4:BE:D6:E9:65:51:94:1D:17:A0:CD:1B:D1:3E:3F:3
issuer="C=SE,O=EJBCA Sample,CN=AdminCA1"
keyUsage="Digital Signature, Non Repudiation, Key Encipherment"
publicKey="B5:AA:3A:4C:2D:54:18:30:FD:82:06:63:FC:9B:62:F7:7C:D0:6B:6E:48:5C:D8:E7:19:4D:
publicKeyAlgorithm="RSA"
serialNumber="66:81:6E:92:8E:47:0D:B5"
signatureAlgorithm="sha1WithRSAEncryption"
validFrom="2015-06-09T14:25:47Z"
validTo="2017-06-08T14:25:47Z"
version="Version 3"
enrollmentProgress
actionId=0
actionName="startOnlineEnrollment"
additionalInfo
""
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the online service"
state=FINISHED
timeActionCompleted="2015-06-09T16:35:40Z"
timeActionStarted="2015-06-09T16:35:39Z"
timeOfLastStatusUpdate="2015-06-09T16:35:40Z"
(config-NodeCredential=1)>top
(config)>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,UserManagement=1,LdapAuthentication
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeType
"MSCALL"
profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory=1"
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>nodeCredential="ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1,NodeCre
(config-Ldap=1)>commit
(Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,NodeCredential=
nodeType
"MSCALL"
profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory=1"
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(Ldap=1)>

2.2.5.2 Example - From Online to Offline

This example show how change node credential enrollment procedure from
online to offline in case of LDAP server is the same used in the initial offline
procedure.

44 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

The information related node credential certificate are required as input. In


this example they are:

• Node credential PKCS#12 container file is available: cert.p12.

• Password needed to decrypt the node credential PKCS#12 container file:


ericsson.

The CA trusted certificate for LDAP server is already installed on APG and
it is represented by MO TrustedCertificate=1 MO, as well as the CA
trusted certificate for enrollment server is already installed on APG and it is
represented by MO TrustedCertificate=2 MO.

First the trusted certificate for CA enrollment server represented by MO


TrustedCertificate=2is deleted using the action removeTrustedCert.
Procedure requires to delete also the MO EnrollmentAuthority=1 and the
EnrollmentServerGroup=1.

Afterwards, the reference of node credential from LDAP configuration, as per


value of attribute nodeCredential, is removed under MO Ldap=1. Then the
node credential certificate can be removed from APG by removing the MO
NodeCredential=1 under CertM=1.

Then a new node credential certificate is installed via offline procedure by using
the action installCredentialFromUri, after creating a NodeCredential=1MO,
using the input file cert.p12 and password ericsson.

Finally, the installed node credential certificate represented by


NodeCredential=1 MO is associated to APG LDAP configuration by setting
the attribute nodeCredential to related DN.
>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,SecM=1,CertM=1
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="installTrustedCertFromUri"
additionalInfo
"TrustedCertificate=2"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the certificate file"
state=FINISHED
timeActionCompleted="2015-05-27T09:28:50Z"
timeActionStarted="2015-05-27T09:28:50Z"
timeOfLastStatusUpdate="2015-05-27T09:28:50Z"
CertMCapabilities=1
EnrollmentAuthority=1
EnrollmentServerGroup=1
NodeCredential=1
TrustCategory=1
TrustedCertificate=1
TrustedCertificate=2
(config-CertM=1)>TrustedCertificate=2
(config-TrustedCertificate=2)>show
TrustedCertificate=2
certificateState=VALID
certificateContent="C=SE,O=EJBCA Sample,CN=AdminCA1"

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 45


User Management

extensionContent
"X509v3 Authority Key Identifier:keyid:E8:07:E5:0F:0A:6E:B7:8B:80:D9:5E:E4:9A:4B:A0:07
"X509v3 Basic Constraints:CA:TRUE"
"X509v3 Key Usage:Digital Signature, Certificate Sign, CRL Sign"
"X509v3 Subject Key Identifier:E8:07:E5:0F:0A:6E:B7:8B:80:D9:5E:E4:9A:4B:A0:07:80:16:C
issuer="C=SE,O=EJBCA Sample,CN=AdminCA1"
keyUsage="Digital Signature, Certificate Sign, CRL Sign"
publicKey="A3:12:A4:CC:13:96:23:F0:6E:36:DB:C7:1E:51:29:91:A9:76:61:D9:60:78:7E:04:F8:28:
publicKeyAlgorithm="RSA"
serialNumber="0A:11:1F:B0:83:2D:A9:18"
signatureAlgorithm="sha1WithRSAEncryption"
validFrom="2014-03-27T08:07:43Z"
validTo="2024-03-24T08:07:43Z"
version="Version 3"
(config-TrustedCertificate=2)>up
(config-CertM=1)>removeTrustedCert TrustedCertificate=2
true
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="removeTrustedCert"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="the TrustedCertificate instance removed"
state=FINISHED
timeActionCompleted="2015-06-19T15:42:51Z"
timeActionStarted="2015-05-27T09:28:50Z"
timeOfLastStatusUpdate="2015-06-19T15:42:51Z"
CertMCapabilities=1
EnrollmentAuthority=1
EnrollmentServerGroup=1
NodeCredential=1
TrustCategory=1
TrustedCertificate=1
(config-CertM=1)>no EnrollmentAuthority=1
(config-CertM=1)>no EnrollmentServerGroup=1
(config-CertM=1)>commit -s
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="removeTrustedCert"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="the TrustedCertificate instance removed"
state=FINISHED
timeActionCompleted="2015-06-19T15:42:51Z"
timeActionStarted="2015-05-27T09:28:50Z"
timeOfLastStatusUpdate="2015-06-19T15:42:51Z"
CertMCapabilities=1
NodeCredential=1
TrustCategory=1
TrustedCertificate=1
(config-CertM=1)>up
(config-SecM=1)>up
(config-SystemFunctions=1)>SecM=1
(config-SecM=1)>UserManagement=1
(config-UserManagement=1)>LdapAuthenticationMethod=1
(config-LdapAuthenticationMethod=1)>Ldap=1
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,NodeCredential=
nodeType
"MSCALL"

46 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>no nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,Cert
(config-Ldap=1)>commit -s
(config-Ldap=1)>
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeType
"MSCALL"
profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>up
(config-LdapAuthenticationMethod=1)>up
(config-UserManagement=1)>up
(config-SecM=1)>CertM=1
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="removeTrustedCert"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="the TrustedCertificate instance removed"
state=FINISHED
timeActionCompleted="2015-06-19T15:42:51Z"
timeActionStarted="2015-05-27T09:28:50Z"
timeOfLastStatusUpdate="2015-06-19T15:42:51Z"
CertMCapabilities=1
NodeCredential=1
TrustCategory=1
TrustedCertificate=1
(config-CertM=1)>no NodeCredential=1
(config-CertM=1)>commit -s
(config-CertM=1)>show
CertM=1
localFileStorePath="certificates"
userLabel="Certificate Management"
reportProgress
actionId=0
actionName="removeTrustedCert"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="the TrustedCertificate instance removed"
state=FINISHED
timeActionCompleted="2015-06-19T15:42:51Z"
timeActionStarted="2015-05-27T09:28:50Z"
timeOfLastStatusUpdate="2015-06-19T15:42:51Z"
CertMCapabilities=1
TrustCategory=1
TrustedCertificate=1
(config-CertM=1)>NodeCredential=1
(config-NodeCredential=1)>commit -s
(config-NodeCredential=1)>installCredentialFromUri cert.p12 NULL ericsson NULL
true
(config-NodeCredential=1)>show

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 47


User Management

NodeCredential=1
certificateState=VALID
keyInfo=RSA_1024
subjectName="CN=ITSAAP18,OU=APG,O=Ericsson,ST=Italy,C=IT"
certificateContent="CN=ITSAAP18,OU=APG,O=Ericsson,ST=Italy,C=IT"
extensionContent
"X509v3 Basic Constraints:CA:FALSE"
"X509v3 Extended Key Usage:TLS Web Client Authentication"
issuer="CN=141.137.32.123_CA,OU=APG,O=Ericsson,ST=Italy,C=IT"
keyUsage=""
publicKey="F1:55:B0:17:EB:D0:22:E3:37:3C:53:E9:AF:66:71:EA:D2:42:AD:A1:8A:EF:45:84:80:9A:
publicKeyAlgorithm="RSA"
serialNumber="01"
signatureAlgorithm="sha1WithRSAEncryption"
validFrom="2014-09-17T13:44:21Z"
validTo="2015-09-17T13:44:21Z"
version="Version 3"
enrollmentProgress
actionId=0
actionName="installCredentialFromUri"
progressInfo=""
progressPercentage=100
result=SUCCESS
resultInfo="installed from the container file"
state=FINISHED
timeActionCompleted="2015-06-19T15:52:23Z"
timeActionStarted="2015-06-19T15:52:23Z"
timeOfLastStatusUpdate="2015-06-19T15:52:23Z"
(config-NodeCredential=1)>up
(config-CertM=1)>up
(config-SecM=1)>UserManagement=1
(config-UserManagement=1)>
targetType
userLabel
LdapAuthenticationMethod=1
LocalAuthorizationMethod=1
(config-UserManagement=1)>LdapAuthenticationMethod=1
(config-LdapAuthenticationMethod=1)>Ldap=1
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeType
"MSCALL"
profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory=1"
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,No
(config-Ldap=1)>commit -s
(config-Ldap=1)>show
Ldap=1
baseDn="ou=People,dc=example,dc=com"
bindDn="cn=Manager,dc=example,dc=com"
bindPassword="1:jZCnE6f7JU8L0GYjz3aA4AfAkDMbmJ9e"
filterType=ERICSSON_ROLES
ldapIpAddress="141.137.32.123"
nodeCredential="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,NodeCredential=
nodeType
"MSCALL"
profileFilter=ERICSSON_FILTER
serverPort=636
tlsMode=LDAPS
trustCategory="ManagedElement=ITSAAPEVO111,SystemFunctions=1,SecM=1,CertM=1,TrustCategory=1"
userLabel="LDAP based login authentication"
useTls=true
EricssonFilter=1
Filter=1
(config-Ldap=1)>

48 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

2.3 MML Authority Handling


This section describes how to handle the MML authority in order to allow an
OaM User to open MML sessions and execute OaM activities on CP. MML
authority is handled partly on AP and partly on CP.

2.3.1 MML Authority Handling on AP


To make an OaM user able to operate into an MML session an MML authority
profile needs to be created. It consists of an association between:

• A predefined CP role and a CP user, in a Single-CP System.

• A predefined CP role and a list of COCA groups, in a Multi-CP System.

The association is done by setting attributes mmlRoleId and mmlProfile in a


new instance of MOC MmlRole.

The following Operational Instructions describe procedures for the MML


authority handling on AP:

• MCS Authority System, Associated Group User, Define

Describes the procedure to define an MML authority profile.

• MCS Authority System, Associated Group User, Delete

Describes the procedure to delete an MML authority profile.

2.3.1.1 Example of MML Authority Profile Creation in Single-CP System

This example shows how to create an MML authority profile in Single-CP


System for an OaM user belonging to role CpRole2 and requiring to have the
MML authority of CP user code CPUSER2.
>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,AxeFunctions=1,SecurityHandling=1,MmlAuthorizat
(MmlAuthorizationM=1)>config
(config-MmlAuthorizationM=1)>MmlRole=CpRole2
(config-MmlRole=CpRole2)>mmlProfile=CPUSER2
(config-MmlRole=CpRole2)>commit
(MmlRole=CpRole2)>

2.3.1.2 Example of MML Authority Profile Creation in Multi-CP System

This example shows how to create an MML authority profile in Multi-CP System
for an OaM user belonging to role CpRole2 and requiring the authority to
perform MML commands part of COCA groups 5..70.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 49


User Management

>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,AxeFunctions=1,SecurityHandling=1,MmlAuthorization
(MmlAuthorizationM=1)>config
(config-MmlAuthorizationM=1)>MmlRole=CpRole2
(config-MmlRole=CpRole2)>mmlProfile=5..70
(config-MmlRole=CpRole2)>commit
(MmlRole=CpRole2)>

2.3.1.3 Example of MML Authority Profile Removal

This example shows how to remove the MML authority profile related to role
CpRole2.
>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,AxeFunctions=1,SecurityHandling=1,MmlAuthorization
(MmlAuthorizationM=1)>config
(config-MmlAuthorizationM=1)>show
MmlAuthorizationM=1
MmlRole=CpRole1
MmlRole=CpRole2
(config-MmlAuthorizationM=1)>no MmlRole=CpRole2
(config-MmlAuthorizationM=1)>commit
(MmlAuthorizationM=1)>

2.3.2 MML Authority Handling on CP


This section describes the MML authority handling executed on CP that
consists of COCA groups handling and CP user handling.

The COCA group specifies the functional CP group that a particular MML
command belongs to. Each MML command is assigned to a COCA group by
default. The COCA group of MML Commands can be changed. The following
Operational Instructions describe the handling of COCA groups:

• MCS Authority System, Command Category Group, Change

Describes the procedure to change the COCA group for an MML command.

• MCS Authority System, Command Category Group, Reset

Describes the procedure to remove a command, with a changed COCA


group from the category group table. The command is returned to its
original COCA group when it is removed from the COCA group table.

COCA groups are associated to CP user group. The following Operational


Instructions describe the procedure to handle CP user groups and COCA
groups association:

• MCS Authority System, User Group, Change

It describes the procedure to change COCA groups for a certain CP user


group.

• MCS Authority System, Command Input, Restrict

50 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

It describes the procedure to block command authority for all other users.

CP users are associated to CP user group. Each CP user can be member of


one CP user group only. The following Operational Instructions describes the
handling of CP users:

• MCS Authority System, User, Initiate.

It describes the procedure to define a user in CP.

• MCS Authority System, User, Delete.

It describes the procedure to delete a user in CP.

• MCS Authority System, Password, Change.

It describes the procedure to change own password for CP user.

• MCS Authority System, User, Verify.

Describes the procedure to verify a CP user.

2.3.2.1 Example

This example creates a CP user CPUSER2, assigns it to CP user group 1


(USERGR=1) and associates COCA groups from 0 to 32 to CP user group 1 in
an MML session.
<IOUAL:USER=CPUSER2, USERGR=1, PSW=AGOODPASSWORD;
<IOUAI:USER=CPUSER2;
<IOUGC:USERGR=1, CATI=0&&32;

Note: Combining examples in Section 2.3.1.1 on page 49 and Section 2.3.2.1


on page 51, a OaM user belonging to CpRole2 can execute any MML
command within 0-32 COCA groups.

2.3.2.2 Example

This example changes COCA group of the MML command IOIOP to 15 in


an MML session.

<IOCTI:COMMAND=IOIOP,COCA=15;

2.4 Troubleshooting User Policy Management


Troubleshooting user policy management allows configuring user specific
security settings. These include password policies and account lockout policies
for local TS users. These settings are applicable only for TS users, defined
locally on the APG as per description in Section 2.5 on page 53.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 51


User Management

2.4.1 Modify Password Policy Parameters

To modify password policy of TS users, the attributes of MO


LocalTsUsersPolicyM=1 should be changed.

The table below explains the password policy parameters and their values:

Table 8 Password Policy


Attribute Name Description Default Value Range
passwordHistorySize It specifies the maximum number of 24 passwords 1 to 24
previous passwords remembered for remembered passwords
a user.
minimumPasswordLength It specifies the minimum number of 8 characters 8 to 12
characters to be used in a password. characters

The Operational Instruction AP, Security Settings, Change , Reference [9],


describes the actions to modify these attributes.

2.4.1.1 Example

This example shows how to modify the values of password


policy parameters. Attribute minimumPasswordLength is set to 9
characters and passwordHistorySize is set to 15 passwords. Role
SystemSecurityAdministrator is required as user authority.
>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,AxeFunctions=1,
SecurityHandling=1,LocalTsUsersPolicyM=1
(LocalTsUsersPolicyM=1)>config
(config-LocalTsUsersPolicyM=1)>minimumPasswordLength=9
(config-LocalTsUsersPolicyM=1)>passwordHistorySize=15
(config-LocalTsUsersPolicyM=1)>commit
(LocalTsUsersPolicyM=1)>

2.4.2 Modify Account Policy Parameters


To modify the account lockout policy, the attributes of MO
LocalTsUsersPolicyM=1 should be changed.

The table below explains the account lockout policy parameters and their
values:

Table 9 Account Policy


Attribute Name Description Default Value Range
lockoutDuration It specifies the minimum duration after 15 minutes 5 to 60 minutes
which locked accounts are automatically
unlocked.

52 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

lockoutBadCount It specifies the maximum number of 3 invalid logon 1 to 20 attempts


login attempts that are allowed for a user attempts
before the user is locked out
maximumAccountAge It specifies the maximum number of 5 days 1 to 30 days
days a user account is valid

Note: Account policy does not apply for TS administrator user.

The Operational Instruction AP, Security Settings, Change , Reference [9],


describes the actions to modify these attributes.

2.4.2.1 Example

The example shows how to modify the values of account policy parameters.
Attribute maximumAccountAge is set to 12 days, lockoutBadCount is set to 4 and
lockoutDuration is set to 10 minutes. Role SystemSecurityAdministrator
is required as user authority.
>show
ManagedElement=CEMSS07
>dn ManagedElement=CEMSS07,SystemFunctions=1,AxeFunctions=1,
SecurityHandling=1,LocalTsUsersPolicyM=1
(LocalTsUsersPolicyM=1)>config
(config-LocalTsUsersPolicyM=1)>maximumAccountAge=12
(config-LocalTsUsersPolicyM=1)>lockoutBadCount=4
(config-LocalTsUsersPolicyM=1)>lockoutDuration=10
(config-LocalTsUsersPolicyM=1)>commit
(LocalTsUsersPolicyM=1)>

2.5 Troubleshooting User Account Administration


Administration of TS user accounts is allowed only to TS administrator user,
tsadmin, through AP commands, see Table 10, given in a TS session.

Table 10 AP Commands Authority


AP Command TS User TS Administrator
addtsuser Yes
listtsuser Yes Yes
modtsuser Yes
pwdmodtsuser Yes
pwdresettsuser Yes
removetsuser Yes

AP command listtsuser can be given by a TS user as well. AP command


pwdmodtsuser can be given only by a TS user.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 53


User Management

2.5.1 Create TS User Account

To create a new TS user account the AP command addtsuser can be used.


Only TS administrator user has privileges to give this command in a TS session.

While creating a new user, TS administrator can assign any password


irrespective of the TS user account policies for passwords. The TS user is
forced to change at first login the password according to the policies defined
through the TS User Policy Management function MOM as per description in
Section 2.4 on page 51. To avoid any possible aliasing between TS users and
OaM users, the TS users must have in their user name the prefix ts_.

If option -d is specified the newly created TS user does not have any MML
authority, otherwise default MML authority applies as explained in Section
1.4.2.6 on page 18.

If option -r is specified the account of an expired TS user is renewed to the


maximumAccountAge value configured in TS User Policy Management function
MOM. Also the number of days can be specified explicitly using the option -e.

2.5.1.1 Example 1

This example shows how the TS administrator user tsadmin can create a new
TS user ts_user2 in a TS session with 5 days as account expiration time.
CEMSS07-SC-2-2:$ addtsuser -e 5 ts_user2
The password policy for TS users may be overridden ONLY when
assigning the initial password below.
This is done by simply ignoring the bad password messages.

Please note that the password set below must be changed


at first login.

When changing it is required that


* At least 8 characters are used
* Previous 24 passwords may not be reused
(minimum password length and password history are
configurable in MO LocalTsUsersPolicyM=1)

It is also required that the changed password must contain


characters from at least 3 out of the 4 classes,
upper case characters, lower case characters, digits and
special characters.

The changed password is also checked if it is found in a


dictionary, if it is just a case change only, or if
it is just a rotated variant of the old password.

Changing password for ts_user2.


New password:
BAD PASSWORD: it is WAY too short
BAD PASSWORD: is too simple
Retype new password:
Password changed.
User Add Success
CEMSS07-SC-2-2:$

54 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

2.5.1.2 Example 2

This example shows how the TS administrator user tsadmin can create a new
TS user ts_user2 in a TS session without any MML authority.
CEMSS07-SC-2-2:$ addtsuser -d ts_user2

The password policy for TS users may be overridden ONLY when


assigning the initial password below.
This is done by simply ignoring the bad password messages.
Please note that the password set below must be changed
at first login.

When changing it is required that


* At least 8 characters are used
* Previous 24 passwords may not be reused
(minimum password length and password history are
configurable in MO LocalTsUsersPolicyM=1)

It is also required that the changed password must contain


characters from at least 3 out of the 4 classes,
upper case characters, lower case characters, digits and
special characters.

The changed password is also checked if it is found in a


dictionary, if it is just a case change only, or if
it is just a rotated variant of the old password.

Changing password for ts_user2.


New password:
Retype new password:
Password changed.
User Add Success
CEMSS07-SC-2-2:$

2.5.1.3 Example 3

This example shows how the TS administrator user tsadmin can renew an
expired TS user ts_user2 in a TS session.
CEMSS07-SC-2-2:$ addtsuser -r ts_user2

The password policy for TS users may be overridden ONLY when


assigning the initial password below.
This is done by simply ignoring the bad password messages.
Please note that the password set below must be changed
at first login.
When changing it is required that
* At least 8 characters are used
* Previous 24 passwords may not be reused
(minimum password length and password history are configurable in
MO LocalTsUsersPolicyM=1)
It is also required that the changed password must contain
characters from at least 3 out of the 4 classes,
upper case characters, lower case characters, digits and
special characters.
The changed password is also checked if it is found in a
dictionary, if it is just a case change only, or if it is just
a rotated variant of the old password.
Changing password for ts_user2.
New password:
Retype new password:
Password changed.
User Renew Success

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 55


User Management

2.5.2 List TS User Accounts

To list the existing TS user accounts along respective MML authority the
command listtsuser can be used. Any TS user can give this command
in a TS session.

2.5.2.1 Example

The below example shows how to list all defined TS users.


CEMSS07-SC-2-2:$ listtsuser
ts_user1
ts_user2 no-mml
CEMSS07-SC-2-2:$

2.5.3 Modify TS User Account


To modify TS user account properties the AP command modtsuser can be
used. Only TS administrator user is authorized to give this command in a TS
session.

The TS user account should not be expired and locked to modify the properties.

2.5.3.1 Example

The below example shows how the TS administrator user tsadmin can change
the expiry time of user ts_user2 in a TS session to 10 days.
CEMSS07-SC-2-2:$ modtsuser -e 10 ts_user2
CEMSS07-SC-2-2:$

2.5.4 Change TS User Account Password


To change a TS user account password the AP command pwdmodtsuser can
be used. Only TS users can use the command in a TS session to change
their own password.

2.5.4.1 Example

This example shows how TS user ts_user2 can change its password in a
TS session.
CEMSS07-SC-2-2:$ pwdmodtsuser
Changing password for ts_user2.
Old Password:
New password:
Retype new password:
Password changed.
CEMSS07-SC-2-2:$

56 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

2.5.5 Reset TS User Account Password


To reset a TS user account password the command pwdresettsuser can
be used. Only TS administrator user is authorized to give this command in a
TS session. This is useful when the TS user is locked out due to failed login
attempts. This is also useful to set a new password of a TS user.

2.5.5.1 Example 1

This example shows how the TS administrator user tsadmin can unlock the
account of user ts_user2 in a TS session.
CEMSS07-SC-2-2:$ pwdresettsuser -u ts_user2
[ts_user2] account successfully unlocked
CEMSS07-SC-2-2:$

2.5.5.2 Example 2

This example shows how the TS administrator user tsadmin can reset the
password of user ts_user2 to new password in a TS session.
CEMSS07-SC-2-2:$ pwdresettsuser -n ts_user2
The password policy for TS users may be overridden ONLY when
assigning the initial password below.
This is done by simply ignoring the bad password messages.
Please note that the password set below must be changed
at first login.

When changing it is required that


* At least 8 characters are used
* Previous 24 passwords may not be reused
(minimum password length and password history are
configurable in MO LocalTsUsersPolicyM=1)

It is also required that the changed password must contain


characters from at least 3 out of the 4 classes,
upper case characters, lower case characters, digits and
special characters.

The changed password is also checked if it is found in a


dictionary, if it is just a case change only, or if
it is just a rotated variant of the old password.

Changing password for ts_user2.


New password:
BAD PASSWORD: it is WAY too short
BAD PASSWORD: is too simple
Retype new password:
Password changed.
password reset with new password success for [ts_user2]
CEMSS07-SC-2-2:$

2.5.6 Remove TS User Account


To remove a TS user account the AP command removetsuser can be used.
Only TS administrator user is authorized to give this command in a TS session.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 57


User Management

2.5.6.1 Example

This example shows how the TS administrator user tsadmin can remove the
TS user ts_user2 in a TS session.
CEMSS07-SC-2-2:$ removetsuser ts_user2
INFO: Success in deleting user : [ts_user2]
CEMSS07-SC-2-2:$

2.5.7 Reset TS Administrator Account Password

Only root has the authority to reset the password of TS administrator


account. A user needs to get root authorities and use command passwd or
pwdresettsuser to reset the TS administrator account password.

2.5.7.1 Example 1

This example shows how a user with root authorities resets the password of TS
administrator user tsadmin using OS command passwd.
CEMSS07-SC-2-2:$ su -
Password:
CEMSS07-SC-2-2:# passwd tsadmin
Changing password for tsadmin.
New password:
Retype new password:
Password changed.
CEMSS07-SC-2-2:#

2.5.7.2 Example 2

This example shows how a user with root authorities resets the password of
TS administrator user tsadmin using AP command pwdresettsuser in a
TS session.

58 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


How to use

CEMSS07-SC-2-2:$ su -
Password:
CEMSS07-SC-2-2:# pwdresettsuser -n tsadmin
The password policy for TS users may be overridden ONLY when
assigning the initial password below.
This is done by simply ignoring the bad password messages.

Please note that the password set below must be changed


at first login.

When changing it is required that


* At least 8 characters are used
* Previous 24 passwords may not be reused
(minimum password length and password history are
configurable in MO LocalTsUsersPolicyM=1)

It is also required that the changed password must contain


characters from at least 3 out of the 4 classes,
upper case characters, lower case characters, digits and
special characters.

The changed password is also checked if it is found in a


dictionary, if it is just a case change only, or if
it is just a rotated variant of the old password.
Changing password for tsadmin.
New password:
BAD PASSWORD: it is WAY too short
BAD PASSWORD: is too simple
Retype new password:
Password changed.
password reset with new password success for [tsadmin]
CEMSS07-SC-2-2:#

2.6 Actions on Alarms

2.6.1 AP, CERTIFICATE MANAGEMENT, FAULT


The alarm AP, CERTIFICATE MANAGEMENT, FAULT is raised with a specific
reason and alarm class, when a node credential certificate installed on APG is
either not valid anymore or the online renewal procedure fails.

Note: No monitoring on CA trusted certificates are done. In case of CA


trusted certificate expired the LDAP authentication is not allowed even
though node credential is not expired yet.

In particular:

1. It is raised with reason CERTIFICATE EXPIRED, REVOKED OR NOT


AVAILABLE and class A1, when a node credential certificate is expired,
revoked or not available. In this case the user authentication towards LDAP
server is not allowed. It is ceased when a valid node credential certificate
is installed on APG.

The Operational Instruction AP, CERTIFICATE MANAGEMENT, FAULT,


Reference [5], describes the actions to take when this alarm is raised.

2. It is raised with reason CERTIFICATE IS ABOUT TO EXPIRE when the


node credential certificate installed on APG is about to expire. The alarm
class might be:

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 59


User Management

• O2, when the number of days before the node credential


certificate expires is equal to or less than the value of the attribute
expiryAlarmThreshold in the MOC NodeCredential.

• A3, when the number of days before the node credential certificate
expires is equal to or less than 1/3 of the value of the attribute
expiryAlarmThreshold in the MOC NodeCredential.

• A2, when the number of days before the node credential certificate
expires is equal to or less than 1/10 of the value of the attribute
expiryAlarmThreshold in the MOC NodeCredential, or at 7 days
before its expiration date.

It is ceased if a valid node credential certificate is renewed on APG.

The Operational Instruction AP, CERTIFICATE MANAGEMENT, FAULT,


Reference [5], describes the actions to take when this alarm is raised.

3. It is raised with reason ONLINE CERTIFICATE ENROLLMENT OR


RENEWAL FAILED and class O2 when online certificate enrollment
or certificate renewal of node credential failed, for temporary network
disconnection, or in case that the enrollment server CA trusted certificate
is expired. It is ceased if a valid node credential certificate is successfully
renewed on APG.

No operator intervention is expected.

2.6.2 MCS AUTHORITY COMMAND INPUT RESTRICTED


The alarm MCS AUTHORITY COMMAND INPUT RESTRICTED is obtained as a
result of the MML command IOUAE given to end the authority of all CP users.
After that only the ordering CP user can enter MML commands.

The Operational Instruction MCS AUTHORITY COMMAND INPUT


RESTRICTED, Reference [16], describes the actions to take when the alarm
is received.

60 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Configuration

3 Configuration

This section describes the configuration of User Management function on the


AXE node.

It also provides the configuration of an LDAP server interworking with the APG
when OSS is not supported in the operator network.

3.1 AXE Node Roles and Rules


There are 20 predefined roles in the AXE node:

• SystemAdministrator

• SystemSecurityAdministrator

• SystemReadOnly

• EricssonSupport

• CpRole0 ... CpRole15

It is not possible to change, add or delete any role. Each role has its own set
of authorization rules. Authorization rules are expressed in terms of RWX
permissions for each system resources. Authorization rules are predefined for
each role and it is not possible to change, add or delete any rule. A user can
be associated to more that one role acquiring the union of authorization rules
of each specific role.

Following chapters describe in detail each predefined role.

3.1.1 Role SystemAdministrator


Role SystemAdministrator is able to perform all configuration activities on
APG, except the security related ones, and access the related folders into
APG file system.

Authorization rules for SystemAdministrator are according to following


details:

• Full access to all AXE MOs. Limited access to security related ones; in
particular read-only access to MO SecM=1, and read-only access to MOs
having CertM=1 and MmlAuthorizationM=1 as parent MO.

• Full access to APG file system, except the folders for audit logging and
certificates (/audit_logs, /certificates).

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 61


User Management

• Execution of all AP commands except alogfind, alogset, aloglist,


alogpchg, alogpls, csadm, gmlog, ipsecdef, ipsecls, ipsecrm,
ldapdef, rpmo.

• No permission to open an MML session.

For more details about authorization rules of role SystemAdministrator


see Section 3.1.6 on page 63.

3.1.2 Role SystemSecurityAdministrator


Role SystemSecurityAdministrator is able to perform only the security
related configuration activities on APG and access the related folders into APG
file system.

Authorization rules for SystemSecurityAdministrator are according to


following details:

• Full access to all security related AXE MOs having SecM=1 and
SecurityHandling=1 as parent MO, and no access to all the other MOs.

• Full access to security related folders, that are /audit_logs and


/certificates, and no access to the other ones.

• Execution of following AP commands: aehls, alist, alogfind,


alogset, aloglist, alogpchg, alogpls, csadm, ipsecdef,
ipsecls, ipsecrm, ldapdef.

• No permission to open an MML session.

For more details about authorization rules of role SystemSecurityAdminist


rator see Section 3.1.6 on page 63.

3.1.3 Role SystemReadOnly


Role SystemReadOnly is able to see all configuration settings on APG, except
the security related ones, and is not able to access any folders into APG file
system.
Authorization rules for SystemReadOnly are according to following details:

• Read-only access to all AXE MOs except for the security related MOs that
are the ones having MO SecM=1 and MO SecurityHandling=1 as parent
MO.

• No access to APG file system.

• Execution of AP printout commands except for security related ones.

• No permission to open an MML session.

62 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Configuration

For more details about authorization rules of role SystemReadOnly see


Section 3.1.6 on page 63.

3.1.4 Role EricssonSupport


Role EricssonSupport is able to perform only specific Ericsson support
procedures.
Authorization rules for EricssonSupport are according to following details:

• No access to any MO.

• Only execution of AP commands gmlog and rpmo.

• Full access to folder /tools only.

• No permission to open an MML session.

For more details about authorization rules of role EricssonSupport see


Section 3.1.6 on page 63.

3.1.5 CP Roles
CP roles are able to operate on CP via MML session. There are 16 CP roles,
CpRole0-CpRole15, mapping 16 CP user groups. Each CpRole must be
associated to a CP user or to a list of COCA groups as described in Section
1.4.1.4 on page 9.

The role CpRole0 is associated by default to CP user ADMINISTRATOR, in a


Single-CP System, and to COCA groups 0..255, in a Multi-CP System. These
associations cannot be altered. A CpRole cannot be associated to more than
one CP user. On the other hand a CpRole not associated to any CP user is
not able to perform any MML session.

A user belonging to a CpRole can execute all MML commands which COCA
groups are associated to it; such a user can also open an AP session and
execute the AP command mml or read-only access the MO SystemHandling=1.
The MO AlphanumericDeviceM=1 can be accessed with RX permissions.

Such a user cannot access to APG file system.

For more details about authorization rules of roles CpRole see Section 3.1.6
on page 63.

3.1.6 AXE Node Authorization Rules


AXE node has a set of predefined authorization rules assigned to each role. It
is not possible to change, add or delete any authorization rule. Authorization
rules are expressed in terms of Read, Write, eXecute (RWX) permissions on
the following AXE node resources:

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 63


User Management

• AP commands. Only X permission applies.

• MOs. X permission refers to actions into MOs.

• File system items.

Figure 10 gives an overview of the first four-levels MOC resources into MOM
AXE.

Figure 10 MOM AXE Overview

Table 11 reports the list of allowed AP commands per roles. A "Yes" in the cell
means the users belonging to that role are allowed to execute the command
in an AP session.

Table 11 AP Commands Authorization Rules per Roles in AP Session


ROLES

AP Command SystemAdmin SystemSecurityA SystemReadOnly EricssonSupport CpRole0-CpR


istrator dministrator ole15
abort Yes Yes Yes Yes Yes
acease (1)
Yes Yes
aehls Yes Yes Yes
afpls Yes Yes
alist Yes Yes Yes Yes
(2)
alogfind Yes Yes
alogset Yes
aloglist Yes
alogpchg Yes
alogpls Yes
back Yes Yes Yes Yes Yes
bioschg Yes
bios_set Yes
bupidls Yes Yes
burbackup Yes
burrestore Yes
cfeted Yes
clhls Yes Yes Yes
clhtran Yes
cmdlls Yes Yes
commit Yes Yes Yes Yes Yes
configure Yes Yes Yes Yes Yes

64 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Configuration

Table 11 AP Commands Authorization Rules per Roles in AP Session


cpdtest Yes Yes
cpfls Yes Yes
cpfrm Yes
cqrhils Yes Yes Yes
cqrhlls Yes Yes Yes
crdls Yes Yes
csadm Yes
dn Yes Yes Yes Yes Yes
date Yes
dsdls Yes Yes
end Yes Yes Yes Yes Yes
exit Yes Yes Yes Yes Yes
fixerls Yes Yes Yes
fwprint Yes Yes
fwupgexec Yes
gmlog Yes
hcstart Yes
help Yes Yes Yes Yes Yes
hwcls Yes Yes
hwmscbls Yes Yes
hwmxls Yes Yes
insert Yes Yes Yes Yes Yes
ipmifwprint Yes Yes
ipmiupgexec Yes
ipnaadm Yes
ipsecdef Yes
ipsecls Yes
ipsecrm Yes
ispprint Yes Yes
ldapdef Yes
length Yes Yes Yes Yes Yes
misclhls Yes Yes Yes
mktr Yes
mml Yes
msdls Yes Yes
mtzln Yes
netdef Yes

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 65


User Management

Table 11 AP Commands Authorization Rules per Roles in AP Session


netls Yes Yes
no Yes Yes Yes Yes Yes
opensession Yes Yes
pfmfwprint Yes Yes
pfmupgexec Yes
ping Yes
prcboot Yes
prcstate Yes Yes
prompt Yes Yes Yes Yes Yes
psdef Yes
psls Yes Yes
psrm Yes
raidmgr Yes
rifdef Yes
rifls Yes Yes
rifrm Yes
rtrch Yes
rtrdef Yes
rtrfe Yes
rtrls Yes Yes
rtrrm Yes
rpls Yes Yes
rpmo Yes
rptran Yes
scriptmode Yes Yes Yes Yes Yes
sells Yes Yes
seltran Yes
show Yes Yes Yes Yes Yes
show-config Yes Yes Yes Yes Yes
show-dn Yes Yes Yes Yes Yes
show-mib Yes Yes Yes Yes Yes
show-table Yes Yes Yes Yes Yes
snrinit Yes
stmotd Yes
stmpts Yes Yes
tesrvls Yes Yes Yes
tesrvtran Yes

66 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Configuration

Table 11 AP Commands Authorization Rules per Roles in AP Session


top Yes Yes Yes Yes Yes
traceroute Yes
tzch Yes
tzls Yes Yes
unzip Yes
up Yes Yes Yes Yes Yes
validate Yes Yes Yes Yes Yes
version Yes Yes Yes Yes Yes
vlanch Yes
vlandef Yes
vlanls Yes Yes
vlanrm Yes
width Yes Yes Yes Yes Yes
xcountls Yes Yes
xpuls Yes Yes
xputran Yes

(1) to cease inconsistency log related alarm in Multi-CP System only


(2) to print inconsistency log and cluster command log in Multi-CP System only

Following AP commands are not allowed on AP2 in a Dual-APG configuration:

• alogset

• alogpchg

• alogpls

• aloglist

• bupidls

• cfeted

• clhls

• clhtran

• cmdlls

• cpdtest

• cqrhils

• cqrhlls

• opensession

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 67


User Management

• cpfls

• cpfrm

• crdls

• fixerls

• fwprint

• fwupgexec

• gmlog

• ipnaadm

• misclhls

• mml

• pfmfwprint

• pfmupgexec

• stmpts

• tesrvls

• tesrvtran

• xcountls

Table 12 below reports authorization rules on MO resources per roles in an


AP session or a NETCONF session.

Table 12 MO Resources Authorization Rules per Roles in AP or NETCONF Session


ROLES
MO Resource SystemAdmin SystemSecurity SystemRead EricssonSup CpRole0 -
istrator Administrator Only port CpRole15
ManagedElement=1 RWX R R R R
SystemFunctions=1 RWX R R R R
SwM=1 and related children RWX R
MOs
SwInventory=1 and related RWX R R
children MOs
BrM=1 and related children RWX R
MOs
FileM=1 RWX R R R R
FileM=1,LogicalFs=1 RWX R R R R
FileGroup=cp,FileGroup= RWX RWX
mml and related children
MOs (*)

68 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Configuration

Table 12 MO Resources Authorization Rules per Roles in AP or NETCONF Session


FileGroup=cp,FileGroup=pr RWX R
intouts and related children
MOs (*)
FileGroup=cp,FileGroup= RWX R
files and related children
MOs (*)
FileGroup=sts_scr and RWX
related children MOs (*)
FileGroup=data_transfer RWX
and related children MOs
FileGroup=backup_restore RWX
and related children MOs
FileGroup=license_file and RWX
related children MOs (*)
FileGroup=audit_logs and RWX
related children MOs
FileGroup=certificates and RWX
related children MOs
FileGroup=health_check RWX
and related children MOs
FileGroup=sw_package RWX
and related chilrend MOs
FileGroup=tools and related RWX
children MOs
FileGroup=support_data RWX
and related children MOs
FileGroup=media RWX
SecM=1 R
SecM=1 and related RWX
children MOs
SecM=1,CertM=1 and R RWX
related children MOs
SysM=1 and related RWX R
children MOs
HealthCheckM=1 and RWX R R
related children MOs
AxeFunctions=1 RWX R R R R
DataOutputHandling=1 and RWX R
related children MOs
SecurityHandling=1 R RWX
SecurityHandling=1,ApS RWX
essionM=1 and related
children MOs
SecurityHandling=1,Audi RWX
tLoggingM=1 and related
children MOs
SecurityHandling=1,Loc RWX
alTsUsersPolicyM=1 and
related children MOs

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 69


User Management

Table 12 MO Resources Authorization Rules per Roles in AP or NETCONF Session


SecurityHandling=1,MmlAu R RWX
thorizationM=1 and related
children MOs
SupervisionHandling=1 and RWX R
related children MOs
SystemComponentHandli RWX R
ng=1 and related children
MOs
SystemHandling=1 RWX R
SystemHandling=1,Alph RWX R RX
anumericDeviceM=1 and
related children MOs
SystemHandling=1,CpFil RWX R
eSystemM=1 and related
children MOs
SystemHandling=1,CpRelo RWX R
adM=1 and related children
MOs
SystemHandling=1,Func RWX R
tionDistributionM=1 and
related children MOs
SystemHandling=1,Licens RWX R
eM=1 and related children
MOs
SystemHandling=1,TimeR RWX R
eferenceM=1 and related
children MOs

Note: (*): The related folders are not present on AP2.

Table 13 reports authorization rules on APG file system resources per roles
in a FT session.

Table 13 File System Authorization Rules per Roles in a FT Session


ROLES
File System Resource SystemAdmini SystemSecurity SystemRead EricssonSup CpRole0 -
strator Administrator Only port CpRole15
/audit_logs RW
/cp/mml RW RW
/cp/printouts RW R
/cp/files RW R
/sts_scr RW
/data_transfer RW
/backup_restore RW
/license_file RW
/certificates RW
/health_check RW
/sw_package R

70 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Configuration

Table 13 File System Authorization Rules per Roles in a FT Session


/sw_package/APG RW
/sw_package/CMXB RW
/sw_package/CP RW
/sw_package/EPB1 RW
/sw_package/EvoET RW
/sw_package/FW RW
/sw_package/IPLB RW
/sw_package/IPTB RW
/sw_package/SCXB RW
/tools RW
/support_data RW
/media RW

Table 14 reports recommended COCA Groups for some security related MML
commands. It is recommended that only CP User Group 0 have the authority
to execute commands with COCA groups 15 and 21 as they are used to
administer the authority system in the CP. Caution is also advised when giving
authority to execute commands belonging to COCA group 12.

Table 14 CP User Group Authority


MML Command COCA Group
IOCTI 15
IOCTP 15
IOTAC 21
IOTAP 21
IOTGC 21
IOTGP 21
IOTTC 21
IOTTP 21
IOUAE 15
IOUAI 15
IOUAL 15
IOUAP 15
IOUAR 15
IOUGC 15
IOUGP 15
PCORI 12

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 71


User Management

PCORL 12
ON, SET, INIT … and other Program 12
Test System commands

3.2 LDAP Server Configuration


A customer not using an Ericsson OSS needs to configure an LDAP server into
network. This chapter provides some additional information to consider during
such configuration phase.

APG supports authentication and authorization based on the POSIX® account


and the POSIX group schemas, which are standardized by Request for
Comments (RFC) 2307, Reference [20].

APG also supports a standard POSIX account schema extended with the
following attributes:

• ericssonUserAuthenticationScope

• ericssonUserAuthorizationScope

The authentication scope extension enables the security manager to define for
which node type or types a user is to be authenticated. It is also called target.
The authorization scope enables the security manager to specify the following:

• The role or roles the user has on the system, which the user has logged
on to. The value of the authorization scope must have the format
<target>:<role>, where colon (:) is a delimiter.

• The alias role or roles the user has on the system, which the user has
logged on to. There is no syntactic difference between a role and an alias
role. If an alias role is defined, the schema must also include the role
aliases schema; see next chapter for details.

For a secure connection the LDAP server must be configured to listen on


secure standard port 636.

Note: LDAP server might require that attributetype has no duplications


between existing schemas and schema created for APG43L. In case
such duplication exists, for example for attributetype ‘role’, the reference
to such existing schemas might need to be removed. Doing this might
prevent using LDAP server towards nodes other than APG43L.

3.2.1 Ericsson Role Aliases Schema


APG supports ericssonRoleAlias LDAP class, including a multi-value
role attribute that enables the resolution of an alias role into a real role. This
resolution of the alias role into a real role is meaningful to the system which the
user has logged on to.

72 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Configuration

APG expects that each real role is equal to a ericssonUserAuthorizati


onScope in the multi-value role attribute, with the restriction that it cannot
contain a nested alias role.

An example of Ericsson role alias in LDAP Data Interchange Format (LDIF) is


shown in the following section.

3.2.1.1 Example of Ericsson Role Alias in LDIF

dn: role=sysadmin,dc=cominf,dc=eei,dc=ericsson,dc=se
objectClass: ericssonRoleAlias
ericssonUserAuthorizationScope: cscfsysadministrator
ericssonUserAuthorizationScope: mtassysadm
ericssonUserAuthorizationScope: topadmin
ericssonUserAuthorizationScope: fmadmin
ericssonUserAuthorizationScope: snmpadmin
ericssonUserAuthorizationScope: secmreadonly
ericssonUserAuthorizationScope: sbg:readonly

3.2.2 Extended POSIX Account Management

The mandatory or optional attributes of Ericsson extended POSIX account that


requires consideration when the account information of LDAP users is defined
are the following:

• uid - It is the UID name. It is the key attribute for user queries.

• uidNumber - It is the UID number of the account. It is mandatory to


use uidNumber greater than or equal to 1000 to avoid collision with TS
accounts on APG.

• gidNumber - It is the GID number of the account. It is recommended to


use gidNumber greater than or equal to 500 to avoid collision with TS
accounts on APG.

• ericssonUserAuthenticationScope - It is the authentication scope


defining for which node type the user is to be authenticated.

• ericssonUserAuthorizationScope - It is the authorization scope


defining the role(s) the user has on the node type the user has to access.

An example of an Extended POSIX Account definition in LDIF is shown in


the following section.

3.2.2.1 Example of Ericsson Extended POSIX Account

In this example, the user has two authentication and authorization scopes:
apg.stockholm and apg.alvsjo. This configuration enables APG to
authenticate the user if apg.stockholm or apg.alvsjo matches a configured
node type. Depending on the node type where the user is logged in different

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 73


User Management

roles apply to it: SystemAdministrator in node apg.stockholm and


SystemReadOnly in apg.alvsjo.
dn: uid=lars,ou=people,dc=apg,dc=telco,dc=com
cn: Lars Magnus Ericsson
ericssonUserAuthenticationScope: apg.stockholm
ericssonUserAuthenticationScope: apg.alvsjo
ericssonUserAuthorizationScope: apg.stockholm:SystemAdministrator
ericssonUserAuthorizationScope: apg.alvsjo:SystemReadOnly
gecos: Lars Magnus Ericsson
gidNumber: 1000
homeDirectory: /home/lars
loginShell: /bin/bash
objectClass: ericssonUserAuthentication
objectClass: ericssonUserAuthorization
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
shadowLastChange: 13159
shadowMax: 0
shadowMin: 0
sn: Ericsson
uid: lars
uidNumber: 1000
userPassword: e1NTSEF9ck9ZbEJIRXNaek9Mbm1ybmRFNVlncUVVSll5TURKTzQ=

3.2.3 LDAP Attributes


This section describes the structure, syntax and matching rules of LDAP
Ericsson specific objectclass and attributetype.

The Object Identities (OID) are registered in the Ericsson branch of the OID
structure.

The below schemas must be loaded on the LDAP server:


attributetype: ( 1.3.6.1.4.1.193.207.372
NAME 'ericssonUserAuthenticationScope'
DESC 'Ericsson User Authentication Scope'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

## Auxiliary Object Class for Ericsson User authentication


## attributes.
objectclass: ( 1.3.6.1.4.1.193.207.374
NAME 'ericssonUserAuthentication'
SUP top AUXILIARY
MAY ( ericssonUserAuthenticationScope ))
attributetype: ( 1.3.6.1.4.1.193.207.373
NAME 'ericssonUserAuthorizationScope'
DESC 'Ericsson User Authorization Scope'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
## Auxiliary Object Class for Ericsson User authorization
## attributes.
objectclass: ( 1.3.6.1.4.1.193.207.376
NAME 'ericssonUserAuthorization'
SUP top AUXILIARY
MAY ( ericssonUserAuthorizationScope ))

attributetype: ( 1.3.6.1.4.1.193.207.371
NAME 'role'
DESC 'Ericsson Role'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

74 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Configuration

3.2.4 Configuring Multi-Domain LDAP Server


LDAP Server can be defined with multiple local domains and one global
domain. An example each to configure a global domain, local domain is given
in the following sections. Users under global domain should be defined under
ou=people as mentioned in Section 3.2 on page 72.

3.2.4.1 Example to configure a Global Domain in LDAP Data Interchange Format


(LDIF)
# GlobalDomain, example.com
dn: ou=people,dc=example,dc=globaldomain
ou: GlobalDomain
objectClass: top
objectClass: organizationalUnit

3.2.4.2 Example to configure a Local Domain in LDIF


# GlobalDomain, example.com
dn: ou=people,dc=example,dc=globaldomain
ou: GlobalDomain
objectClass: top
objectClass: organizationalUnit

3.2.4.3 Example to configure a referral to Global Domain

Referral to a Global domain is configured with the "ref" attribute.


dn: ou=GlobalDomain,ou=LocalDomain,dc=example,dc=com
ou: GlobalDomain
objectClass: top
objectclass: referral
objectclass: extensibleObject
ref: ldaps://lin-vir2-ldap.eri.ericsson.se/ou=People,dc=example,dc=globladomain

3.2.5 APG Configuration


Once the LDAP server has been prepared and made available into APG
connectivity network, settings described in Section 2.1 on page 21 should be
followed.

In particular if the LDAP server certificates have the FQDN as common


name in the subject field, the attributes ldapIpAddress, for primary LDAP
server, and fallbackLdapIpAddress, for fallback LDAP server, must be set
with FQDN, otherwise IP addresses should be used. Refer to International
Telecommunication Union Telecommunication Standardization Sector (ITU-T)
Recommendation X.509, Reference [19], for more information.
In case of FQDN also the AP command ldapdef is required to allow APG to
resolve FQDN with corresponding IP address.

It is recommended to configure the LDAP server to have its IP address as


access method and not the FQDN.

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 75


User Management

76 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Glossary

Glossary

AP LDAP
Adjunct Processor Lightweight Directory Access Protocol

APG LDAPS
Adjunct Processor Group LDAP over SSL

CA LDIF
Certification Authority LDAP Data Interchange Format

COCA MML
Command Category Man-Machine Language

CP MOC
Central Processor Managed Object Class

CMP MOM
Certificate Management Protocol Managed Object Model

CPI NETCONF
Customer Product Information Network Configuration

DER OaM
Distinguished Encoding Rules Operation and Maintenance

ENM OID
Ericsson Network Management Object Identities

FQDN OSS
Fully Qualified Domain Name Operation Support System

FT OSS-RC
File Transfer Operation Support System-Radio Core

GID PEM
Group Identity Privacy Enhanced Mail

HW PKCS
Hardware Public Key Cryptography Standards

ITU-T RBAC
International Telecommunication Union Role-Based Access Control
Telecommunication Standardization Sector
RFC
LCT Request for Comments
Local Craft Terminal
RSA
Rivest Shamir Adleman

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 77


User Management

RWX
Read, Write, or eXecute

SHA
Secure Hash Algorithm

SSL
Secure Sockets Layer

TBAC
Target-Based Access Control

TS
Troubleshooting

UID
User Identity

URI
Uniform Resource Identifier

78 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11


Reference List

Reference List

AXE CPI References

[1] Alphanumeric Device Management


USER GUIDE

[2] AP, Certification Authority Trusted Certificate and Node Credential, Install
OPERATIONAL INSTRUCTION

[3] AP, Certification Authority Trusted Certificate and Node Credential,


Remove
OPERATIONAL INSTRUCTION

[4] AP, Certificate Management, Node Credential Enrollment Procedure,


Change
OPERATIONAL INSTRUCTION

[5] AP, CERTIFICATE MANAGEMENT, FAULT


OPERATIONAL INSTRUCTION

[6] AP, File, Transfer


OPERATIONAL INSTRUCTION

[7] AP, LDAP Client, Configure


OPERATIONAL INSTRUCTION

[8] AP, Node Credential Renewal, Initiate


OPERATIONAL INSTRUCTION

[9] AP, Security Settings, Change


OPERATIONAL INSTRUCTION

[10] AXE Security Management


USER GUIDE

[11] AXE Equipment Management


USER GUIDE

[12] Ericsson Command-Line Interface


USER GUIDE

[13] How to Access an AXE


USER GUIDE

[14] Managed Element Management


USER GUIDE

4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11 79


User Management

[15] Managed Object Model


USER GUIDE

[16] MCS AUTHORITY COMMAND INPUT RESTRICTED


OPERATIONAL INSTRUCTION

OSS CPI References

[17] Node Centralized User Management Integration Guide for OSS-RC

[18] COMInf SUN Directory Server, System User Guide

Standard References

[19] ITU-T Recommendation X.509, "http://www.itu.int/rec/T-REC-X.509"

[20] RFC 2307, "https://www.ietf.org/rfc/rfc2307.txt"

80 4/1553-CXA 118 03/2-V3 Uen B | 2016-11-11