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 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 Default Ports
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.
To help you plan for network traffic, the following ports are used in the initial set of network transactions:
- 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.
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 Server Suite software.
| This port | Is used for | Server Suite software component |
|---|---|---|
| 23 | TCP communication for Telnet connections | Server Suite 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 | Clients use the Active Directory DNS server for DNS lookup requests. |
| 88 | Encrypted UDP communication | Kerberos ticket validation and authentication, agents. |
| 123 | UDP communication for simple network time protocol (NTP) | Keeps time synchronized between clients and Active Directory for Kerberos ticketing. |
| 389 | Encrypted TCP/UDP communication | Active Directory authentication and client LDAP service. |
| 443 | Cloud Connector communication with Privileged Access Service | Cloud Connector |
| 445 | Encrypted TCP/UDP communication for delivery of group policies | The 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 | Kerberos ticket validation and authentication for agents, adpasswd, and passwd. |
| 1433 | Encrypted TCP communication for the collector connection to Microsoft SQL Server | The collector service sends audited activity to the database |
| 3268 | Encrypted TCP communication | Active Directory authentication and LDAP global catalog updates. |
| 5063 | Encrypted TCP/RPC communication for the agent connection to collectors | The auditing service records user activity on an audited computer. |
| 5064 | Encrypted SSL/TLS communication for the agent connection to collectors for systems that are not joined to Active Directory. | The auditing service records user activity on an audited computer outside of Active Directory. |
| none | ICMP (ping) connections | To determine whether if a remote computer is reachable. |
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.
Determining How Many Collectors and Audit Stores to Install
Although you can add collectors and audit stores to your audit 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 agents that are actively capturing user sessions in a site at the same time.
Guidelines for Linux and UNIX Computers
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 Linux and UNIX computers:
| Number of concurrent sessions | Recommended number of collectors | Recommended number of audit stores |
|---|---|---|
| 500 (or less) agents | 2 | 1 |
| up to 1000 agents | 4 | 1 |
| more than 1000 agents | 2 for every 500 agents | 1 for every 1000 agents |
Guidelines for Windows Computers or Mixed Environments
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 |
|---|---|---|
| 100 (or less) agents | 2 | 1 |
| more than 100 agents | 2 for every 100 agents | 1 for every 100 agents |
If you auditing Linux, UNIX, and Windows computers, use the numbers of collectors and audit stores recommended for Windows agents unless you have significantly fewer Windows 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.
Guidelines for Linux and UNIX Computers
You can use the following guidelines as the recommended hardware configuration for the computers you use for collectors and audit store servers when auditing Linux and UNIX computers:
| Computer used for | Number of concurrent sessions | CPU cores | CPU speed | Memory |
|---|---|---|---|---|
| Collectors | Up to 250 active UNIX agents | 2 | 2.33 GHz | 8 GB |
| 250 to 500 active UNIX agents | 4 | 2.33 GHz | 16 GB | |
| Audit store | Up to 250 active UNIX agents | 2 | 2.33 GHz | 8 GB |
| 250 to 500 active UNIX agents | 4 | 2.33 GHz | 16 GB | |
| 500 to 1000 active UNIX agents | 4 | 2.33 GHz | 32 GB |
Guidelines for Windows Computers
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 Windows agents | 2 | 2.33 GHz | 8 GB |
| Audit store | Up to 200 active Windows agents | 2 | 2.33 GHz | 8 GB |
| 200 to 500 active Windows agents | 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 store 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.
