INFORMATION

Tenable Identity Exposure (TIE) achieves its security monitoring by accessing the Active Directory (AD) replication flow without the need for administrative privileges. Despite its many advantages (operation safety, limited attack surface, etc.), this approach relies on the ability of the user account to read all Active Directory objects stored in a domain including, but not limited to:

• User accounts
• Organizational units
• Groups

DETAILS

Other than that it should be created in the main monitored domain, the TIE service account:

• can be created in any Organizational Unit (OU). It is a best practice to create it in the OU that houses other security service accounts.
• should be a member of a standard user group (e.g. the "Domain Users" built-in group).

TIE currently supports explicit authentication based on a login and password. Therefore, it is recommended to use a pre-defined password with the PasswordNeverExpires attribute set, or with password renewal policies not being enforced. A strong and unpredictable password must be used.

While all collected data is accessible by a simple user and no secret attributes (credentials, password hashes, or Kerberos keys) are accessed by TIE, the following two containers do need to be manually configured to allow read access for the TIE user account:

• Deleted Objects: The container hosting deleted objects located at:

  CN=Deleted Objects,DC=,DC=

• Password Settings: The container hosting password policies located at:

  CN=Password Settings Container,CN=System,DC=,DC=

This is necessary because TIE updates the information related to AD objects according to their modifications that appear in the replication flow. When an object is deleted, TIE can only update its state if it can read the deleted object container. If deviance was present on an object being deleted and the application is not able to access this information, the state of the object can never be updated and the deviance will never be resolved. Similarly, if the Password Settings container cannot be accessed, related Indicators of Exposure (e.g. "Weak password policies are applied to users") cannot be determined.

Granting access to AD objects and containers

In the domain controller's PowerShell console, run the following commands to grant access to Active Directory objects or containers, where <SERVICE_ACCOUNT> refers to the service account that Tenable Identity Exposure uses:

#Set Service Account
$serviceAccount = "<SERVICE_ACCOUNT>"

#Don't Edit after here
$domain = Get-ADDomain
@($domain.DeletedObjectsContainer, "CN=Password Settings Container,$($domain.SystemsContainer)") | ForEach-Object {
    & dsacls $_ /takeownership
    & dsacls $_ /g "$($serviceAccount):LCRP" /I:T
}

Note: You must run these commands on each domain that Tenable Identity Exposure monitors.

Alternatively, if PowerShell is not available, you can also execute these commands for each container.

For each of the above-mentioned containers, a member of the Domain Admins group needs to grant access to the TIE service account via the command line:

dsacls "<CONTAINER>" /takeownership
dsacls "<CONTAINER>" /g <SERVICE_ACCOUNT>:LCRP /I:T

Note: Replace <CONTAINER> and <SERVICE_ACCOUNT> according to the AD environment.

For example, for a TIE service account named TenableAD in your.domain:

dsacls "CN=Deleted Objects,DC=your,DC=domain" /takeownership
dsacls "CN=Deleted Objects,DC=your,DC=domain" /g TenableAD:LCRP /I:T
dsacls "CN=Password Settings Container,CN=System,DC=your,DC=domain" /takeownership
dsacls "CN=Password Settings Container,CN=System,DC=your,DC=domain" /g TenableAD:LCRP /I:T