Kerberos Trust Provider

The Kerberos Trust Provider enables the attestation of Client Workloads running on virtual machines (VMs) joined to Active Directory (AD).

This attestation method is specifically designed for on-premise deployments where alternative attestation methods, such as AWS or Azure metadata service Trust Providers, aren’t available.

This Trust Provider is unique because it relies on attestation provided by an Aembit component, rather than attestation from a third-party system. In this scenario, the Aembit Agent Controller acts as the attesting system. It authenticates a client (specifically, Agent Proxy) via Kerberos and attests to the client’s identity. The client’s identity information is then signed by the Aembit Agent Controller and validated by Aembit Cloud as part of the access policy evaluation process.

Prerequisites

Many prerequisites are necessary, particularly regarding domain users and principals. This page outlines Aembit’s current recommendations for a secure and scalable deployment.

Kerberos based attestation is available only for Virtual Machine Deployments.

Join your Edge Components to AD domain

You must join Agent Controller VMs to AD before you install Agent Controller on them.
You must join Client Workload VMs to AD before installing Agent Proxy.

Domain users and service principals

You must create a user in AD named aembit_ac for Agent Controllers. This user doesn’t need any specific permissions in AD.
You must create a service principal for the Agent Controller under the aembit_ac AD user.
- For testing purposes, create a service principal HTTP/<Agent-Controller-hostname>.
- For production purposes, see High Availability.
Agent Controllers on Windows Server in high availability (HA) configurations, must set the SERVICE_LOGON_USER environment variable to an AD user in Down-Level Logon Name format (for example: SERVICE_LOGON_USER=<DOMAIN>\<sAMAccountName>$).

Network access

Agent Controller VMs don’t need access to the Domain Controller.
Client Workload VMs must have access to the Domain Controller to acquire tickets.

Keytabs

Agent Controller
- Agent Controller Linux VMs require a keytab file for the Agent Controller AD user.
- You can place the keytab file on the VM before or after the Agent Controller installation.
- The Agent Controller Linux user must have read/write permissions on the keytab file (aembit_agent_controller). If you place a keytab file before you install the Agent Controller, Aembit recommends creating a Linux group aembit and a Linux user aembit_agent_controller, and making this file accessible by this Linux user/group.
- If your organization has mandatory AD password rotation, make sure you have a configuration in place for keytab renewal.
  
  See Agent Controller keytab rotation for more information.
Agent Proxy
- The Agent Proxy on the Client Workload machine uses the host keytab file.
- The Agent Proxy uses the sAMAccountName principal from the host keytab.
- The host keytab can have Linux root:root ownership.

Kerberos Trust Provider match rules

The Kerberos Trust Provider supports the following match rules:

Principal
Realm/Domain
Source IP

:::warning Important

When matching on Principal or Realm/Domain, see Kerberos Principal formatting for guidance.

:::

Data	Description	Example
Principal	The Agent Proxy’s VM principal	`IP-172-31-35-14$@EXAMPLE.COM`
Realm	The realm of the Client Workload VM principal	`EXAMPLE.COM`
Domain	The NetBIOS domain of the Client Workload VM principal	`example`
Source IP	The Network Source IP address of the Client request	`192.168.1.100`

Associated Agent Controllers

During the configuration of the Kerberos Trust Provider, you must specify the list of Agent Controllers responsible for providing attestation. Aembit trusts only the attestation information signed by specified Agent Controllers by a Kerberos Trust Provider entry.

Kerberos Principal formatting

Aembit supports Agent Controller on Windows VMs to improve management of the Aembit Edge Components. This is especially true for Agent Controller high availability configurations that use Windows Group Managed Service Accounts (gMSA) to manage multiple Agent Controllers.

The challenge is that Windows and Linux systems treat AD differently, in that Linux treats it purely as Kerberos and Windows treats it natively like AD. This results in different naming and formatting for the Kerberos Principal value that Aembit uses in Kerberos tokens which it exchanges for AD authentication.

The following table details all the combinations you can encounter based on the OS installed on Agent Controller and Agent Proxy:

OS combination	Principal format
Linux Agent Controller + Linux Agent Proxy	`<sAMAccount name>@<realm>`
Linux Agent Controller + Windows Agent Proxy	`<User name>@<realm>`
Windows Agent Controller + Linux Agent Proxy	`<NetBIOS domain name>\<sAMAccount name>`
Windows Agent Controller + Windows Agent Proxy	`<NetBIOS domain name>\<User name>`

As part of the Kerberos Trust Provider attestation process and to address this challenge, Aembit Cloud automatically parses the attested Kerberos Principal value and verifies either the realm or the domain from the value for you.

Enable Kerberos attestation

By default, Aembit disables Kerberos attestation on both Agent Controller and Agent Proxy.

Follow the applicable sections to enable Kerberos attestation on Aembit Edge Components:

Agent Controller on Windows Server

To enable Kerberos attestation for Agent Controller on a Windows Server VM, you must set the following environment variables:

AEMBIT_KERBEROS_ATTESTATION_ENABLED=true
SERVICE_LOGON_USER=<DOMAIN>\<sAMAccountName>$

Agent Controller on Linux

To enable Kerberos attestation for Agent Controller on a Linux VM, you must set the following environment variables:

AEMBIT_KERBEROS_ATTESTATION_ENABLED=true
KRB5_KTNAME=<Agent Controller keytab file location>

Agent Proxy

Similarly, the Agent Proxy installer requires the following environment variable (in addition to the standard variables provided during installation):

AEMBIT_KERBEROS_ATTESTATION_ENABLED=true
AEMBIT_PRIVILEGED_KEYTAB=true

TLS

The contents of the communication between Agent Proxy and Agent Controller is sensitive. In a production deployment, you may configure Agent Controller TLS to secure communication between these two components using either a Customer’s PKI or Aembit’s PKI. Please see the following pages for more information on using a PKI in your configuration:

High availability

Given the critical role of attestation in evaluating an Access Policy, Aembit strongly encourages configuring multiple Agent Controllers in a high availability architecture.

To learn how, see Agent Controller High Availability.

The following are the additional steps you must perform for Kerberos attestation to work in a highly available configuration:

You don’t need to join the load balancer to your domain.
You must create a service principal HTTP/<Load Balancer hostname> under the Aembit Agent Controller Active Directory user.
You don’t need to create principals for individual Agent Controller VMs.
You must place the keytab for the Agent Controller AD user (including the load-balancer service principal) on all Agent Controller VMs.
If you operate multiple Agent Controller clusters running behind one or more load balancers, you must add each load balancer FQDN as the service principal under Agent Controller AD account.

Agent Controller keytab rotation for high availability deployment

Standard best practice recommends the periodic rotation of all keytabs.

Considering that Aembit shares the keytab representing an Agent Controller’s identity across multiple Agent Controller machines, the common method of keytab rotation on Linux (using SSSD) isn’t feasible.

Your organization must have a centrally orchestrated keytab rotation, where the Agent Controller AD user keytab is rotated centrally and then pushed to all Agent Controller Virtual Machines. Note that the entity performing the keytab rotation needs the appropriate permissions in AD to change the Agent Controller password during new-keytab creation.