Deciding Where to Install Collectors and Audit Stores
Although a collector and an audit store database can be installed on the same computer for evaluation, you should avoid doing so in a production environment. As part of the planning process, therefore, you need to decide where to install collectors and audit store databases. In designing the network topology for the audit and monitoring service installation, there are several factors to consider. For example, you should consider the following:
- Database load and capacity
- Network connectivity
- Port requirements
- Active Directory requirements
The next sections provide guidelines and recommendations to help you decide where to install the collectors and audit store databases required to support the number of computers you plan to audit.
Use Separate Computers for Collectors and Audit Store Databases
To avoid overloading the computers that host collectors and audit store databases, you should install collectors and audit store SQL Server databases on separate computers. Because SQL Server uses physical memory to store database information for fast query results, you should use a dedicated computer for the audit store database, and allocate up to 80% of the computer’s memory to SQL Server. In most installations, you also need to plan for more than one audit store database and to periodically rotate from one database to another to prevent any one database from getting too large. For more information about managing audit store databases, see Managing audit store databases.
Plan for Network Traffic and Data Storage
You should minimize the distance network packets have to travel between an agent and its collector. You should also minimize the distance between collectors and their audit stores. If possible, you should not have more than one gateway or router hop between an agent and its collector.
Default Ports for Network Traffic and Communication
To help you plan for network traffic, the following provides an overview of the network communications and ports used when a user logs on and the ports used in the initial set of network transactions.
When a user logs on, the Agent for Windows connects to Active Directory to begin the lookup process, then the agent and the domain controller exchange messages as follows:
- Directory Service - Global Catalog lookup request on port 3268.
- Authentication Services - LDAP sealed request on port 389.
- Kerberos – Ticket Granting Ticket (TGT) request on port 88.
-
Network Time Protocol (NTP) Server – Time synchronized for Kerberos on port
123.
-
Domain Name Service (DNS) – Host (A), Pointer (PTR), Service Location (SRV)
records on port 53.
-
RPC over TCP - For inbound RPC endpoint mapper connections to support
network discovery or if password management and validation uses RPC over TCP
on port 135.
Depending on the specific components you deploy and operations performed, you might need to open additional ports. The following table summarizes the ports used for different editions of Delinea software.
| This port | Is used for | Delinea software and operation requiring this port |
|---|---|---|
| 22 | Encrypted TCP communication for OpenSSH connections | Authentication service and privilege elevation service for secure shell connections on remote clients. |
| 23 | TCP communication for Telnet connections | Delinea authentication service, privilege elevation service, and audit and monitoring service. By default, telnet connections are not allowed because passwords are transferred over the network as plain text. |
| 53 | TCP/UDP communication | Authentication service and privilege elevation service, clients use the Active Directory DNS server for DNS lookup requests. |
| 88 | Encrypted UDP communication | Authentication service and privilege elevation service, Kerberos ticket validation and authentication, agents, Delinea PuTTY |
| 123 | UDP communication for simple network time protocol (NTP) | Authentication service and privilege elevation service, keeps time synchronized between clients and Active Directory for Kerberos ticketing. |
| 389 | Encrypted TCP/UDP communication | authentication service and privilege elevation service, Active Directory authentication and client LDAP service. |
| 443 | Cloud proxy server to Delinea cloud service | Delinea software for mobile device management. |
| 445 | Encrypted TCP/UDP communication for delivery of group policies | Authentication service and privilege elevation service, adclient and adgpupdate use Samba (SMB) and Windows file sharing to download and update group policies, if applicable. |
| 464 | Encrypted TCP/UDP communication for Kerberos password changes | Authentication service and privilege elevation service, Kerberos ticket validation and authentication for agents, Delinea PuTTY, adpasswd, and passwd. |
| 1433 | Encrypted TCP communication for the collector connection to Microsoft SQL Server | Authentication service, privilege elevation service, and audit and monitoring service; collector service sends audited activity to the database. |
| 3268 | Encrypted TCP communication | Authentication service and privilege elevation service, Active Directory authentication and LDAP global catalog updates. |
| 5063 | Encrypted TCP/RPC communication for the agent connection to collectors | Authentication service, privilege elevation service, and audit and monitoring service; auditing service records user activity on an audited computer. |
| none | ICMP (ping) connections | Authentication service and privilege elevation service, to determine whether if a remote computer is reachable. |
Auditing Requires Database Management
If you are planning a deployment with just audit and monitoring service or with identity management, privilege management, and auditing, you must plan how you will create and manage the databases that receive and store audit data. You should also consider your data archiving and retention policies, who should be given auditor permissions, and other details because these decisions affect your storage and maintenance requirements. For more information about managing an installation for auditing, see Managing auditing for an installation.
For audit and monitoring service, you should plan a pilot deployment of 20 to 25 agents to determine how much audit data your organization would generate and how fast the database can increase in size as you add agents. For more information about monitoring a pilot deployment for audit and monitoring service and guidelines for sizing the database, see Estimating database requirements based on the data you collect.
Identify an Active Directory Site or Subnets
Depending on the size and distribution of your Active Directory site, an audit store might cover an entire site or specific subnet segments. If you have a large, widely distributed site, you should consider network connectivity and latency issues in determining which subnets each audit store should serve. In addition, you should always place collectors in the same site as the agents from which they receive data. Collectors and agents must always be in the same Active Directory forest. If possible, you should put collectors and agents in the same domain.
If you deploy agents in a perimeter network, such as a demilitarized zone (DMZ), that is separated from your main network by a firewall, put the collectors in the same Active Directory domain as the audited computers. The collectors can communicate with the audit store database through a firewall.
Determine How Many Collectors and Audit Stores to Install
Although you can add collectors and audit stores to your audit and monitoring service installation after the initial deployment, you might want to calculate how many you will need before you begin deploying components. You should always have at least two collectors to provide redundancy. As you increase the number of agents deployed, you should consider adding collectors.
Estimate the Number of Agents and Sessions Audited
If you plan to use more than the minimum number of collectors, the most important factor to consider is the number of concurrent sessions you expect to monitor on audited computers. The number of concurrent sessions represents the number of interactive users that the agent is actively capturing for at the same time.
You can use the following guidelines as a starting point and adjust after you have observed how much audit data you are collecting and storing for Windows computers:
| Number of concurrent sessions | Recommended number of collectors | Recommended number of audit stores |
|---|---|---|
| up to 100 agents | 2 | 1 |
| more than 100 agents | 2 for every 100 agents | 1 for every 100 agents |
Determine the Recommended Hardware Configuration
The hardware requirements for collectors and audit store servers depend on the size of the installation and where the components are installed on the network. For example, the requirements for a computer that hosts the collector service are determined by the number of audited computers the collector supports, the level of user activity being captured and transferred, and the speed of the network connection between the agents and the collector and between the collector and its audit store.
You can use the following guidelines as the recommended hardware configuration for the computers you use as collectors and audit store servers when auditing Windows computers:
| Computer used for | Number of concurrent sessions | CPU cores | CPU speed | Memory |
|---|---|---|---|---|
| Collectors | Up to 100 active agents | 2 | 2.33 GHz | 8 GB |
| Audit store | Up to 200 active agents | 2 | 2.33 GHz | 8 GB |
| 200 to 500 active agent | 4 | 2.33 GHz | 32 GB |
Guidelines for Storage
Because audit and monitoring service collectors send captured user sessions to the active SQL Server database, you should optimize SQL Server storage for fast data logging, if possible. For the active database, you get the most benefit from improvements to disk write performance. Read performance is secondary. Fibre Attached Storage (FAS) and Storage Area Network (SAN) solutions can provide 2 to 10 times better performance than Direct Attached Storage (DAS), but at a higher cost. For attached databases that are only used to store information for queries, you can use lower cost storage options.
Guidelines for Disk Layout
The following table outlines the recommended disk arrays:
| Application | Disk configuration | Use the disk for |
|---|---|---|
| Operating system | C: RAID 1 | Operating system files, page file, and SQL Server binaries. |
| Microsoft SQL Server | D: RAID 10 (1+0) | Audit store database. |
| E: RAID 10 (1+0) | Audit database log files. | |
| F: RAID 1 or 10 (1+0) | Temporary database space (tempdb) for large queries for reports. | |
| G: RAID 1 | Database dump files. |
The size of disk needed depends on the number, length, and types of sessions recorded each day, the selected recovery model, and your data retention policies. For more information about managing audit store databases, see Managing audit store databases.
