DeepSurface: LDAP (Active Directory)

Documentation
Installation Guide
Overview
Let DeepSurface Host For You
Getting Started
System Requirements
Self Hosted Quick Start - Installing to Cloud Platforms
Self Hosted - Installation Using an OVA
Registration, Package Installation, and Initialization
First Steps After Initialization of the Console
Deployment Options
Main and Subordinate Consoles
Agent-Based Deployment
User Managed Scan Deployment
Credentialed Scanning Deployment
Mixed Environment
Deployment Tools
Active Directory Group Policy
Microsoft Endpoint Configuration Manager (part of InTune)
Tanium Deploy
HCL BigFix
Ivanti
Virtual Machines
VMWare
Virtual Box
VirtualBox Guest Additions
AWS EC2 (BYOL)
AWS EC2 (Usage Based)
Azure Cloud
Google Cloud
Additional Items to Consider
Main Console Server Certificates
LDAP
TOFU
Clock Sync
DeepSurface Commands
Multiple Vulnerability Sources
API Documentation
User Guide
Reporting
Dashboards
Exports
Risk Insight
Hosts
Patches
Vulnerabilities
Vulnerability Instances
Users
Remediation Workflow Manager
Plans
Settings
Integrations
Workflow
Exporting
Accepted Risk Plans
Accepted Risk Workflow
Explore
Model
Paths
Activity
Tasks
Configuration Alerts
Scan Logs
Notification Settings
Scanning
Status
Agents
User Managed
Credentialed Scanning Settings
Credentials
Scan Groups
General Settings
Cloud Scanning
Network Connectivity
Subordinates
Vulnerability Sources
Setup
Sensitive Assets: Polices
Sensitive Assets: Manual
Admin Settings
SMTP Settings
Certificates
Outbound Proxy
Authentication Providers
Users
Tags
Integrations Guide
Vulnerability Sources
CrowdStrike Spotlight
SentinelOne
Carbon Black Cloud
Microsoft Defender for Endpoint
Wazuh
Lansweeper Cloud
Nessus API
Tenable.io API
Security Center/Tenable.sc API
Rapid7 InsightVM API
Qualys API
Nozomi Guardian
Eclypsium
AWS Inspector
Remediation
Jira Software
Tanium (BETA)
Authentication Providers
LDAP (Active Directory)
SAML (Azure Active Directory)
SAML (Google)
SAML (Okta)
PAM
CyberArk
Delinea (Thycotic)
Microsoft LAPS
Security Guide
Firewall Configuration
Base Network Requirements
Agent Network Requirements
Credentialed Scanning Network Requirements
API Network Requirements
How DeepSurface Scans Work
Domain (LDAP) Scanning
Host Scanning Routine
Reasons for the Administrative Access Requirement
Endpoint Protection Considerations
Other Items
Scope of Data Storage and Retention
IPS/IDS Considerations
Logging
Resetting the DSADMIN password
Product Information
Changelogs
Open source Licenses
End User License Agreement (EULA)

The Lightweight Directory Access Protocol LDAP can be used to communicate with Microsoft Active Directory service to authenticate web console users. Under this authentication provider configuration, a user's username and password must match their domain username and password exactly.

Here is more detail regarding each of the fields you see when creating a new authentication provider of this type.

Name: A label for this particular configuration.

Provider Type: Currently, only LDAP for Active Directory is supported.

Servers: A list of servers used for validating administrative user credentials. The list will be tried in order. The names should be separated with commas or newlines and may be either IP addresses or host names.

Encryption Protocol: DeepSurface requires that any communication with LDAP servers be encrypted. There are two types currently supported.

  1. SSL/TLS - typically runs on port 636.
  2. StartTLS - typically runs on port 389.

Port Number: The TCP port number of the LDAP service corresponding to the encryption protocol chosen, generally 636 for SSL/TLS or 389 for StartTLS.

Windows Domain: The Windows domain of users associated with this Authentication Provider.

For example, suppose the Windows domain is ACME and there is a user, alice, associated with that domain. Alice's password will be validated by an attempted LDAP bind as ACME\alice (with the user, alice, entering their password).

If the field is left blank, each user account's username must configured with the form [Domain][user name], or in Alice's case, ACME\alice. You might want to do that if you have multiple domains where a single set of domain controllers can authenticate users for all of those domains, which would allow you to have just a single Authentication Provider configuration.

If you specify a domain, then each user account's username must not include the domain name. In the example, if the administrator set the domain to ACME, then Alice's username must be set to "alice" and Alice would enter this exact string as the username during login. This is configuration is simpler for users to remember, but would require a separate authentication provider configuration for each domain.

Trust on First Use (TOFU): If an LDAPS or LDAP/StartTLS service presents a certificate that isn't signed by a known certificate authority (e.g. a self-signed certificate), then DeepSurface will reject this certificate (unless TOFU is enabled) and the authentication provider will be rendered non-functional.

Visit the Trust on first use (TOFU) to learn more about how it works and what the limitations are. TOFU allows for a much simpler deployment while minimizing the window of opportunity for man-in-the-middle attacks. However, in high-security environments, DeepSurface Security recommends TOFU be disabled and that every service be configured with a signed certificate from a trusted certificate authority (CA). If your organization maintains an internal CA, you can add the CA certificate on the certificates administration page.