SP2 Version 1.0.

Kaspersky Lab
www.kaspersky.com
Table of Contents
Introduction .................................................................................................................... 4

Chapter 1. Traffic Management ..................................................................................... 4

1.1 Considerations ........................................................................................................................................................ 4
What the traffic consists of ..................................................................................................................................... 4
Traffic metrics ........................................................................................................................................................ 6
1.2 Traffic Monitoring .................................................................................................................................................. 8
1.3 Traffic Limitation Methods................................................................................................................................... 10
General traffic ...................................................................................................................................................... 10
Synchronization traffic ......................................................................................................................................... 12
Information about the computer........................................................................................................................... 12
Event traffic .......................................................................................................................................................... 14
Updates traffic...................................................................................................................................................... 14

Chapter 2. Update Agents and Connection Gateways ................................................ 16

2.1 Update Agents ...................................................................................................................................................... 16
Purpose ................................................................................................................................................................ 16
How it works ........................................................................................................................................................ 16
How to configure .................................................................................................................................................. 18
Multicast .............................................................................................................................................................. 19
Update source for an Update Agent..................................................................................................................... 22
Network polling .................................................................................................................................................... 22
Installation using Update Agents ......................................................................................................................... 22
Automatic allocation of Update Agents ............................................................................................................... 24
2.2 Connection Gateways ........................................................................................................................................... 26
Purpose ................................................................................................................................................................ 26
How it works ........................................................................................................................................................ 26
How to configure .................................................................................................................................................. 26
Connection Gateway in DMZ............................................................................................................................... 28
2.3 Monitoring Update Agents ................................................................................................................................... 30
Statistics ............................................................................................................................................................... 30
Reports ................................................................................................................................................................. 32
Dashboards .......................................................................................................................................................... 32
Search .................................................................................................................................................................. 32
klnagchk.exe ......................................................................................................................................................... 34

Chapter 3. Using Several Administration Servers ....................................................... 34

3.1 Considerations ...................................................................................................................................................... 34
Prerequisites ........................................................................................................................................................ 34
Alternatives .......................................................................................................................................................... 36
Possible architectures .......................................................................................................................................... 37
3.2 Independent Servers .............................................................................................................................................. 38
Moving computers ................................................................................................................................................ 40
Connection profiles .............................................................................................................................................. 42
3.3 Hierarchy of Servers ............................................................................................................................................. 50
Connecting to a hierarchy .................................................................................................................................... 50
Aggregate reports ................................................................................................................................................ 60
Inheritance of policies and tasks .......................................................................................................................... 62
Updates in hierarchy ............................................................................................................................................ 68
Program distribution in hierarchy ....................................................................................................................... 70
2 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Chapter 4. Managing Administrators ............................................................................ 78

4.1 Access Control ...................................................................................................................................................... 78
Main scenarios ..................................................................................................................................................... 78
Access control system description ........................................................................................................................ 78
Access control ...................................................................................................................................................... 80
Access rights ......................................................................................................................................................... 80
Additional access objects ..................................................................................................................................... 90
Creating internal users of Administration Server ................................................................................................ 92
Report on effective user rights .............................................................................................................................. 92
4.2 Audit ..................................................................................................................................................................... 94
Purpose ................................................................................................................................................................ 94
Configuring audit parameters .............................................................................................................................. 94
Audit events description ....................................................................................................................................... 94

Chapter 5. Special Features ......................................................................................... 96

5.1 Updates Testing..................................................................................................................................................... 96
Why test ................................................................................................................................................................ 96
How update testing works .................................................................................................................................... 96
How to configure updates testing ......................................................................................................................... 98
Possible results of updates testing ...................................................................................................................... 102
5.2 Policy Profiles ..................................................................................................................................................... 103
What policy profiles are and who needs them .................................................................................................... 103
How to create a policy profile ............................................................................................................................ 104
How policy profiles are applied ......................................................................................................................... 106
5.3 Tagging Rules ..................................................................................................................................................... 108
When tagging rules come in handy .................................................................................................................... 108
How to create a tagging rule .............................................................................................................................. 108
Where to find the assigned tags .......................................................................................................................... 110
5.4 Network Location Awareness ............................................................................................................................. 110
What is NLA ....................................................................................................................................................... 110
How to configure conditions for a NLA subnet .................................................................................................. 112
How to create an NLA subnet............................................................................................................................. 112
How to assign an Update Agent to an NLA subnet ............................................................................................ 112
5.5 Installing Kaspersky Security Center Failover Cluster ....................................................................................... 114
3
4 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Introduction

This course describes the use of Kaspersky Security Center administration system in large networks and its
functions and capabilities designed for this purpose. Specifically:

— Traffic management
— Update Agents and Connection Gateways
— Multi-server architectures
— Separation of duties
— Testing updates
— Installation on a cluster

These functions are usually not required in small and middle-size networks where one Administration Server is
almost always sufficient, traffic is not a problem, and there is either one administrator or several administrators
having the same permissions.

Chapter 1. Traffic Management

This Chapter describes the operations connected with information transfer between the server and client computers
and gives statistics on the volume of this information, and Kaspersky Security Center functions that help to monitor
and decrease the traffic.

1.1 Considerations

What the traffic consists of

There are several situations in which the server and client computers exchange information. Let us examine them.

Some tasks involve information transfer from the server to the client computers: Update, Installation, Uninstallation,
and, in a sense, ‘Send message to user’ tasks. All of them, except for Update tasks, are not regular and do not
influence the daily load of the Administration Server. Update tasks, on the contrary, run often and are responsible
for the majority of the daily traffic.

In addition to Kaspersky Lab updates, there are also Windows Updates and updates for programs by other
manufacturers. They are distributed less frequently, and are usually large. Running a task that fixes vulnerabilities
and installs updates can increase the network traffic considerably. If the Network Agents are configured to use
the Administration Server as the data source for Windows Updates, that data is sent between the server and
the clients when searching for vulnerabilities.

Information is also sent from server to clients when centralized settings are changed. When the administrator creates
or changes tasks and policies, the Administration Server tries to initiate connection to all clients of the group to
transfer the new settings to them. If the group is big enough, this can result in peak number of connections and peak
network load.
 5
Chapter 1. Traffic Management

Traffic can also be caused by other actions of the administrator—manual start of tasks, viewing computer properties
and statistics of the managed programs, tunneling. Except for the task start, these actions likely concern only one
client computer and exercise insignificant influence on the network and server load.

The server also generates traffic when polling the network to discover computers and when scanning the computers
discovered by the NAC subsystem.

There is also event traffic. According to group policy settings, client computers send events to the Administration
Server, which are stored in the database and used for reports. The events are sent immediately after
their registration.

In addition to events, client computers send their status information to be represented in the Administration
Console—virus counter changes, the date of the last update, scanning, etc. This data is not related to events and is
sent even if none of the events are stored in database.

Client computers periodically check their settings against the parameters specified on the Administration Server.
This process is called synchronization and takes place once every 15 minutes by default. If discrepancies are
detected, the client computer receives the actual tasks and policies from the server, and informs the server about its
status.
6 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Also, client computers send to the Administration Server the information about the installed devices and programs,
executable files and detected vulnerabilities, local quarantine and backup repository contents, and unprocessed
threats.

KSN traffic is different, because it bypasses the Network Agent unlike all the described types of traffic. KSN
requests are sent directly from Kaspersky Endpoint Security to the Administration Server. Network Agent is not
involved and because of that, standard traffic monitoring and control tools available in KSC are not applicable to
KSN traffic.

Information that creates peaks in the network load or raises the average load is problematic.

Peak load may result from running an update or fix vulnerabilities task, or mass push synchronization after global
tasks and policies are modified.

Average or background load is made up of events, KSN requests and planned synchronizations. It is also uneven, as
events and KSN requests result from the activity on the computer. During business hours they increase, and at night,
decrease.

Traffic metrics

Single data exchange sessions generate the following traffic on the Administration Server, depending on
the information type.

Traffic of the installation and update tasks:

Information Traffic Note

Network Agent installation 42 MB Package size

Installation of the standard package of KES 10 for About 270 MB 3-4% less than the database package size
Windows with databases thanks to traffic compression

Medium total size of hourly updates per day loaded 20-30 MB

by KES 10 for Windows

Traffic related to the events, policy modifications and task running

Information Traffic Note

A set of events transferred >13 KB A few events can be sent together, e.g., when an infected object is
during a single TCP session detected. About 12 KB is an invariable volume, plus 1-2 KB per
event

New task application 23-25 KB Virus Scan or Find Vulnerabilities

New KES policy enforcement 103 KB On a client OS

Changing one parameter in 35-50 KB Depends on the changed parameter. When exclusions, Firewall
KES policy rules, application categories, etc. are created, information volume
can increase considerably

Running a virus scan task 63-75 KB Since the task is started and until it is completed, including all
the events involved (Task started, Task completed)

Running a Vulnerability scan 113-115 KB See above The task has already been run, which is why a few
task vulnerabilities are found

KES 10 synchronization About 2 MB Including planned synchronizations (with the default interval,
traffic per day 15 minutes) and KSN synchronizations. Without user activity and
tasks (except updates)
 7
Chapter 1. Traffic Management
8 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

1.2 Traffic Monitoring

There are monitoring tools in the Administration Console that allow the administrator to evaluate the network load.
They are also available on the Statistics tab of the Administration Server node. By default, network statistics is not
displayed, but the administrator can easily add a new statistics page and fill it with charts displaying data exchange
speed and the number of client connections.

The following charts are available:

— Network traffic history

— Network traffic rate history
— Established connections history
— Connections frequency history
— Active connections history
— Statistics for connections to Update Agents
— Statistics for connections to slave Servers

Each chart displays either average or average and maximum values of the title index for some intervals within
the framework of the reporting period. The reporting period is specified in days in the chart properties.
 9
Chapter 1. Traffic Management
10 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

1.3 Traffic Limitation Methods

General traffic

Traffic limitation rules

If the average network load is not too high, but there are peak load periods, you can balance the load by creating
traffic limitation rules.

The rule specifies the maximum speed allowed for client-server data exchange. If the real speed exceeds
the allowed, the server increases the interval between the sent network packets, thus decreasing the data exchange
speed.

Traffic management rules are specified in the Administration Server properties, under the Traffic section. Rule
properties include subnet, the time when the rule is to be used, the speed limit for this time and the speed limit for
the rest of the day.

The speed limit defines the total data exchange speed for all client computers within the specified range, not the data
exchange speed for each client. The limitation applies to all types of traffic between the Administration Server and
Network Agents on the client computers. KSN traffic does not belong to this category and these limitations do not
apply to it. KSN traffic is on average significantly less than other types of traffic.

The subnet setting in the rule allows the administrator to set different limits for different subnets depending on how
they are connected to the Administration Server and which network equipment is used in them. Lower thresholds
can be set for remote subnets connected to the central office by a slow channel.

Client-server connection schedule

The Network Agent connection schedule is another tool for managing information exchange between the clients and
server. It is a part of the Network Agent policy and is applied to the corresponding groups instead of IP address
ranges.

The schedule is configured within the policy, under the Network, Connection manager section. There you can
specify the list of allowed intervals for server connections. Days of the week can also be specified for each interval.

The main objective of this functionality is to avoid undesirable tumbling into the mobile mode. Consider, for
example, a small remote office that connects to the central office network through a modem that works to schedule.
Under the default settings, when the connection cannot be established, after three failed attempts to connect to
the Administration Server, office computers will switch into the mobile mode of protection and update, although
they have not been disconnected from the office network. To avoid this, you can specify a connection schedule for
Network Agents that coincides with the modem schedule.

By default, these settings are not mandatory. To enforce them, close the padlock in the Connection manager
section.
 11
Chapter 1. Traffic Management
12 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Synchronization traffic
There are planned and unplanned synchronizations. Planned synchronizations are initiated by the client computer.
The client checks that its local policies and tasks correspond to the settings specified on the server, and the server
checks that the information on the client available in the database corresponds to its real status. Synchronization
concerns settings, tasks, policies, lists of managed programs, lists of objects in the repositories, statuses of programs
and components.

There are two types of planned synchronizations: synchronization of lists and synchronization of policies, tasks,
statuses, etc. The former takes place once every 12 hours and cannot be adjusted. The latter is performed with
the interval specified in the Network Agent policy1, 15 minutes by default. The first synchronization takes place
when the computer is turned on and then repeated as configured. Since all computers are likely never powered on
simultaneously, the synchronizations are staggered and do not create peaks. If the average load on
the Administration Server is high because of synchronizations, you can increase the interval of synchronizations up
to 30-60 minutes or even more, depending on the network size and the desired result. There is a rule of thumb that
the synchronization interval should be increased by 15 minutes per every 5000 clients. The synchronization interval
is specified in the Network Agent policy.

Unplanned synchronizations are initiated by the Administration Server when the administrator changes tasks or
policies, or as soon as the Administration Server backup copying is completed (since its service has not been
running meanwhile and the data might be outdated). The Administration Server sends the command to start
synchronization to the UDP ports of all computers concerned. In a large network, this can result in considerable load
on the server. The list of clients awaiting connection to the server can reach several thousands of computers in this
case.

To help balance the peak load, the following measures can be taken. First, you can delete policies and tasks from
the Managed computers group, because their changes impact all computers connected to the server. If changes are
made in the policies and tasks at lower levels, fewer computers are affected and the peak load is lower.

Second, you can disable the use of the UDP port on the clients. In this case a changed policy will not result in
overall synchronization as the server will not be able to send this command to the clients. A changed policy will be
gradually distributed to the clients during the planned synchronizations. This approach smoothes the peaks, but
makes the administrator unable to immediately connect to the clients if the need arises.

Slave Servers also decrease the load on the server when changed policies and tasks are distributed.

Information about the computer

Policies also influence the data about the computers that is sent to the Administration Server. These settings are
partly located in the Network Agent policy, and partly in the protection tool policy, specifically, in the policy of
Kaspersky Endpoint Security 10 for Windows. If the two policies conflict, protection tool policy settings have
higher priority.

1
To be more precise, the interval between the synchronizations is randomized within the range of 100%-110% of the selected value.
 13
Chapter 1. Traffic Management
14 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Event traffic
Some events are sent to the Administration Server immediately after they are registered on the client computers.
Others are stored only in the local log of Kaspersky Endpoint Security 10 for Windows. By default, only the most
important events are sent, which helps to even out the loads for the network and save space in the Administration
Server database.

If necessary, the administrator can configure the action to be taken when an event is logged in its properties in
the policy.

In addition to events, client computers transfer information about the Kaspersky Endpoint Security status to
the server. For example, the information that the databases became obsolete is status information, and it is
transferred regardless of whether the similar event is transferred. The same concerns the other statuses, such as
“Many viruses detected” (does not depend on the detection event transfer), “Reboot is required” (does not depend on
the “Restart required to complete the task” event transfer), “License expired”, etc.

Transfer of the information about statuses can also be disabled. For this purpose, disable the corresponding
condition in the group properties. By default, conditions for statuses are set in the properties of the Managed
computers node and are inherited by all groups; but the inheritance can be disabled. Status information transfer, just
like that of events, can be specified at the group level.

Updates traffic

Update distribution creates high peaks in the network load. These can be leveled by traffic limitation rules.
Additionally, you can randomize the start in the update task settings. By default, the randomization interval depends
on the network size specified by the administrator during the server installation. In networks comprising up to 100
computers, randomization is not used by default; for the other network sizes, the Define task launch delay
automatically mode is used.

Automatic randomization fits most organizations. However, if the network load is still too high, resulting in server
connection errors after an update task start, the randomization interval can be manually set to 30 or 60 minutes.
A larger randomization makes no sense as it becomes comparable to the database updates frequency.

The other method of balancing the network load during the updates is creating intermediate update sources—Update
Agents and/or slave Administration Servers.
 15
Chapter 2. Update Agents and Connection Gateways
16 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Chapter 2. Update Agents and Connection

Gateways

2.1 Update Agents

Purpose
Update Agents distribute information from the Administration Server to clients. Instead of downloading updates
from the Administration Server, client computers may download them from an Update Agent. Update Agents are
especially useful in the following cases:

— A subnet connects to the Administration Server through a slow communication channel. If updates are
received in the usual way, every computer downloads updates through the slow channel, downloading takes
a long time, updates are late, and other network applications are slowed down.

If there is an Update Agent assigned to the subnet, it downloads the necessary data and distributes it to all
managed computers through local channels.

— There are many computers in the network and when all of them download updates from the Administration
Server, the network is congested. Consequently, some computers cannot receive updates at all, and for
others it takes a long time to receive them. If the administrator selects to randomize the update time, delays
only increase.

If Update Agents are assigned within groups, updates from the Administration Server will be downloaded
not by all computers, but only by Update Agents. The other computers will receive updates from their
Update Agents.

Update Agents can transfer almost everything that Network Agents usually receive from the server:

— Updates for Kaspersky Lab programs

— Installation packages
— Windows Updates and updates for programs by other manufacturers
— Policies and tasks

Update Agents do not influence KSN traffic distribution, because KSN requests are not sent via Update Agents, they
are sent directly from KES to KSN proxy server service. The same concerns activation codes 2.0: Network Agents
are not involved, and therefore Update Agents are not involved either.

How it works

Update Agents accept connections from clients on the same ports as the Administration Server: by default, TCP port
13000 for SSL connections and TCP port 14000 for non-SSL.

Updates

Update distribution works as follows if an Update Agent is assigned to a group. Once new updates are downloaded
in the repository, the Administration Server tries to connect to the Update Agents. If the connection cannot be
established immediately, the server waits for a planned connection.
 17
Chapter 2. Update Agents and Connection Gateways

After the connection with an Update Agent is established, the server sends all new and changed files downloaded
during the last update. The Update Agent saves these files in its storage and provides them, by request, to the client
computers of the group.

As soon as updates are transferred to the Update Agent, the server sends the "Updates are downloaded in
the repository" signal to the client computers. So, the "When new updates are downloaded to the repository"
schedule is activated not right after the updates are downloaded to the Administration Server, but after they are
transferred to Update Agents.

When an update task starts on a client computer, it contacts the Update Agent, and the Update Agent provides
the required files just like the Administration Server. If the requested files are missing from the Update Agent
storage, the Update Agent will immediately download them from the server and transfer to the client, and at
the same time save them in the storage. This may happen if the client computer databases were last updated earlier
than the Update Agent was assigned.

Update files are stored in the Update Agent repository as long as it remains an Update Agent. After it is relieved of
this role, the storage is removed.

If the Update Agent is inaccessible, client computers will try to download updates from the Administration Server
by default to avoid having outdated databases in the whole group. However, in some cases it is undesirable, for
example, when it is more important to decrease the load on the communication channels than to receive timely
updates.

The computers’ behavior can be modified via the Network Agent policy. To avoid having computers try to
download updates from the server but rather wait for the Update Agent to become available, select the Download
updates through update agents only check box in the Settings section of the Network Agent policy.
18 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Remote installation, Windows Updates and third-party updates

Installation packages (when pushed using Network Agent tools), Windows updates (if Administration Server acts as
a WSUS server) and third-party updates (which are installation packages in fact) are distributed similarly.

On those computers to which the task is assigned, Network Agents try to download the necessary data from
the Update Agent. If it is missing from the Update Agent’s repository, the Update Agent downloads it from
the server and then provides it to the client. After a while, the Update Agent deletes the data from its repository, for
example, as soon as the task is deleted.

How to configure
Update Agents can be assigned to groups and subnets2. There is the Update agents section in the Administration
Server properties, where the administrator can assign Update Agents. The computers are to be selected from
the Administration Server database. Alternatively, you can add an Update Agent by IP address if it has no direct
access to the server (for example, if it is located in DMZ). This is described later in this chapter.

For a computer to be able to act as an Update Agent, the Network Agent must be installed on it, and it must be able
to connect to the Administration Server. The computer can belong to any group, not necessarily to the group for
which it acts as an Update Agent.

It goes without saying that Update Agents must be accessible for the group clients. By default, Update Agents
accept connections on the same ports as Administration Server, that is, 13000 for SSL connections and 14000 for
non-SSL. The SSL port can be modified in the Update Agent properties. The non-SSL port cannot be modified, but
it is not used by default.

The information about the assigned Update Agents and their ports is automatically transferred by the server to all
clients of the group. If the server can connect to the clients, it transfers this information right after the Update Agents
are assigned. If it cannot, the clients receive this information during the next planned synchronization with
the server.

An Update Agent serves all computers of the target group, including the subgroups. If a group includes numerous
computers, you can assign a few Update Agents to it.

If a few Update Agents are assigned to a group and the default Update Agent (the first one) is overloaded or
inaccessible, each client computer will select an Update Agent depending on the hop count. If the number of hops is
equal, the Update Agent will be chosen randomly. If Update Agents are assigned both within the computer’s group
and within its parent group, the nearest Update Agent from the hierarchy point of view will be used.

If a few Update Agents serve the same group, one of them becomes active and the others standby. The active Update
Agent is randomly selected by the Administration Server. If the active Update Agent becomes unavailable, the
Administration Server starts working with another Network Agent.

Only the active Update Agent downloads files (updates and packages) from the Administration Server. The standby
Update Agents download files from the active Update Agent.

If Update Agent A is assigned to Group 1, and Update Agent B is assigned to Group 2, and Group 2 is a child group
of Group 1, then Update Agent B will download files from Update Agent A.

The klnagchk.exe utility shows whether the Update Agent is active or standby.

2
Chapter 5 “Special Features” tells how to assign Update Agents to subnets instead of groups.
 19
Chapter 2. Update Agents and Connection Gateways

Multicast

Purpose

By using the Update Agents as described above, you can decrease the number of connections to the Administration
Server. Group clients will take updates and installation packages from the Update Agents of their groups. The server
will be contacted only by the Update Agents. This approach balances the network load, but cannot decrease
the overall volume of transferred data. Each computer downloads the required updates and packages over
the network.

To decrease the volume of transferred data or the number of connections to Update Agents, Update Agents have
the multicast function. This allows an Update Agent to distribute updates and installation packages to each client of
the group during a single session.

From the network load viewpoint, this method of sending is similar to broadcasting. An Update Agent sends
information once, and all computers receive it simultaneously. Unlike broadcast, which sends data to all computers
belonging to the corresponding network segment, multicast sends data only to the group clients.
20 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

How it works

If multicast is enabled, information exchange is altered. Just like earlier, the Administration Server transfers new
and changed files to Update Agents after updates are downloaded in the repository. Update Agents immediately start
multicasting these files, without waiting for clients’ requests.

Group clients are automatically subscribed to all multicasts from the Update Agents. The received files are saved in
a temporary folder until called for. When an update task starts, the client initially checks the temporary folder—most
likely, the necessary update files are already received by multicast.

If the temporary folder lacks the required data, the client tries to download it from the Update Agent in the usual
mode. This way, the clients that did not receive the multicast data do not suffer.

Remote installation and installation of updates and patches work similarly. The Administration Server transfers
the files to the Update Agent that then multicasts them. The client computers save the received files into
their temporary folders. Later, the computers where the installation is to be performed check for the necessary files
in their temporary folders and only if they are missing try to download them from the Update Agents.

The operation principle is the same, regardless of whether the installation task is assigned to all group computers or
only one of them. The package is multicast to all computers within the group. Unnecessary data is automatically
deleted from the clients’ temporary folders after some time.

A special IP range is reserved for multicast: 224.0.0.1—239.255.255.255. Update Agents send information to an IP
address belonging to this range, not to the IP addresses of the group clients.

By default, Update Agents use address 225.6.7.8 and port 15001 for multicast. Client computers receive multicast
data on this port. The clients automatically receive the multicast address and port from the Administration Server,
similarly to the address and ports of the Update Agent.

How to configure

Multicast is enabled by default. If you just assign an Update Agent to a group, it will work in the multicast mode.

In Update Agent properties, you can disable multicast or modify its parameters: address and port. Any port can be
selected, while the multicast address must belong to range 224.0.0.1—239.255.255.255. Do not change multicast
address and port unless it is absolutely necessary.

The administrator can select which data to distribute via Update Agents, and which directly from the server.
The following options are responsible for this:

— Deploy updates
— Deploy installation packages

By default, both options are enabled.

 21
Chapter 2. Update Agents and Connection Gateways
22 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Update source for an Update Agent

The described update scenario presumes that Update Agents receive updates from the Administration Server; but it’s
not the only choice. If Update Agents are located in a remote office with independent access to the Internet,
downloading updates directly from Kaspersky Lab servers may be a more efficient solution.

To configure this, in the Updates source section of the Update Agent properties, select the Use update download
task mode and create this task. The settings are similar to those of the task that downloads updates into the server
repository. It allows the administrator to select the updates to be downloaded including the Network Agent module
updates. Also, in its properties, you can specify the folder where the updates will be downloaded. By default, it is
%ProgramData%\KasperskyLab\adminkit\1103\Updates

This task is created as a local task of the Update Agent. It can be deleted in the Tasks section of the computer
properties. It cannot be deleted via Update Agent properties; there, you can only revert to the default mode Retrieve
from Administration Server.

Network polling

Update Agents can poll the network. For example, if some computers are located in a subnet that the Administration
Server cannot reach, they cannot be discovered by Windows network polling. In the networks of remote offices,
polling by other methods may also fail.

If the remote subnet has access to the Administration Server, the Network Agent can be installed on the computers.
They will be added to the server database at the first connection. However, this approach has two problems:

— Network Agents may need to be installed by the employees of the remote office whose qualifications may
be insufficient for antivirus system maintenance

— Network Agents will most probably have to be installed manually, that is, it will take longer and there is
a risk of making an error or skipping a computer

An alternative approach would be to: install the Network Agent on one computer of the remote office. Make this
computer an Update Agent. Wait until the Update Agent polls the subnet and discovers the other computers. Run
remote installation on these computers using the Update Agent.

Network polling is disabled by default in the Update Agent properties.

Installation using Update Agents

When the Administration Server is not accessible for target computers, but there is a managed computer that can
access the Administration Server as well as the target computers, using the Update Agents for installation fulfills
the need.

A computer can be made an Update Agent and used as an intermediary for remote installation using Windows tools.
The administrator creates a typical remote installation task (or uses the wizard), as if the Administration Server were
installed on the computer that is assigned to be an Update Agent. On the wizard page where the installation method
is specified, the administrator selects the Using Microsoft Windows resources by means of Update Agents
option.

When running this task, the Administration Server transfers the installation package(s) to the Update Agents, and
the Update Agents upload them to the target computers using Windows tools. If the Administration Server has no
access to the Update Agent, it waits for a planned connection from this computer.
 23
Chapter 2. Update Agents and Connection Gateways
24 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Automatic allocation of Update Agents

In Kaspersky Security Center, the Update Agents can be allocated automatically. This feature is enabled by default
and is designed for large networks where Update Agents are necessary to decrease traffic rather than to maintain
connection to the computers in remote offices.

The server starts assigning Update Agents automatically as soon as it has more than 100 managed computers. While
the number of clients is less, Update Agents are not assigned.

The server automatically adds and removes Update Agents depending on the number of computers in the group:

The sequence number of the Update Is added if the number of computers Is removed if the number of
Agent exceeds computers is less than
1 6 4
2 20 10
3 80 60
4 160 120
5 240 180
6 320 And so forth

If less than 40 clients remain on the Server, it removes all automatically assigned Update Agents.

When the computer to be automatically allocated as an Update Agent is being selected, the following criteria are
considered:

— The computer belongs to the target group

— Has at least 50 GB of free drive space
— Is not a notebook, which is checked by the availability of the “Battery” device
— Is not an Administration Server
— Has the most powerful processor among the group computers
— Has the most total time of visibility from the Administration Server—to filter out the computers that are
often powered off or inaccessible

The status of automatically assigned Update Agents is revised hourly. A computer is deprived of the Update Agent
status if:

— It has been moved to another group

— It has been inaccessible for more than 24 hours running
— Less than 300 MB of free drive space remains

If automatic allocation is disabled, all automatically selected Update Agents are deprived of this role.

When automatic allocation of Update Agents is used, the administrator cannot assign them manually. The Add
button in the corresponding section of the group properties appears dimmed. To make it available, clear the Assign
update agents automatically check box.

If there had been manually assigned Update Agents in the network before automatic allocation was enabled, they
will remain in this role after automatic allocation is disabled.

All currently assigned (whether manually or automatically) Update Agents are listed in the Administration Server
properties. The administrator can open their properties to check their coverage, settings and statistics.
 25
Chapter 2. Update Agents and Connection Gateways

Automatic allocation within broadcast domains

Groups do not necessarily join computers that are geographically close. Administrators often create Servers and
Workstations groups, which may contain computers from different subnets or even cities.

In this case, Update Agents should be assigned to subnets rather than groups. The Administration Server does this
automatically as soon as it gathers sufficient information on the network.

The Administration Server finds out to which broadcast domain computers belong. As soon as the broadcast domain
has been identified for more than 70% of computers, the Administration Server stops assigning Update Agents to
groups and starts assigning them to the broadcast domains.

The same criteria are used. An Update Agent is assigned if there are 6 or more computers in a broadcast domain,
and so on.
26 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

2.2 Connection Gateways

Purpose
Update Agents work as a one-way intermediary—from server to client computers. In the reverse direction,
the information is transferred directly. Clients connect to the Administration Server directly to send events or for
planned synchronization.

These connections also load the server. Besides, it is not always advisable to allow access to the Administration
Server from any computer on any subnet.

For an Update Agent to work as an intermediary in both directions, it must also be made a Connection Gateway.
Client computers will then transfer their events and settings to the Update Agent instead of the Administration
Server. Then the Update Agent will synchronously send them to the server.

How it works

If the necessity arises to send an event, information about status change or a synchronization request, the client
computer calls the Connection Gateway instead of the Administration Server. The gateway synchronously sends
such a request to the server, receives the answer and synchronously transfers it to the client. If a long-lasting data
exchange takes place, for example, synchronization or update, the packets are continually exchanged via
the Connection Gateway. The gateway neither caches nor stores client information, it acts as a real-time
intermediary.

If a Connection Gateway is inaccessible for some reason, client computers try to connect to the Administration
Server. A problem with the Connection Gateway will not make the clients unmanageable.

If a Connection Gateway cannot establish connection to the Administration Server, its client computers will receive
the “Connection to server failed” verdict. The information that the computer intended to send is cached by
its Network Agent. It is considered untransferred. So, events and other data will not be lost because of connection
problems.

Typically, a Connection Gateway maintains connection to the Administration Server and is always able to transfer
client data.

How to configure
The Connection Gateway is enabled within the Update Agent properties. The information about these changes is
distributed to the client computers during the planned or forced synchronizations.

On Virtual Servers, automatically assigned Update Agents simultaneously receive the Connection Gateway role.
 27
Chapter 2. Update Agents and Connection Gateways
28 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Connection Gateway in DMZ

In some organizations, an additional Administration Server is installed in the demilitarized zone (DMZ) for
managing mobile clients, VPN clients or other clients outside the corporate network. This server is accessible from
the Internet and remote clients may receive updates, tasks and policies from it.

This approach does have some problems though. First, one Administration Server is more convenient than several
from the protection management viewpoint. Second, an Administration Server accessible from the Internet
jeopardizes the network’s security. If criminals manage to connect to the Administration Server, they will receive
almost complete control over the managed computers. Although access is not easy to get, it is much safer to place
the Administration Server behind a firewall.

Instead of an Administration Server, you can place a computer that works as a Connection Gateway into
the demilitarized zone, which will be accessible to the client computers outside the network as well as to
the Administration Server located within the network thus enabling information exchange. Criminals may get access
to the Connection Gateway, but this will pose minimal risk.

A demilitarized zone is typically organized as follows: computers within the DMZ are accessible (over specified
ports) both from the internal network and from the Internet. The Internet is accessible from DMZ, while the internal
network is not. So, if a computer within the DMZ gets compromised, criminals will not receive access to the internal
network.

Procedure

In the described configuration, a Network Agent from the DMZ cannot establish connection to the Administration
Server. Moreover, the Administration Server is often unable to discover computers located within the DMZ. It
seems almost certain that the regular procedure of assigning an Update Agent and Connection Gateway will fail.

In this scenario, the following procedure can be employed:

1. Install Network Agent on the future Connection Gateway with the Use as connection gateway in DMZ
option enabled. This option is available both in the properties of the Agent’s installation package and in its
installation wizard

2. Assign the Update Agent role to this computer by IP address. In this case, the Connection gateway and
Initialize connection to gateway from Administration Server parameters are enabled automatically.
After a while, the Administration Server will establish the connection, and the computer will appear in
the Unassigned devices node

3. Move the computer to the corresponding group. Do not forget to enable the Initialize connection to
gateway from Administration Server option

Different addresses are often used when accessing the computers located in the DMZ from the internal
network and from the Internet. The address where the Administration Server contacts the Connection
Gateway can be inaccessible for the computers that are supposed to use this Connection Gateway to
connect to the server. That is why Connection Gateways have the Gateway address for remote client
computers parameter.

4. Install Network Agent on other computers within the DMZ and outside the network that are supposed to
connect to the Administration Server via the Connection Gateway. During the installation, specify that
the Network Agent needs to connect to the Administration Server via the Connection Gateway and type
the Connection Gateway’s address. Otherwise, the computers will try to connect to the Administration
Server directly, fail, and never know about the Connection Gateway location
 29
Chapter 2. Update Agents and Connection Gateways
30 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

To install the Network Agent so that it is immediately assigned the Connection Gateway role, either install it with
the wizard by running the setup.exe file from the installation package folder, or create a package for the Network
Agent and enable the Use as connection gateway in DMZ option in its properties. Later, you can convert it into
a standalone package that can either be used for local installation or installed remotely by Windows tools if
the shared folders of the DMZ computers are accessible from the internal network.

Adding an Update Agent by IP address is similar to selecting a computer from the administration groups. The Select
button that allows you to choose the computer offers the following options: Add computer from group and Add
connection gateway in DMZ by address. Select “by address” and type the name or address of the Connection
Gateway. A temporary record will be created in the list of Update Agents in this case. After the computer is detected
by the server, it can be moved to an administration group.

To specify a Connection Gateway for the other computers during the Network Agent installation, you can similarly
either use the installation wizard, or create an individual installation package, select the Connect to Administration
Server using connection gateway option there and specify the Gateway address.

2.3 Monitoring Update Agents

Statistics

Information about an Update Agent operation can be found in its properties, in the Statistics section. The statistics
are also available in the properties of the computer that acts as an Update Agent—as a section within the general
Network Agent statistics.

In statistics, you can find out how much information the agent has distributed by multicast, and how much was
downloaded by the clients during individual sessions (update data is represented separately from the rest of
the data). Also, there is information about the location of the Update Agent’s service folder and its volume.

The information about the Connection Gateway activity is not shown in the statistics.
 31
Chapter 2. Update Agents and Connection Gateways
32 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Reports
The aggregate information about all Update Agents in the network can be found in the report on Update Agents
activity. It is not created by default and has to be created manually.

The report contains information about total volume of information transferred by Update Agents and about each
multicast session.

Dashboards

Dashboards or statistics pages are available in the Administration Server node. The information about Update
Agents is not represented by default, but you can manually select to display the Statistics for connections to
update agents chart. It displays how long ago the Update Agents connected to the server. Click a connection status
to view the list of all Update Agents having this status.

Search

The list of all Update Agents is available in the Administration Server properties. It shows all Update Agents,
whether assigned manually or automatically.

You can also find Update Agents using the Search window and computer selections. To search for Update Agents,
open the Network activity tab and select Yes for the Is an update agent condition.

To check whether a specific computer uses Update Agents, open its properties and switch to the System Info \
Update agents section.
 33
Chapter 2. Update Agents and Connection Gateways
34 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

klnagchk.exe
The information showing whether a computer acts as an Update Agent or Connection Gateway can be found in
the report of the klnagchk.exe utility, in the end of the Network Agent settings section. The ports on which
the Agent accepts connections are also specified, as well as whether the Agent is active or standby.

This way, you can also find out whether the computer uses a Connection Gateway to connect to the server, and
whether it uses an Update Agent to receive information from the server.

Chapter 3. Using Several Administration Servers

3.1 Considerations

Prerequisites

Lab tests show that one server can support up to 150,000 computers, depending on its performance. In practice,
Kaspersky Security Center shares network bandwidth with other applications and services. Therefore a realistic
estimate based on the deployment experience is about 20,000–30,000 clients per single Administration Server.

The previously mentioned measures for balancing the average and peak loads, only help to some extent.
Realistically, you cannot completely disable the information transfer from the clients to the Administration Server
and still call it a computer management system. No matter how many Update Agents and Connection Gateways are
allocated in a network, important events will get to the server sooner or later and will require resources for
processing both on the Administration Server and in the server database.

That is why, if a network is comprised of several tens or hundreds of thousands of computers, one Administration
Server is not enough. The only way to balance this is to install several Administration Servers and distribute
the client computers among them.

Another example where several Administration Servers are more efficient than one is an organization with several
offices. If there are administrators in each office, it is logical to install an Administration Server in each office.

Even in centralized organizations, the decision between assigning an Update Agent in a remote network and
installing an Administration Server there is a choice between two compromises. Both options have their pros and
cons.
 35
Chapter 3. Using Several Administration Servers
36 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Alternatives
Using several Administration Servers is a solution that has its drawbacks. That is why alternatives may be preferable
under some circumstances.

Adequate hardware

You can increase the number of managed computers to a certain extent by moving the Administration Server and
the database server to better hardware. This solution is almost always more expensive than using several standard
server computers and almost always requires non-standard software and hardware; as a result, maintenance becomes
more complicated.

But at the same time such an approach allows the administrator to maintain a single database for events, while on
several servers the event database is inevitably split. Aggregate reports can be generated, but, for example, aggregate
event selections cannot be created if several servers are used.

Not the least of the factors is that the management structure becomes more complicated if several servers are used.
A single high-performance server allows the administrator to have a relatively simple structure.

Update Agents / Connection Gateways

Instead of deploying additional Administration Servers, you can introduce additional Update Agents, which also
take some load off the Administration Server. However, it does not solve the database server scaling problem.
Numerous computers imply the necessity to store and process numerous events, descriptions, attributes, etc.
The question about splitting the database or moving it to better hardware will eventually need to be addressed.

Another distinctive feature of Update Agents is their transparency. They were developed so that the management
mechanisms could operate regardless of Update Agent availability. This is especially convenient for inexperienced
administrators as nothing needs to be reconfigured after the Update Agents are allocated. On the other hand, this
approach limits Update Agents’ manageability. The administrator cannot use multicast on demand, and sometimes
cannot get complete and structured information about the Update Agents’ operation. Additional Administration
Servers are free of these drawbacks.

Separation of privileges and virtual servers

When it is necessary to separate administrators’ privileges rather than decrease the load on the hardware, consider
using access control tools instead of deploying additional Administration Servers, or creating virtual servers, which
are managed similarly to slave servers. This approach is preferable for compact centralized networks and for
the networks where administrators mainly work from the central office.

In geographically distributed networks where the administrators work in local offices, additional servers are
preferable. They help to localize administering traffic between the client computers and the Administration Server
instead of sending it through the central office.

Additional servers decrease the load on the master server and are preferable when it is necessary not only separate
privileges but also solve the problem of excess load on the server.

So, the optimal solution depends on the problem to be solved. It may be one of the abovementioned alternatives, or
their combination. For example, introducing additional Administration Servers can be accompanied with assigning
Update Agents or access separation for the administrators. Alternatively, the organization may choose to buy new
hardware for the database server and at the same time assign Update Agents to decrease the network load.
 37
Chapter 3. Using Several Administration Servers

Possible architectures

In an organization with separate offices, you can use independent Administration Servers without organizing them
into a structure. The connection profile capability comes in very handy in this case. They allow mobile computers
(notebooks) to connect to the server managing the network they are on. This is described in detail later in this
chapter.

When it is necessary to receive aggregate information about network protection, the servers need to be joined into
a hierarchy. For this purpose, one of the servers is selected to be the ‘master’, and the others connected to it as
‘slaves’. The master server can influence the slave, but not vice versa. A master server can have numerous slave
servers.

To gather reporting information, the best solution is to install an additional Administration Server and connect all
others to it. This Administration Server will have no client computers, or policies, or tasks, and will not require
many resources. Its only function is to gather information from slave servers and create aggregate reports. Slave
Administration Servers in such a structure have settings that are completely independent.
38 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

If additional Administration Servers are introduced for the purpose of balancing the load, and the protection is
managed centrally, the master server can be used for managing tasks and policies of the slave servers. The tasks and
policies of the master Administration Server are inherited by slave servers and are applied to their client computers.
Additionally, the master server can become the point of update downloading and distributing.

You can create hierarchies that are more complex. Some of the slave Servers can be masters to other slave Servers.
This way you can have many levels of slave Servers in the hierarchy. Usually, a multilevel hierarchy of
Administration Servers reflects the multilevel office structure in the company. In practice, you rarely have more than
two levels of slave Servers—a deeper hierarchy is harder to manage.

3.2 Independent Servers

If a multi-server structure is a part of the initial plan, and it is known in advance which network segments must be
connected to which server, this schema can be easy to implement. Usually, installation within each segment is
performed by the server to which the computers of this segment will be connected. Another approach is possible:
deploy the protection system from one server, but create several installation packages for the Network Agent to be
installed in different network segments and specify in each of them the connection parameters for the corresponding
server.
 39
Chapter 3. Using Several Administration Servers
40 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Moving computers
Sometimes you need to introduce an additional Server because the network has grown and the existing
Administration Servers is overloaded. Installation of the Administration Server software takes a few minutes.
The challenging part is disconnecting the computers from the old Administration Servers and connecting them to
the new one, to distribute the load.

Additionally, computers can be relocated from one department into another or even from one office into another if
the employee changes their location. If the new office has an Administration Server of its own, the computer should
be transferred to it.

Administration Server replacement is another example of a situation that may require moving computers. This
procedure can be performed differently. Sometimes the old and new servers work in parallel for a period of time
until the administrator moves tasks and computers and optimizes the management structure3.

To connect an unconnected computer, you deploy the Network Agent to it. This method works for reconnecting too.
However, it would create a lot of unnecessary traffic by sending the installation package of the Network Agent to all
computers that you need to connect to the new Server. To avoid this, you can modify connection settings by
a special task.

Relocation task

The task type is Change Administration Server. In the task creation wizard, you can find it in the Advanced
folder under the Kaspersky Security Center Administration Server application. To move computers from an old
Server to a new one you create this task on the old Server and specify the connection parameters of the new Server
in the task properties. These parameters include address, port, proxy server settings, etc.

When you run the task, it takes several minutes for the Network Agent to actually disconnect from one Server and
connect to another. During this time, you would not be able to synchronize with the computers from either Server.
Afterwards, the computers will appear on the new server with the Visible status.

After a computer is moved to another server, it needs to be deleted from the old server. This is not done
automatically. A relocated computer remains in the same group on the old server, but becomes unmanaged, because
the server shows that Network Agent is not installed.

In order for moved computers to not impact the statistics on the old server, the administrator can organize
the process as follows. On the old server, create a group named Computer relocation, and then create a group task
for changing the Administration Server. Then, the computers to be relocated need to be added to this group, so that
after they become unmanaged, you can delete them from the group. This way, if the report shows an unmanaged
computer in the Computer relocation group, the administrator will recognize that it is not a problem, just the result
of changing the server.

On the new server, moved computers get placed into the Unassigned category and remain there. They are also
displayed in the Unassigned computers with Network Agent selection, from which the administrator can move
them into proper groups.

Alternatively, the administrator can create relocation rules for unassigned computers with the Network Agent.

3
If the task is to just replace the hardware and preserve the settings, it is sufficient to give the same address to the new server and recover the data from
the backup copy.
 41
Chapter 3. Using Several Administration Servers
42 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Connection profiles

Purpose

Depending on the circumstances, client computers can connect to different Administration Servers. For example,
a mobile computer connected to the network in another office can automatically connect to the local Server instead
switching into the mobile mode.

This function is designed for truly mobile computers. A mobile computer can connect to different network segments
and utilize different Administration Servers at different times. Connecting to the nearest Administration Server for
updates might reduce the overall traffic.

When a mobile computer is in a remote office it can make sense to report its status to the Administration Server of
this office so that the local administrator is aware of any issues and can resolve them. It also makes sense for this
computer to use tasks and policies from the local Administration Server.

How it works

When and to which Administration Server a mobile computer should connect, depends on the settings defined by
the administrator. These settings are called connection profiles. In a connection profile, the administrator specifies
the connection parameters and connection mode for an alternative Administration Server. There is no need for
the original Administration Server in a profile. Computers retain connection settings for it and connect to it when no
connection profile is used.

The connection mode defines how much information a computer exchanges with the Administration Server. There
are three connection modes:

— Complete reconnection—the computer reports its events to the Administration Server specified in
the profile, and downloads updates, tasks and policies from it. This mode is useful if the organization
consists of separate offices each having its own Administration Server and local administrator

— Updates only—the computer is managed by its original Server, but downloads updates from the Server
specified in the profile. This mode is useful when all Servers share common address space, and
the administrator aims to optimize update traffic

— Mobile mode—the computer starts using the roaming policy and mobile settings of the update task.
The situation when the mobile mode turns on (after 3 failed attempts of synchronization with
the Administration Server) is described in Unit IV of KL 002.10 course. The administrator can use
connection profiles to modify the conditions of turning on the mobile mode.

It should be noted that a computer working in the mobile mode can either remain connected to the server or
be disconnected from it. For the mode with the connection, Administration Server address is specified in
the profile, and the computer keeps sending events and receiving settings from this server despite turning
on the mobile mode. In the mode without connection, the computer does not try to connect to
the Administration Server. The standard <Not connected> profile is used in this case.

The administrator can create several profiles for the same Server with different connection modes.

The administrator specifies when and which profile is to be used in the switch conditions stipulated within
the switch rules. There can be several conditions; and a rule is applied only if all of them are met. Conditions
contain network parameters, such as subnet address and mask, gateway or DNS server address, availability of
a Windows domain, resolvability of the specified DNS or NetBIOS name, SSL server accessibility.

The Network Agent keeps track of the network attributes, and if they meet the conditions of a rule, the Agent starts
using the corresponding connection profile. As soon as the switch conditions are mismatched, the Agent returns to
the original Administration Server.
 43
Chapter 3. Using Several Administration Servers
44 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Configuring connection parameters

Connection profiles and rules are set up in the Network Agent policy properties: in the Network, Connection
section. Profiles and rules are configured independently: profiles—in the upper part of the window, rules—in
the lower. So you can create several rules for one profile.

The administrator specifies server connection parameters in the profile settings:

— Address
— Ports
— Use of SSL
— Proxy server parameters (if necessary)
— Connection Gateway (if necessary)

and the connection mode. The mode is configured by three settings:

— Enable out-of-office policy

— Use to receive updates only
— Synchronize connection settings with Server settings specified in this profile

By default, only the second option is enabled. In this case, the computer will be managed by its usual Administration
Server, but download updates from the server specified in the profile4.

To make a computer completely manageable, temporarily, by another server, disable the Use to receive updates
only option. The Enable out-of-office policy option is irrelevant in this case as the computer will use the active
policy from the temporary server. If the Use to receive updates only check box is selected, the temporary Server is
used only as the source of updates; the Agent remains connected to the original Server, sending all events and status
changes. Which policy the computer uses depends on the Enable out-of-office policy parameter.

Each connection profile has a name. When you select which connection profile to use in a rule or simply want to
edit connection settings, you have to choose the profiles by their names. It is much easier to find the profile you
want if the name reflects the Server address and connection mode.

If the computer is to use the out-of-office policy under the specified conditions rather than try to connect to
the Administration Server, use the standard <Not connected> profile. The events will stay in the local cache of
the Network Agent until a profile that allows it to connect to an Administration Server is switched on. The <Not
connected> profile cannot be deleted or modified.

By default, the mobile mode turns on if there are connection profiles that determine the use of out-of-office policies.
Additionally, you can configure automatic switch over to the mobile mode in case the Administration Server is
inaccessible to avoid complicated (and thus error-prone) configurations. To enable changeover to the mobile mode
when the server is inaccessible, select the Switch to out-of-office policy when Administration Server is not
available check box. This parameter has its own lock; make sure that it is closed. The server is considered to be
inaccessible if there are no enabled network connections on the client computer or if three consecutive planned
synchronization attempts fail.

It is not always desired, because temporary inaccessibility of the Administration Server can lead to the mobile mode
enabled on the network computers.

There is also another standard profile that cannot be deleted or modified: <Home Administration server>. This
profile tells the Network Agent to connect to its original Administration Server as per usual.

It is used when creating profile switch rules that do not modify server connection parameters. Instead, these rules
may contain conditions for applying protection policy profiles, or conditions for manual allocation of Update Agents
to subnets rather than groups. Allocation of Update Agents to subnets and policy profiles are described in more
detail in Chapter 5 “Special Features”.

4
To be more precise, the server address specified in the profile is used for receiving updates from the Administration Server source. The active profile does
not influence other update sources.
 45
Chapter 3. Using Several Administration Servers
46 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Switch rules

Switch rules are configured separately from connection profiles. Rule settings consist of conditions and
the connection profile to be used when the conditions are met. The following types of conditions are available:

— Default gateway address

— DHCP server address
— DNS domain
— DNS server address
— Windows domain accessibility
— Subnet
— WINS server address
— DNS name resolvability
— Availability of SSL connection address (and certificate match, if necessary)

Several conditions can be specified in a rule. For example, for the Main gateway address condition, you can
specify several IP addresses for the gateway and then select one of the two options:

— Condition is true if [the main gateway address] parameter matches at least one value from the list
— Condition is true if [the main gateway address] parameter does not match any of the values in the list

For example, if two Administration Servers are installed in the company—one within the network, and the other one
in DMZ for external connections, you can specify a connection profile for the DMZ server and a rule for this profile
that will switch the computer to it when network attributes differ from those used in the internal network.

The other conditions are configured similarly, except Windows domain accessibility, which has one checkbox
only: Windows domain is available. You can either select it or leave it blank. This condition checks the availability
of the domain to which the computer belongs.

A rule can have only one condition of each type. If several conditions are specified within a rule, all conditions must
be met for the rule to be applied.

The conditions that contain the address of a subnet, gateway or a service server are simple, but do not identify
the network unambiguously. The ranges typical of internal networks are also used in public networks—in hotels,
bars, airports, etc. At the same time, the DNS name of a computer belonging to the internal network is highly
probable to be unique. It must be a name belonging to the internal DNS domain and unresolvable from outside
the network.

If several rules are applicable to the computer (for example, one of the rules checks availability of Windows domain,
and another subnet address), the higher rule is applied. Rules can be moved up and down in the list and temporarily
disabled.
 47
Chapter 3. Using Several Administration Servers
48 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Managing guest computers

When a Network Agent uses a connection profile where the Use to receive updates only check box is cleared, it is
supposed to download tasks and policies from the temporary server and send events there. However, to be able to
accomplish this, the computer must be added to the Managed Computers group on the temporary server.

Let us call the computers connected to a temporary Administration Server “guest computers”. By default,
a temporary Administration Server does not take any action when a guest computer connects to it. If such
a computer is unassigned, tasks and policies will not be applied, and it will not inform the Administration Server
about its events.

Unassigned guest computers are included in the selection Unassigned computers with Network Agent and
influence the status of the Computer management area on the Monitoring page.

To find guest computers among others, you can create a selection or just search for them. On the Network activity
tab of the search window, select Yes for the Connection profile switched condition.

Since tasks and policies cannot yet be applied to a selection, move the guest computers to a group to be able to
manage them fully. You may do it manually, by regularly looking through the selection and moving its computers to
the necessary group. Alternatively, you can create a rule for moving these computers and select Yes in
the Connection profile switched drop-down list in the Network section of the rule.

When guest computers are added to a group, active policies from this group are enforced on them, including
the policy for Network Agents. However, a guest computer always keeps profiles and connection rules from its
original server. It just ignores these parameters in the Network Agent policy received from the temporary server.

To change this behavior, in the profile properties, select the Synchronize connection settings with Server settings
specified in this profile check box. When switched over to this profile, the client will pick up all the settings
(including network settings and new connection profiles) from the temporary server. However, as soon as the profile
becomes inapplicable, the client will revert to the initial settings of the “home” policy.

At the client computer, the administrator can view which connection profile is used in the klnagchk.exe utility
report. The report contains the list of profiles and connection rules set up for the computer, as well as
the information about the active profile and update settings. You can also check which connection profile is used
with the help of the klcsngtgui.exe graphic utility.
 49
Chapter 3. Using Several Administration Servers
50 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

3.3 Hierarchy of Servers

Connecting to a hierarchy
If there are several Administration Servers in the network, introducing them into a hierarchy brings advantages
rather than risks. Connecting an Administration Server to a hierarchy will not diminish the rights of its
administrator. It is possible to use the hierarchy for only creating summary reports. However, if necessary, you can
manage the protection of all the computers in the hierarchy from the master Administration Server.

A hierarchy is created by selecting the master server and connecting other servers as slaves to the master server.
A slave Administration Server may have its own slave Administration Servers—such a hierarchy is multilevel.

Connecting by wizard

To connect an Administration Server to a hierarchy, there is a special wizard in the Administration Console of
the master Administration Server. It is located within the special Administration Servers folder available in each
group of managed computers. If during the installation of the Administration Server you have specified a small or
medium network size, the Administration Console will not show the Administration Servers folders as well as other
parameters related to server hierarchy.

To enable representation of these parameters, in the Configure interface window, select the Display slave
Administration Servers check box. This window can be opened using the Configure functionality displayed in user
interface link in the Administration Server area on the Monitoring page.
 51
Chapter 3. Using Several Administration Servers
52 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

After this, the Administration Servers node will be displayed in all groups of managed computers. If you want to
add a slave Administration Server, start the wizard from the shortcut menu of such a node or click the corresponding
task link in the right pane.

The wizard prompts the administrator for the name or address of the slave Administration Server, and also the name
or address of the master Administration Server. The wizard, then, creates a new slave Administration Server object
in the Administration Console of the master Administration Server and changes the settings of the slave
Administration Server so that it starts acting as slave.

The first step, which is optional, is to specify slave server connection address. If skipped, the wizard will not be able
to establish connection, and you will need to change the hierarchy settings on the slave server side. If both servers
can connect to each other over the network, it is much easier to specify the address and complete the procedure in
the master server console.

Two-way connection between the servers is not always available. For example, if a slave server is located in
the DMZ, and the master—in the internal network, the connection can be initiated only by the master server. Access
from the DMZ to the internal network is usually prohibited. If such an architecture is used, do not forget to enable
the Connect Master Administration Server to slave Server in DMZ option when specifying the slave server
address.

The second step—specifying the name of the slave server to be displayed in the console of the master server. Any
name can be used; by default, the wizard suggests “Administration Server <the address specified at the previous
step>.”

For the third step, the administrator specifies the address which the slave server will use to connect to the master.
The same principles are applicable as when selecting the connection address for Agents. If the administrator enables
the Connect Master Administration Server to slave Server in DMZ option at the first step, the wizard will skip
this step.
 53
Chapter 3. Using Several Administration Servers
54 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Finally, the wizard tries to connect to the slave server, then pass the certificate and master server connection address
to it, and receive the certificate of the slave server for future authentications. If no obstacles are encountered,
the wizard successfully establishes the connection and the slave server object becomes available in the master server
console.

You can find whether a given Administration Server is a slave in its properties window, in the Advanced,
Administration Servers hierarchy section5. If the Server is a slave, the This Administration Server is a slave
server in the server hierarchy option is enabled, and the address of its master Administration Server is displayed
below.

The added Administration Slave server is displayed in the Administration Servers folder within the group. It is
a container analogous to the Administration Server in the root of the console tree. Expand the slave Administration
Server node to see its objects: Managed computers, Computer selections, Tasks, Policies, etc.

Slave servers can be moved from one group to another as easily as client computers: dragged by a mouse or cut and
pasted.

Connection via Firewall

A slave Administration Server may be located in a subnet that has one-way access to the master Administration
Server, for example, a regional office network that can access the network of the central office over VPN
connection, but reverse communications are impossible. In this case, the wizard started on the master Administration
Server will not be able to complete the connection.

5
If this area is not visible, the Display slave Administration Servers option is disabled in the interface settings.
 55
Chapter 3. Using Several Administration Servers
56 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

After trying to connect to the slave Administration Server, the wizard will return an access error. Then, it will
request the certificate of the slave Administration Server. This certificate is used to authenticate the slave
Administration Server at "upward" connections. Once the wizard is completed, a node for the slave Administration
Server will appear on the master Administration Server, but the slave Administration Server will remain
inaccessible.

To finalize the connection, open the hierarchy parameters in the console of the slave Administration Server, enable
the This Administration Server is a slave server in the server hierarchy option, specify the address of the master
Administration Server, and click the Select button to specify the certificate of the master Administration Server.

After this, the slave Administration Server will try to connect to the master. The master Administration Server
authenticates the slave server by the certificate. If it succeeds, the slave Administration Server will become
accessible from the master Administration Server console.

In this case, there is no need to specify the address of the slave server in the wizard. The slave server is authenticated
by its certificate.

Protecting connection

The administrator of the slave Administration Server can not only enable, but also disable the This Administration
Server is a slave server in the server hierarchy option and thus remove the Server from the hierarchy. To prevent
this, the administrator of the master Administration Server can create a policy for slave servers.

The policy is created on the master Administration server in the group that contains the slave Administration Server.
In the policy creation wizard, select the Kaspersky Security Center Administration Server application.
 57
Chapter 3. Using Several Administration Servers
58 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

In addition to preventing the disconnection from the hierarchy, the policy for Administration Servers contains many
other parameters. Some of them can be configured in the policy creation wizard. All parameters will be described
later in this chapter. To protect the connection between the servers, finish the wizard and open the policy properties.

In the policy properties, clear the Allow hierarchy settings modification on slave Administration Servers check
box located in the Administration Servers hierarchy section. After the policy is enforced, the This
Administration Server is a slave server in the server hierarchy check box appears dimmed and cannot be cleared
on the slave server side.

Additionally, it makes sense to force policy inheritance in the General section. Otherwise, the administrator of
the slave server will be able to create another policy for Administration Servers, disable inheritance, allow hierarchy
settings modification and ultimately disconnect the slave server from the hierarchy.
 59
Chapter 3. Using Several Administration Servers
60 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Aggregate reports
Usually you connect Servers into a hierarchy to be able to receive summary information from all Administration
Servers. To gather aggregate information, you can use reports and computer selections.

Other reporting tools, such as event selections, statistics, repositories of licenses and dangerous objects, have no
hierarchy properties. They show only information on the computers connected to the master Administration Server.
Even if a selection containing computers connected to slave Servers is chosen as the information source in
the statistics pane properties, only the data on the computers connected to the master Server will be shown.

If aggregate reports are the only purpose for creating a hierarchy, it might be worthwhile to delete or not to create a
protection policy on the master server, not to connect client computers to it, and use it only to create reports and
selections.

Configuring report information exchange

Hierarchical reports are created on the master Administration Server. By default, all report templates are configured
to gather data from the first level of slave servers. If there are no slave servers, the report is created for the master
Administration server only.

To edit the settings that regulate gathering data for a report, open the Administration Servers hierarchy section in
its properties.

If you want to add the Details tables from slave Administration Servers into a hierarchical report, enable
the Transfer detailed information from slave Administration Servers option in the report template. Please note
that with this option selected, the traffic between Servers will increase.

To gather information from the second level of slave servers or deeper, specify the number of levels in the Up to
nesting level parameter. One (1) means gathering data only from the slave servers directly connected to the master
server. Two (2) means including the information from the next hierarchy level, etc. The deeper the reporting data is
gathered, the more time it will take to generate the report.

There is no guarantee that all of the slave Administration Servers will be accessible when the master Server starts
gathering data for a report. Some of them may be temporarily off, or some may be inaccessible because of
communication breakdowns between offices. It would be unreasonable for the master Server to wait for the data
indefinitely. Therefore, it waits a certain amount of time and then generates the report with the data on hand.
The exact waiting time is defined by the Data wait timeout parameter in the report template. The default value is 5
minutes. If a slave Administration Server is connected over a slow channel or information is gathered from several
nesting levels, it might be worthwhile to increase the waiting time.

If a slave Server is unavailable, its Summary and Details tables will show N/A for the missing data. You can make
the report show cached values from the last data exchange with the slave Server instead: enable the Cache slave
Administration Server data option in the report template. When a report shows cached rather than current data, it
also shows the date and time of caching this data next to the slave Administration Server name.

Creating a hierarchy report

When creating a report, the master server sends a request to slave servers, waits for the answer for the specified time
and then publishes the report including the gathered data. To save network traffic, slave servers transfer compiled
information for the report instead of the source data (events).
 61
Chapter 3. Using Several Administration Servers
62 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

A hierarchical report is a report that represents more data. The chart shows aggregate data from the master and slave
Administration Servers. The Summary table also shows the aggregate data. However, there is no aggregate Details
table by default. Instead, below the aggregate Summary section, there are individual Summary tables for all Servers
whose data was included into the report, the master Servers and all the slaves. The last section is the Details table for
the master Server.

Searching for computers within hierarchy

Computer search results also include aggregate information from all servers in the hierarchy. To search among all
hierarchy computers, on the Administration Servers hierarchy tab in the search window, select the Include data
from slave Servers (down to level) check box and specify the search depth. The same option is available in
computer selection properties. It is located in the General section.

When the search includes data from slave Administration Servers, the same computer can be found several times.
For example, if several Administration Servers scan the same subnet. If you search among managed computers,
rather than among all of them, there will be fewer duplicates as two servers cannot manage one computer at
the same time, although it can be listed in the group of managed computers on several Administration Servers by
mistake.

You can distinguish computers connected to different servers by the Server column in search results.

Computers connected to the master Administration Server are completely manageable from the search results
window or a selection. Computers connected to slave Servers can be managed to a lesser extent. Their protection
status is displayed, which allows the administrator to find all problem computers from the master Administration
Server. However, you cannot take any action on them from the search results on the master Administration Server.

Inheritance of policies and tasks

Tasks and policies are inherited by the slave Administration server from the master Administration server similarly
to tasks and policies inheritance within the groups of managed computers. There are slight differences though.
Update and remote installation tasks, for example, need to be adjusted to ensure correct use within the hierarchy.
 63
Chapter 3. Using Several Administration Servers
64 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Policy inheritance

Policies are inherited by default in a hierarchy. If the master server has active policies in the group to which a slave
server is connected, they are automatically inherited by the slave server. Whether these are policies of the group that
contains the slave Administration Server or they are inherited from a higher group on the master Administration
server, you cannot disable policy inheritance on the master Administration server side.

There can only be one active policy for an application. That is why the inherited policies change the settings of
policies created on the slave server. An inherited policy enforces only those required (locked) parameters.

Inactive policies are not inherited. Out-of-office policies are inherited, but not enforced. If the slave Administration
server has no out-of-office policy, it uses the out-of-office policy inherited from the master Administration server. If
the slave Administration server has an out-of-office policy of its own, the inherited policy will not redefine its
settings and essentially be ignored.

Inherited policies are displayed in the Managed computers container of the slave Administration server and are
applied to all computers of the slave server, unless inheritance is disabled. An inherited policy cannot be edited on
the slave Administration server.

An inherited policy also has a different icon: there is a down arrow on it.

Overall, policy inheritance between Administration servers works the same way as between groups. To disable
inheritance, open the properties of the slave server policy and clear the Inherit settings from parent policy check
box. Policy inheritance is then disabled on the slave Administration server, not on the master.

If the slave server does not need to use the policies configured on the master server at all, it is easier to move
the slave server to a group where there are no enforced policies.
 65
Chapter 3. Using Several Administration Servers
66 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Policy for Kaspersky Security Center Administration Servers

As mentioned earlier, within a hierarchy, you can use a policy to manage the settings of slave Administration
Servers. There you can specify almost all Administration Server properties, as well as some other global settings:

— Processing parameters for Administration Server events

— Parameters of storing events in the Administration Server database
— Server communication ports
— Network scan intervals
— Computer status conditions
— Permission to disconnect slave servers from hierarchy
— Virus outbreak conditions
— Cisco NAC interaction settings
— KSN Proxy parameters
— Internal Web server parameters

Global parameters that are not regulated by a policy for servers:

— Automatic allocation of Update Agents

— Traffic limitation settings
— Proxy server settings
— Notification parameters
— Report header settings

To create a policy for servers, select the Kaspersky Security Center Administration Server application in
the policy creation wizard. This policy is enforced on slave Servers just like the Protection policy is enforced on
the managed computers. Mandatory (locked) parameters are enforced and cannot be modified in Administration
Server properties. Parameters with open lock are not enforced and can be modified in the properties of each
Administration Server.

A policy for Administration Servers can affect settings of the master Administration Server itself. This happens if
the computer where Administration Server is installed is included in the group to which the policy for Servers
applies. Technically, a policy for Administration Servers applies to all client computers where Kaspersky Security
Center Administration Server program is installed.

In order for the policy for Administration Servers to not be applied to the master Administration Server, the policy
and the computer with Administration Server must belong to different groups. This is only possible if the policy for
Administration Servers is created within subgroups rather than in the root Managed computers group.

Task inheritance

By default, tasks are not inherited. If two recently installed servers are connected into a hierarchy, tasks from
the master server will not be inherited on the slave. For a task to be inherited, select the Distribute to slave and
virtual Administration Servers check box within its properties. A group task of any type, for any product, can be
inherited.

Similarly to inheritance within groups, the master server’s tasks do not supersede the tasks available on the slave
server, they are cumulative. If the slave server has a virus scan task, and another virus scan task is inherited from
the master server, both will run by their respective schedules.

Only group tasks are inherited, and only within the groups that have slave Administration Servers. Enabling
inheritance within the tasks of the groups where there are no slave servers will have no effect. Administration Server
tasks and Tasks for specific computers cannot be inherited.
 67
Chapter 3. Using Several Administration Servers
68 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Inherited tasks on a slave server are group tasks in the Managed computers group. Unlike resident tasks, inherited
tasks do not allow the administrator to exclude subgroups from their scope. Therefore an inherited task always
applies to all client computers of the slave Administration Server.

Inherited tasks are visible on the Tasks tab of the Managed computers container. Their icons are different from
the usual task icons. You cannot change settings of an inherited task on the slave Server, but you can see the task
properties. The settings can only be changed in the original task on the master Server.

You can run an inherited task from either the master or slave Administration Server. When you start it on the slave
Administration Server, it runs only on the computers belonging to the slave Server. When you start it on the master
Administration Server, it runs on all computers comprising the group, including those belonging to the slave
Servers.

The results of a task inherited by slave Administration Servers can also be checked on the master Administration
Server. Click the View results for slave servers link in the task results window. The link opens a window with
the list of slave Servers to which the task applies. To check the task results of the client computers, select
the respective Server and click the Details button below the list. Yet another window will open where you can
consult the task results for the computers of the slave Server.

Updates in hierarchy

The natural flow of updates in the hierarchy is from the master server to slave, and from the slave to their client
computers. The fact that the servers are joined into a hierarchy does not change the default update settings: each
Administration Server keeps downloading updates from the Internet and transferring them to the client computers.
This can be modified by changing the tasks’ settings.
 69
Chapter 3. Using Several Administration Servers
70 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

To make a slave Administration server receive updates from the master, modify the settings of the Download
updates to the repository task on the slave Administration server. Make the Master Administration Server the first or
the only source. By default, the list of sources only includes Kaspersky Lab update servers.

Updates are downloaded over the Kaspersky Security Center management protocol, from port 13000 of the master
Administration server. Don’t bother to give access to the server’s shared folder or publish the update files on HTTP
or FTP servers.

However, if nothing else is changed, the slave Administration server will check for updates according to its
schedule. The difference in the schedules of master and slave servers can delay updates.

To have the master server inform the slave server about downloaded updates, enable the Force update of slave
servers option in the parameters of the task that downloads updates on the master Administration Server. Once
updates are downloaded in the repository of the master server, it will inform the slave Administration server about
this, which will start its download updates task. 6

Inheritance of group update tasks is not usually desirable. The Quick Start wizard creates client update tasks
scheduled to run When new updates are downloaded to the repository on all servers. The clients need no other
tasks for regular updates. To be able to urgently start updates on all computers, create an additional task scheduled
to run Manually on the master Administration server and enable inheritance in its settings.

Program distribution in hierarchy

Group installation tasks can also be inherited. The administrator can create an installation task on the master
Administration server and run it on all network computers. This approach best serves the purpose of upgrading
a program, or deploying a critical fix on all computers, or running a utility that eliminates infection after-effects—in
all cases where an installation task needs to be started on managed computers. The initial deployment on unassigned
computers does better without inherited installation tasks.

Enabling inheritance is not sufficient for the successful completion of an installation task on those computers of
the slave servers. Managed computers always download installation packages from their managing server, while
the installation package specified in an inherited installation task is available only on the master server by default.
Consequently, the task returns an error on slave servers: This installation package is missing from the slave
Administration Server. Use the Distribute installation package task and repeat the attempt.

The correct procedure for running an installation on all hierarchy computers is as follows. Prepare the installation
package and distribute it to slave servers by a special task. After that, enable inheritance in the package installation
task and start it.

6
You can force updates on the slave servers without changing the source. In this case, they will download updates at the command of the main server, but
from the Internet, not from the master server.
 71
Chapter 3. Using Several Administration Servers
72 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

The use of inheritance in installation tasks presumes the copying of the installation packages from the master server
to slave. A special Distribute installation package task is used for this purpose, which can be found under
the Kaspersky Security Center Administration Server | Advanced folder in the task creating wizard.

Specify which installation packages to copy within the task settings. The task can be created for a group or for
specific computers. In the former case, it will copy the package to all slave Administration Servers within the group;
in the latter, to the selected servers. The distribute installation package task, just like an installation task, has
a limitation on the number of simultaneous downloads, five by default.

After the necessary package is copied, start the hierarchy installation task. If it is an upgrade of Network Agent7 or
protection products, it should complete successfully on all managed computers.

Installation on slave Administration Servers

If you need to upgrade the Administration Server software, you usually do it in the interactive mode. However, it is
possible to do it remotely, by running a task in Kaspersky Security Center. This capability is useful when slave
Administration Servers are located in distant offices where there are no administrators, programs are managed
remotely from the central office, and sending an employee on a trip just to upgrade an Administration Server is
expensive and unreasonable.

The administrator needs to create an installation package for the Administration Server, and then either install it on
the slave servers using a special task or make a standalone installation package that can be installed even by
an inexperienced employee.

7
When Network Agent package is copied, Administration Server address in the package properties is automatically substituted with the address of the slave
server.
 73
Chapter 3. Using Several Administration Servers
74 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

The installation package of Kaspersky Security Center Administration Server is not included in the Kaspersky
Security Center distribution. It needs to be created from the installation files of the Administration Server by
the New Package Wizard. At the first step, select creating a package for a Kaspersky Lab program.

When prompted for the application file, specify the sc10.kud file of the unpacked server distribution. You can
unpack the Administration Server distribution using the corresponding link in the Kaspersky Security Center
installation wizard.

You can specify the following installation parameters in the properties of an Administration Server installation
package:

— SQL server—you can select whether to install a new instance or use an existing local instance; (a remote
SQL or MySQL server cannot be selected).
— Connection ports—only the ports used for Network Agent and console connections; 13000 and 14000 by
default
— The name of the shared folder—by default, KLSHARE
— Installation path—by default, %ProgramFiles%\Kaspersky Lab\Kaspersky Security Center\
— Upgrade parameters—whether to create a backup copy
— License—if it will be necessary to activate the Systems Management and/or Mobile Device Management
functionality, or more than 10 virtual Administration Servers will be created
 75
Chapter 3. Using Several Administration Servers
76 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

If the package is intended for an upgrade, only the backup copy parameters are important, the other parameters will
be inherited from the previous version. Conversely, if the package is intended for initial deployment from
a standalone installation package, all other parameters except for backup copy parameters are important.

The Install application on slave Administration Servers remotely task helps to remotely upgrade
the Administration Server. Select the Kaspersky Security Center Administration Server installation package and
target servers in its parameters. The task can be created for a group or for the selected Administration Servers.

The only special parameter in this task is Do not install application if it is already installed. The other parameters
are standard: schedule and result storage settings.

To install a package on a slave Administration Server, first copy the created package by an installation package
distribution task. An installation task for slave Administration Servers presumes that the installation package resides
in the repository of the slave server.

The Administration Server installation package can be used in the ordinary remote installation tasks, too, but only
for initial installation of Administration Server by Windows tools. An upgrade must be performed by the “Install
application on slave Administration Servers remotely” task.
 77
Chapter 3. Using Several Administration Servers
78 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Chapter 4. Managing Administrators

4.1 Access Control

Main scenarios

The necessity to separate access to the Administration Server arises when there are several employees for whom
different access privileges need to be configured.

For example, an organization may have several sites with their respective administrators’ teams. A site administrator
needs access to the computer protection management system of their site only.

Or, there can be server administrators and helpdesk personnel in an organization. Server administrators are
responsible for infrastructure status and network security in general, while the helpdesk solves problems with client
computers. Helpdesk employees need limited access to the Administration Console so that they are able to check
computer status, view its event history, protection settings, etc., and start tasks, but without the ability to modify any
parameters. Server administrators, in contrast, need full access.

Sometimes, managers need access to console reports. Limited access without the capability to start tasks is usually
enough for them.

Finally, differentiation of the KSC and managed products’ functionality may be necessary: some administrators
manage protection of workstations and servers; some mobile device protection; and some maintain
the Administration Server.

Access privileges can be separated by various methods—for example, documents can be written describing
responsibilities of various employees and oblige them to act within the framework of these limitations. However,
technical measures much more efficiently restrict employees’ activities. First, they help to decrease maintenance
cost as there is no need to expend resources on repairing the damage caused by accidental or deliberate actions taken
by employees misusing their privileges. Second, employees’ work efficiency grows: they can concentrate more on
getting the job done instead of worrying about unwanted changes in the system—it is the access control system that
will take care of that.

At the same time, many organizations may not need to separate Kaspersky Security Center access privileges. For
example, organizations where there is a dedicated administrator of Kaspersky Security Center or a small team of
administrators who have a wide range of responsibilities including Kaspersky Security Center administration.

Access control system description

The access control system in Kaspersky Security Center is implemented similarly to access separation to files,
folders and other objects in Windows operating system.

The main functions of an access control system are authentication, authorization and audit.

Authentication is the process of matching a user against an identifier in the system. During the authentication,
the user confirms the right to use the selected identifier, for example, enters the password.

Authorization is about allowing or denying an operation according to the specified settings.

Audit concerns recording attempts and results of operation execution for further analysis.
 79
Chapter 4. Managing Administrators

Authentication

Identifiers of two types: Windows accounts and internal Administration Server accounts can be used in Kaspersky
Security Center.

If the user logs on to the system on behalf of a Windows user, they enter the username and password, and then
Kaspersky Security Center uses the operating system functionality to verify the password.

If the administrator logs on to the system on behalf of an internal user of the Administration Server, they enter
the username and password, and the Administration Server verifies the password itself.

Windows identification is typically used for convenience. Internal Administration Server users are necessary for
special cases when persons who do not have accounts in the organization network need access to the server. For
example, a service provider that administers Kaspersky Security Center may need to give access to the reports to
the customer’s employees via a special web interface.
80 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Authorization

To take the decision about whether a user is allowed to perform an action, access control lists are used in Kaspersky
Security Center. They are similar to the access control lists in the properties of Windows folders and files.

At an attempt to execute an operation, the system checks whether the user identifier is included in the access control
list. If not, the operation is denied. If yes, the system consults the list of permissions specified for this identifier and
returns the verdict.

An access control list may contain user and group identifiers (Windows groups and internal groups of Kaspersky
Security Center can be used equally).

It may turn out that the list contains several records applicable to the user. For example, there may be specified
permissions for the account itself and for one or several groups it belongs to. In this case, Kaspersky Security Center
behaves like Windows operating system: the settings that deny access take precedence.

In the list of permissions specified for an account, an operation can be allowed, denied, or neither. For the operation
to be actually allowed, it must be allowed explicitly. If several records are applicable to the user and the rights
configured for them differ, the system acts as follows:

— If the operation is explicitly denied for at least one of these records, the final verdict will be Deny

— If the operation is not explicitly allowed for none of these records, the final verdict will be Deny

— If the operation is explicitly allowed for at least one of these records and is not explicitly denied for
the others, the final verdict will be Allow

Permissions for files and folders in Windows operating systems are calculated the same way.

Access control

Access separation system in Kaspersky Security Center contains more than 90 permissions for various operations
performed through the Console. Separate sets of rights can be specified for different administration groups, reports,
etc. This granularity allows the administrator to create an account with any possible set of permissions and solve any
access segregation task in the Console.

The role model of access permissions was implemented in KSC 10 SP1. A specified set of rights can be saved as
a role, which can be assigned to administrators or groups. After the installation, there are 13 roles in the system,
which permit managing or monitoring various KSC objects. The administrators can create custom roles or adjust
the existing ones.

Access rights
Access rights are grouped by the products that support the role model in KSC 10 SP1: KSC 10 SP1, KES 10 SP1
for Windows, KES 10 SP1 for Mobile and Kaspersky Mobile Device Management 10 SP1. Within each product,
functional areas are represented.

Thus, KSC access objects now include not only Administration Server properties, but also the settings of
the managed products.

Access to those product settings that do not support the new role-based permissions system is granted according to
the permissions specified for the Basic functionality of Kaspersky Security Center Administration Server.
 81
Chapter 4. Managing Administrators
82 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

General rights

Read—enables viewing the object and generating reports. If an administrator is deprived of the Read access, he or
she will either not be able to see the object at all, or will not be able to open its properties. Only KES 10 SP1
policies are always accessible regardless of whether the administrator is granted the corresponding Read permission.
If a user has no Read access to the Basic functionality of Kaspersky Security Center Administration Server, he or
she will not be able even to log on to the Server.

Modify—generally, it grants the permission to edit the object’s settings, for example, Kaspersky Endpoint Security
for Windows policy (entirely or partly) or the parameters of storing events in the Administration Server database.

Execute—generally, the ability to start tasks.

Performing operations for selected computers—restricts access to computer relocation rules, tagging rules, tasks
and reports for computer selections.

KSC Administration Server rights

KSC Administration Server rights include: General features, Mobile Device Management and Systems
Management.

General features

Basic functionality defines the administrator’s ability to access the Administration Server (Read), view its settings,
edit them (Modify) and start the Administration Server’s tasks (Execute). Basic functionality includes:

— Administration Server settings: KSN proxy server, Settings, Traffic, Web server, and Advanced sections
— Group management (creating, deleting, configuring the properties according to the granted rights)
— Moving computers, policies, and tasks within the group hierarchy
— Reports: Anti-virus database usage, Viruses, Most infected computers, Users of infected computers,
Vulnerabilities, About blocked starts, Web Control, Device Control events, Errors and some others
— Administration Server tasks
— Network Agent tasks
— Network Agent policy, except Information about installed applications, Microsoft Windows updates
information, Hardware registry details, Software updates and vulnerabilities, and NAC, which require
special permissions
— Status conditions
— Selections of computers and events
— Computer relocation rules and network polling parameters
— Deleting files from the centralized Quarantine and Backup repositories
— Viewing the used licenses
— Viewing the Kaspersky Endpoint Security for Windows 10 SP1 policy
— Performing any operations with policies and tasks of the products that do not support the permissions
system implemented in Service Pack 1

What is not included with the Basic functionality (but could have been):

— The Administration Server settings that are not listed above

— Some parameters of the Network Agent policy: NAC, Software updates and vulnerabilities, Information
about installed applications, Microsoft Windows updates information, Hardware registry details
— Installation packages, including viewing
— KES 10 for Windows SP1 tasks, including viewing
— KES 10 for Mobile SP1 policy, including viewing
— All other Mobile Device Management and Systems Management functions, including viewing
 83
Chapter 4. Managing Administrators

Event processing determines the administrator’s ability to modify the parameters of storing events in
the Administration Server database. This permission relates to the Administration Server events, and all events of
policies and tasks. The following rights can be granted:

— Modify—change the number of events stored in the Administration Server database and lifetime of
the events received from remote computers
— Change event log settings
— Change notification settings
— Delete events

Deploy Kaspersky Lab applications allows the administrator to:

— Read—view the installation packages of Kaspersky Lab programs (except Kaspersky Endpoint Security 10
for Mobile), properties of remote installation tasks, and the deployment-related reports: Protection
deployment report, Kaspersky Lab software version report, Key usage report
— Modify—edit the corresponding packages and tasks, create new ones; edit and create the abovementioned
reports
— Execute—start remote installation tasks

Keys

— The Modify right enables the administrator to add new keys to the Administration Server, delete old ones,
and define whether a key will be distributed automatically.
— Export key allows the administrator to export a key file from the storage.

Hierarchy of Servers

Regulates the administrator’s ability to add/delete slave Administration Servers. If a slave server has been added
earlier, the administrator can manage it regardless of possessing the Edit Administration Server hierarchy
settings right.

User rights

Enable the administrator to configure permissions: edit the rights granted to the existing users and groups, grant
rights to new users, create KSC users, create and modify roles, disable permissions’ inheritance in the group
hierarchy.

Virtual Server

To be able to successfully add a virtual server, the administrator must have the Read, Modify and Manage virtual
servers rights. Most of the other operations do not require the Manage virtual servers right.
84 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Mobile Device Management

The Mobile Device Management permissions define availability of the Mobile Device Management node in
the Administration Console, ability to add new devices and access the Self Service Portal.

The ability to create and edit the Kaspersky Endpoint Security 10 for Mobile policy is configured separately, in
the respective section.

The ability to create and edit MDM policies, and adjust the parameters of mobile device management servers (iOS
MDM and Exchange ActiveSync) is configured in Kaspersky Mobile Device Management 10 SP1.

General

Contains the standard Read and Modify rights. Read defines whether the Mobile Device Management node with
all of its contents is displayed in the Console. Modify allows the administrator to configure Google Cloud
Messaging connection parameters, adjust the parameters of certificate creation and make any changes to Mobile
device management settings, except the parameters of Mobile device management servers.

The Connect new devices right enables the administrator to generate certificates, and personal KES 10 for Mobile
packages (which include a certificate) for user devices, and send users links to these packages. Note that it does not
allow the administrator to edit the KES 10 for Mobile package; the Remote installation rights are required for that.

Send commands to mobile devices enables the administrator to send any supported commands to the mobile
devices.

Send only information commands to mobile devices restricts the available capabilities to Set off alarm,
Mugshot, and Locate. However, since the device gets locked after any of these commands is carried out, and
the Unlock command is not informational, this category should be used very carefully.

Self-Service Portal

The General node is designed for the KSC administrator responsible for Mobile device management, while
the Self-Service Portal rights are granted to the users who will connect their smartphones to the system themselves
through the Self Service Portal.

The following rights are available:

— Read—for accessing the portal

— Modify—permits deleting the available packages
— Connect new devices—allows the administrator to create and load the packages to be installed on the new
mobile devices
— Send only information commands and Send commands to mobile devices are similar to their
counterparts from the General node

Systems management

The Systems Management rights mainly concern the corresponding KSC functionality.

Connections:

— Read—permits viewing the Report on users of the computers.

— Modify—report creation/modification
— Save files from client computers to the administrator’s workspace allows the administrator to save files
from the Backup, Quarantine and Unprocessed files repositories to his or her workstation
— Create RDP sessions—allows/prohibits the corresponding command and the Remote Desktop command
— Connection to existing RDP sessions—allows the administrator to use the corresponding command

Hardware inventory

— Read—displays the Hardware container and permits viewing the Report on hardware registry, report on
Device Control events, and Hardware report
 85
Chapter 4. Managing Administrators

— Modify—allows the administrator to edit device attributes, add summary fields, add devices, import data
from *.xml or excel, change properties of the abovementioned reports.

Network Access Control8

— Read—displays the NAC section in the Network Agent policy and in the Agent application properties.
— Modify—prohibits enabling/disabling a NAC Enforcer and changing its mode.

Deploy operating system

— Read—displays the Deploying computer images container and the installation images within it
— Modify—allows the administrator to create the computer image capture task, generate an installation image
from a WIM file, and configure an image package
— Execute—permits starting the computer image capture task and image package installation task
— Deploy PXE servers—regulates the ability to assign the PXE server role

Management of vulnerabilities and patches

— Read—displays the Software updates container

— Modify—allows/prohibits the administrator to adjust the settings within the Software updates and
vulnerabilities section of the Network Agent policy, create and edit the Perform Windows Update
synchronization and Install required updates and fix vulnerabilities tasks, accept license agreements for
updates, approve and reject updates, and create installation packages using the Kaspersky Lab database of
third-party applications
— Execute—permits starting tasks

Remote installation

— Read—displays the Kaspersky Endpoint Security 10 SP1 for Mobile package and custom packages
— Modify—allows the administrator to edit the abovementioned packages

Software inventory

— Read—displays the Applications registry container and allows the administrator to create
the Applications registry report
— Modify—permits adding Monitored Applications, publishing an installation event, editing the created
Applications registry reports
— Execute—allows/prohibits the administrator to edit Automatic updating settings, if any

8
Starting with KSC 10 SP2, the NAC subsystem is no longer being developed and cannot be installed by default.
86 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Kaspersky Endpoint Security 10 Service Pack 1 for Windows

Starting with KES version 10 SP1 for Windows, permissions are grouped into subcategories; within each category,
the Read, Modify and Execute rights are available.

Without special permissions, an administrator can only view KES 10 SP1 for Windows policies, but cannot edit
them; KES 10 SP1 for Windows tasks are not even displayed.

Policy editing privileges are structured as follows (the respective Modify permission is required):

— Anti-Virus protection—allows the administrator to edit General Protection Settings (except the Trusted
zone and Monitored ports), and configure File Anti-Virus, Mail Anti-Virus, Web Anti-Virus, IM Anti-
Virus, Vulnerability Monitor
— Application Startup Control—permits adjusting the parameters of Application Startup Control
— Basic functionality—General Protection Settings (except the Trusted zone and Objects for detection),
and all the Advanced Settings: Application Settings, Reports and Storages, KSN Settings, Interface
— Intrusion Prevention—Firewall, Network Attack Blocker, System Watcher
— Web Control—Web Control
— Trusted Zone—Trusted zone
— Device Control—Device Control
— Encryption—Encryption

To be able to access, create/modify and start KES 10 SP1 for Windows tasks, permissions are required in
the following sections (task—section):

— Virus scan—Anti-Virus protection

— Update, Update Rollback, Inventory, Add key, Change application components—Basic functionality
— Manage authentication agent accounts—Encryption

Kaspersky Endpoint Security 10 Service Pack 1 for Mobile

The permissions configured for Kaspersky Endpoint Security 10 SP 1 for Mobile define the ability to configure
the product’s policy:

— Android for work—Android for Work profile settings

— Anti-Theft—Anti-Theft
— App Control—App Control, Third-party apps
— Protection—Protection, Scan, Update
— Compliance control—Compliance control
— Containers—Containers (the permission to create packages is to be granted additionally)
— Device Settings—Synchronizing, Device Settings
— Manage Samsung device—Manage Samsung device (including subsections)
— Systems management—Device Management, Additional Settings
— Web Protection—Web Protection

Rights for the Events and Licensing sections depend on the Event processing and Keys permissions specified
within the General features node of Kaspersky Security Center Administration Server rights.
 87
Chapter 4. Managing Administrators

Kaspersky Mobile Device Management 10 Service Pack 1

The permissions specified for Kaspersky Mobile Device Management 10 SP1 enable the administrator to create and
modify the MDM policy:

— Exchange ActiveSync—the Settings of EAS devices section

— Additional: AirPlay, AirPrint, Web Clip, Fonts in the Settings of iOS MDM devices section

— General: General, Single Sign-On, Web Protection, Wireless networks (Wi-Fi), Email, Exchange
ActiveSync, Access Point (APN) in the Settings of iOS MDM devices section

— LDAP(calendar/contacts): LDAP, Calendar, Contacts, Subscribed Calendar in the Settings of iOS

MDM devices section

— Restrictions/Security: Password, Restrictions for Features, Restrictions for Applications, Restrictions

for Media Content, Global HTTP Proxy, Virtual private networks (VPN), Certificates, SCEP
88 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Roles

A role-based authorization model is implemented in Kaspersky Security Center 10 SP1, which means that in
addition to granting specific rights to a user, you can create a role possessing the necessary set of permissions, and
then assign it to the users. This approach helps to save time considerably when distributing rights and reduce
the probability of human error (which is easy to make when creating, say, 10 users with the same permissions) and
makes the system more transparent. A Systems Management license is required for using the role-based
authorization model; without it, the respective interface parameters are hidden.

By default, there are 13 roles in KSC 10 SP1. Their permissions reflect various aspects of using KSC and
the managed products. The Administrator and Operator roles are created for the major functional areas. Generally,
the Administrator possesses all the permissions available, while the Operator can view the objects’ properties,
generate reports and start the tasks created by administrators.

Roles Rights
Main Administrator The whole system
Main Operator
Administration Server Administrator Administration Server
Administration Server Operator General features:
Basic functionality
Event processing
Hierarchy of Servers
Virtual Server
Systems management:
Connections
Hardware inventory
Software inventory
Endpoint’s Administrator Administration Server
Endpoint’s Operator General features:
Basic functionality
KES 10 SP1 for Windows
KES 10 SP1 for Mobile
Kaspersky Mobile Device Management 10 SP1
Mobile Device Management Administration Server
Administrator General features:
Mobile Device Management Operator Basic functionality
Mobile Device Management
Systems Management Administrator Administration Server
Systems Management Operator General features:
Basic functionality
Systems management
Installation Administrator Administration Server
Installation Operator General features:
Basic functionality
Deploy Kaspersky Lab applications
Keys
Virtual Server
Read
Execute
Systems management:
Deploy operating system
Management of vulnerabilities and patches
Remote installation
Software inventory

There is also the Mobile Device Management Self Service User role, which has full permissions within
the framework of the corresponding functionality. The users having this role are not allowed to access the KSC
Console.

By default, only the Main Administrator role is allowed to configure the security system.
 89
Chapter 4. Managing Administrators

How rights correlate to roles

Roles cannot exist without rights. In fact, every role consists of rights. Instead of assigning a role, you can manually
grant the user the corresponding set of permissions to the same effect.

Also, you can grant specific rights to a user in addition to the assigned role, or assign a role in addition to
the granted rights. Since a role is essentially a set of rights, roles are transformed into lists of rights when calculating
the resulting set of permissions.

A user may have a few roles, and possess all the respective permissions. If additional rights are granted to the user,
they are also added when calculating the final list.

A denial has higher priority than a permission: if Alex has the Administration Server Administrator role, but
the Deny checkbox corresponding to the Hierarchy of Servers is selected on his permissions, Alex will not be able to
access Hierarchy parameters.
90 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Where to configure rights and roles

User permissions are configured in the Administration Server properties, in the Security section. You can assign
roles or grant rights to Windows and internal Kaspersky Security Center users here.

By default, the KL Admins (domain and local) groups receive the Main Administrator permissions (this cannot be
changed); BUILTIN\Administrators Main Administrator (you can modify these privileges); and KL Operators
the Operators permissions, which can also be modified.

You can add or edit role templates in the User Roles section next to the Security.

Also, you can view the list of rights granted to a role here: select the necessary role, then click Modify, Rights.

Additional access objects

By default, the rights specified in the Administration Server properties influence all server objects, but for some
access roles, they can be redefined for the following types of objects:

— Administration groups
— Kaspersky Security Center tasks
— Tasks for specific computers
— Report templates
— Statistics pages
— Custom event and computer selections

Usually, the access list is taken from the properties of the parent object—Administration Server or group—and
cannot be edited. To modify access rights for an object, open its properties, switch to the Security section and clear
the Inherit checkbox. After the inheritance is disabled, the access list is copied from the parent object and becomes
editable.

Administration group

Group access rights may need to be modified to implement a role of an administrator responsible for a part of
the network. Rights for such a role are configured similarly to the Administration Server rights.

This role requires the Read and Modify rights for the Basic functionality.

Without the Read right for the group, the administrator will not see it in the Administration Console; the computers
of this group will also be hidden, as well as any information related to them. Selections, repositories and reports will
look as if the computers of this group did not exist.

Without the Modify right within a group, the administrator cannot edit policies and tasks, add or delete computers,
change parameters in the group properties.

The other rights are not that critical. The Main Administrator decides whether to grant them depending on
the administrator’s responsibilities.

Read, Modify and/or Execute rights can be granted. Group administrators may need to start the “Download updates
to the repository” task manually. They also may need the report delivery task. At the same time, the backup copying
task can be hidden from them, and update settings’ modification denied.
 91
Chapter 4. Managing Administrators
92 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Tasks for specific computers

Require the same access rights as Administration Server tasks: Read, Modify, and Execute. Using these rights, you
can create separate tasks for each administrator, which will be inaccessible or even invisible for other administrators.

Selections, report templates and statistics pages

Only Read and Modify rights are applicable to them. Thus, the administrators may protect their templates from
accidental change or hide them from other administrators. The rights can be configured so that each administrator
can see only their own reports and statistics pages.

It is almost the same with event and computer selections. Read and Modify permissions are applicable to them, and
if there are group administrators with different responsibilities, personal selections can be created for each of them
that will be invisible for the others. The hard-coded selections are visible to everybody—they have no access control
lists and use the settings specified for the Administration Server.

Creating internal users of Administration Server

Internal users are displayed in the general list of users in the Advanced \ User accounts node. Internal users can be
added either via the accounts node, or via the Server properties.

The required parameters of an internal user are the full name and password. You can additionally specify
a description, email address and phone number. Internal users can be temporarily disabled.

Internal users can be joined into groups. To create a new group, click the Add security group button. To add users,
open the group properties. The user properties show the groups into which the account is included.

You can add only internal Kaspersky Security Center users to Kaspersky Security Center groups. Mixed groups
consisting of internal and Windows users are not allowed.

Accounts of internal users can be created, enabled, disabled or deleted. Their access permissions are configured in
the Security section of the object properties, together with the permissions of Windows users.

When adding a user to the access list, the Add button expands into a drop-down list with two options:

— Microsoft Windows authentication—to add a Windows user or group to the access list
— Kaspersky Security Center authentication—to add an internal user to the access list

Report on effective user rights

If rights are assigned to roles, groups and users, it may be difficult to understand which permissions are granted to
a specific account. The Report on effective user rights helps to check this. Select the necessary account in
the template properties and the report will show the resulting rights of this user for all Administration Server objects.

To find out who has any permissions for the Server objects, consult the Report on rights.
 93
Chapter 4. Managing Administrators
94 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

4.2 Audit

Purpose
Access parameters can help the head administrator to decrease the instances of abuse, but cannot prevent them
completely. Even an administrator whose permissions are restricted can harm the system by weakening protection
parameters or disabling updates. These actions can be done either deliberately or by mistake; also, we should take
into account the fact that an administrator’s password might leak out.

In addition to the access control system, the head administrator needs the capability to track actions taken by other
administrators. This functionality is provided by audit events. They register connections made to the Server,
attempts to change settings and start tasks, and also the results of these attempts.

Configuring audit parameters

Audit events are registered on the Administration Server. To modify their settings, open the Events section of
the Administration Server properties, and then open the Info category that comprises audit events.

Just like other server information messages, audit events are stored in the database for 30 days by default.

Audit events description

There are four audit events. Actually, each of them represents a category, which registers attempts to access various
objects with various results.

The Audit: Connection to the Administration Server event registers attempts to connect to the Server, either
successful or unsuccessful. An event description contains the username and the address of the connecting computer.
Disconnecting from the Server is not logged.

The Audit: Object modified event is registered when tasks, policies, installation packages, report templates,
statistics pages, or event and computer selections are added, changed or deleted; when access parameters are
modified for these objects; when Administration Server parameters are modified; or when objects in repositories are
processed.

The event description includes the name of the modified object and its location. If it is a group task, the group is
specified. If an object is recovered from a repository, names of the repository and computer where the object was
found are specified, but not the object name.

Successful object modifications are always logged, while some denied attempts are not.

The Audit: Object status modified event is registered when a user attempts to start a task or create a report. All
attempts are logged, both allowed and denied. Attempts to create standalone installation packages are not logged.

The Audit: Group settings modified event is registered when subgroups are created, computers are moved into
a group, or group settings are modified. Only successful actions are logged.
 95
Chapter 4. Managing Administrators
96 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Chapter 5. Special Features

5.1 Updates Testing

Why test

Programs may conflict. To prevent failures, administrators test programs before deployment. Conflicting programs
are either set up to operate safely, or replaced with analogs. When there are updates, they are re-tested.

Antivirus programs should also be tested. Unlike most other programs, antivirus software is updated often,
sometimes hourly. Although the changes are slight, they may potentially result in conflicts.

Neither users nor the manufacturer wants conflicts. Generally, testing is the duty of the manufacturer. It helps to
reduce the risk of conflicts, but cannot rule them out completely. Many companies use internal tailor-made software
whose compatibility cannot be tested by the antivirus manufacturer.

To minimize the risk, additional update testing in the customer network is necessary. Testing is a laborious process,
and few companies do it unless the manufacturer offers special tools for testing updates. Kaspersky Security Center
incorporates such tools.

How update testing works

Updating that undergoes testing works as follows:

1. The administrator selects several computers for testing.

2. The Administration Server downloads updates into a temporary repository.

3. Test computers get updates from the temporary repository.

4. Test computers undergo automatic verification actions.

5. The Administration Server checks whether there were antivirus errors or application conflicts on the test
computers during the verification.

6. If there were no errors or conflicts, updates are moved from the temporary repository to the permanent one
and become available for other computers in the network.

7. If events contain errors or conflicts, updates are not moved, and the update task results in failure.

Verification actions are selected by the administrator and may include:

— Running a virus scan task

— Restarting the computer after the update
— Checking real-time protection status after the update and restart

After all verification actions are completed, the updates testing task waits for events from the test computers for 5
minutes. This time is preset and cannot be changed.
 97
Chapter 5. Special Features

Any Critical event or Functional failure indicates a problem caused by the updates. In particular, the following
events are considered: detection of a malicious or suspicious object, detection of a network attack, device blocking,
failure to update, failure to start a virus scan task, corrupted license. Warning events do not influence test results.

If checking the real-time protection status is enabled, the Administration Server verifies that real-time protection is
running after the update and restart. If not, the update testing returns a failure. Note that real-time protection is
considered to be stopped only when all protection components are stopped. If any one of the components is running,
the overall status of the real-time protection is Running.

Test computers keep all updates received during updates testing, regardless of the testing result. The administrator
can create an update rollback task for them and use the On completing another task schedule option to make it
start automatically after the updates testing task returns an error.
98 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

How to configure updates testing

To prepare updates testing, first create a separate group and move the computers where updates will be tested into it.
The group must contain no other computers.

Then, enable updates testing within the properties of the Download updates to repository task. Updates testing is
a global setting. Meaning, you cannot make computers in one group receive updates after testing, and in another—
without testing.

Updates testing runs as a special task for the created group. After enabling updates testing, select or create
an updates testing task. The only way to create it is via the properties of the Download updates to repository task. If
updates testing was temporarily disabled and then enabled again, you can select the task created beforehand instead
of creating a new one.

In the task-creating wizard the administrator specifies the group where test computers are located. After that,
the wizard automatically creates an updates testing task for this group and also auxiliary tasks and policies.

After creating an update verification task, the administrator can modify its settings. Specifically, testing parameters.

The configurable parameters define which update and scan tasks should be used for testing. By default,
those automatically created along with the update testing task itself are used. However, the administrator can create
more update and scan tasks in that group and use them. In particular, the administrator can add tasks to update and
scan Kaspersky Endpoint Security 8/10 for Windows, KES 8 for Linux or Kaspersky Anti-Virus 8 for Windows
Servers Enterprise Edition. Or, the administrator can disable all virus scan tasks if considered redundant.

Restarting the computer and checking the real-time protection status are also configurable parameters. Just like on-
demand scanning, these actions are not an integral part of update testing. Test parameters are considered correct if at
least one update task is selected. All other verification actions can be turned off.

The Updates Verification task has no schedule. It starts automatically as soon as the “Download updates to
repository” task downloads updates to the temporary repository.

To disable updates testing, clear the corresponding check box in the properties of the “Download updates to
repository” task. If an update verification task is not necessary, it can be deleted. Auxiliary tasks and policies can
also be deleted.
 99
Chapter 5. Special Features
100 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

The following tasks and policies are automatically created in the group selected for update testing:

— Kaspersky Endpoint Security 10 for Windows update task

— Kaspersky Endpoint Security 10 for Windows scan task
— Test policy—Kaspersky Endpoint Security 10 for Windows

On the surface, an update task seems to have regular settings. The update source is Administration Server.
The schedule is Manually. In fact, this task is controlled by the updates testing task, and starts automatically when
the testing begins and takes updates from the temporary repository.

The virus scan task is configured to scan critical areas. With these settings, the task is able to detect conflicts with
system processes, but is likely to miss possible conflicts with custom applications. To test custom applications, add
the corresponding folders to the scan scope. Remember that in this case, testing will take somewhat longer.

Security level is similar to the recommended level, the difference being that all files are scanned including old and
unchanged, and iSwift and iChecker technologies are not used. With these settings, conflicts with old programs will
be detected, too, which can be important.

The recommended action (more often than not, Delete) is taken against the detected dangerous objects. If it turns out
to be false positive, the files will have to be recovered from the repository. To avoid this, you can select the Inform
action for this task. If the test computers are reliably isolated from infection sources and are only used for testing
the corporate software for false positives, the risk is negligible.

An auxiliary policy does not inherit parameters of a higher-level policy. So the settings within the test group are
isolated from the other groups’ settings. All parameters are configured by default, including the File Anti-Virus
action: Select automatically. Similarly to the virus scan task, it might be worthwhile to select the Block action here
to avoid grave consequences in case of false positives.
 101
Chapter 5. Special Features
102 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

Possible results of updates testing

Good updates

If updates are good, critical events and functional failures will not be encountered during the testing.
The “Download updates to repository” task should complete successfully, and updates will become available for all
network computers.

The administrator will not need to take extra actions. The only difference from the usual update process is that
updating is delayed for most computers until the testing is finished. With the default settings, updates are typically
tested for 15-20 minutes.

Bad updates

If the updates cause false positives or KES 10 malfunctioning, dangerous object detection events or errors will be
registered during the testing, the Administration Server will report a failure of the Download updates to repository
task, and other computers will not receive these updates.

The administrator should inform Kaspersky Lab about false positives through the technical account manager,
technical support portal, or [email protected] and attach the detected files.

Soon a corrected update will be issued that will not detect false positives. Until then, managed computers will not
get updates from the Administration Server.

Test computer is infected

If one of the test computers is really infected, it will also result in the failure of the Download updates to
the repository task, and the computers will not receive updates.

Following the “Bad updates” scenario, the administrator sends a request to Kaspersky Lab. In response, an answer
arrives that it is a real virus. The administrator needs to clean the test computers and start updating again. After this,
other network computers will receive updates.

The whole process takes a bit longer than necessary. To avoid this, select testing computers that are more unlikely to
be infected. Ideally, these should be dedicated computers, unexposed to malware threats, e.g. in a lab behind a very
strict firewall, with all the typical software preinstalled.
 103
Chapter 5. Special Features

5.2 Policy Profiles

What policy profiles are and who needs them

Product settings are specified in a policy. To configure different settings for different computers, you will need two
or more policies. Policies are bound to groups in Kaspersky Security Center. To apply a few policies, you will need
to group the computers accordingly.

In some cases, however, you cannot add groups, yet need to specify different settings. For example, if the groups of
Kaspersky Security Center copy the Active Directory structure (which you cannot modify), and you need to disable
some of the KES components, but only on the computers that have less than 1 GB of RAM. What if those computers
belong to different groups?

The solution is to create a profile within a policy that will be applied to the computers that have less than 1 GB of
RAM, and disable the unnecessary components in this profile.

Policy profiles provide the capability to configure different settings for different computers within a single group.
104 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

How to create a policy profile

Not all policies permit creating profiles. Kaspersky Security Center 10 SP2 enables you to create profiles in
the following policies:

— Kaspersky Endpoint Security 10 SP1 for Windows

— Kaspersky Endpoint Security 10 SP1 MR2 for Windows
— Kaspersky Endpoint Security 10 for Mobile
— Kaspersky Mobile Device Management (10 SP2)

To create a policy profile for Kaspersky Endpoint Security for Windows, open the policy properties and switch to
the Policy profiles section at the bottom. Click the Add button and name the profile properly. For example, briefly
describe the settings modified by the profile.

Configure the profile application rules. In the profile window, switch to the Activation rules section. To add a rule,
click the Add button and name the rule. A good name briefly describes the rule conditions.

You can specify the following conditions within the activation rules:

— Computer offline: Yes or No—use to apply the configuration profile to computers in the mobile mode, or,
on the contrary, to the computers connected to the Administration Server

— Rule for connection to Administration Server is active on the computer (equals to or differs from
the selected connection rule)—use to apply the configuration profile to the computers where a profile has
been switched according to the specified rule (see the section describing connection profiles for details)

In a wider sense, profile switch rules describe sites and subnets within the enterprise network. You can
apply different configuration profiles to the computers located in different subnets or offices

— Active Directory—use if groups do not copy the Active Directory structure, and configuration profiles are
to be applied to computers belonging to specific Active Directory units or groups

— Device owners—use to apply configuration profiles to mobile devices. Specify the device owners and
apply configuration profiles depending on the group the user belongs to

— Hardware—use to apply special settings to the computers that have, e.g., scarce or abundant memory, or
few or many processor cores. Quite often, all old computers can be described with the simple “Less than
1025 MB of RAM” condition

— Computer tags—use when the other conditions are not enough to describe the computers that need special
settings. Tag the target computers and then activate the profile for them.

You can combine tags or activate a configuration profile on the computers that do not have the specified tag
or tags.

All the conditions specified within a single rule are applied simultaneously. If you select a tag in the rule and
additionally specify that the computer must have more than 4096 MB of RAM, the rule will activate
the configuration profile on the computers that meet both conditions at the same time.

If you want to activate a profile on the computers that meet either of your conditions, create a separate rule for each
of the conditions. In our example, create a rule for the tagged computers and another rule for the computers having
4 GB of RAM or more.
 105
Chapter 5. Special Features
106 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

How policy profiles are applied

In a profile, you can specify the same parameters as in the policy: enable or disable any component, adjust
the security level, configure an exclusion, or create a Web Control rule.

Policy profiles should be used as follows. Suppose you want to disable the Firewall on the computers located within
the internal network:

1. Create a new profile in the policy

2. Configure activation rules for the profile to make it applied only to the computers located within
the network (for example, using the connection profile switch rules)

3. In the policy profile, switch to the Firewall section, clear the Firewall check box and close the lock to
the right of it

A closed lock in a policy profile means that this profile parameter replaces the policy parameter. The Firewall is
enabled in the policy, and this setting is enforced on all computers except those matching the profile conditions.
The computers that meet the profile activation conditions use the value specified in the profile.

By default, all parameters have opened locks in a profile. Their values are not applied to the computers. Instead,
the policy parameters are used.

The list of computers where the profile is activated is available in its properties. It is located in the Client
computers section, below the activation rules.

You can also check which profiles are activated on a computer within its properties.

A client computer does not know anything about profiles. If a policy profile is applicable to a computer,
the Administration Server calculates the resulting settings for it and sends them as if those where the policy settings.

If a few profiles are applicable to a computer, the Administration Server adds all the profiles’ settings to the policy
settings. If two profiles modify the same parameter, the one that is higher on the list takes priority.

Try to carefully consider the conditions and profiles so that every computer has no more than one profile applied.
The Administration Server will calculate the resulting settings anyway, while the administrator may get entangled.

Also, try not to use configuration profiles and policy inheritance at the same time. Profiles are inherited similarly to
the other policy parameters. Therefore, if there is a profile in the parent group policy, and the child policy inherits its
parameters, it will inherit the profile, too. However, it will be pretty easy to get lost in such a structure.
 107
Chapter 5. Special Features
108 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

5.3 Tagging Rules

When tagging rules come in handy

Tags are used in computer relocation rules, when configuring custom computer selections, and are most profitable in
policy profile activation rules. In all cases, tags help to describe a group of computers when standard conditions are
not enough.

To be able to use tags, assign them to the computers beforehand. Before Kaspersky Security Center 10 SP2,
the administrator could only assign tags in the properties of computers or Network Agent installation packages. If
you have a network of a few thousand nodes, manual tagging would be quite boring.

Meanwhile, tagging rules help to automatically assign tags to many computers: hundreds or even thousands at
a time.

How to create a tagging rule

To create a tagging rule, open the Administration Server properties and switch to the Tagging rules section. Click
the Add button and name the rule.

Then select the tag that the rule will assign. If it is a new tag, type it in the Enter a tag box. If you have already
assigned the tag manually, select it in the drop-down list.

After that, switch to the Conditions section and specify the conditions for the computers. The rule will tag all
computers that match the specified conditions.

To add a condition, click Add and enter a name for it. Then select the necessary parameter values.

Tagging conditions are similar to those used in computer relocation rules. A rule can be applied depending on:

— Network attributes of the computer:

— Name
— Domain
— Domain suffix
— IP address
— The connection IP address of the Administration Server

— Location in Active Directory:

— Unit
— Group

— Operating system:

— Type and version (Android, Linux, Windows 7, etc.)

— Architecture: x86 or x64
— Service pack number

— Virtual architecture
 109
Chapter 5. Special Features
110 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

— Installed applications:

— Application name
— Application version
— Manufacturer

A condition is used only if all the specified parameters are met. For example, if you select the Windows XP
operating system and Internet Explorer version 6.0, the tag will be applied only to the computers where both
the operating system and Internet Explorer meet the specified conditions. If you want to assign the tag to
the computers that match either of the parameters, create two separate conditions: one for Windows XP, and
the other for Internet Explorer.

A tagging rule may have any number of conditions. A rule assigns the tag to all computers that match at least one of
the specified conditions.

Two different rules may not assign the same tag. Do not try to add a new rule; just add conditions to an existing one.

You can enable and disable rules. Enabled rules work automatically and assign tags in the background. If you need
to assign tags immediately, click the Run rule now button.

Where to find the assigned tags

All computer tags are listed in its properties, in the Tags section. If a tag is selected, it is assigned. The Tag
assigned column shows how it was assigned: manually or by a rule.

If a tag has been assigned by a rule, you cannot revoke it manually. To remove an automatically assigned tag,
disable or delete the respective rule. The Administration Server will automatically remove tags from all target
computers. The tag will remain on the list, but will not be selected anymore.

5.4 Network Location Awareness

What is NLA
Network Location Awareness means that computer settings depend on their location within the network rather than
on the group. For example, policy profiles can be assigned depending on the connection profile switch rules.

Update Agents can also be assigned to subnets rather than groups. For this purpose:

1. Describe subnets using the connection profile switch rules

2. Specify NLA subnets in the Administration Server properties
3. Assign Update Agents to NLA subnets
 111
Chapter 5. Special Features
112 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

How to configure conditions for a NLA subnet

Conditions for NLA subnets are configured in the Network Agent policy. Open the policy properties and switch to
the Network, Connection section.

Add the conditions that describe the subnets to the Switch profiles list. These conditions also change
the Administration Server for computers. To avoid changing the Server, specify the standard <Home Administration
server> profile in the conditions that describe the subnets.

Describe the subnet in the terms used for switching the Administration Servers:

— Subnet address
— Address of the Gateway, DNS server, WINS server, DHCP server
— DNS domain
— DNS server address
— Name resolvability
— Accessibility of the SSL server (and certificate match)

Enable the rule that describes the subnet.

How to create an NLA subnet

Create NLA subnets in the Administration Server properties:

1. Open the Server properties and switch to the Update agents section
2. Clear the Assign update agents automatically check box and click the Configure NLA subnets link
3. Click the Add button and name the subnet
4. Select the conditions that describe the subnet on the list

This list contains all conditions from all Network Agent policies available on the Server, including inactive policies
and disabled conditions, as well as the conditions that are not related to Update Agents but are necessary for
switching the Administration Servers or applying configuration profiles. To avoid confusion, mark the conditions
for NLA subnets with, for example, the NLA acronym.

After you have created an NLA subnet, you can see which computers it comprises. Open the subnet properties and
click the View computers button.

How to assign an Update Agent to an NLA subnet

Update Agents can be assigned to NLA subnets similarly to groups. In the list of Update Agents, click Add and
select the computer. Then click the down arrow on the lower Select button, select Network Location Awareness
subnet and specify the subnet name.

If you need to change the Update Agent’s subnet, open its properties and modify its scope: add new subnets or
groups, remove those unnecessary.

You can also make the Administration Server assign Update Agents to NLA subnets automatically. For this purpose,
in the NLA subnet properties, select the Assign update agent in NLA subnet automatically check box. The Server
will automatically assign at least one Update Agent to the subnet. If there are many computers in the subnet,
the Server will also assign the second, third and more Update Agents using the same criteria as those used for
the groups: the second Update Agent is assigned if there are more than 20 computers, and so on.

The Update Agents automatically assigned by the Server to NLA subnets are displayed on the list. The administrator
can change their settings.
 113
Chapter 5. Special Features
114 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

5.5 Installing Kaspersky Security Center Failover

Cluster

Kaspersky Security Center offers a few capabilities that improve system availability and disaster recovery. One of
them is an installation on a Windows Server failover cluster. Kaspersky Security Center 10 binaries and some of
the services are installed on two nodes at least while only one node is active at any particular time, which means that
only this node has management server’s processes running. If the active node becomes inactive for some reason,
another one is activated that takes over the processes

From the client computer management viewpoint, cluster installation does not differ from an ordinary one. Let us
only mention that the virtual name of the cluster resource (which is specified during the installation) will be
displayed instead of the Administration Server name when connecting the Console to the Server, when running
the klnagchk utility, in the local interface of Kaspersky Endpoint Security for Windows, etc.

This installation is specific because of the use of cluster resources. We will note only the steps that differ from
the standard installation, which is described in course KL 002.10. When installation is started on a cluster node, the
installation wizard will detect the cluster and prompt to decide between an ordinary local installation or installation
to all cluster nodes.

Then you will need to specify the virtual server name, which will be used when connecting client computers,
displayed in the reports, etc.
 115
Chapter 5. Special Features
116 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

At the next step, you will need to specify the public IP address of the virtual server; this address will be used for
connecting the client computers. This is a must because cluster nodes typically have at least two network interfaces:
one for external connections, and another one for interactions between the nodes.

Then a cluster group that will contain all the cluster resources of this installation is created or selected. After that,
you need to specify the storage for the shared data that the application will use on all cluster nodes.

That’s it for special cluster settings. Ordinary installation starts then, except that some capabilities are missing due to
cluster specifics.

The installation wizard does not offer to automatically create accounts for the Administration Server services. You
will need to select accounts from among existing: one of the accounts for the Administration Server service, and
another one for accessory services.
 117
Chapter 5. Special Features
118 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

At the next step, the database server and name is specified, which will be used by the Administration Server. During
a cluster installation, a local instance of Microsoft SQL Express cannot be used, and you need to specify a dedicated
database server.

And finally, you need to specify a name for the shared folder (the default one is KLShare), where installation
packages and updates will be stored. The folder will reside in the abovementioned storage. There are no more
differences.

After the installation is finished, you can make sure that the cluster name is actually used instead of a node name
when connecting and when displaying events and reports. However, if an event concerns only one of the cluster
nodes, the node name will be displayed. You can also make sure that a hidden folder related to Kaspersky Security
Center has been created on the shared network drive connected to the active node, which contains installation
packages, updates, and some other data. You can also open Windows Failover Cluster Manager and notice a new
group with Security Center cluster resources. And finally have a look at the Administration Server services: almost
all of them have the “_cluster” suffix in the name due to their nature.
 119
Chapter 5. Special Features
120 KASPERSKY LAB™
KL 302.10. Kaspersky Endpoint Security and Management
Advanced Skills

v1.0.1