Security and User Management: DN09106695 Issue 3-1

Nokia Networks
Security and User

Management
DN09106695
Issue 3-1
Security and User Management
The information in this document applies solely to the hardware/software product (“Product”) specified
herein, and only as specified herein.
This document is intended for use by Nokia Solutions and Networks' customers (“You”) only, and it may not
be used except for the purposes defined in the agreement between You and Nokia Solutions and Networks
(“Agreement”) under which this document is distributed. No part of this document may be used, copied,
reproduced, modified or transmitted in any form or means without the prior written permission of Nokia
Solutions and Networks. If you have not entered into an Agreement applicable to the Product, or if that
Agreement has expired or has been terminated, You may not use this document in any manner and You
are obliged to return it to Nokia Solutions and Networks and destroy or delete any copies thereof.
The document has been prepared to be used by professional and properly trained personnel, and You
assume full responsibility when using it. Nokia Solutions and Networks welcome Your comments as part of
the process of continuous development and improvement of the documentation.
This document and its contents are provided as a convenience to You. Any information or statements
concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on
an “as is” and “as available” basis in this document, and Nokia Solutions and Networks reserves the right
to change any such information and statements without notice. Nokia Solutions and Networks has made all
reasonable efforts to ensure that the content of this document is adequate and free of material errors and
omissions, and Nokia Solutions and Networks will correct errors that You identify in this document. But,
Nokia Solutions and Networks' total liability for any errors in the document is strictly limited to the correction
of such error(s). Nokia Solutions and Networks does not warrant that the use of the software in the Product
will be uninterrupted or error-free.
NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY OF AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN RELATION TO THE
CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA SOLUTIONS AND NETWORKS BE
LIABLE FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT,
INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF
PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY
ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF
ERRORS IN OR OMISSIONS FROM THIS DOCUMENT OR ITS CONTENT.
This document is Nokia Solutions and Networks’ proprietary and confidential information, which may not be
distributed or disclosed to any third parties without the prior written consent of Nokia Solutions and
Networks.
Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document
may be trademarks of their respective owners, and they are mentioned for identification purposes only.
Copyright © 2014 Nokia Solutions and Networks. All rights reserved.
f Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle this
product and only after having carefully read the safety information applicable to this product.
The safety information is provided in the Safety Information section in the “Legal, Safety and
Environmental Information” part of this document or documentation set.
Nokia Solutions and Networks is continually striving to reduce the adverse environmental effects of its
products and services. We would like to encourage you as our customers and users to join us in working
towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations
for power use and proper disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental services we
offer, please contact us at Nokia Solutions and Networks for any additional information.
2 DN09106695 Issue: 3-1

Table of Contents
This document has 66 pages
Summary of changes .................................................................... 7
1 Security and user management overview...................................... 8

1.1 Authentication................................................................................ 8
1.1.1 MMI system users.......................................................................... 8
1.1.2 User IDs......................................................................................... 9
1.1.3 Passwords......................................................................................9
1.1.4 Delay between failed login attempts.............................................11
1.1.5 Restriction on users attached to an administrative profile............ 11
1.2 MMI user authorization.................................................................12
1.2.1 MMI user profiles..........................................................................12
1.2.2 MML command authority..............................................................12
1.2.3 MML user authority...................................................................... 14
1.2.4 MML terminal authority.................................................................14
1.2.5 Service terminal authority.............................................................14
1.2.6 MML session authority................................................................. 15
1.2.7 MML session idle time limit.......................................................... 17
1.2.8 MML session policy......................................................................17
1.2.9 MML command blocking.............................................................. 17
1.2.10 MMI system security hardening recommendations......................17
1.3 Audit Trail logs..............................................................................19
1.3.1 MML command log.......................................................................20
1.3.1.1 MML command visibility............................................................... 21
1.3.2 Service terminal command log.....................................................21
1.3.3 FTP command log........................................................................22
1.3.4 SFTP command log..................................................................... 22
1.3.5 HTTP(S) logs (WEB GUI)............................................................ 23
1.3.6 Security reporting log................................................................... 25
1.4 Access systems and file transfer security.................................... 27
1.4.1 Network security-related hardening recommendations................27
2 Managing MMI system security and network security..................31

2.1 Managing MMI system users....................................................... 31
2.1.1 Creating local users and super users...........................................31
2.1.2 Creating network users................................................................ 32
2.1.3 Configuring a password policy..................................................... 32
2.1.4 Defining a user account policy..................................................... 33
2.1.5 Activating centralized user authentication and authorization....... 34
2.1.6 Configuring the restriction on users attached to an administrative
profile........................................................................................... 35
2.2 Managing MML command logs.................................................... 36
2.2.1 Printing out data from MML command log................................... 36
Issue: 3-1 DN09106695 3

2.3 Managing security reporting.........................................................37

2.3.1 Outputting a detailed security report............................................ 37
2.4 Configuring FTP server................................................................ 38
2.5 Configuring HTTPS server........................................................... 38
2.6 Configuring XOHS server.............................................................39
2.7 Configuring XOH HTTPS protocol............................................... 40
2.8 Configuring SSL/TLS authentication proxy.................................. 43
2.9 Configuring MMI over SSH server interface for OMU.................. 46
2.10 Configuring SFTP server interface...............................................47
2.11 Managing network element IP security........................................ 48
2.11.1 Configuring IPSec VPNs for OMU with IKE pre-shared key-based
VPN authentication...................................................................... 48
2.11.2 Configuring IPSec VPNs for OMU with PKI certificate-based VPN
authentication...............................................................................51
2.11.3 Configuring in-host IP ACLs for OMU.......................................... 56
3 Security and user management troubleshooting..........................58

3.1 Command can be executed by unauthorized user.......................58
3.2 A blocked command can be executed by unauthorized user.......59
3.3 Command cannot be executed by authorized user......................59
3.3.1 Command cannot be executed by operator................................. 60
3.3.2 Command cannot be executed by user ID administrator............. 60
3.4 The terminal authority has no effect on the user’s authorities......61
3.5 All terminals have too low authorities...........................................62
3.6 A profile has too low authorities for command class I.................. 63
3.7 An unrequired profile cannot be deleted...................................... 64
3.8 Insufficient space for more profiles...............................................65
3.9 Insufficient space for more user IDs.............................................65
3.10 A network connection cannot be established via FTP................. 66
4 DN09106695 Issue: 3-1

List of Figures
Figure 1 Average user rights............................................................................ 15
Figure 2 Low user rights................................................................................... 16
Figure 3 Critical commands with high authority requirement............................16
Figure 4 Choose XML file................................................................................. 41
Figure 5 Set <protocol> element value to "https"............................................. 42
Figure 6 Activate XML file.................................................................................43
Figure 7 Configuring network element IPSec with IKE pre-shared key-based
VPN authentication.............................................................................49
Issue: 3-1 DN09106695 5

List of Tables
Table 1 MML command authority categories.................................................. 12
Table 2 MMI system security hardening recommendations............................ 17
Table 3 Network security -related hardening recommendations..................... 27
6 DN09106695 Issue: 3-1

Security and User Management Summary of changes
Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
Changes made between issues 3–1 and 3–0

The GIVAXI interface has been added to the Network security-related hardening
recommendations section.

Steps in sections Configuring HTTPS server and Configuring XOHS server have been
updated with two added notes.

Minor corrections in section Managing network-element-integrated IPSec.
Issue: 3-1 DN09106695 7

Security and user management overview Security and User Management
1 Security and user management overview
1.1 Authentication
1.1.1 MMI system users
Local users
The user accounts of local users are defined in each network element separately, and
the users can log in only to those network elements in which they have a user account.
A local user must have an MMI user profile and can additionally have a network user
profile or an HTTP profile. The profile defines the user's authority to execute MML
commands.
A local user who has admin rights to command IAH can add other users to the network
element.
If Feature 31390: Password Policy is used in the network element, a password policy
can be defined and attached to a user profile. The requirements set in the password
policy are activated when the user changes a password attached to that user profile.
In addition, it can be determined that the system checks the history of every new
password the user is creating. This way, the user can be prevented from re-creating a
password that has been recently used in the network element.
If Feature 31391: User Account Policy is used in the network element, it can be defined
that what kinds of formal requirements the local user account must fulfill.
Centralized users
A centralized user has authentication and authorization details defined in a centralized
LDAP server in the Network Management System (NMS) NetAct.
Network element centralized users are related to the Centralized User Authentication
and Authorization (CUAA) solution in NetAct. CUAA functionalities contain an LDAP
client interface in the OMU functional unit. The LDAP client interface is used to obtain
authentication and authorization details from the CUAA LDAP server when the CUAA is
enabled in the network element.
The user accounts are stored to the LDAP server. Each user is given an access list
defining which network elements the user can log into.
An LDAP client can be configured in the network element, if the following requirements
are met:
• The network element has TCP/IP connections.

• The NetAct supports centralized user management.
• The NE account of the network element has been received from the NetAct.
The address of the LDAP directory must be defined before centralized user accounts can
be used.
Information management over a remote connection requires the XML over HTTP
interface or the NWI3 interface. A centralized user who has administrator rights to
command IAH can add local users to the network element.
8 DN09106695 Issue: 3-1

Security and User Management Security and user management overview
Centralized users can be defined only in the NetAct.
Network users
Network users are users who need to operate the system remotely from the NetAct over
connection.
A network user needs an MMI user account to be able to log in to the network element.
The user account consists of a local user ID and user profile, which defines the
appropriate user rights.
Super users
A super user profile has authority 251 in one or more command classes. The profile
lends the user un-restricted rights to execute commands in those command classes to
which special authority is granted. The special authority bypasses command blocking,
MML command authorization, and the authority restriction of the MML terminal. The
super user profile can be attached to an MMI user ID or to an MML terminal.
1.1.2 User IDs

Every user of the MMI system must have a unique user ID. The ID consists of six
alphanumeric characters. Digits from 0 to 9 and capital letters from A to Z can be used. A
local user ID must begin with a letter.
By default, the maximum number of local user IDs is per network element.
1.1.3 Passwords
When creating passwords, the following principles have to be taken into account:
• The minimum length of a password is 6 characters and the maximum length 16

characters.
• The password can consist of alphanumeric characters, and ASCII characters from
HEX 21 to HEX 7E.
• The password cannot be identical to the user ID.
• Passwords are case-sensitive.
The purpose of case-sensitivity and the possibility to use a large amount of different
characters in the password is to increase system security and it is recommended to take
full advantage of both.
When creating, storing and using passwords, follow the common recommendations and
your company's security policy.
Validity time
In the VTIME parameter of command IAA, you can define how long a password is valid.
The value range is from 1 to 250 days.
If the value is 0, the password has to be changed at every login.
If the value is FOREVER, the password does not have an expiration date. Use this value
only in NetAct connections.
Issue: 3-1 DN09106695 9

Encryption
Passwords are not stored to the MMI system in plaintext format. Only a hash value of
each password is stored to the MMI system. It is enough for the system to conclude, if
the password values given in O&M user logins match with the hash values in the MMI
system O&M user account book-keeping.
Hash values of passwords are calculated with the International Data Encryption
Algorithm (IDEA) encryption algorithm which uses the Davies-Meyer method. The
method provides one-way encrypted result to make it impossible to resolve the actual
password values from one-way encrypted results (hash values).
The password encryption keys are generated by the system and they are not visible to
users. You can only print out a list of reserved indexes, and change an existing index.
The one-way encryption method is not supported by all older systems. Therefore, it is
advisable to create parallel passwords for those users who need to establish remote
connections to a system which does not support the one-way encryption method.
Parallel passwords
The purpose of parallel passwords is to allow local users an access to systems which do
not recognize passwords that have been encrypted with the one-way encryption method.
When a user with two passwords logs in locally, the system checks both passwords, and
does not request the user accounts again when the user opens a remote session.
You can create parallel passwords in the PARAPW parameter of command IAA. The
parameters have to be completely separate (two different digit sequences) and both
have a validity time of their own.
If a user's new-type password has expired but the old-type password is still valid, the
user can log in locally and change the expired password. Other local operations cannot
be executed using the old-type password.
If a user's old-type password has expired but the new-type password is valid, the user
can open a remote session from a network element of an older system level to one of a
newer system level and change the expired password. Other operations cannot be
executed in the remote session using the new-type password.
Password policy
A password policy states what kinds of formal requirements a password must fulfill. In
the password policy, you can define:
• The minimum length of a password.

• How many alphabetical, numerical, or special characters the password must include
in the minimum.
• How many characters occurring in alphabetical or numerical order the password may
include in the maximum.
• How many repeated characters the password may include in the maximum.
• How many historical passwords to be checked.
You can additionally define:
• Whether the user ID as such or written from back to front can be used as a substring
in the password.
• Whether the forbidden password list must be checked.
10 DN09106695 Issue: 3-1

• That the password history is checked before certain MML commands are executed.
• That the password policy is checked before certain MML commands are executed.
1.1.4 Delay between failed login attempts

If there are three failed login attempts, coming from the same source and occurring in
consecutive order, the MMI system generates a delay before the next login attempt is
allowed. The initial delay value is 10 seconds by default, which is configurable for users.
At each new failed login attempt, the delay is doubled until its value reaches the
maximum. The maximum delay value is 24 hours by default which is configurable for
operators.
The system informs the user about the delay with a message.
If the delay is less than one minute, the message shows the delay time in seconds. For
example:
DELAY OF 40 SECONDS APPLIED. PLEASE WAIT.
If the delay is more than one minute, the message shows the end time of the delay. For
example:
DELAY APPLIED. PLEASE WAIT UNTIL 08:22.
The purpose of the delay is to prevent dictionary attacks by using a program which
automatically generates user account login attempts. Even if the attacker knows the
correct user ID and is trying to guess only the password, the delay keeps increasing,
because the system recognizes the source from which the login attempts originate.
From the system's point of view, each Telnet connection is handled as a separate
source. Connections using the PAD protocol are handled as one unidentifiable source,
and connections using ISO VT protocols as one source.
The maximum delay for a single source is 24 hours. The first successful login from the
source resets the delay.
The following settings in the login delay functionality are defined in PRFILE parameters:
• 044:0001 FIRST_MMI_LOGIN_DELAY
defines the length of the first delay.
• 044:0002 MAX_MMI_LOGIN_DELAY
defines the maximum length of the delay.
• 044:0003 OVERFLOW_LOGIN_DELAY
defines the length of the delay in those Telnet connections to which unique delay
cannot be applied.
You can check and change the values of these parameters with the commands of
command group WO. For information about the commands, see the Parameter Handling
MML command reference manual.
1.1.5 Restriction on users attached to an administrative profile

With the parameter ADMPROF you can define whether the profile is an administrative
profile. When the value of parameter ADMPROF is ‘Yes’, the profile is an administrative
profile.
Issue: 3-1 DN09106695 11

If the value of the PRFILE parameter UA_RESTRICT_ADMIN_USER (58:0008) is set to 1,

MML sessions are restricted to the users with an administrative profile who want to login
over Telnet or SSH.
You can switch user ID with command IAP. With command group WO, you can check
and modify the value of UA_RESTRICT_ADMIN_USER.
1.2 MMI user authorization

1.2.1 MMI user profiles
User profiles make it easy to divide the network element's operating personnel into
different user groups according to their daily responsibilities.
The profile defines what kind of an MML command authority the user has in certain
command classes. All MML terminals, service terminal extensions, virtual terminals, and
the command calendar are also attached to a profile.
Changes made to a profile affect all the users who have been defined with the profile.
This way, you can manage and supervise the authority of the user IDs and terminals
sharing the same profile.
The default profile (PROFILE) is defined for the system in the configuration phase. All
terminal devices, the command calendar and the default user ID (SYSTEM) are attached
to this profile. The profile has a default authority of 250 in all command classes.
1.2.2 MML command authority

MML command authority requirement defines what the minimum MML session authority
must be in that command class. MML command authority requirement is defined per
command.
The default authority requirements of MML commands are defined when a software build
is generated. When the build is complete, all commands must have an authority of 50,
100, 150, 200, or 250.
The authority can be changed, if needed. Any value between 1 and 250 can be given.
The special authority 251 is reserved for super users. Table 1: MML command authority
categories describes the default authority levels defined for different types of commands.
Table 1 MML command authority categories
Command Description Authority

classification
Group 1 Critical commands that are used 250
• to change the state of the system to a significant

extent.
• to handle sensitive data.
12 DN09106695 Issue: 3-1

Table 1 MML command authority categories (Cont.)
Command Description Authority

classification
For example, commands for managing MMI system

authorities, network security protocols and
databases.
Group 2 Critical commands that are used 200
• to change the state of the system to a moderate

extent.
• to handle sensitive data.
For example, commands for managing system

supervision and charging data.
Group 3 Commands that are used to change the state of the 150
system to a fairly limited extent.
For example, commands for managing subscribers
and services.
Group 4 Commands that are used 100
• to change the state of the system to a very

limited extent.
• to check the state of the system
For example, commands for modifying measurement

data.
Group 5 Commands that are used only to check the state of 50

the system.
You can check the command authority of a command group with command IAT and
change it with command IAM. For examples, see MMI System Authority Handling MML
command reference manual.
t The default authority requirements defined in the software package can be considered
a general recommendation given by the network element manufacturer, but the network
operators have to evaluate the MMI system accessibility from the point of view of their
own network’s operability.
As a rule of thumb, access to sensitive data and to commands that are critical from the
point of view of system security and operability (command authority 200 or higher)
should be limited to system administrators who are servicing the network element.
Also, access to command groups with which online call monitoring (lawful interception)
is handled should be restricted to a specific number of users accountable for operation
in this area.
Issue: 3-1 DN09106695 13

1.2.3 MML user authority

The authority granted to a user of the MMI system is defined in a user profile, which is
attached to the user ID. In the profile, the authority is always defined per entire command
class.
User profiles can be created for local users and network users.
In addition to the user ID, the user needs a password to be able to open an MML
session.
1.2.4 MML terminal authority

MML terminal is also given a profile which defines its authority. The authority is defined
per entire command class and it has to be defined locally.
You can check the authority of an individual terminal with command IAI.
The authority can be changed by:
• Attaching the terminal to another profile, which has the required authority (with
command IAE).
• Creating a new profile with required authority and attaching the terminal to it (with
commands IAA and IAE).
• Updating the profile currently attached to the terminal (with command IAA).
t A change made to a profile affects all terminals attached to the profile.
1.2.5 Service terminal authority

A service terminal session can be started from an MMI session with command DDS, or
from a terminal which is connected to the local management serial port on the blade of a
functional unit. Authority for service terminal session is granted for the user accounts
which have authority to execute command DDS in their MMI profiles.
• When a service terminal session is started from a terminal, the user ID and password
are requested.
• When a session is started from an MMI session, the user ID and password are not
requested, because the authentication and authorization details from the MMI
session are already applied for the user.
In addition to the user account having authority to execute command DDS, a service
terminal session can also be started with a fixed user name and password. This method
can be applied in a fault situation when the MMI system implementation is unable to
provide authentication and authorization for an individual functional unit.
• The fixed user name can be applied only from the local management serial port. The
system prevents service terminal logins to the functional unit with the fixed user
name as long as the MMI system is able to serve the functional unit (via network
element internal message bus).
• The password is configurable for operators.
14 DN09106695 Issue: 3-1

t For security reasons, it is recommended that the default authority of command group
DD is not decreased from the default 250.
The fixed user name and its password are intended only for administrator users and it is
recommended to change the password regularly.
The use of service terminal commands should be limited to testing, fault detection, and
specific tasks in the commissioning phase.
1.2.6 MML session authority

MML user authority and MML terminal authority together determine the MML session
authority.
If the user's authority in a certain command class is lower than the MML terminal’s, the
system automatically restricts the execution rights according to the user’s authority.
Similarly, if the MML terminal authority is lower than the user authority, the execution
rights are restricted according to the MML terminal authority.
The only exception to this is special authority (251), which can be granted to a user
(super user) or a terminal (super terminal). Special authority is defined per entire
command class and it gives the user unrestricted rights to execute commands in that
command class.
For normal users (whose authority is lower than 251), the command authority
requirement restricts the MML session authority on command level. Figure 1: Average
user rights illustrates a case where the user can access command group RC, but the
command authority requirement of certain single commands inside the group is so high
that it prevents the user from executing these particular commands.
Figure 1 Average user rights
Issue: 3-1 DN09106695 15

If the user’s authority is set so low that it prevents access to an entire command class,
the user cannot see the command groups that belong to the command class, either.
Figure 2: Low user rights illustrates a case where a user’s rights are so low that the
execution of all commands is prevented.
Figure 2 Low user rights
251
250
Command 200
authority
requirement
150
100
50
Userrights 1
Commandgroup R R R R
Command O M T I
Figure 3: Critical commands with high authority requirement illustrates a case where
access to the more critical commands has been limited to a small number of
administrator users by keeping the authority requirement of these commands higher than
the average users’ authorities.
Figure 3 Critical commands with high authority requirement
16 DN09106695 Issue: 3-1

1.2.7 MML session idle time limit

The MML session idle time limit determines how long an MML session can be inactive
before it is closed by the system. The idle time limit can be from 1 to 60 minutes and it
can be defined separately for every local and centralized user profile.
If an MML session idle time limit is changed during an MML session, the change
becomes effective immediately.
1.2.8 MML session policy

MML session policy limits the number of users' concurrent MML sessions. The session
policy is defined in the user profile, which means that all users who have the same profile
have the same session policy.
1.2.9 MML command blocking

Executing, for example, equipment handling and unit connections handling commands
during a software upgrade or backup copying may be hazardous.
To prevent an accidental execution of certain commands, you can block them with
command IAB.
1.2.10 MMI system security hardening recommendations

When planning MMI system security, consider the following:
1. Divide the users of the network element into user groups according to their tasks,
and create a dedicated MMI profile for each group:
• Separate, for example, system administrator-type of users who are servicing or
maintaining the network element from users managing individual functionalities.
• Specify the MML command authority in each MMI profile according to the tasks
each user group need to be authorized. See Table 2: MMI system security
hardening recommendations for examples of user groups.
Table 2 MMI system security hardening recommendations
User group / profile Authority
System administrators These are users who service and manage the network element.
They need fairly high authority in command classes which are used to handle
software packages and the basic functionality of the system.
For example:
– SYSTEM SUPPORT AND COMMUNICATION (command class D)

– I/O SYSTEM ADMINISTRATION (command class I)
– UNIT ADMINISTRATION (command class U)
– SYSTEM CONFIGURATION ADMINISTRATION (command class W)
Authority in other command classes (for example call control) can be low.
Issue: 3-1 DN09106695 17

Table 2 MMI system security hardening recommendations (Cont.)
For the administration of software packages, system administrators need MMI

profiles for which the FTP/SFTP WRITE authority is enabled.
For other MMI profiles, the FTP/SFTP authority can be either NO or READ as
described below.
Operator users Operator users need adequate rights for managing functionality (for example the
call control interface) and MMI user accounts.
These profiles separate
function management from, Operator users need high authority only in those command classes with which
for example, system functionality is handled.
administration.
Authority in system administration-related command classes can be kept low,
preventing authority for example to service terminal sessions.
Also SFT/SFTP authority can be defined as NO for these profiles, to prevent
operator users from accessing the file system.
Governmental authority Governmental authority users need high authority in command class V (LAWFUL
INTERCEPTION HANDLING) to be able to carry out tasks related to Lawful
These profiles separate
interception and OLCM.
governmental authorities
from operator users. Authority in other command classes can be kept low.
FTP/SFTP authority can be defined as NO, to prevent these users from accessing
the file system.
t Other than governmental authority users do not need authority in command

class V at all, because all commands in this command class are used only
for authority management.
FTP/SFTP READ operations These profiles are needed, if the network element has charging functionalities
(CHU units) or an audit trail log transfer interface from the OMU units towards the
NMS.
These users do not need authority to execute any other MML commands; only the
FTP/SFTP READ authority needs to be enabled for them.
EMT interface This profile is needed, if the network element has an interface towards the NMS
NEMU element.
This profile does not need authority in any MML command class, and also the
FTP/SFTP authority can be defined as NO.
For this profile, it is sufficient that an MMI user account exists in the network
element for logging in to the EMT, but authority settings of the profile can be kept to
the minimum.
t For a NetAct-based NMS, the administrative end user-related authorization

is done in the NetAct.
This is the reason why the NetAct system normally manages the end entity
network elements with one high-authorized MMI user account and user
profile.
18 DN09106695 Issue: 3-1

Table 2 MMI system security hardening recommendations (Cont.)
Network-element-web- Create network-element-web-manager-WebGUI user accounts only for users who

manager-WebGUI users have to be able to manage the XML-over-HTTP notification interface towards the
NMS NetAct.
The HTTP network-element-web-manager-WebGUI is used only to configure this
interface, and the only users who need authority to use it are the system
administrators.
2. Minimize the risk of unauthorized service terminal access.

• Authority to execute command DDS gives the user an authority to a service
terminal. Do not lower the default authority requirement (250) of command group
DD.
• Grant service terminal authority only to system administrator users.
Service terminal is needed only for troubleshooting in failure cases and for some
other system administration operations. Other than system administrator users
can handle their tasks without service terminal authority.
3. Define a password policy for different user profiles.

4. Create user profiles for the different user groups and terminals.
5. Attach the correct user profile to each user group and terminal.
6. Enable password history checking.
7. Enable security reporting.
8. On unmanned sites and sites that are not regularly guarded, set the terminal
authority so that local sessions cannot be established.
t All remote connections to the MMI system are routed through the virtual terminal (VTP).
If the VTP has a super terminal profile, all remotely connected users who log in through
Telnet/SSH get super user rights as the terminal authority 251 runs over their profile-
defined user rights.
If super terminal rights are needed, add the super terminal profile only to the VDUs.
9. Make sure that all users are aware of the company's security policy.
1.3 Audit Trail logs

Audit Trail logs, or Security Audit Trail logs, provide the security-related data that show
who has accessed a computer system and what operations have been performed on a
system during a given period of time. Audit trail logs can be used for both maintaining the
security and recovering the lost transactions.
The log files are collected by Audit Trail in the network management system (NMS), so
that you can trace the commands and operations given in the network elements. With
the Audit Trail, you can process, browse and trace the collected files. So it is possible to
solve the problems originated from the misuse of the given commands and operations.
The Audit Trail logs are as follows:
Issue: 3-1 DN09106695 19

• MML command log

• Service terminal command log
• FTP command log
• SFTP command log
• HTTP(S) log
• Security reporting log
1.3.1 MML command log

Data about successfully established and ended MML sessions, occurrences of MML
command execution as well as command execution results are collected in a permanent
logical file (MMLLOG) shared by all MMI system users.
The MML command log provides the following information:
• network element name

• file name of the log
• log type
• creating time of the log
• username
• session ID
• start date and time of the session
• terminal name
• MML command and its parameters given in the session
• log status: the execution result of the MML command
• IP address of the client
The default path to the log is:

OMU:/ASWDIR/MMLLOG/YYYYMMDD.XML
This is the path in active software packet directory. ‘YYMMDD’ indicates the date when
the log file is created, where YY = year, MM = month, DD = day.
To access the MML command log, use command IGO.
The contents of the log can be printed out to a file or to an output device. The output can
be further processed outside the network element or be used inside the network element
as a command file.
g Information of remote and local user accounts cannot be separated in the command
log. Centralized users have their own profile object for the MML log in the centralized
profile.
Alarms related to MML command log handling:

Alarm 2683 ERROR IN MML COMMAND LOG ACCESS is related to the MML
command log.
This alarm means that an error occurred while reading or writing the MML command log.
For a detailed alarm description and recovery instructions, see Failure Printouts (2000-
3999).
MML command log access
20 DN09106695 Issue: 3-1

The rights to access the MML command log are defined when creating a user profile.
They can be:
LIMITED The owners of the profile can read only their own MML
command log records.
MEDIUM The owners of the profile can read their own command log
records and all other users’ public MML command log
records.
COMPLETE The owners of the profile can read all MML command log
records.
You can change the MML command log access with command IAA. For examples, see
the command description in the command reference manual of MMI System Authority
Handling.
1.3.1.1 MML command visibility
Every MML command has a visibility attribute, which determines whether the command
can be printed out from the MML command log. The visibility can be:
PUBLIC all users who have medium or complete access to the

MML command log can print out the command from the
log.
PRIVATE only those users who have complete access rights to the
MML command log can print out the command from the
log.
There is one exception: users with only limited or medium
access to the command log can view the commands which
they themselves have executed, even if the visibility of the
commands were PRIVATE.
The visibility of an MML command is PUBLIC by default. You can change the visibility
with the IAM command. For examples, see the command description in the command
reference manual of MMI System Authority Handling.
1.3.2 Service terminal command log

All the operations of the service terminal session, together with the user accounts and
times, are recorded in the service terminal command log.
The service terminal command log provides the following information:
• log type
• username
• the date and time of the session
• the connection type: direct or remote
• the unit name of the network element
• the process ID: the service terminal ID
• the session type: the start or stop of the session
Issue: 3-1 DN09106695 21

• the operations carried out over the service terminal sessions: opening or closing a
session, the command executions and the parameters given in the service terminal

OMU:/ASWDIR/ST0LOG/HLEYYMMDD.XXX
This is the path in active software packet directory. ‘YYMMDD’ indicates the date when
the log file is created, where YY = year, MM = month, DD = day, XXX = number starting
from 001. For example, the name of a log file which was created on March 17th, 2008
can be HLE20080317.001.
g There are more than one service terminal command log generated during one day. In
order to distinguish the different log files, the .XML file extension is not given in the log
path.
For both local and remote service terminal sessions, the service terminal command log is
collected.
The feature of collecting the service terminal command log can be disabled by only
authorised operators. Contact Customer Service Center to perform this operation.
1.3.3 FTP command log

Data about all the FTP connections and commands given in the sessions are recorded in
the FTP command log. For the FTP command log, the network element serves as the
server.
Data about the following information are recorded in the FTP command logs:
• username
• the start date and time of the session
• the operations carried out over the FTP connections: opening or closing the
connections, renaming files, getting the file from the server and storing the file into
the server, etc
• the FTP commands given in the sessions

OMU:/ASWDIR/FSRLOG.XML
This is the path in active software packet directory.
g The log path cannot be changed.
1.3.4 SFTP command log

Data about all the SFTP connections and commands given in the sessions are recorded
in the SFTP command log. For the SFTP command log, the network element serves as
the server.
Data about the following information are recorded in the SFTP command logs:
• username
22 DN09106695 Issue: 3-1


• the date of time of the session
• the operations carried out over the SFTP connections: opening or closing the
connections, getting the file from the server and storing the file in the server, etc
• the SFTP commands given in the sessions

OMU:/ASWDIR/SIKLOG.XML
1.3.5 HTTP(S) logs (WEB GUI)

The HTTP(S) logs record all the operations performed on the ‘network element web
manager’ over the HTTP(S) connection. For the HTTP(S) logs, the network element
serves as the server.
There are four types of HTTP(S) logs:
• Session log
The SESSION.XML file records the information of the sessions carried over HTTP(S)
in the network element.
The log includes the following information:
– network element name
– the file name of the log
– the log type
– the creating time of the log
– the username
– session ID
– the start date and time of the session
– the operations carried out over the HTTP connections: session requests, session
request results, session request failure reasons, etc
– the entry types of the log: NORMAL, NOTICE, DISTURBANCE, ERROR and
FATAL_ERROR
– the IP address of the client
OMU:/WEBFIL/SESSION.XML
• Error log
The DXHERR.XML file records the printouts of the failed operations carried over
HTTP(S) connection in the network element.
– the log type
Issue: 3-1 DN09106695 23


– the operations carried out over the HTTP(S) connections: bad requests, internal
server errors, etc
FATAL_ERROR
OMU:/WEBFIL/DXHERR.XML
• Access log
The ACCESS.XML file records the access information of the sessions carried over
HTTP(S) in the network element.
– the log type
– the username
– session ID
– the operations carried out over the HTTP(S) connections: HTTP(S) object
request results, etc
FATAL_ERROR
– IP address of the client
OMU:/WEBFIL/ACCESS.XML
• Log of the download/upload information
The DUHFILGX.XML file records the information of the latest attempts to download
or upload the files over the HTTP(S) in the network element.
– the log type
– the operations carried out over the HTTP(S) connections: file upload requests,
activation requests
FATAL_ERROR
OMU:/LFILES/DUHFILGX.XML
The HTTP(S) log files are maintained by the Network Element Web Manager. The Web
Manager user menu contains a list of the different logs with HTML links to them. The
logs are stored on network element disks.
24 DN09106695 Issue: 3-1

When you select an HTTP(S) log file, it opens automatically in a window. You can save
the log file on your local workstation in XML format. You can select more than one log file
and save them all in one file. In this case, the HTTP(S) log files are automatically
compressed into a ZIP file.
g The log paths cannot be changed.
1.3.6 Security reporting log

Security reporting supervises the information security by reporting attempts to violate the
security of the network element, and give an alarm when a possible security violation is
noticed. You can use security reporting to identify problems involving information
security. Security reporting collects security-related data from various sources, such as
the MMI system and the alarm system.
There are following types of the security reporting log:
• service terminal session

It includes the username, computer unit name of the network element and the
terminal name, the date and time of the action, the operation types (opening or
closing the sessions), the access status (successful logins and illegal attempts to
login to the service terminal).
• MML session login
It includes the username, the network element name and the terminal name, the date
and time of the action, the action types (opening or closing), and the connection
address of the remote host (for example, the IP address if the session is established
over Telnet or SSH).
• MML command
It includes the executions of the MML command: executed command, the username,
the network element name, the date and the time of the command execution, and the
terminal name, and the status of the command execution.
• login delay
It includes the username, the network element name, the terminal name, the login
date and time, the access status, the session types (MMI, FTP, SFTP, ST, etc.), and
the connection address (for example, the IP address if the session is established
over IP).
g There is no IP address recorded in the login delay logs for the ST session.
• network access
It includes the username, the network element name, the terminal name, the login
date and time, the information about the attempts to access the network element, the
connection types are FTP, SFTP, and HTTP, (for example, the IP address if the
session is established over IP)
• SSH session
It includes the information of the username, the time and date of the session, the
start/stop information, the access status, and the connection address of the remote
host (for example, the IP address).
Issue: 3-1 DN09106695 25

The security reporting system collects the security-related data, prepares the reports,
and manages the reporting function. When the system starts up for the first time, the
security reporting log is automatically created and stored in the disk. The system records
the information in the created log every time when there is session connected or
operation performed. You cannot modify or configure the log.
A periodical security counter indicates the number of events collected since the periodic
security counter report was last printed out. These counters are reset automatically when
the periodic security counter report is put out.
A long-term counter contains the number of events collected since the long-term
counters were last reset. Long-term counters help you to define reasonable critical limits
for security counters. They also help you to see if the situation shown by periodical
counters has suddenly changed drastically compared to the situation shown by long-term
counters. Unlike periodical counters, long-term counters are not reset when the periodic
security counter report is output. You can reset them with command IRR.
To access the security reporting log, enter command group IR.
OMU:/LFILES/LETTERGX.XML
Some of the MML commands are monitored automatically and others can be set to be
monitored manually. Monitoring means that security reporting is informed every time the
command is used. If you want to set a single MML command to be monitored, you can
do it with command IAM.
Outputting a detailed report is important at least when a critical limit has been reached.
The detailed report enables you to find out the reason for the excessive number of
events.
MML login delay report

Data about delayed login attempts is stored to an MML login delay report. The report
shows
• the third occurrence of consecutively failed login attempts that came from the same
source
• all failed login attempts in which the user name is different from the previous one
used in the same source
• a successful login made after the failed ones
• the address of the source where the login attempts were made
For PAD and ISO VT connections, the address information is ‘unidentified’, but the name
of the protocol is shown.
26 DN09106695 Issue: 3-1

1.4 Access systems and file transfer security

In connections that are used to access and transfer data between the network element
and an external system, one potential security hazard is that data communication could
be monitored from outside the network.
Access systems include:
• PAD and VTP connections

• LDAP connections
t To minimize security risks:
• Do not set the user authority of virtual terminals so high that normal operations
cannot be carried out via the MML terminal.
• Ensure that the connection between the network element and LDAP has been
protected, for example with the IPSec protocol.
1.4.1 Network security-related hardening recommendations

Take the following aspects in Table 3: Network security -related hardening
recommendations into account in remote O&M connections.
Table 3 Network security -related hardening recommendations
Interface Recommendation
MMI over Telnet in OMU Consider applying the MMI over SSH server interface
instead of the default MMI over Telnet interface.
If MMI over SSH is used, the MMI over Telnet interface
can be disabled.
FTP server interface in OMU Consider applying the SFTP Server interface instead
(MSS/MSC’s CHU or SGSN’s of the default FTP server interface.
MCHU)
If SFTP Server is used, the FTP server interface can
be disabled.
HTTP server network-element- Consider disabling this interface, if it is not used.

web-manager-WebGUI interface
The HTTP network-element-web-manager-WebGUI
in OMU
interface is needed only for configuring the XML-over-
HTTP(s) notification interface towards the NMS NetAct.
If this interface is not used, there should not be any
reason to keep the HTTP network-element-web-
manager-WebGUI enabled.
Even if the XML-over-HTTP(s) notification interface is
used, it can be kept disabled by default, and enabled
only when modifying the interface configuration.
Issue: 3-1 DN09106695 27

Table 3 Network security -related hardening recommendations (Cont.)
Consider applying the HTTPS network-element-web-

manager-WebGUI interface instead of the default
HTTP network-element-web-manager-WebGUI
interface for configuration changes in the XML-over-
HTTP(s) interface, if this interface is used.
This is recommended especially if the network-
element-web-manager-WebGUI interface cannot, for
practical reasons, be kept disabled during the times
when there is no need to make configuration
operations in the notification interface or the
configuration operations are carried out remotely over
network segments which can be potentially dangerous.
When using the HTTPS network-element-web-
manager-WebGUI interface, configure the SSL/TLS-
level certificate-based authentication as instructed in
section Configuring SSL/TLS authentication proxy.
HTTP server XML-over-HTTP Consider disabling the XML-over-HTTP request

request interface in OMU interface, if the interface is not used in the network
element.
If NetAct is the only entity receiving XML-over-HTTP(S)
notifications, there should not be any reason to keep
the interface enabled.
NetAct uses the network-element-web-manager-
WebGUI interface for configuring the XML-over-
HTTP(s) notification interface. As a result, there are not
any entities ordering notifications by means of the
XML-over-HTTP(s) request interface.
Consider also applying the XML-over-HTTPS request
interface instead of the default XML-over-HTTP
interface, if it is not possible to disable the default
interface without activating the HTTPS-based interface.
When using the XML-over-HTTPS request interface,
configure the SSL/TLS-level certificate-based
authentication as instructed in section Configuring
SSL/TLS authentication proxy.
XML-over-HTTP notification Consider applying the XML-over-HTTPS notification

interface in OMU interface instead of the default interface, if XML-over-
HTTPS and related features are available in the
network element.
When using XML-over-HTTPS notification interface,
configure the SSL/TLS-level certificate-based
authentication as instructed in section Configuring
SSL/TLS authentication proxy.
EMT server interface Consider disabling this interface, if it is not used.
28 DN09106695 Issue: 3-1

Table 3 Network security -related hardening recommendations (Cont.)
The EMT interface is needed only for interacting with

the NEMU.
VPP-over-Telnet server interface Virtual printers are used to direct data from the system
in OMU to a printer using a virtual printer driver and POSIX
printer services.
Consider disabling this interface, if it is not used.
SFTP operations Consider enabling server authentication, based on

SSH RSA/DSA public key, in SFTP client operations, if
SFTP client is used, for example, in charging interfaces
instead of the FTP client.
SFTP is an improved version of the File Transfer
Protocol (FTP). It uses an encrypted network
connection provided by Secure Shell (SSH).
The SSH file transfer protocol provides file transfer and
manipulation functions over any reliable data stream.
SFTP clients can resume interrupted transfers, get
directory listings and remove remote files.
RUIM/CUAA interface in OMU If the Remote User Information Management

(RUIM)/Centralized User Authentication and
Authorization (CUAA) solution is used, consider
applying secure RUIM (RUIM LDAP over TLS) instead
of RUIM LDAP over plaintext TCP.
When using secure RUIM, configure the SSL/TLS-level
certificate-based authentication as instructed in section
Configuring SSL/TLS authentication proxy.
GIVAXI Disable the GIVAXI interface.
1. Use the ZWOI:2,2093; command to check the

current status of GIVAXI interface.
• If the value is 00, it means the GIVAXI
interface is already disabled.
• If the value is 00FF, it means the GIVAXI
interface is currently enabled.
2. Execute the ZWOC:2,2093,0; command to

disable the GIVAXI interface.
3. Wait for a few minutes after executing the
command and then the GIVAXI ports should no
longer be open in any of the functional units.
4. Use the ZQRS command to check that the TCP
port 8019/8021 is no longer active in the relevant
functional units.
Issue: 3-1 DN09106695 29

t In some products, the following features referred to in these hardening

recommendations may be optional and may additionally require a license:
• Configurable O&M Interfaces

This feature makes it possible to use the commands (in command group I2) with
which the O&M interfaces can be enabled and disabled.
For a description of the command syntaxes and parameters, see the command
reference manual of SSH Protocol Layer Handling.
• MMI over SSH
• SFTP Server
• HTTPs network-element-web-manager-WebGUI
• XML-over-HTTPS request interface
• XML-over-HTTPS notification interface
30 DN09106695 Issue: 3-1

Security and User Management Managing MMI system security and network security
2 Managing MMI system security and network

security
2.1 Managing MMI system users

2.1.1 Creating local users and super users
t In some products, the User Account Policy feature is optional. In such cases, the
feature has to be activated first.
If the feature is not optional in the network element software, you can skip the first two
steps.
1 Activate the user account policy feature

ZWOA:58,0001,A;
2 Check that the user account policy feature has been activated successfully
ZWOS:58,0001:;
3 Create a new user profile

ZIAA:<profile name>:<command class>=<authority>:::FTP=<FTP
authority>:;
If you want to create a super user, set the authority at 251. For example:
ZIAA:SWJ:ALL=251:::FTP=NO:;
If you want to create an administrative profile, set the value of ADMPROF to ‘Yes’. For
example:
ZIAA:ADMPRO:ALL=250:ADMPROF=YES::FTP=W:;
g To create an administrative profile, the Feature 31391: User Account Policy must be
activated.
By default, the FTP authority is disabled (defined as "NO"). If needed, you can
enable the FTP authority in the MML profile:
• FTP=W (access with read and write permissions)
• FTP=R (access with read permission)
4 Create a user ID for the profile

ZIAH:<user id>:<profile>:;
5 Check that the data is correct

ZIAI:PROFILE=<profile>:COM;
Issue: 3-1 DN09106695 31

Managing MMI system security and network security Security and User Management
Further information
Existing profiles can be deleted with command IAR, if they have not been attached to
any user ID.
2.1.2 Creating network users

A network user profile can be created only for the already existing local user.
t The password defined for the user ID must not be longer than 15 characters although
16 characters can be given in the command.
1 Check the user ID

ZIAI:LOCAL=ALL:LIM;
2 Create user profile for the user

ZIOA:<user id>:APPL=<application field>;
Further information
The FTAM user profile and access right can be removed with command IOR.
When the entire user profile of user is deleted, the MMI user account remains in the
system, but when a local MMI user account is deleted, the system automatically deletes
its FTAM profile.
2.1.3 Configuring a password policy

Password policy can be defined only for local users. Centralized users’ passwords are
defined and modified in the NetAct.
Password policy cannot be applied to passwords used in some older system-level
network elements.
t In some products, the Password Policy feature is optional. In such cases, the feature
has to be activated first.
steps.
1 Activate the password policy feature

ZWOA:58,0000,A;
2 Check that the password policy feature been activated successfully

ZWOS:58,0000:;
32 DN09106695 Issue: 3-1

3 Activate password policy checking

ZIVS:STATE=ON;
4 Activate password history checking

ZIVH:STATE=ON;
5 Define the password policy

ZIVK:<password policy name>: [[PCMDS=[IAH | IAS | IAG |
IAF]...] | [HCMDS=[IAS | IAG | IAF]...] | [LENGTH=<min
password length>] | [CHAR=<min characters in password>] |
[DIGIT=<min digits in password>] | [SPECIAL=<min special
characters in password>] | [REPEAT=<max repeating
characters>] | [ALPH=<max alphabetical order>] |
[NUMERIC=<max numerical order>] | [USERID=[ YES | NO ]] |
[HCOUNT=<count of limited historical password>] | [FPWL=[ ON
| OFF ]]]...;
6 Configure the forbidden password list

ZIVM:[A|D]:[FPWS=<forbidden passwords>];
7 Check the forbidden password list

ZIVN:FPWS=<forbidden password>;
8 Check that the data is correct

ZIVI:POLICY=PASSWORD:PWPOLICY=<password policy name>;
9 Attach the password policy to a user profile

ZIAA:<profile>::PWPOLICY=<password policy name>:::;
2.1.4 Defining a user account policy
t In some products, the User Account Policy feature is optional. In such cases, the
feature has to be activated first.
steps.
1 Activate the user account policy feature

ZWOA:58,0001,A;
2 Check that the user account policy feature has been activated successfully
ZWOS:58,0001:;
Issue: 3-1 DN09106695 33

3 Activate user account policy checking, if it has not been activated

ZIVU:STATE=ON;
4 Activate last login information checking

ZIVT:STATE=ON;
5 Create a user profile with a user account policy

ZIAA:<profile>:
[command class>=<authority>]:
[VTIME=<password validity time>,
[MINVTIME=<minimum password validity time>,
ACCESS=[COM | MED | LIM def],
UNIQUE[YES | NO def]]...,
PWPOLICY=<password policy name>,
ADMPROF=[YES | NO def],
DABLETIME=<disable time>:
[TLIMIT=<mml session idle time limit>]:
FTP=[W | R | NO def];
2.1.5 Activating centralized user authentication and

authorization
t When Centralized User Authentication and Authorization (CUAA) has been configured
to be active, the user does not have to do anything in the network element. CUAA
simply enables the usage of O&M user accounts that have been defined in NetAct's
LDAP server.
1 Set a NE account
ZIAY:<NE account username>:;
t Password of a NE account is asked when command is executed.

An NE account is used for opening a connection to an LDAP server when users with
centralized accounts are authorized. It must have been set into the LDAP server before
this command is executed.
2 Configure the LDAP client for centralized user authentication and authorization
ZIAJ:STATE=ON:TYPE=[PRI | SEC]: [IPV4=<IP address version 4>]
| [IPV6=<IP address version 6], PORT=<port
number>:[SSL=OFF|FOR|CON]:<dn path>;
Where
34 DN09106695 Issue: 3-1

OFF SSL is not used
FOR (forced) only SSL is used
CON (conditional) an unauthenticated connection is used if

SSL connection cannot be used
Example:
ZIAJ
:STATE=ON:TYPE=PRI:IPV4=”10.102.39.58”,PORT=389:SSL=CON:”CN=DX
,OU=LDAPCONFDATA,OU=RUIM,OU=REGION,OU=REGIONS,OU=NETACT,DC=NOK
LAB,DC=NET”;
t When using an SSL connection, you have to configure the required certificates and a
related private key. For instructions, see section
Configuring SSL/TLS authentication proxy.
3 Activate the authentication and authorization of centralized users

ZIAN:ON;
4 Check that the configuration is correct

ZIAV:TYPE=ALL:LIM:;
Example:
EXECUTION STARTED
CONFIGURATION LDAP DIRECTORY

============================
IP ADDRESS: <IP address of configuration LDAP server>
PORT NUMBER: <port number>
SSL STATE: <state of SSL>
PRIMARY LDAP DIRECTORY

======================
IP ADDRESS: <IP address of primary LDAP server>
PORT NUMBER: <port number>
SSL STATE: <state of SSL>
FEATURE ACTIVATION STATUS

=========================
DIRECTORY CLIENT ACTIVATION STATUS: ACTIVE

CENTRALIZED USER AUTHENTICATION STATUS: ACTIVE
COMMAND EXECUTED
2.1.6 Configuring the restriction on users attached to an

administrative profile
g UA_RESTRICT_ADMIN_USER (58:0008) is defined in the parameter PRFILE.
Issue: 3-1 DN09106695 35

1 Enable the restriction on users attached to an administrative profile

ZWOC:58,0008,0001;
2 Check that the parameter UA_RESTRICT_ADMIN_USER has been activated

successfully
ZWOI:58,0008;
3 Disable the restriction on users attached to an administrative profile

ZWOC:58,0008,0000;
2.2 Managing MML command logs

2.2.1 Printing out data from MML command log
You can print out data from the MML command log into a logical file or MML terminal.
The following example shows how to print data from the log into a text file named
MMLOUT.TXT via a logical file named MMLLOGOUT.
1 Create the logical file

Create a temporary logical file and connect it to the system disk.
ZIIF::MMLLOGOUT,T:DEV=WDU-S;
2 Create a subdirectory
The physical file has to be stored to the MMDIRE/MLOGS directory.
ZIWL::WS:MMDIRE:MLOGS,100,2,QA;
3 Create the physical file in the MMDIRE/MLOGS directory

ZIWC::WS:MMDIRE,MLOGS:MMLOUT,TXT,100,QA:;
If a file already exists, but it contains data, you can empty it with the command:
ZIWE::WS:MMDIRE,MLOGS:MMLOUT,TXT;
4 Connect the logical file to the physical file

ZIII::MMLLOGOUT:,MMDIRE,MLOGS:MMLOUT,TXT,;
5 Print out data from the MML command log

Print out the data related to user MSFORD and recorded today between 9:00 A.M.
and 1:00 P.M., and save the data to the logical file created above.
ZIGO:,00-00,,09-00:USERID=SYSTEM::OUTPUT=MMLLOGOUT;
36 DN09106695 Issue: 3-1

2.3 Managing security reporting

2.3.1 Outputting a detailed security report
1 Activate the monitoring of an MML command

ZIAM:<command>:SECN=YES;
2 Activate the MML command

This is the command to be monitored.
ZUSI;
3 Output a detailed security report

Output a detailed security report on the events associated with the MML commands
on the current day (default) from 7:00.
ZIRO:TYPE=MCO:TIME=07-00;
The MML command monitored is now shown in the security report:
DETAILED SECURITY REPORT: MML COMMANDS
COMMAND USERNAME TERMINAL DATE TIMEIAH

USER01 MANCHES/VTP3 2010-05-26 14:01:34
STATUS: COMMAND EXECUTED
IAI USER02 MANCHES/VTP3 2010-05-26 14:01:51
STATUS: COMMAND EXECUTED
COMMAND EXECUTED
4 Output a service terminal report

To display the service terminal report containing all events, give the following
command:
ZIRO:TYPE=SET;
In the execution printout, the DEBUG! identifier means that logon to the Network
Element (NE) has been done with a fixed username for the service terminal:
DETAILED SECURITY REPORT: SERVICE TERMINAL SESSIONS

USERNAME TERMINAL ACTION DAT TIME
USER01 OMU-1 /CONSOLE-0 START 2010-05-26 06:07:12
STATUS: ILLEGAL PASSWORD
USER01 OMU-1 /CONSOLE-0 START 2010-05-26 06:07:28

STATUS: SUCCESS
USER01 OMU-1 /CONSOLE-0 STOP 2010-05-26 06:16:04

STATUS: SUCCESS
USER02 CM-0 /REMOTE START 2010-05-26 08:19:54

STATUS: SUCCESS
Issue: 3-1 DN09106695 37

USER02 CM-0 /REMOTE STOP 2010-05-26 08:19:54

STATUS: SUCCESS
USER03 OMU-0 /REMOTE START 2010-05-26 08:20:20

STATUS: SUCCESS
USER03 OMU-0 /REMOTE STOP 2010-05-26 08:20:21

STATUS: SUCCESS
COMMAND EXECUTED
2.4 Configuring FTP server

By default, the FTP service is enabled, but the FTP authority is disabled (defined as
"none") for all O&M users in their MMI profiles for the security reasons. To enable the
FTP authority (read, or alternatively read + write) for O&M users under certain MMI
profile, carry out the following steps.
1 Check the current FTP configuration

ZI2H:PROTOCOL=FTP:;
2 Change the configuration of the FTP server, if needed.

ZI2G:IPV4STATE=<ON/OFF>,IPV4PORT=<port
number>:IPV6STATE=<ON/OFF>,IPV6PORT=<port number>:;
3 Create a user profile with FTP access rights

ZIAA:<profile>::::FTP=<authority>;
4 Create a user ID for the profile

ZIAH:<user id>:<profile>:;
5 If needed, change the FTP privileges of the user profile as Read, Write or No
Access.
2.5 Configuring HTTPS server

HTTPS (HTTP over SSL/TLS) protocol provides a secure way to use the Network
Element Web Manager interface over an insecure network by applying SSLv3/TLSv1
based protection (end-to-end) for HTTPS sessions. HTTPS ensures protection from
eavesdroppers and man-in-the-middle attacks assuming certificate based authentication
exists in the OMU functional unit in SSL/TLS level configurations.
The HTTPS server is an optional feature which is activated in the software build during
network element release upgrade or integration phase.
38 DN09106695 Issue: 3-1

t Before HTTPS can be used, network element end-entity certificate, private key related
to it and trusted CA certificate must have been added to the network element key
storage (with the commands of the Q4 command group) and enabled for OMU
functional unit in SSL/TLS layer configurations (with the commands of the I3 command
group). For more information, see section Configuring SSL/TLS authentication proxy.
1 Enable HTTPS server

ZI2C:PROTOCOL=HTTPS:IPV4STATE=ON:IPV6STATE=OFF;
g The parameter HTTPS is visible only if the feature HTTPS WEBGUI is in use.
The status of the command execution is displayed in the execution printout.
2 Disable the HTTP server, if needed.

ZI2C:PROTOCOL=HTTP:IPV4STATE=OFF:IPV6STATE=OFF;
t If needed, the HTTP server can be enabled again with the following command:
ZI2C:PROTOCOL=HTTP:IPV4STATE=ON:IPV6STATE=OFF;
2.6 Configuring XOHS server

XOHS protocol provides a secure way to configure XML over HTTP feature over an
insecure network. When XOHS protocol is used, configuration requests are transmitted
using HTTPS (HTTP over SSL/TLS) protocol. HTTPS ensures protection from
eavesdroppers and man-in-the-middle attacks assuming certificate based authentication
exists in the OMU functional unit in SSL/TLS level configurations.
The XOHS server is an optional feature which is activated in the software build during
network element release upgrade or integration phase.
t Before XOHS can be used, network element end-entity certificate, private key related to
it and trusted CA certificate must have been added to the network element key storage
(with the commands of the Q4 command group) and enabled for the OMU functional
unit in SSL/TLS layer configurations (with the commands of the I3 command group).
For more information, see section Configuring SSL/TLS authentication proxy.
1 Enable XOHS server

ZI2C:PROTOCOL=XOHS:IPV4STATE=ON:IPV6STATE=OFF;
g The parameter XOHS is visible only if the feature HTTPS SOAP REQUEST is in use.
The status of the command execution is displayed in the execution printout.
2 Disable the XOHS server, if needed.

ZI2C:PROTOCOL=XOH:IPV4STATE=OFF:IPV6STATE=OFF;
Issue: 3-1 DN09106695 39

t If needed, XOH server can be enabled again with the following command:
ZI2C:PROTOCOL=XOH:IPV4STATE=ON:IPV6STATE=OFF;
2.7 Configuring XOH HTTPS protocol

The XOH HTTPS protocol is an optional feature which is controlled by the network
element FIFILE. XOH is short for XML over HTTP.
1 Activate HTTPS_XOH_INTERFACES
ZWOA:058,0007,A;
If the network element FIFILE does not contain XOH HTTPS feature, the network
element prints out:
PARAMETER NOT FOUND FROM PARAMETER FILES
2 Configure SSL_TLS authentication

For details, see section Configuring SSL/TLS authentication proxy.
3 Login to the network element web page

The following steps show you how to set the value of protocol in EHC00?GX.XML to
HTTPS.
The ? in EHC00?GX.XML is any value of 1, 2, 3, 4, 5.
Login to the network element web page by entering the IP address of the network
element "http://<IP address of network element>" in the address bar.
4 Open the Text editor page

Click link "Administrator -> Edit configuration files" on the left side bar to open the
Text editor page.
5 Choose LFILES/EHC00?GX.XML in File drop-down menu

Choose LFILES/EHC00?GX.XML in File drop-down menu shown in Figure 4:
Choose XML file. The ? in EHC00?GX.XML is any value of 1, 2, 3, 4, 5.
40 DN09106695 Issue: 3-1

Figure 4 Choose XML file
6 Set the value of <protocol> element

If there is no <protocol> element in the file, add "<protocol>https<protocol>" into the
file, see Figure 5: Set <protocol> element value to "https". Otherwise, set <protocol>
element value to "https".
Issue: 3-1 DN09106695 41

Figure 5 Set <protocol> element value to "https"
7 Activate file LFILES/EHC00?GX.XML

Click "Activate" button, and then choose "Yes" in the "Activate file" prompt window.
See Figure 6: Activate XML file.
42 DN09106695 Issue: 3-1

Figure 6 Activate XML file
After successful activation, the following printout is shown:

Status: File activated.
2.8 Configuring SSL/TLS authentication proxy

SSL/TLS-based connections are authenticated with X.509v3 PKI certificates.
With the commands of command group Q4, the trusted certificate issuer certificate(s)
and the network element’s own end-entity certificates can be installed to the network
element’s key storage.
Then with the commands of command group I3, the SSL/TLS server and client interfaces
of a functional unit can be assigned to apply the certificates to their SSL/TLS protocol-
based connections.
SSL/TLS protocol-based functional unit interfaces include:
• Secure RUIM client interface, which is an LDAP-over-TLS-based client interface in

the OMU, applied to connect the O&M system of a network element to the RUIM
LDAP server interface of a network management system (NMS).
• HTTP server XML-over-HTTPS request interface in the OMU, applied to receive
NMS-originated XML-over-HTTPS requests.
Issue: 3-1 DN09106695 43

• XML-over-HTTPS notification client interface in the OMU, applied to send XML-over-

HTTPS notifications towards the NMS.
• HTTP server HTTPS network-element-web-manager-WebGUI interface in the OMU.
Network security-related X.509v3 PKI certificates are operator-specific and are provided
by the operator’s certificate issuer. Therefore, the SSL/TLS server and client interfaces of
a functional unit do not, by default, apply any certificates to their SSL/TLS connections.
Above presented means that by default, without below described operator specific
certificate configuration operations, functional unit does not authenticate remote
SSL/TLS peers to the extent required to guarantee network-level security.
• do not include end-entity certificates or trusted-certificate-issuer certificates in the

SSL/TLS handshake-related server-and-client hello packets.
• do not verify an SSL/TLS certificate issued by a remote peer, if such a certificate is
included in an SSL/TLS hello packet.
In other words, the SSL/TLS interfaces operate in a non-authenticated mode when

applying default configurations. To configure the interfaces to function in a authenticated
mode, follow the instructions given below.
1 Transfer the CA certificate of a trusted-certificate issuer to the hard drive

The certificate is in the straight DER (ASN.1) binary format, not, for example, in the
PKCS#7-enveloped format.
In this example, the CA certificate is stored to the active software packet directory on
the hard drive of the OMU with filename CACERT.BIN.
2 Transfer the network element’s own end-entity certificate to the hard drive
The certificate is in the straight DER (ASN.1) format, not, for example, in the
PKCS#7-enveloped format.
In this example, the certificate is stored to the active software packet directory with
filename OWNCERT.BIN.
3 Transfer the network element’s own RSA or DSA private key to the hard drive
The private key is a PKCS#1 (RSA or DSA) private key in the DER-encoded (ASN.1)
binary format. It is needed for the network element’s end-entity certificate.
In this example, the private key is stored to the active software package directory on
the hard drive of the OMU with filename OWNPRIV.BIN
4 Configure the trusted CA certificate from the hard drive to the key storage
ZQ4A:CACERT,C:F,”W0-CACERT.BIN”:;
The trusted CA certificate is stored to the network element’s internal key storage with
name CACERT.
5 Remove the CA certificate file from the hard drive

ZDDS:;
ZLP:M,MAS
44 DN09106695 Issue: 3-1

ZMD:W0-CACERT.BIN
ZE
6 Configure the end-entity certificate from the hard drive to the key storage
ZQ4A:OWNCERT,C:F,”W0-OWNCERT.BIN”:;
The end-entity certificate is stored to the network element's internal key storage with
name OWNCERT.
7 Remove the end-entity certificate file from the hard drive

ZDDS:;
ZLP:M,MAS
ZMD:W0-OWNCERT.BIN
ZE
8 Configure the private key of the end-entity certificate from the hard drive to the
key storage
ZQ4A:OWNPRIV,P:F,”W0-OWNPRIV.BIN”:;
The private key is stored to the network element’s internal key storage with name
OWNPRIV.
9 Remove the private key of the end-entity certificate from the hard drive
ZDDS:;
ZLP:M,MAS
ZMD:W0-OWNPRIV.BIN
ZE
10 Assign the SSL/TLS server and client interfaces to apply the configured
certificates to SSL/TLS-based connections
ZI3C:OMU:OWNCERT,OWNPRIV:CACERT:;
After this, the OMU applies the configured certificates to all SSL/TLS connections:
• In an SSL/TLS handshake, the SSL/TLS server and client interfaces verify that a
remote peer end-entity certificate is issued and digitally signed by the same
certificate issuer's CA certificate that has been configured as trusted.
• The OMU checks that the validity time in the remote peer certificate is correct.
This is done by comparing the 'not before' and 'not after' parameters in the
certificate to the calendar time of the system.
• The OMU includes its end-entity certificate and the trusted-certificate-issuer
certificate in the SSL/TLS server-and-client hello message in an SSL/TLS
handshake. This makes it possible for the remote peer (server or client) to
authenticate the OMU end-entity certificate in the same way as the OMU
authenticates the remote peer's certificate.
The SSL/TLS-level authentication functionalities do not include certificate revocation-
related functionalities.
Issue: 3-1 DN09106695 45

SSL/TLS functionalities cannot be connected to a CA entity certificate revocation list

(CRL) distribution point server interfaces in the same way as, for example, the
integrated IPSec functionalities can.
As a result, the SSL/TLS functionalities do not verify certificate revocation in
SSL/TLS handshakes by obtaining CRLs from the CA entity interfaces or by verifying
certificate revocation status with the OCSP.
Certificate issuer solutions
Linux/Unix de-facto OpenSSL tools are one example of small-scale certificate issuer
tools.
OpenSSL, which is delivered in de-facto Unix/Linux distributions, is one of the most
easily-acquired tools that can be applied to generate X.509v3 PKI certificates,
suitable for SSL/TLS and IPSec end-entity usage.
CSI Insta Certifier CA entity solution, again, is an example of a more comprehensive
certificate issuer or CA entity solution, which supports LDAP and HTTP-based CRL
distribution point and web enrolment interfaces (for example, CMP over HTTP).
The following examples show you how to use de-facto OpenSSL tools to convert
certificates and private keys from the PEM (ACSII) format into the DER (ASN. 1)
binary format suitable for the system.
• To convert a PEM-format X.509v3 PKI certificate into the DER binary format:
openssl x509 -inform PEM -outform DER - in
cert_filename.pem -out cert_filename .bin
• To convert a PEM-format PKCS#1 RSA private key into the DER binary format:
openssl rsa -inform PEM -outform DER - in rsa_rilename.pem
- out rsa_filename .bin
• To convert a PEM-format PKCS#1 DSA private key into the DER binary format:
openssl dsa -inform PEM - outform DER -in dsa_filename.pem
- out dsa_filename .bin
2.9 Configuring MMI over SSH server interface for OMU
1 Activate the SSH feature

ZWOA:58,2,A:;
2 Create RSA and DSA keys

ZI2K:<public key’s name>,<private key’s name>:<key type
(RSA/DSA)>:<key size>:;
For example:
ZI2K:PUBKEYNM01,PRIKEYNM01:RSA:1024:;
ZI2K:PUBKEYNM02,PRIKEYNM02:DSA:1024:;
3 Enable the SSH server

ZI2S:IPV4STATE=ON,IPV4PORT=22:IPV6STATE=OFF:RSAKEY=<private
RSA key’s name>,DSAKEY=<private DSA key’s name>:60:;
For example:
46 DN09106695 Issue: 3-1

ZI2S
:IPV4STATE=ON,IPV4PORT=22:IPV6STATE=OFF:RSAKEY=PRIKEYNM01,DSAK
EY=PRIKEYNM02:60:;
The status of the command execution is shown in the execution printout.
If the configuration cannot be changed, the failed cases are listed. The execution
printout shows the session type, protocol, computer unit, and the status of the
operation. For example:
CONFIGURATION FAILED IN FOLLOWING UNITS:
SSH OMU
IPV4 TIME LIMIT EXCEEDED IN MESSAGE WAITING
IPV6 TIME LIMIT EXCEEDED IN MESSAGE WAITING
COMMAND EXECUTED
4 Disable MML over Telnet connections

ZI2T:TYPE=MML:IPV4STATE=OFF:IPV6STATE=OFF:;
Although the MML over Telnet connection is set OFF, the Telnet port is still visible in
the execution printout until all MML sessions established before the state change are
closed.
Despite this, new MML sessions cannot be opened using the Telnet protocol.
2.10 Configuring SFTP server interface
1 Check that the SSH server has been configured

ZQRS:OMU;
2 Configure the SSH server if it has not been configured

a) Activate the SSH feature
ZWOA:58,2,A:;
b) Create RSA and DSA keys
ZI2K:<public key’s name>,<private key’s name>:<key type
(RSA/DSA)>:<key size>:;
c) Enable the SSH server
ZI2S:IPV4STATE=ON,IPV4PORT=22:IPV6STATE=OFF:RSAKEY=<private
RSA key’s name>,DSAKEY=<private DSA key’s name>:60:;
3 Activate the SFTP feature

ZWOA:58,3,A:;
Issue: 3-1 DN09106695 47

4 Enable the SFTP server

ZI2Q:STATE=ON;
5 Disable the FTP server, if needed.

ZI2G:IPV4STATE=OFF:IPV6STATE=OFF;
2.11 Managing network element IP security

Feature 31302 IP Security is a network security extension to IP protocol stack
functionalities of network element functional units, providing capabilities for in-host IP
Access Control List (ACL) filtering and IPSec Virtual Private Network (VPN) termination
in the same functional units which terminate the IP-based connections.
The capability to construct IP ACL filtering configurations is supported by default and is
provided without optional controls of the feature.
The capability to configure IPSec VPN termination is an optional extension controlled
with the software license based feature codes: 1057 IPSec for management
plane and 1058 IPSec for control plane.
• Feature code 1057 provides the capability to configure IPSec VPNs to OMU, Open
TAS and MSS/MSC CHU, Open TAS and MSS/MSC STU, HLR EMU, HLR EIRU
and SGSN MCHU functional units.
• Feature code 1058 provides the capability to configure IPSec VPNs to the other
functional units of Open TAS, MSS/MSC, HLR, SGSN and MME, excluding user
plane termination units, for example, SGSN IOCP unit.
g Activating both feature codes 1057 and 1058 provides the capability to configure IPSec
VPNs to all functional units. For BSC products, only feature code 1057 is supported and
the capability to configure IPSec VPNs is only for OMU.
The following examples show how to configure in-host IP ACL filtering and IPSec VPNs
for OMUs of network elements. The examples present the configurations on Operability
Administration and Maintenance (OAM) IP-based network interfaces between OMU and
network management site. For other functional units, the corresponding configuration
logic can be applied to the interfaces, such as the charging interfaces of MSS/MSC, and
the Lawful Interception (LI) interfaces of MSS/MSC, SGSN and MME.
2.11.1 Configuring IPSec VPNs for OMU with IKE pre-shared key-
based VPN authentication
Purpose
See Figure 7: Configuring network element IPSec with IKE pre-shared key-based VPN
authentication, IPSec protection is configured for O&M traffic in network element A1. The
same procedure applies to network elements B1 and B2.
48 DN09106695 Issue: 3-1

Figure 7 Configuring network element IPSec with IKE pre-shared key-based VPN
authentication
Site A SiteB
NE A1 M-planebackbone NEB1
(e.g.10.0.0.0/24)
OMUIP address OMUIP address
10.0.0.9/24 10.0.0.11/24
NEB2
OMUIP address
VPN-GWWANsideIP address
10.0.0.13/24
10.0.0.8/24
VPN-GW(cluster)
NMSSite
Trustednetwork
domain
192.168.8.0/24
Network
management
(NetAct)servers
On site B (remote site), IPSec VPNs are terminated in the same functional unit which
terminates the IP connections.
On the NMS site, IPSec VPNs are terminated in the VPN GW cluster. There is no IPSec
protection within the NMS site, because the site-internal network is considered trusted.
t Figure 7: Configuring network element IPSec with IKE pre-shared key-based VPN
authentication shows the basic principles of the IPSec configuration logic, but the
details may vary in different network environments, depending, for example, on the
network topology and VPN GW type.
Data used in the example:
• The IPSec VPN authentication is based on IKE pre-shared keys.

• The encapsulation method is ESP in tunnel mode.
• The IP address of the IPSec tunnel endpoint in the VPN GW is 10.0.0.8.
• The IP address of OMU is 10.0.0.9.
• The IP address space of the network management site is 192.168.8.0/24.
• The cipher and message authentication algorithms are AES-256 and SHA1 for both
IKE and IPSec security associations.
• The value of the ISAKMP modp group and the PFS modp group is 2.
Issue: 3-1 DN09106695 49

1 Install the license containing IPSec for management plane

ZW7L:<license file name>:;
2 Activate feature code 1057

ZW7M:FEA=1057:ON:;
3 Create an IKE pre-shared key to be used in IPSec VPN authentication between

OMU and VPN GW
The name of the key is PSKOM.
ZQ4A:PSKOM,S:K:A;
Enter the key value when the following prompt appears:
ENTER KEY (MAX 32 CHARACTERS)
4 Create traffic handling rules
a) Create a rule which passes all IPv4 traffic in plaintext

ZQ2C:PASSV4,P,BOTH:,"0.0.0.0/0":"0.0.0.0/0":;
b) Create a rule which passes IPSec signalling in plaintext
The IPSec signalling is ISAKMP/IKE protocol traffic (UDP traffic to/from port 500).
ZQ2C:PASSIKEV4,P,BOTH:UDP,"0.0.0.0/0",500:"0.0.0.0/0",500;
5 Create a host-to-network type IPSec rule

The rule applies ESP encapsulation in tunnel mode to all IPv4 traffic between OMU
and the IP addresses on the network management site.
ZQ2C
:ESPNMS,I,TN,"10.0.0.9","10.0.0.8":,"10.0.0.9":"192.168.8.0/24
":2,2,,1,1,,PSK,PSKOM:E,,,1,1:;
6 Activate IPSec for OMU

ZQ2K:OMU:::::PASSV4:;
The rule PASSV4 is attached to OMU during the activation of IPSec.
7 Attach the traffic handling rules to OMU
a) Attach rule PASSIKEV4

ZQ2A:OMU::PASSIKEV4:;
b) Attach rule ESPNMS
ZQ2A:OMU::ESPNMS:;
8 Detach rule PASSV4 from OMU

ZQ2R:OMU::PASSV4:;
50 DN09106695 Issue: 3-1

When the rule has been detached from OMU, it accepts only IPSec VPN
connections originating from network 192.168.8.0/24 and delivered through VPN-GW
at IP address 10.0.0.8.
The MMI over Telnet O&M connection is unavailable until the corresponding ESP in
transport mode policies have been configured in the NMS site VPN-GW.
9 Check that the configuration was created correctly

ZQ2L:OMU:;
Example output:
INTERROGATING IPSEC CONFIGURATION
COMPUTER UNIT:.......... OMU

CA DEFINITION SET ID:...
PUBLIC KEY:.............
PRIVATE KEY:............
PUBLIC INTERFACE:.......
PRIVATE INTERFACE:......
CERTIFICATE EXPIRE SET:.
RULES:.................. PASSIKEV4
ESPNMS
2.11.2 Configuring IPSec VPNs for OMU with PKI certificate-

based VPN authentication
Purpose
The following data is used in the example:
• There are two VPNs:

– One for securing the traffic which relates to certificate management between
OMU and PKI CA portal, located network management site IP address
192.168.8.10
– One for securing the rest of the O&M traffic between OMU and network
management site elements.
• The encapsulation method is ESP in tunnel mode.

• The IP address of the IPSec tunnel endpoint in the VPN GW is 10.0.0.8.
• The IP address of OMU is 10.0.0.9.
• The IP address space of the network management site is 192.168.8.0/24.
• The IPSec VPN authentication is based on IKE pre-shared keys. The IPSec VPN
which secures the rest of the O&M traffic is authenticated with X.509v3 PKI
certificates.
• The cipher and message authentication algorithms are AES-256 and SHA1 for both
IKE and IPSec security associations.
• The value of the ISAKMP modp group and the PFS modp group is 2.
1 Install the license containing IPSec for management plane

ZW7L:<license file name>:;
Issue: 3-1 DN09106695 51

2 Activate feature code 1057

ZW7M:FEA=1057:ON:;
3 Configure trusted CA certificate in the network element

This can be done in one of two ways:
To configure the certificate from the OMU unit’s file system to the network-
element key storage:
a) Download the file which contains the trusted CA certificate to the file system. In
this example, the name of the file is CA1.CRT.
b) Configure the CA certificate to the network element-internal key storage.
ZQ4A:CA1CERT,C:F,”W0-/CA1.CRT”:;
c) Remove the CA1.CRT file from the file system.
ZDDS;
ZLP:M,MAS
ZMD:W0-/CA1.CRT
d) Create the CA definition set, which is equipped with CA certificate CA1CERT.
ZQ2T:CA1::CA1CERT;
To configure the certificate by fetching it from the CA entity LDAP server:
a) Create a pre-shared key to be used in IPSec VPN authentication between OMU
and VPN-GW on the network management site providing access to PKI CA entity
services.
ZQ4A:PSKCA,S:K:A;
Enter the key value when you get the prompt:
b) Create a rule which passes all IPv4 traffic in plaintext.
ZQ2C:PASSV4,P,BOTH:,"0.0.0.0/0":"0.0.0.0/0":;
c) Create a rule which passes IPSec signalling in plain text. The IPSec signalling is
ISAKMP/IKE protocol traffic (UDP traffic from or to port 500).
ZQ2C:PASSIKEV4,P,BOTH:UDP,"0.0.0.0/0",500:"0.0.0.0/0",500:;
d) Create a rule which secures IPv4 traffic towards PKI CA entity on the network
management site.
ZQ2C
:ESPCA,I,TN,"10.0.0.9","10.0.0.8":,"10.0.0.9":"192.168.8.10
":2,2,,1,1,,PSK,PSKCA:E,,,1,1:;
e) Create CA definition set which contains information about the CA LDAP server.
The identification of the set is CA1.
ZQ2T:CA1::N,LDAP,"192.168.8.10",389:;
f) Activate IPSec for OMU.
ZQ2K:OMU::CA1:::PASSV4;
Rule PASSV4 is attached to OMU during the activation of IPSec.
g) Attach rule PASSIKEV4 to OMU.
ZQ2A:OMU::PASSIKEV4,PASSV4:;
h) Attach rule ESPCA to OMU.
ZQ2A:OMU::ESPCA,PASSV4;
i) Check the results.
ZQ2L:OMU:;
Example output:
INTERROGATING IPSEC CONFIGURATIONS
COMPUTER UNIT:............OMU
52 DN09106695 Issue: 3-1

CA DEFINITION SET:.....CA1
PUBLIC KEY:...............
PRIVATE KEY:..............
PUBLIC INTERFACE:.........
PRIVATE INTERFACE:........
CERTIFICATE EXPIRE SET:...
RULES:.................PASSIKEV4
ESPCA
PASSV4
COMMAND EXECUTED
j) Detach rule PASSV4 from OMU.
ZQ2R:OMU::PASSV4;
When rule PASSV4 has been detached from OMU, the unit accepts only ESP-
encapsulated traffic originated from IP address 192.168.8.10 and encapsulated
by the VPN GW (address 10.0.0.8).
This OMU Ethernet interface can now be connected to the management plane
network so that OMU can obtain the CA certificate from the network
management site.
The MMI over Telnet traffic from an IP address other than 192.168.8.10 is
discarded. The following MML commands can be given locally from the VIMMLA
service terminal extension in OMU, or remotely from the network management
site IP address 192.168.8.10.
k) Configure the trusted CA certificate in the network element-internal key storage
by fetching it from the CA entity LDAP server.
ZQ2F:OMU:CA1CERT:C,”CN=CA1,O=Operator,C=FI”:;
l) Add the CA certificate CA1CERT to the CA definition set CA1.
ZQ2Y:CA1:ADDCA:CA1CERT:;
4 Create a watchdog to supervise the validity periods of the certificates

The name of the watchdog is ALARMEXP, and it raises an alarm 60 days before the
certificate supervised by it is expiring.
ZQ2G:ALARMEXP:A:60,0:;
Output:
CONFIGURED CERTIFICATE EXPIRE SET
CERTIFICATE EXPRE SET ID:....ALARMEXP

ACTION:.....................RAISE ALARM
START IN DAYS:...........60
START IN HOURS...........0
COMMAND EXECUTED
5 Attach the watchdog to the CA definition set CA1

ZQ2Y:CA1:ADDEXP:ALARMEXP:;
Now the ALARMEXP watchdog supervises the validity of the CA certificates included
in the CA1 definition set.
Issue: 3-1 DN09106695 53

6 Create the network element’s own certificate in the network element-internal

key storage
This can be done in one of two ways:
To configure the certificate and private key from the OMU unit’s file system:
a) Download the file which contains the network element’s own X.509v3 PKI
certificate to the OMU unit’s file system. The file name can be, for example,
OWN.CRT.
ZQ4A:OWNCERT,C:F,”W0-/OWN.CRT”:;
b) Download the file which contains the private key related to the certificate to the
OMU unit’s file system. The file name can be, for example, OWN.PRV.
ZQ4A:OWNPRIV,P:F,”W0-/OWN.PRV”:;
c) Remove files OWN.CRT and OWNPRV from the OMU unit’s file system.
ZDDS;
ZLP:M,MAS
ZMD:W0-/OWN.CRT
ZMD:W0-/OWN.PRV
ZE
To generate the network element’s own private key in OMU and CA-signed
certificate by CMP enrollment from the network management site PKI CA
entity:
a) Create a pre-shared key for the CMP enrolment.
The CMP provider defines the value of the key. The name of the key can be, for
example, CA1CMPKEY.
ZQ4A:CA,CMPKEY,S:K:A:;
Enter the key value when the following prompt appears:
b) Add a certificate enrolment point definition to the CA definition set CA1.
ZQ2Y
:CA1:ADDCEP:CMP,CA1CMPKEY,”http://192.168.8.10:8080/pkix/”,
1234;
Where
• http://192.16.8.8.10:8080/pkix/ is the address of the enrolment service.
• 1234 is a reference number, which is needed with the CMP pre-shared key to
authenticate the network element CMP client to the CMP service provider.
c) Enrol the certificate to the network element.

ZQ2E
:OMU,0:OWNCERT,OWNPRIV:"C=FI,O=Operator,CN=NEA1":RSA,2048:;
The command generates a 2048-bit RSA public/private key pair for the network
element and sends a certificate request to the PKI CA entity CMP server.
As a result of a successful enrolment, the NE’s own certificate and private key
related to it are generated in the NE-internal secure key storage with
identifications OWNCERT and OWNPRIV.
7 Create traffic handling rules
a) Create a rule which passes all IPv4 traffic in plain text.

ZQ2C:PASSV4,P,BOTH:,”0.0.0.0/0”:”0.0.0.0/0”:;
b) Create a rule which passes IPSec signalling in plain text.
The IPSec signalling is ISAKMP/IKE protocol traffic (UDP traffic from or to port
500).
54 DN09106695 Issue: 3-1

ZQ2C:PASSIKEV4,P,BOTH:UDP,”0.0.0.0/0”,500:”0.0.0.0/0”,500:;
Create a host-to-network-style IPSec VPN rule, which applies ESP encapsulation
in tunnel mode to all IPv4 traffic between OMU and the IP addresses on the
network management site.
ZQ2C
:ESPNMS,I,TN,"10.0.0.9","10.0.0.8":"192.16.8.8.0/24":2,2,,1
,1,,RSS: E,,,1,1:;
8 Attach traffic handling rules to OMU
a) Activate IPSec for OMU.

ZQ2K:OMU:CA1:::PASSV4;
b) Assign its own certificate and private key to OMU.
ZQ2Q:OMU::ADDKEY,OWNCERT,OWNPRIV:;
c) Attach rule PASSIKEv4 to OMU.
ZQ2A:OMU::PASSIKEV4,:;
d) Attach rule ESPNMS to OMU.
ZQ2A:OMU::ESPNMS,:;
e) Check the configuration.
ZQ2L:OMU;
Example output:
INTERROGATE IPSEC CONFIGURATION
COMPUTER UNIT:...............OMU
CA DEFINITION SET:........CA1
PUBLIC KEY:...............OWNCERT
PRIVATE KEY:..............OWNPRIV
PUBLIC INTERFACE:.........
PRIVATE INTERFACE:........
CERTIFICATE EXPIRE SET:...
RULES:....................(PASSV4)
PASSIKEV4
(ESPCA)
ESPNMS
f) Detach rule PASSV4 from OMU.
ZQ2R:OMU::PASSV4:;
When the rule has been detached from OMU, the unit accepts only IPSec VPN
connections originating from network 192.168.8.0/24 and delivered through VPN-
GW at IP address 10.0.0.8.
The MMI over Telnet O&M connection is unavailable until the corresponding ESP
in transport mode policies have been configured in the NMS site VPN-GW.
9 Create a watchdog to supervise the validity of the network element’s own

certificate
If the network element’s own certificate was generated using the CA CMP interface,
you can configure the network element to renew the certificate automatically via the
same CMP protocol interface when the system detects that the certificate is expiring
within a short period of time.
In this case, you need to create a new watchdog and include it in OMU.
Create a watchdog called ENROLLEXP, which executes an automatic renewal of the
certificate 30 days before the expiration date and raises an alarm if the operation
fails.
Issue: 3-1 DN09106695 55

ZQ2G:ENROLLEXP:E:30,0:;
Output:
CONFIGURED CERTIFICATE EXPIRE SET
CERTIFICATE EXPIRE SET ID:.....ENROLLEXP

ACTION:......................AUTOMATIC CERTIFICATE ENROLLMENT
START IN DAYS:.............30
START IN HOURS:.............0
COMMAND EXECUTED
ZQ2Q:OMU::ADDEXP,ENROLLEXP:;
Alternatively, you can configure the network element to raise an alarm when it
detects that the certificate is expiring within a short period of time.
In this case, you can use the same watchdog that was created to supervise the
validity of the CA certificate.
ZQ2Q:OMU::ADDEXP,ALARMEXP:;
Further information
The maximum number of trusted CA certificates per OMU is five.
If you want to remove a certificate from the list, give the following command:
ZQ2Y:<name of definition set>:REMCA: <name of certificate>:;
If you want to add a certificate to the list, give the following command:
ZQ2Y:<name of definition set>:ADDCA: <name of certificate>:;
2.11.3 Configuring in-host IP ACLs for OMU

The in-host IP ACL configurations assume the similar network environment and IP
addresses shown in Figure 7: Configuring network element IPSec with IKE pre-shared
key-based VPN authentication. The example configuration causes network element A1
OMU filtering out the IP datagrams which are not transmitted between OMU and network
192.168.8.0/24. The same configuration also can be applied to network elements B1 and
B2 for the same filtering functionality.
1 Create a traffic handling rule

ZQ2C:PASSNMS,P,BOTH:,"0.0.0.0/0":"192.168.8.0/24":;
The rule passes all IPv4 traffic in plaintext towards the IP addresses within network
192.168.8.0/24 on NMS site.
2 Activate IPSec for OMU

ZQ2K:OMU:::::PASSNMS:;
The rule PASSNMS is attached to OMU during the activation of IPSec. After
executing this command, OMU filters out the IP datagrams which are not transmitted
between OMU and network 192.168.8.0/24.
56 DN09106695 Issue: 3-1

3 Check that the configuration was created correctly

ZQ2L:OMU:;
Example output:
INTERROGATING IPSEC CONFIGURATION
COMPUTER UNIT:.......... OMU

CA DEFINITION SET ID:...
PUBLIC KEY:.............
PRIVATE KEY:............
PUBLIC INTERFACE:.......
PRIVATE INTERFACE:......
CERTIFICATE EXPIRE SET:.
RULES:.................. PASSNMS
Issue: 3-1 DN09106695 57

Security and user management troubleshooting Security and User Management
3 Security and user management

troubleshooting
3.1 Command can be executed by unauthorized user

Steps
1 Check the terminal's authority rights.

On a super terminal, any user can execute commands that belong to the classes to
which the terminal has special authority. Check if the terminal has special authority
(authority value 251).
To output the user profiles of all user identities and the contents of the profiles, give
the following command:
ZIAI:USERID=ALL:COM;
g All remote connections to the MMI system are routed through the virtual terminal (VT). If
the VT has a super terminal profile, all remotely connected users who log in through
Telnet/SSH get super user rights as terminal authority 251 runs over their profile-
defined user rights.
If super terminal rights are needed, add the super terminal profile only to the VDUs.
If the terminal has special authority, go to step Change the terminal's authority
rights..
If the terminal does not have special authority, go to step Report the trouble if
necessary..
2 Change the terminal's authority rights.

Change the authority of the terminal to 250 at the most. After that the terminal is no
longer a super terminal, and the MML session authority is defined by the user
authority.
To define new authority requirements for a profile, give the following command:
ZIAA:<profile>:<command class>=<authority>;
3 Report the trouble if necessary.

Report the trouble according to the fault reporting practice.
58 DN09106695 Issue: 3-1

Security and User Management Security and user management troubleshooting
3.2 A blocked command can be executed by

unauthorized user
Steps
1 Check the user rights.

A super user is allowed to execute also blocked commands. Check if the user has
special authority (authority value 251) in the command class in question.
Check also the FTP accessibility of a user profile.
To output the user profile of a certain user identity and the contents of the profile,
give the following command:
ZIAI:USERID=<user id>:COM;
If the user does not have special authority, go to step Check the terminal's authority
rights..
If the user has special authority, go to step Change the user or authority rights to
block a command..
2 Check the terminal's authority rights.

Blocked commands can be executed from a super terminal. Check if the terminal has
special authority (authority value 251) in the command class in question.
To output the profile names and contents of a certain terminal, give the following
command:
ZIAI:TERMINAL=<terminal>:COM;
If the terminal has special authority, go to step Change the user or authority rights to
block a command..
If the terminal does not have special authority, go to step Report the trouble if
necessary..
3 Change the user or authority rights to block a command.

If you want to block the execution of the command altogether, change the authority of
the user or the terminal to 250 at the most.
ZIAA:<profile>:<command_class>=<authority>;

3.3 Command cannot be executed by authorized user
Issue: 3-1 DN09106695 59

3.3.1 Command cannot be executed by operator

Steps
1 Check your authority.

Check if your authority is the same or higher than the authority requirement of the
command in question.
To output the user profile of a certain user identity and the contents of the profile,
give the following command:
2 Change the terminal authority if necessary.

If the terminal authority of the command class in question is lower than the authority
requirement of the command in question and you want to execute commands
according to the authorities in your profile, change the terminal authority to be at
least as high as your own.
3 Change your password if necessary.

The problem may be due to the fact that your password has expired.
Try to change your password by giving the following command, and go back to step
Check your authority..
ZIAG;
If you cannot change your password, go to step Contact the user ID administrator..
4 Contact the user ID administrator.

Contact the user ID administrator. The user ID administrator must follow the
instructions given in section Command cannot be executed by user ID administrator.
3.3.2 Command cannot be executed by user ID administrator

Steps
g All the steps in this section are executed by user ID administrator.
1 Check if the user's password is valid.

Make sure that the user's password has not expired.
To output the user profiles of all user identities and the contents of the profiles, give
the following command:
If the password has expired, go to step Change the user's password if necessary..
If the password is still valid, go to step Check the alarms..
60 DN09106695 Issue: 3-1

2 Change the user's password if necessary.

To change the user's password, give the following command:
ZIAS:<user id>;
If you cannot change the password, go to step Report the trouble if necessary..
3 Check the alarms.

Check if any of the alarms are set.
ZAHO;
Follow the recovery instructions given in the alarm reference manuals.
If there are no active alarms, go to step Report the trouble if necessary..

3.4 The terminal authority has no effect on the user’s

authorities
Steps
1 Check the user rights.

A super user can execute commands that belong to the classes to which the user
has special authority. Check if the user has special authority (authority value 251).
To output the user profile, give the following command:
If the user has special authority, go to step Change the user rights..
If the user does not have special authority, go to step Report the trouble if
necessary..
2 Change the user rights.

Change the authority of the user to 250 at the most. After that the user is no longer a
super user.

Issue: 3-1 DN09106695 61

3.5 All terminals have too low authorities

Steps
1 Restart the session if necessary.

If all terminals have too low authorities, the MML session must be started by a super
user or on a super terminal.
If there are no super user IDs or super terminals in the system, go to step Restore
the UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG files..
If there are super user IDs or super terminals in the system, go to step Check the
terminal profiles..
2 Restore the UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG files.

Restore the UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG files from a
backup build by using either IWY or IBC MML command.
If you cannot use the MML commands, use the service terminal commands.
3 Perform OMU restart after all the files have been restored.
OMU restart is needed to make the changes in the previous step take effect.
4 Check the terminal profiles.

To output the profile names and the contents of all the terminals, give the following
command:
ZIAI:TERMINAL=ALL:COM;
5 Modify terminal profiles if necessary.

Increase terminal authorities by modifying the existing profile, or by attaching the
terminals to another profile that has enough authority, or by creating a new profile
with suitable authorities and attaching the terminals to that profile.
For example, to update the authority requirements of an existing profile, give the
following command:

62 DN09106695 Issue: 3-1

3.6 A profile has too low authorities for command

class I
Steps
1 Restart the session if necessary.

In this case, the MML session must be started by a super user or on a super
terminal.
If there are no super user IDs or super terminals in the system, go to step Restore
the UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG files..
If there are super user IDs or super terminals in the system, go to step Check the
terminal profiles and the user profiles..
2 Restore the UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG files.

Restore the UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG files from a
backup build by using either IWY or IBC MML command.
If you cannot use the MML commands, use service terminal commands.
3 Perform OMU restart after all the files have been restored.
OMU restart is needed to make the changes in the previous step take effect.
4 Check the terminal profiles and the user profiles.

To output the profile names and the contents of all the terminals, give the following
command:
5 Modify the terminal profiles and the user profiles if necessary.

Increase the authorities by modifying the existing profile, or by attaching the terminal
or user ID to another existing profile with enough authority, or by creating a new
profile with suitable authorities and attaching the terminal or user ID to this profile.
For example, to update the authority requirement of an existing profile, give the
following command:

Issue: 3-1 DN09106695 63

3.7 An unrequired profile cannot be deleted

Steps
1 Check whether there are user IDs or terminals attached to the profile.
If you cannot delete a profile as long as it is attached to any user ID or terminal,
interrogate which user IDs or terminals are attached to the profile which you want to
delete, give the following commands:
If there are terminals attached to the profile in question, go to step Attach the non-
equipped terminals to the common profile..
If there are user IDs attached to the profile, go to step Attach the user IDs to another
profile..
2 Attach the non-equipped terminals to the common profile.

There are always 16 terminals defined in the MMI system, and some of them may
not be equipped. It is recommended that you define one common profile for the
terminals that are not equipped.
Attach all the non-equipped terminals to the common profile and go to step Delete all
unnecessary profiles..
To create a new common profile with default values, give the following command:
ZIAA:<profile>;
To attach a terminal to the common profile, give the following command:
ZIAE:TERMINAL=<terminal>:<profile>;
3 Attach the user IDs to another profile.

To attach a profile to a user identity, give the following command:
ZIAE:USERID=<user id>:<profile>;
4 Delete all unnecessary profiles.

To delete all profiles that are not needed, give the following command:
ZIAR:<profile>;

64 DN09106695 Issue: 3-1

3.8 Insufficient space for more profiles

Steps
1 Interrogate unused profiles.

Interrogate all the profiles in the system to check if there are any profiles that are not
used by any user ID or terminal, give the following command:
ZIAI:PROFILE=ALL:COM;
If there are profiles which are not in use, go to step Delete unused profiles..
If all profiles are in use, go to step Contact your local customer care if necessary..
2 Delete unused profiles.

To delete the profiles that are not in use, give the following command:
ZIAR:<profile>;
3 Contact your local customer care if necessary.

Contact Customer Service Center for help if you cannot make room for more profiles.
3.9 Insufficient space for more user IDs

Steps
1 Interrogate all user IDs.

Interrogate all the user IDs in the system to check if there are user IDs that are not
needed any more, give the following command:
If there are user IDs which are no longer in use, go to step Delete unnecessary user
IDs..
If all user IDs are in use, go to step Contact your local customer care, if necessary..
2 Delete unnecessary user IDs.

To delete the unnecessary user IDs to make room for new IDs, give the following
command:
ZIAD:<user id>;
If you do not succeed, go to step Contact your local customer care, if necessary..
3 Contact your local customer care, if necessary.

Contact Customer Service Center for help if you cannot make room for more user
IDs.
Issue: 3-1 DN09106695 65

3.10 A network connection cannot be established via

FTP
Steps
1 Check that FTP access rights have been defined in the user profile.
Check that the user has a user profile with FTP access rights.
• User with local user account:
a) Check MMI profile of local user account which is used to establish a
connection to the network element.
ZIAI:USERID=<username>:COM;
b) Create a local MMI profile with FTP access rights.
ZIAA:<profile>:<command class>=<authority>:::FTP=<access
right>;
c) Attach the user profile to the user ID.
ZIAE:USERID=<username>:<profile>;
• User with remote user account:

a) Check FTP access rights of centralised user account from NetAct.
b) Create FTP access rights for the user in NetAct.
2 Check the length of the username.

If the username consists of more than 6 characters, an FTP session cannot be
started.
• User with local user account:
Ensure that 6-character-long usernames are always used when transferring files
in the network element.
• User with remote user account:
If the user account consists of more than 6 characters, create a 6-character-long
user account for the network element in NetAct.
66 DN09106695 Issue: 3-1

Security and User Management: DN09106695 Issue 3-1

Uploaded by

Copyright:

Available Formats

You might also like

Security and User Management: DN09106695 Issue 3-1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Security and User Management: DN09106695 Issue 3-1

Uploaded by

Copyright:

Available Formats

Nokia Networks

Security and User

Copyright © 2014 Nokia Solutions and Networks. All rights reserved.

f Important Notice on Product Safety

2 DN09106695 Issue: 3-1

Summary of changes .................................................................... 7

1 Security and user management overview...................................... 8

2 Managing MMI system security and network security..................31

Issue: 3-1 DN09106695 3

2.3 Managing security reporting.........................................................37

3 Security and user management troubleshooting..........................58

4 DN09106695 Issue: 3-1

Issue: 3-1 DN09106695 5

6 DN09106695 Issue: 3-1

Changes made between issues 3–1 and 3–0

Changes made between issues 3–0 and 2–0

Changes made between issues 2–0 and 1–0

Issue: 3-1 DN09106695 7

1 Security and user management overview

• The network element has TCP/IP connections.

8 DN09106695 Issue: 3-1

Centralized users can be defined only in the NetAct.

1.1.2 User IDs

• The minimum length of a password is 6 characters and the maximum length 16

Issue: 3-1 DN09106695 9

• The minimum length of a password.

You can additionally define:

10 DN09106695 Issue: 3-1

1.1.4 Delay between failed login attempts

1.1.5 Restriction on users attached to an administrative profile

Issue: 3-1 DN09106695 11

If the value of the PRFILE parameter UA_RESTRICT_ADMIN_USER (58:0008) is set to 1,

1.2 MMI user authorization

1.2.2 MML command authority

Table 1 MML command authority categories

Command Description Authority

Group 1 Critical commands that are used 250

• to change the state of the system to a significant

12 DN09106695 Issue: 3-1

Table 1 MML command authority categories (Cont.)

Command Description Authority

For example, commands for managing MMI system

Group 2 Critical commands that are used 200

• to change the state of the system to a moderate

For example, commands for managing system

Group 4 Commands that are used 100

• to change the state of the system to a very

For example, commands for modifying measurement

Group 5 Commands that are used only to check the state of 50

Issue: 3-1 DN09106695 13

1.2.3 MML user authority

1.2.4 MML terminal authority

t A change made to a profile affects all terminals attached to the profile.

1.2.5 Service terminal authority

14 DN09106695 Issue: 3-1

1.2.6 MML session authority

Figure 1 Average user rights