This post will describe the steps to prepare and deploy TDAD (Javelin). This is part of a series of articles about Javelin AD Protect and installing, configuring, and investigating incidents. This one will focus on how to install Symantec Endpoint Threat Defense for AD.

AD Protect Deployment Introduction

There are a few ways and scenarios to install ADProtect, for a simple or complex environment. Still, the primary consideration depends on your environment, so let’s start with basic deployment.
It is important to emphasize that some of the requirements and settings are compatible with complex and straightforward deployment.
Protect defends the Active Directory environment, both from the endpoint and the domain controller’s perspectives. The AD Protect core server manipulates memory via SMB to allow seamless integration and, more critically, hiding from an attacker.
The challenging part of an ADProtect deployment is preparing and confirming the prerequisites for ADProtect. This is because few crucial requirements are needed for the ADProtect architecture and allow ADProtect to defend your Active Directory environment.

Architecture

The ADProtect Architecture includes an ADProtect role and other components (based on your environment):

• ADProtect Core server – including the core server itself, DM, and Web-Based UI
• Cloud and On-Premises – AAD Connect, Active Directory environment including a connector to cloud, SIEM, endpoint, and servers

Requirements

The ADProtect prerequisites are divided into few parts:

• ADProtect Server – the ADProtect core server including all components for DM and UI
• Accounts – service account for deployment, deception, and daily manage
• Active Directory – audit configuration and security logs
• Firewall Ports – specific firewall ports for ADProtect core server

The requirements for ADProtect deployment is describing below:
Note: in any part of the Account or server’s preparation and settings, do not mention any names belonging to Javelin or protect at all.

ADProtect Core Server Requirements

• Windows Server 2012 R2 and higher
• Hardware – 2 Cpu, 8GB Memory, and 200GB Hard Drive
• Static IP address
• Must be a Domain member
• Do not install tools and products such as IIS Role, AV (can be installed after core), or any other role or components.
• Latest Windows Update with all security update

Services Accounts Requirements

The ADProtect core server working with a few services accounts for deployment and management.
Core Server Account – this Account is intended for installation and management (Based on DA Equivalent)

• Domain user account 
• Local Admin on endpoints and servers
• Configure with “interactive Login Right.”
• Complete Control of the Deception Account
• Configure with “account is sensitive and cannot be delegated.”

Deception Account – This Account is stored in each endpoint’s memory in the lsass process and appears to be a Domain Admin. 

• Part of Domain users
• Must be alphanumeric and do not include any special characters
• The initial password can only contain these special characters.
• Domain password requirement is not more than 30 characters.

DM Account – (depend on the scenario – no need if you have a Core account) The Core Server will have a local DM running an IIS application pool that will use this Account for deployments. (in a specific scenario where the Core account will be the DM account).
This implementation style does not leave the Account vulnerable to a Privileged SPN scan, Silver Ticket Attack, or Kerberoasting. The credential is not left behind when it executes the MM deployment.

• Configure as Account is sensitive and cannot be delegated
• Member of Domain Users
• Make sure it is configured with Logon as a service.
• Make sure it is configured with Logon as a batch job.
• Make sure it is configured with Allow Log on Locally.

Active Directory Audit & Logs Requirements

There are several ways that ADProtect can collect the relevant logs from the Active Directory, such as Windows Management Instrumentation (WMI), Event Forwarding, and Syslog Forwarding.
Domain Controllers Event & Logs
The Domain Controllers must be configured to create security events around authentication. This is usually already configured in production environments but rarely is configured in test labs. Event IDs created are 4624, 4768, 4769, 4771, and 4776.

• Ensure that Active Directory auditing is enabled on each Domain Controller (DC’s that are part of the scope).
• 4624 – A new Kerberos ticket created
• 4768 – A Kerberos authentication ticket (TGT) was requested
• 4769 – A Kerberos service ticket was requested
• 4771 – Kerberos pre-authentication failed
• 4776 – NTLM events.

Default Domain Controller Security Policy
Make sure that the settings below are configured:

• Audit Account Logon Events – Success and Failure 
• Audit Logon Events – Success and Failure 
• Confirm Audit Credential Validation –  Success and Failure 
• Confirm Audit Kerberos Authentication Service – Success and Failure 
• Confirm Audit Kerberos Service Ticket Operations – Success and Failure 
• Confirm Audit Other Account Logon Events – Success and Failure

Active Directory Security Logs
This requirement is to limit the scope. An increase in a range can be discussed with your Javelin SE before the POC begins.
There are multiple ways that ADProtect can collect the necessary security logs from the Active Directory: WMI, Event Forwarding through Microsoft Event Subscription, and Syslog Forwarding. 

Firewall and Network Requirements

To allow ADProtect to work with dedicated ports, you need to configure the following firewall ports:
Windows Firewall and Advanced Security

• Confirm Com+ Network Access (DCOM-in) is enabled.
• Com+ Remote Administration (DCOM-in) is enabled
• Remote Event log management (NP-in) is enabled.
• Remote Event log management (RPC) is enabled.
• Remote Event log management (RPC-EPMAP) is enabled.
• Windows Management Instrumentation (ASync-in) is enabled.
• Windows Management Instrumentation (DCOM-in) is enabled.
• Windows Management Instrumentation (WMI-in) is enabled.

Firewall Rules
Most rules only apply to internal traffic on the network. If endpoints have Windows FW on, you will need a GPO to enforce the first rule below. Also, VPN Clients will need this FW rule as well.

Install, Configure & LAB

The installation and configuration process is pretty simple but essential in ADProtect deployment and must be done carefully. The installation below is based on Microsoft Azure with a virtual machine and the following roles:

The LAB

• Active Directory-based Windows Server 2019
• ADProtect core server based on Windows Server 2016
• Windows 10 build 1903 (Attacker and User Desktop)

The Installation Process

Note: The Installing Javelin Core… will take about 15 minutes, and it depends on your Windows Server resources


Note: Once the installation is finished, you must reboot the ADProtect Core server and perform a VM snapshot (VM snapshot – if the server is virtual).

Configuration & Settings

The configuration process is a one-time configuration and settings unless you need to make some changes.
Access to UI – First thing first go to the Web-Based UI > https://servername or ipaddress\ui (our scenario https://jlab-adp/ui)
Create Javelin Application Account – Next, the “Create Your Javelin Account” will appear; type Javelin admin user and password.
Note: this is the first Javelin application administrator


Javelin Settings – Next, you can configure a few settings that allow you to send an email notification, send health data to Javelin, and let the valuable AD Assessment.
Note:

• Javelin Cloud will send health data on your server back to Javelin, allow you to get software updates from the cloud, and enable Javelin Support to fetch logs directly (No PI info is sent).
• AD Assessment enables the “Dark Corners,” the scan of vulnerabilities and misconfigurations within Active Directory.
• These settings can be changed from the admin console as required.

Deployment Manager Configuration – Once finished with the Account and general settings, you will land on the ADProtect console.
The Javelin Domains settings contain the Deployment Manager configured within the application and handle communication between the ADProtect Core server and the protected endpoints (Windows Server and Windows Client). A DM is bound by the Forest and Domain of the Core account or DM Account assigned.
This Account will execute within an IIS JSM application pool and be used for endpoints (Windows Server and Windows Client) Memory Manipulation deployment. The first DM will run on the local host of the ADProtect Core Server. Large environments with multiple

Note: Type Core account or DM account

Note: Choose your Log Method

Conclusion

As you can see, the Javelin ADProtect installation and the first configuration process are pretty simple and relatively fast actions. The most crucial measure on the Javelin ADProtect server is the preparation steps. The following post will describe the best practices, essential activities, and recommendations in the Javelin ADProtect installation process.
More blog posts about AD Security