Managing user accounts individually within Wazuh becomes increasingly difficult as your security team grows. Creating local users for every analyst, administrator, auditor, and incident responder introduces unnecessary administrative work, increases the likelihood of configuration inconsistencies, and makes user lifecycle management more complex. Integrating Wazuh LDAP authentication solves this problem by allowing Wazuh to authenticate users against an existing enterprise directory service.

LDAP (Lightweight Directory Access Protocol) enables Wazuh to verify user credentials using centralized identity stores such as Microsoft Active Directory or OpenLDAP.

Rather than maintaining separate usernames and passwords inside Wazuh, administrators can leverage existing corporate accounts, simplifying access management while improving security.

For organizations already using centralized identity management, LDAP integration offers significant operational advantages.

User onboarding becomes almost automatic, employee departures can be handled by disabling a single directory account, password policies remain consistent across systems, and security teams gain better visibility into authentication activity.

Whether you’re deploying Wazuh for a small security team or a large enterprise SOC supporting thousands of users, LDAP authentication helps create a more secure, scalable, and maintainable deployment.

In this guide, you’ll learn:

• What Wazuh LDAP authentication is and how it works
• How Wazuh integrates with LDAP directory services
• The difference between authentication and authorization
• Which LDAP servers are supported
• The benefits of centralized authentication
• How to configure LDAP step by step
• Common troubleshooting techniques
• Security best practices for production deployments

What Is Wazuh LDAP Authentication?

Wazuh LDAP authentication allows users to log in to the Wazuh Dashboard using credentials stored in an external LDAP directory instead of locally managed accounts.

During the login process, Wazuh forwards the supplied username and password to the configured LDAP server, which validates the credentials before granting access.

This approach enables organizations to reuse their existing identity infrastructure rather than maintaining separate authentication databases for every security application.

How Wazuh Integrates with LDAP Directories

The Wazuh Dashboard relies on the underlying OpenSearch Security authentication framework to communicate with LDAP servers.

When a user submits login credentials, the authentication backend performs an LDAP bind operation using the configured directory settings.

If the bind succeeds, Wazuh authenticates the user and can retrieve additional directory attributes such as group membership for authorization decisions.

Depending on the deployment, administrators can:

• Authenticate users directly against LDAP
• Retrieve LDAP group memberships
• Map LDAP groups to Wazuh roles
• Control Dashboard permissions using existing directory groups

This allows security administrators to centrally manage both identities and access privileges without creating duplicate accounts inside Wazuh.

Authentication vs Authorization

Although these terms are often used together, they serve different purposes.

Authentication verifies a user’s identity by confirming that the supplied username and password are valid within the LDAP directory.

Authorization determines what an authenticated user is allowed to do after logging in.

Wazuh assigns permissions through roles that control access to dashboards, indices, alerts, APIs, management functions, and other resources.

For example:

• LDAP confirms that Alice is a valid employee.
• Wazuh determines whether Alice should have Administrator, Analyst, or Read-Only permissions based on her assigned roles or LDAP group membership.

Many organizations authenticate every employee against LDAP while restricting administrative access to only designated security groups.

Related Guide: Troubleshooting Wazuh RBAC

Supported LDAP Directory Services

Wazuh can authenticate against most standards-compliant LDAP directory servers supported by the underlying OpenSearch Security plugin.

The most common deployments include:

Microsoft Active Directory

Microsoft Active Directory is the most widely deployed enterprise LDAP implementation.

Organizations already using Windows domain authentication can integrate Wazuh directly with existing domain controllers, allowing employees to use their normal corporate credentials.

Benefits include:

• Existing user accounts
• Existing security groups
• Centralized password policies
• Multi-domain support
• Group-based role assignments

OpenLDAP

OpenLDAP is a popular open-source LDAP implementation commonly used in Linux environments.

It provides standards-compliant directory services that integrate well with Wazuh and is frequently deployed by organizations running Linux-based infrastructure.

Common OpenLDAP deployments include:

• Linux enterprise environments
• Academic institutions
• Research organizations
• Cloud-native infrastructure
• Self-hosted authentication systems

Other LDAP-Compatible Servers

Because LDAP is an open standard, Wazuh can also integrate with many other compatible directory services, provided they support the required authentication operations.

Examples include:

• 389 Directory Server
• Apache Directory Server
• IBM Security Directory Server
• Oracle Unified Directory
• Other standards-compliant enterprise LDAP servers

Before deployment, verify compatibility with your directory’s schema, authentication methods, TLS configuration, and group lookup capabilities.

Benefits of Using LDAP with Wazuh

Configuring LDAP authentication provides much more than centralized logins.

It improves operational efficiency, strengthens security, simplifies compliance, and reduces administrative effort across the entire security platform.

Centralized Identity Management

LDAP provides a single directory that manages user identities across multiple enterprise applications, including Wazuh.

Instead of creating separate accounts for every security platform, administrators maintain users in one centralized location.

This reduces account duplication while ensuring user information remains consistent across the organization.

Single Source of User Credentials

Employees continue using their existing corporate usernames and passwords when accessing Wazuh.

Advantages include:

• No additional passwords to remember
• Consistent password policies
• Central password expiration
• Central password resets
• Reduced password reuse

Organizations that already enforce strong password complexity, expiration schedules, and multifactor authentication through their directory services automatically extend those protections to Wazuh where supported by the authentication architecture.

Simplified User Onboarding and Offboarding

User lifecycle management becomes dramatically easier.

When a new security analyst joins the organization:

• Create the directory account.
• Add the user to the appropriate LDAP group.
• Wazuh access becomes available automatically.

When an employee leaves:

• Disable or remove the LDAP account.
• Wazuh access immediately stops without requiring separate administrative action.

This significantly reduces orphaned accounts and minimizes security risks associated with forgotten local users.

Role-Based Access Management

LDAP groups integrate naturally with Wazuh’s role-based access control (RBAC).

Instead of assigning permissions individually, administrators can map directory groups to Wazuh roles.

For example:

This approach scales much better in large environments where hundreds or thousands of users require controlled access.

Related Guide: Troubleshooting Wazuh RBAC

Improved Compliance and Auditing

Many security frameworks emphasize centralized identity management and controlled access to critical systems.

Using LDAP helps organizations support requirements found in frameworks such as:

• NIST Cybersecurity Framework
• CIS Controls
• ISO/IEC 27001
• PCI DSS

Centralized authentication also simplifies auditing because user identities remain consistent across enterprise applications instead of being duplicated in multiple local databases.

Expert guidance from the Center for Internet Security (CIS) recommends centralizing identity management and applying least-privilege access as foundational security practices.

Reduced Administrative Overhead

Managing local Wazuh accounts becomes increasingly time-consuming as deployments grow.

LDAP eliminates many repetitive administrative tasks, including:

• Creating local users
• Resetting passwords
• Removing former employees
• Updating user information
• Synchronizing account changes

Security administrators spend less time maintaining accounts and more time monitoring threats and improving detections.

Better Security Through Centralized Password Policies

One of LDAP’s greatest advantages is enforcing consistent security policies across the organization.

Instead of every application defining its own password requirements, organizations can apply centralized policies covering:

• Password complexity
• Password history
• Expiration intervals
• Account lockout thresholds
• Multifactor authentication integrations
• Account disablement

Research published in the NIST Digital Identity Guidelines (SP 800-63B) emphasizes centralized identity management, strong authentication controls, and secure credential lifecycle management as key components of modern enterprise authentication systems.

As a result, Wazuh benefits from the same enterprise-grade identity controls already protecting the rest of the organization’s infrastructure.

Related Guides:

• How to Set Up a Multi-Node Wazuh Cluster
• The Complete Wazuh Cluster Architecture Guide

How Wazuh LDAP Authentication Works

Understanding the authentication workflow makes it much easier to configure LDAP correctly and troubleshoot issues when users cannot log in.

Although the process involves several components, the overall flow is straightforward: Wazuh verifies user credentials against the LDAP directory, retrieves user and group information, maps permissions, and establishes an authenticated session.

Authentication Flow

When a user attempts to sign in to the Wazuh Dashboard, the authentication request is passed to the configured LDAP authentication backend.

Rather than checking credentials against a local database, Wazuh communicates with the LDAP server to determine whether the supplied username and password are valid.

A successful authentication typically involves the following stages:

1. The user enters their username and password.
2. Wazuh Dashboard forwards the authentication request to the LDAP backend.
3. LDAP verifies the supplied credentials.
4. Wazuh retrieves user attributes and group memberships.
5. LDAP groups are mapped to Wazuh roles.
6. Wazuh creates an authenticated session.
7. The user gains access according to their assigned permissions.

User Login Process

The login begins when a user accesses the Wazuh Dashboard through their web browser and submits their credentials.

Unlike local authentication, Wazuh does not compare the password against an internal user database.

Instead, it securely passes the credentials to the configured LDAP server for validation.

If the LDAP server confirms the identity, the login process continues. Otherwise, authentication fails and access is denied.

LDAP Bind Operations

LDAP authentication relies on one or more bind operations, which establish communication between Wazuh and the directory server.

Most deployments use two separate bind operations:

Service (Bind DN) Authentication

Wazuh first authenticates using a service account (Bind DN).

This account has permission to search the directory but typically cannot log in interactively.

The Bind DN is used to:

• Search for user objects
• Locate LDAP groups
• Retrieve directory attributes
• Perform user lookups

User Authentication

Once the user’s directory entry has been found, Wazuh attempts another bind using the user’s Distinguished Name (DN) and the password entered during login.

If this bind succeeds, LDAP confirms that the credentials are valid.

Using a dedicated service account follows the principle of least privilege by granting only the permissions required for directory searches rather than full administrative access.

User and Group Lookups

After successful authentication, Wazuh queries the LDAP directory to retrieve additional information about the authenticated user.

Commonly retrieved attributes include:

• Username
• Distinguished Name (DN)
• Email address
• Display name
• Organizational Unit (OU)
• Group memberships

Group membership is particularly important because it determines which permissions the user receives within Wazuh.

For example:

Role Mapping Within Wazuh Dashboard

Authentication only proves who the user is.

Authorization determines what they are allowed to do.

Once LDAP groups have been retrieved, Wazuh maps those groups to Dashboard roles configured within the OpenSearch Security plugin.

Examples include:

• Full administrator access
• Security analyst permissions
• Compliance dashboards
• Read-only reporting
• API access
• Index permissions

This approach allows administrators to manage access centrally through directory groups instead of editing Wazuh accounts individually.

Related Guide: Troubleshooting Wazuh RBAC

Session Establishment

After authentication and role assignment are complete, Wazuh creates an authenticated session for the user.

The session stores authentication information that allows users to continue interacting with the Dashboard without re-entering credentials for every request.

Session security typically includes:

• Session expiration
• Secure cookies
• TLS-encrypted communication
• Automatic logout after inactivity (depending on configuration)

Once established, the session is presented with subsequent requests until it expires or the user signs out.

Authorization After Successful Authentication

Every action performed within Wazuh is evaluated against the user’s assigned roles.

For example:

• A SOC analyst may investigate alerts but cannot modify cluster settings.
• A compliance officer may view dashboards without editing detection rules.
• A security administrator can manage users, configure integrations, and administer the platform.

Because permissions are driven by LDAP groups, changing a user’s directory membership automatically changes their Wazuh access after the next authentication cycle.

This centralized authorization model makes permission management significantly easier in enterprise environments with large security teams.

LDAP Authentication Architecture

LDAP authentication involves several Wazuh components working together to validate identities and authorize access.

Each component has a specific responsibility within the authentication process.

Authentication Components

User

The authentication process begins with a user attempting to access the Wazuh Dashboard using a web browser.

The user supplies:

• Username
• Password

These credentials are transmitted securely over HTTPS to the Wazuh Dashboard.

Web Browser

The browser acts as the client interface.

Its responsibilities include:

• Presenting the login page
• Sending credentials securely
• Storing the authenticated session cookie
• Displaying the Dashboard after login

Using HTTPS is strongly recommended to protect credentials during transmission.

Wazuh Dashboard

The Dashboard serves as the authentication entry point.

It:

• Accepts login requests
• Passes credentials to the LDAP authentication backend
• Retrieves LDAP groups
• Maps groups to Wazuh roles
• Creates authenticated user sessions

The Dashboard itself does not validate passwords directly, it relies on the configured LDAP backend.

LDAP Server

The LDAP server is responsible for identity verification.

It performs:

• User searches
• Password validation
• Group lookups
• Attribute retrieval

This may be an OpenLDAP server, Microsoft Active Directory, or another LDAP-compatible directory.

Active Directory (Optional)

Many enterprise deployments use Microsoft Active Directory as the LDAP directory.

In these environments, Active Directory provides:

• Centralized user accounts
• Organizational Units (OUs)
• Security groups
• Password policies
• Account lockout policies
• Existing enterprise identities

Because Wazuh supports LDAP, no special Active Directory integration is required beyond configuring the appropriate LDAP connection settings.

Wazuh Indexer

The Wazuh Indexer hosts the OpenSearch Security plugin, which performs LDAP authentication and authorization operations behind the scenes.

Responsibilities include:

• Authenticating users
• Retrieving LDAP attributes
• Applying security roles
• Enforcing index-level permissions
• Managing authenticated sessions

Wazuh Manager

The Wazuh Manager is not directly involved in authenticating users.

Instead, it focuses on:

• Log collection
• Rule evaluation
• Threat detection
• Agent communication
• Alert generation

After authentication succeeds, the Dashboard communicates with the Manager according to the authenticated user’s assigned permissions.

Simple Authentication Workflow

A typical authentication sequence looks like this:

1. User opens the Wazuh Dashboard in a web browser.
2. User enters LDAP username and password.
3. Wazuh Dashboard forwards the authentication request to the OpenSearch Security plugin.
4. The security plugin connects to the LDAP server using the configured Bind DN.
5. LDAP searches for the user’s directory entry.
6. LDAP performs a bind using the user’s credentials.
7. If authentication succeeds, LDAP returns the user’s group memberships.
8. Wazuh maps LDAP groups to Dashboard roles.
9. An authenticated session is created.
10. The user gains access to Wazuh according to their assigned permissions.

This architecture separates identity management from security monitoring, allowing organizations to maintain a single source of truth for user accounts while enforcing fine-grained access controls within Wazuh.

Prerequisites

Before configuring LDAP authentication, verify that your Wazuh deployment, directory services, and network infrastructure meet the necessary requirements.

Having this information prepared beforehand greatly reduces configuration errors and simplifies troubleshooting.

Supported Wazuh Versions

LDAP authentication is supported in modern Wazuh releases through the OpenSearch Security authentication framework used by the Wazuh Dashboard and Indexer.

For best compatibility, use:

• Wazuh 4.x or later
• Matching Dashboard, Manager, and Indexer versions
• Supported OpenSearch Security plugin versions

Running mixed component versions can lead to authentication or authorization issues.

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

Required Components

A functioning LDAP deployment requires several infrastructure components.

Wazuh Dashboard

The Dashboard provides the login interface and communicates with the LDAP authentication backend.

Ensure that:

• The Dashboard is operational.
• HTTPS is configured.
• Users can already access the login page.

Wazuh Indexer

The Wazuh Indexer hosts the security plugin responsible for LDAP authentication and role mapping.

Verify that:

• The Indexer cluster is healthy.
• Security features are enabled.
• Dashboard connectivity is working correctly.

Related Guide: The Ultimate Wazuh Indexer Guide

LDAP Server

You’ll need access to a functioning LDAP directory such as:

• Microsoft Active Directory
• OpenLDAP
• 389 Directory Server
• Apache Directory Server
• Another LDAP-compatible server

Confirm that the server is reachable and that the service account has permission to search users and groups.

Network Connectivity

Reliable network communication is essential.

Verify connectivity between the Wazuh Dashboard/Indexer and the LDAP server by confirming:

• DNS resolution works correctly.
• Firewall rules allow LDAP traffic.
• Required ports are open.
• TLS certificates are trusted when using LDAPS.

Common LDAP ports include:

Testing connectivity with tools such as ldapsearch before configuring Wazuh can help identify firewall, DNS, or certificate issues early.

Required Information

Gather the following configuration details before beginning the setup.

LDAP Hostname

The fully qualified domain name (FQDN) or IP address of the LDAP server.

Example:

ldap.example.com

Port

The LDAP service port.

Examples:

• 389 (LDAP)
• 636 (LDAPS)

Bind DN

The Distinguished Name (DN) of the service account used to search the directory.

Example:

CN=wazuh-service,CN=Users,DC=example,DC=com

Use a dedicated, least-privileged service account rather than a domain administrator account.

Bind Password

The password associated with the Bind DN account.

Store this credential securely and avoid embedding it in version-controlled configuration files.

Base DN

The starting point for LDAP searches.

Example:

DC=example,DC=com

A well-defined Base DN improves search performance by limiting the directory scope.

User Search Filter

Defines how Wazuh locates user accounts.

Example:

(sAMAccountName={0})

or

(uid={0})

The appropriate filter depends on your directory schema.

Group Search Filter

Specifies how LDAP groups are located for role mapping.

Example:

(member={0})

Proper group search filters are essential for assigning the correct Wazuh roles after authentication.

SSL/TLS Certificates (If Applicable)

When using LDAPS or StartTLS, ensure that:

• The LDAP server presents a valid certificate.
• The issuing CA is trusted by the Wazuh host.
• Certificates are current and not expired.
• Hostnames match the certificate’s Subject Alternative Name (SAN).

Using encrypted LDAP connections helps protect credentials in transit and aligns with security best practices recommended for enterprise identity services.

Preparing Your LDAP Server

Before modifying your Wazuh configuration, verify that your LDAP directory is properly configured and accessible.

Most LDAP authentication issues are caused by incorrect connection details, insufficient permissions, invalid search filters, or TLS configuration problems rather than problems within Wazuh itself.

Taking a few minutes to validate your LDAP environment beforehand can significantly reduce troubleshooting later.

Verify LDAP Connectivity

The first step is confirming that the Wazuh Dashboard/Indexer can communicate with your LDAP server.

Verify the following:

• DNS resolves the LDAP hostname correctly.
• The LDAP server is online.
• Required firewall ports are open.
• Routing between servers is working.
• TLS certificates are trusted (if using LDAPS).

For Linux systems, the ldapsearch utility is one of the easiest ways to verify connectivity.

Example:

ldapsearch -H ldap://ldap.example.com \
-D "cn=wazuh-service,dc=example,dc=com" \
-W \
-b "dc=example,dc=com"

A successful response indicates that:

• The LDAP server is reachable.
• The Bind DN is valid.
• The password is correct.
• The Base DN exists.
• Search operations are permitted.

If the query fails, resolve connectivity or directory issues before proceeding with the Wazuh configuration.

Create a Service Account

Wazuh should authenticate to the LDAP directory using a dedicated service account rather than a domain administrator account.

The service account is responsible for:

• Searching users
• Searching groups
• Reading required directory attributes

It generally does not require permission to:

• Modify users
• Reset passwords
• Create objects
• Delete directory entries
• Administer the domain

Using a dedicated read-only account follows the principle of least privilege and limits the impact of credential exposure.

A typical service account might resemble:

cn=wazuh-service,ou=Service Accounts,dc=example,dc=com

For Microsoft Active Directory:

CN=Wazuh Service,CN=Users,DC=corp,DC=example,DC=com

Determine the Base DN

The Base Distinguished Name (Base DN) defines where LDAP searches begin.

Choosing the appropriate Base DN improves search performance by limiting the search scope to relevant directory objects.

Examples include:

Entire directory

dc=example,dc=com

Specific organizational unit

ou=Employees,dc=example,dc=com

Active Directory domain

DC=corp,DC=example,DC=com

If users exist across multiple organizational units, selecting a higher-level Base DN may be necessary.

Identify User Search Attributes

LDAP directories use attributes to identify users. Your search filter must reference the correct attribute for your directory implementation.

Common user attributes include:

Examples:

OpenLDAP

(uid={0})

Common Name

(cn={0})

Active Directory

(sAMAccountName={0})

Email login

(mail={0})

Selecting the wrong attribute is one of the most common causes of failed LDAP logins.

Configure Security

LDAP authentication should always be secured using encrypted communication.

LDAPS

LDAPS encrypts the entire LDAP connection using SSL/TLS.

Default port:

636

Advantages include:

• Encrypted credentials
• Protected directory queries
• Prevention of credential interception
• Industry-standard deployment

Most production environments use LDAPS.

StartTLS

StartTLS begins with a standard LDAP connection before upgrading it to a TLS-encrypted session.

Default LDAP port:

389

Advantages include:

• Standards-based encryption
• Uses the standard LDAP port
• Supported by many enterprise LDAP servers

Whether to use LDAPS or StartTLS depends on your organization’s directory configuration.

Certificate Validation

When TLS is enabled, Wazuh should validate the LDAP server’s certificate.

Verify that:

• The certificate is trusted.
• The certificate has not expired.
• The hostname matches the certificate.
• The issuing Certificate Authority (CA) is trusted.
• Intermediate certificates are installed if required.

Disabling certificate verification may simplify testing but should never be used in production because it leaves the authentication process vulnerable to man-in-the-middle attacks.

Expert guidance from the OWASP Transport Layer Security Cheat Sheet recommends validating server certificates and avoiding insecure TLS configurations in production environments.

Configuring Wazuh LDAP Authentication

Once your LDAP server has been prepared, you can configure Wazuh to authenticate users against the directory.

This configuration is performed through the OpenSearch Security settings used by the Wazuh Dashboard and Indexer.

Note: Configuration file names and locations may vary slightly between Wazuh versions. Always verify the paths for your installed release.

Locate the Authentication Configuration

LDAP authentication is configured within the OpenSearch Security authentication backend configuration.

Depending on your deployment, the relevant files are typically located within the OpenSearch Security configuration directory.

Before making any changes:

• Back up the existing configuration.
• Verify cluster health.
• Document your current authentication settings.
• Plan a maintenance window for production systems if authentication services will be restarted.

Related Guide: How to Backup Wazuh Manager Configuration

Configure LDAP Connection Settings

The connection settings define how Wazuh communicates with the LDAP directory.

Host

Specifies the LDAP server hostname or IP address.

Example:

ldap.example.com

Use a fully qualified domain name whenever possible to simplify certificate validation.

Port

Specifies the LDAP service port.

Typical values include:

Protocol

Defines the protocol used to communicate with the directory.

Examples include:

• LDAP
• LDAPS
• LDAP with StartTLS

Encrypted protocols should always be preferred in production.

SSL

Controls whether encrypted communication is enabled.

Common options include:

• SSL enabled
• SSL disabled
• StartTLS enabled

Production deployments should always encrypt authentication traffic.

Bind DN

The Bind DN identifies the service account used to search the directory.

Example:

cn=wazuh-service,ou=Service Accounts,dc=example,dc=com

This account should have read-only access to users and groups.

Password

The password associated with the Bind DN.

Protect this credential by:

• Restricting file permissions.
• Avoiding version control.
• Using secret management solutions where available.
• Rotating passwords periodically.

Base DN

Defines the directory subtree where searches begin.

Example:

dc=example,dc=com

Using a narrower Base DN improves search efficiency.

Configure User Search

The user search determines how Wazuh locates the authenticating user.

Typical filters include:

OpenLDAP:

(uid={0})

Active Directory:

(sAMAccountName={0})

Email authentication:

(mail={0})

Ensure the selected attribute matches the usernames users enter on the Wazuh login page.

Configure Group Search

After successful authentication, Wazuh retrieves the user’s LDAP groups.

Typical group search filters include:

(member={0})

or

(uniqueMember={0})

Depending on your directory schema, additional filters or nested group support may be required.

Configure Role Mapping

LDAP groups are mapped to Wazuh security roles.

For example:

Managing permissions through directory groups allows administrators to control access centrally without creating local Wazuh users.

Related Guide: Troubleshooting Wazuh RBAC

Save the Configuration

After completing the LDAP configuration:

1. Save the updated configuration files.
2. Validate the syntax.
3. Apply the security configuration if required by your deployment.
4. Restart affected services if necessary.
5. Test authentication using a non-administrative account before rolling the changes into production.

Always verify both successful logins and expected authorization levels to ensure role mappings are functioning correctly.

Related Guide: How to Use Wazuh Logtest

Example LDAP Configuration

The following examples illustrate common LDAP authentication configurations.

They are intended as reference templates and should be adapted to match your environment, directory schema, and Wazuh version.

OpenLDAP Example

The example below demonstrates a typical OpenLDAP configuration using LDAPS, a dedicated service account, and user authentication based on the uid attribute.

# LDAP authentication backend
authc:
  ldap_auth_domain:
    description: "OpenLDAP authentication"

    http_enabled: true
    transport_enabled: true
    order: 1

    http_authenticator:
      type: basic
      challenge: false

    authentication_backend:
      type: ldap
      config:

        # LDAP server hostname
        hosts:
          - ldap.example.com:636

        # Use SSL/TLS (LDAPS)
        enable_ssl: true

        # Disable StartTLS because LDAPS is used
        enable_start_tls: false

        # Verify server certificate
        verify_hostnames: true

        # Service account used for searches
        bind_dn: "cn=wazuh-service,ou=Service Accounts,dc=example,dc=com"

        # Service account password
        password: "StrongPassword"

        # Search base
        userbase: "dc=example,dc=com"

        # Locate users by uid
        usersearch: "(uid={0})"

        # Retrieve LDAP groups
        rolebase: "ou=Groups,dc=example,dc=com"

        # Group membership lookup
        rolesearch: "(member={0})"

        # Group attribute
        rolename: cn

Configuration Highlights

• Uses encrypted LDAPS (port 636)
• Authenticates users with the uid attribute
• Searches under a dedicated user base
• Retrieves group memberships for role mapping
• Validates server certificates for secure communication

Microsoft Active Directory Example

Microsoft Active Directory uses a different schema and typically authenticates users with the sAMAccountName or userPrincipalName attribute instead of uid.

Common Active Directory changes include:

Example user search:

(sAMAccountName={0})

Some organizations instead allow users to log in with their User Principal Name (UPN):

(userPrincipalName={0})

A typical Bind DN in Active Directory looks like:

CN=Wazuh Service,CN=Users,DC=corp,DC=example,DC=com

Role mapping also differs slightly because Active Directory commonly uses Security Groups, which can include nested memberships depending on the organization’s design.

If nested groups are used, additional configuration may be required to resolve inherited memberships correctly.

Regardless of whether you use OpenLDAP or Microsoft Active Directory, the overall workflow remains the same:

1. Authenticate the user against the LDAP directory.
2. Retrieve group memberships.
3. Map groups to Wazuh roles.
4. Establish an authenticated session.
5. Authorize access based on the assigned roles.

This consistent authentication model makes it straightforward to integrate Wazuh into existing enterprise identity infrastructures while maintaining centralized control over user access.

Configuring Secure LDAP (LDAPS)

Although LDAP can operate over an unencrypted connection, production environments should always use LDAP over SSL/TLS (LDAPS) or StartTLS to protect authentication traffic.

Usernames, passwords, directory queries, and group information are sensitive data that should never be transmitted in plaintext.

Implementing LDAPS helps prevent credential theft, man-in-the-middle (MITM) attacks, and unauthorized interception of authentication requests.

Why LDAPS Is Recommended

LDAPS encrypts all communication between the Wazuh Indexer (OpenSearch Security plugin) and the LDAP server using TLS.

Compared to standard LDAP, LDAPS provides:

• Encrypted user credentials
• Confidential directory queries
• Protection against network eavesdropping
• Server identity verification through certificates
• Compliance with enterprise security requirements

Most enterprise environments expose LDAPS on:

If your directory infrastructure supports StartTLS, it provides similar protection while using the standard LDAP port (389).

The OWASP Transport Layer Security Cheat Sheet recommends using modern TLS configurations, validating certificates, and avoiding insecure protocols to protect authentication traffic.

Importing Certificates

For Wazuh to trust the LDAP server, the issuing Certificate Authority (CA) certificate must be available on the host running the Wazuh Indexer.

Typical steps include:

1. Export the LDAP server’s CA certificate.
2. Copy the certificate to the Wazuh server.
3. Add the certificate to the operating system’s trusted certificate store or configure OpenSearch Security to trust the CA explicitly.
4. Restart affected services if required.

Never import self-signed certificates into production environments unless they are intentionally managed by your organization’s internal PKI.

Certificate Trust

TLS only provides meaningful protection if the LDAP server’s certificate can be trusted.

Verify that:

• The certificate is issued by a trusted CA.
• The certificate chain is complete.
• Intermediate certificates are installed.
• The certificate has not expired.
• The certificate has not been revoked.

Using trusted certificates prevents attackers from impersonating the LDAP server during authentication.

TLS Validation

During connection establishment, Wazuh validates the LDAP server’s certificate before sending authentication requests.

Validation typically includes:

• Certificate chain verification
• Hostname validation
• Signature verification
• Expiration checks
• Trusted CA verification

Disabling hostname verification or certificate validation may simplify testing but significantly weakens security and should be avoided in production.

Common Certificate Issues

LDAP authentication failures are frequently caused by certificate problems rather than configuration errors.

Common issues include:

Testing the LDAP TLS connection before configuring Wazuh helps identify certificate problems early.

Example using OpenSSL:

openssl s_client -connect ldap.example.com:636

Review the certificate chain and verify that the TLS handshake completes successfully before enabling LDAPS within Wazuh.

Mapping LDAP Groups to Wazuh Roles

After LDAP successfully authenticates a user, Wazuh determines what that user can access by mapping LDAP groups to Wazuh security roles.

This approach eliminates the need to manage permissions for individual users and allows administrators to control access entirely through directory group membership.

Centralized role mapping is especially valuable in large organizations where user responsibilities change frequently.

Example Role Mapping

The following examples illustrate common enterprise mappings.

SOC Analysts

SOC analysts typically require access to:

• Security alerts
• Event searches
• Dashboards
• Threat hunting
• Incident investigation

They generally should not have permission to:

• Modify authentication settings
• Change cluster configuration
• Delete indices
• Create administrative users

Security Engineers

Security engineers usually require broader permissions because they manage detection content.

Typical responsibilities include:

• Creating custom rules
• Building decoders
• Configuring integrations
• Managing active response
• Testing detection logic

Related Guides:

• The Complete Custom Wazuh Rules and Decoders Guide
• Wazuh Decoder Guide

Administrators

Administrators require unrestricted access to manage the platform.

Typical capabilities include:

• User management
• Authentication configuration
• Cluster administration
• Index management
• Security configuration
• Dashboard administration
• API management

Because administrator accounts have extensive privileges, membership should be limited to a small number of trusted personnel.

Read-Only Users

Read-only roles are appropriate for users who need visibility but should not modify the environment.

Examples include:

• Executive dashboards
• Security reporting
• Operational monitoring
• Business stakeholders

Restricting these accounts prevents accidental configuration changes while still providing access to important security data.

Auditors

Compliance auditors often need historical visibility without administrative capabilities.

Typical permissions include:

• Compliance dashboards
• Historical alerts
• Reports
• Security evidence
• Audit logs

Read-only access helps preserve the integrity of collected security data during audits.

Apply the Principle of Least Privilege

When designing LDAP role mappings, follow the principle of least privilege by granting users only the permissions required to perform their jobs.

Benefits include:

• Reduced attack surface
• Lower risk of accidental changes
• Better separation of duties
• Simplified compliance
• Easier auditing
• Stronger insider threat protection

The Center for Internet Security (CIS) Controls identifies least-privilege access management as a foundational cybersecurity practice for enterprise environments.

Related Guide: Troubleshooting Wazuh RBAC

Testing LDAP Authentication

After configuring LDAP authentication, thoroughly test the integration before allowing production users to log in.

Verifying each stage of the authentication process independently makes it much easier to identify configuration problems.

Verify LDAP Connectivity

Begin by confirming that the LDAP server is reachable.

Common checks include:

• DNS resolution
• Firewall connectivity
• LDAP port availability
• TLS negotiation

Example:

nc -zv ldap.example.com 636

or

telnet ldap.example.com 636

Successful connections indicate that the LDAP service is reachable.

Verify Successful Bind Operations

Test whether the configured Bind DN can authenticate successfully.

Example:

ldapsearch \
-H ldaps://ldap.example.com \
-D "cn=wazuh-service,dc=example,dc=com" \
-W \
-b "dc=example,dc=com"

A successful bind confirms:

• Correct Bind DN
• Correct password
• Proper TLS configuration
• Valid Base DN

Verify User Searches

Ensure that LDAP can locate users using the configured search filter.

Example:

ldapsearch \
-b "dc=example,dc=com" \
"(uid=jdoe)"

or for Active Directory:

ldapsearch \
-b "DC=corp,DC=example,DC=com" \
"(sAMAccountName=jdoe)"

If no results are returned, review the Base DN and search filter.

Verify Group Retrieval

Confirm that LDAP returns the user’s group memberships.

Example:

ldapsearch \
-b "dc=example,dc=com" \
"(member=uid=jdoe,ou=People,dc=example,dc=com)"

Verify that:

• Expected groups are returned.
• Group names match configured Wazuh role mappings.
• Nested groups are resolved if required.

Verify Successful Login

After confirming directory connectivity, log in to the Wazuh Dashboard using an LDAP account.

Successful authentication should:

• Display the Dashboard.
• Create an authenticated session.
• Show the expected user identity.
• Apply the correct permissions.

If login fails, review authentication logs before modifying the configuration.

Verify Dashboard Permissions

After logging in, confirm that role mapping is functioning correctly.

Verify that users can only perform actions appropriate for their assigned roles.

Examples include:

• Analysts can investigate alerts.
• Read-only users cannot modify rules.
• Administrators have full management access.
• Auditors can access reporting dashboards.

Testing multiple user roles helps ensure LDAP group mappings are working as intended.

Troubleshooting Common Wazuh LDAP Problems

Even well-designed LDAP integrations can encounter authentication issues.

Fortunately, most problems stem from a small number of configuration errors that can be resolved systematically.

Invalid Credentials

Symptoms

• Login rejected
• Authentication failed
• Invalid username or password

Possible causes

• Incorrect user password
• Incorrect Bind DN password
• Locked user account
• Expired password

Resolution

• Verify credentials directly against the LDAP directory.
• Confirm the Bind DN password.
• Check for account lockouts or password expiration policies.

Unable to Bind to LDAP Server

Symptoms

• Bind operation fails
• Authentication backend reports bind errors

Possible causes

• Incorrect Bind DN
• Invalid password
• Insufficient permissions
• Incorrect Base DN

Resolution

• Test the Bind DN using ldapsearch.
• Verify service account permissions.
• Confirm the Bind DN syntax matches your directory.

Connection Refused

Symptoms

• Unable to connect to LDAP server
• Timeout or connection refused errors

Possible causes

• Firewall blocking LDAP traffic
• Incorrect hostname
• Incorrect port
• LDAP service not running

Resolution

• Verify DNS resolution.
• Test port connectivity with nc or telnet.
• Confirm the LDAP service is listening on the expected port.

TLS Handshake Failures

Symptoms

• SSL negotiation errors
• TLS handshake failures
• Secure connection cannot be established

Possible causes

• Unsupported TLS versions
• Invalid certificates
• Incorrect cipher suites
• Certificate chain problems

Resolution

• Test the connection using:

openssl s_client -connect ldap.example.com:636

• Verify TLS protocol compatibility.
• Confirm the complete certificate chain is installed.

Certificate Validation Errors

Symptoms

• Certificate verification failed
• Unknown CA
• Hostname mismatch

Possible causes

• Expired certificate
• Self-signed certificate
• Missing CA certificate
• Incorrect hostname

Resolution

• Install the appropriate CA certificate.
• Verify hostname matching.
• Replace expired certificates.
• Avoid disabling certificate verification in production.

User Not Found

Symptoms

• Valid users cannot authenticate
• LDAP searches return no results

Possible causes

• Incorrect search filter
• Wrong Base DN
• Incorrect user attribute

Resolution

• Verify search filters.
• Confirm whether users authenticate with uid, cn, mail, sAMAccountName, or userPrincipalName.
• Test searches manually using ldapsearch.

Incorrect Base DN

Symptoms

• Authentication succeeds for some users but not others
• Searches return incomplete results

Possible causes

• Search scope too narrow
• Wrong organizational unit
• Incorrect domain components

Resolution

• Expand the Base DN temporarily.
• Confirm the directory structure.
• Verify user locations within the LDAP hierarchy.

Group Mapping Failures

Symptoms

• Login succeeds
• Users receive incorrect permissions
• Users receive no permissions

Possible causes

• Incorrect group search filter
• Incorrect group attribute
• Missing nested group support
• Typographical errors in role mappings

Resolution

• Verify LDAP group membership.
• Confirm Wazuh role mappings.
• Test group searches independently.

Login Loops

Symptoms

• Users authenticate successfully but are redirected back to the login page repeatedly

Possible causes

• Session cookie issues
• Authentication backend configuration errors
• Reverse proxy misconfiguration
• Browser cookie restrictions

Resolution

• Clear browser cookies.
• Review proxy configuration.
• Check Dashboard logs.
• Verify session configuration.

Related Guide: How to Stop the Infinite Wazuh Login Loop After a Version Upgrade

Permission Denied After Login

Symptoms

• User logs in successfully.
• Access to dashboards or APIs is denied.

Possible causes

• Missing role mapping
• Incorrect LDAP group membership
• RBAC configuration errors

Resolution

• Verify LDAP group assignments.
• Confirm role mappings.
• Test with a known administrative account.

Dashboard Authentication Failures

Symptoms

• Dashboard rejects all LDAP users
• Authentication backend errors appear in logs

Possible causes

• Invalid LDAP configuration
• OpenSearch Security configuration errors
• Service restart required

Resolution

• Review Dashboard and Indexer logs.
• Validate configuration syntax.
• Reload or restart affected services after making changes.

Related Guide: Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Time Synchronization Issues

Symptoms

• Authentication succeeds intermittently
• TLS validation errors
• Certificate validity problems

Possible causes

• Unsynchronized system clocks
• Incorrect NTP configuration
• Significant clock drift between servers

Resolution

• Synchronize all Wazuh and LDAP servers using a reliable NTP source.
• Verify system time, time zones, and certificate validity periods.
• Continuously monitor clock synchronization across the environment, especially in clustered deployments, to prevent intermittent authentication and TLS issues.

LDAP Security Best Practices

A properly configured LDAP integration improves Wazuh security by centralizing identity management, but the directory connection itself must be protected.

Since LDAP authentication handles sensitive credentials and determines who can access security monitoring systems, organizations should follow strict security practices when deploying it in production environments.

Always Use LDAPS

Production Wazuh deployments should use LDAPS or LDAP with StartTLS to encrypt communication between Wazuh and the directory server.

Unencrypted LDAP connections can expose:

• Usernames
• Passwords
• Directory queries
• Group membership information

Using TLS encryption protects authentication traffic from interception and helps satisfy security requirements for protecting sensitive identity data.

Recommended practices:

• Use certificates issued by a trusted internal or public CA.
• Enable certificate validation.
• Avoid disabling hostname verification.
• Monitor certificate expiration dates.

Related Guide: How to Fix Wazuh Certificate Errors

Disable Anonymous Binds

Anonymous LDAP binds allow clients to query directory information without authentication.

Although some LDAP deployments enable anonymous access by default, it should be disabled in enterprise environments.

Benefits of disabling anonymous binds include:

• Preventing unauthorized directory discovery
• Reducing information leakage
• Limiting attacker reconnaissance
• Improving compliance posture

The Wazuh LDAP service account should always authenticate explicitly using a dedicated Bind DN.

Use Dedicated Service Accounts

Wazuh should connect to LDAP using a dedicated service account rather than a personal administrator account.

A dedicated account provides:

• Clear ownership
• Easier auditing
• Controlled permissions
• Simplified credential rotation
• Reduced security impact if compromised

Example:

CN=wazuh-ldap-service,OU=Service Accounts,DC=example,DC=com

The account should only have permissions required to:

• Search users
• Search groups
• Read required directory attributes

It should not have permissions to modify directory objects.

Rotate Service Account Passwords

Service account credentials should be rotated regularly according to organizational security policies.

Recommended practices:

• Establish a password rotation schedule.
• Use strong randomly generated passwords.
• Store credentials securely.
• Update Wazuh configuration after rotation.
• Monitor failed authentication attempts after changes.

For large environments, consider integrating service account credentials with enterprise secrets management solutions.

Apply Least Privilege

LDAP integration should follow the principle of least privilege.

Users should receive only the Wazuh permissions necessary for their responsibilities.

Examples:

Avoid assigning Administrator permissions broadly because compromised accounts could gain full control over security monitoring infrastructure.

Restrict LDAP Network Access

Limit which systems can communicate with your LDAP infrastructure.

Recommended controls include:

• Firewall rules restricting LDAP access.
• Allowing connections only from Wazuh servers.
• Blocking unnecessary inbound LDAP traffic.
• Monitoring LDAP connection attempts.

Example:

Allow:
Wazuh Indexer → LDAP Server:636

Deny:
All other external systems → LDAP Server:636

Network segmentation reduces the risk of unauthorized LDAP queries.

Enable Logging and Auditing

LDAP authentication events should be monitored and retained for security investigations.

Important events include:

• Successful logins
• Failed authentication attempts
• Disabled accounts attempting access
• Privilege changes
• Group membership changes

Centralized logging allows security teams to correlate identity activity with Wazuh alerts and incidents.

Related Guide: How to Monitor Windows Event Logs Using Wazuh

Monitor Authentication Failures

Repeated LDAP authentication failures may indicate:

• Incorrect configurations
• Expired passwords
• Account lockouts
• Brute-force attacks
• Compromised credentials

Security teams should monitor:

• Failed Wazuh Dashboard logins
• LDAP bind failures
• Suspicious authentication patterns
• Excessive login attempts

Related Guide: Wazuh Brute Force Detection Guide

Use Strong Password Policies

LDAP inherits the password security controls configured in the directory service.

Organizations should enforce:

• Strong password complexity requirements
• Password expiration policies
• Account lockout thresholds
• Removal of inactive accounts
• Multifactor authentication where possible

Microsoft Active Directory environments can enforce these controls through domain policies.

Keep Wazuh Updated

Regular Wazuh updates ensure that authentication components receive:

• Security patches
• Bug fixes
• OpenSearch security improvements
• Compatibility updates

Before upgrading production environments:

• Review release notes.
• Test LDAP authentication in a staging environment.
• Verify role mappings after upgrades.

Related Guide: How to Upgrade a Wazuh Agent

Performance Considerations

LDAP authentication is usually lightweight, but large enterprise directories require careful planning.

Poorly optimized LDAP queries can increase login times and place unnecessary load on directory servers.

Efficient Search Filters

Search filters determine how quickly LDAP locates users and groups.

Avoid broad searches such as:

(objectClass=*)

because they may scan thousands of directory objects.

Instead, use specific filters:

OpenLDAP:

(uid={0})

Active Directory:

(sAMAccountName={0})

Efficient filters reduce authentication latency and directory workload.

Minimize Search Scope

The Base DN determines where LDAP searches begin.

A broad search:

DC=example,DC=com

may scan the entire directory.

A narrower search:

OU=Employees,DC=example,DC=com

limits the search area.

Benefits include:

• Faster authentication
• Lower LDAP server load
• Reduced query complexity

Connection Pooling

LDAP connections require resources on both the client and directory server.

Connection pooling allows Wazuh components to reuse existing LDAP connections instead of creating a new connection for every authentication attempt.

Benefits:

• Lower authentication latency
• Reduced LDAP server load
• Better performance during login spikes

This becomes especially important in environments with many analysts accessing the Dashboard simultaneously.

LDAP Indexing

LDAP servers should index frequently searched attributes.

Common indexed attributes include:

• uid
• cn
• mail
• sAMAccountName
• member

Proper indexing improves:

• User lookup speed
• Group searches
• Authentication response times

For large directories, LDAP indexing is essential for maintaining performance.

Large Directory Optimization

Organizations with thousands or millions of directory objects should optimize LDAP queries carefully.

Recommended practices:

• Avoid unnecessary attributes.
• Use specific Base DNs.
• Limit group searches.
• Avoid excessive nested group lookups.
• Monitor LDAP query performance.

Large environments should test authentication performance before enabling LDAP access for all users.

High Availability LDAP Servers

LDAP authentication becomes a critical dependency once Wazuh relies on centralized identity services.

Organizations should consider:

• Multiple LDAP servers
• Active Directory domain controllers
• Load balancing
• Geographic redundancy
• DNS-based failover

High availability ensures users can still access Wazuh during directory maintenance or server failures.

Authentication Caching Considerations

Authentication caching can improve performance by reducing repeated LDAP queries, but it must be balanced against security requirements.

Advantages:

• Faster authentication
• Reduced LDAP traffic
• Better user experience

Potential risks:

• Delayed permission changes
• Delayed account removal
• Temporary access after group membership changes

Organizations should determine appropriate cache behavior based on security requirements.

Real-World Example

Enterprise SOC Centralizes Wazuh Authentication Using Active Directory

A large enterprise operates a security operations center responsible for monitoring thousands of employees across multiple departments, including finance, engineering, operations, and executive teams.

The organization uses Microsoft Active Directory as its centralized identity provider but previously maintained separate local accounts inside Wazuh.

This created administrative challenges:

• Security analysts required manual account creation.
• Departing employees required separate account removal.
• Access permissions were difficult to audit.
• User roles were inconsistent across the security team.

To solve these challenges, the organization implements Wazuh LDAP authentication.

Implementing Secure LDAP Integration

Administrators begin by configuring secure LDAPS communication between the Wazuh Indexer and Active Directory domain controllers.

They:

• Enable LDAPS using trusted certificates.
• Import the internal CA certificate into the Wazuh environment.
• Verify TLS certificate validation.
• Confirm network connectivity over port 636.

This ensures authentication credentials are protected during transmission.

Creating a Dedicated Bind Account

The security team creates a dedicated Active Directory service account:

CN=wazuh-ldap-service,CN=Users,DC=company,DC=com

The account receives only the permissions required to:

• Search users
• Retrieve group memberships
• Read directory attributes

It does not have administrative privileges.

Mapping Active Directory Groups to Wazuh Roles

The organization creates security groups based on job responsibilities:

This allows access permissions to follow existing organizational structures.

When an employee changes departments, administrators only update their Active Directory group membership.

Testing the Integration

Before production rollout, administrators validate:

• LDAP connectivity
• Bind account authentication
• User searches
• Group retrieval
• Role assignments
• Dashboard permissions

They create test accounts representing each user type:

• Analyst
• Engineer
• Administrator
• Auditor
• Executive

Each account is verified to ensure it receives the correct permissions.

Operational Benefits After Deployment

After implementation:

• New employees automatically receive Wazuh access based on Active Directory membership.
• Terminated employees immediately lose access when their directory account is disabled.
• Security permissions remain consistent across departments.
• Auditors can verify access controls more easily.
• Administrators spend less time managing local accounts.

The organization achieves centralized identity management, improved security, reduced administrative overhead, and streamlined compliance auditing across its security operations.

Frequently Asked Questions

Question: Does Wazuh Support Active Directory?

Yes. Wazuh supports authentication against Microsoft Active Directory through LDAP integration.

Organizations can authenticate users using Active Directory attributes such as:

• sAMAccountName
• userPrincipalName

Active Directory groups can also be mapped to Wazuh roles for authorization.

Question: Can Wazuh Authenticate Against OpenLDAP?

Yes. Wazuh can authenticate against OpenLDAP and other LDAP-compatible directory services.

OpenLDAP deployments commonly use attributes such as:

• uid
• cn
• mail

The authentication workflow is the same:

1. Search for the user.
2. Validate credentials.
3. Retrieve groups.
4. Assign Wazuh roles.

Question: What Is the Difference Between LDAP and LDAPS?

LDAP is the standard directory communication protocol.

LDAPS is LDAP encrypted with SSL/TLS.

The main difference:

Production Wazuh deployments should use LDAPS whenever possible.

Question: Can Multiple LDAP Servers Be Configured?

Yes. Enterprise environments commonly configure multiple LDAP servers for availability and redundancy.

Examples:

• Multiple Active Directory domain controllers
• LDAP replicas
• Geographic directory servers

Multiple servers reduce downtime risk during maintenance or failures.

Question: How Do I Map LDAP Groups to Wazuh Roles?

LDAP groups are mapped through the Wazuh/OpenSearch Security role mapping configuration.

The process involves:

1. Creating LDAP security groups.
2. Retrieving group membership during authentication.
3. Assigning LDAP groups to Wazuh roles.
4. Testing permissions with user accounts.

Question: Does LDAP Replace Local Wazuh Users?

LDAP authentication can replace local Wazuh users for most enterprise deployments, but local accounts may still be maintained as emergency administrative accounts.

A local break-glass account can provide access if LDAP becomes unavailable.

Question: Why Are LDAP Users Unable to Log In?

Common causes include:

• Incorrect credentials
• Wrong Bind DN
• Invalid Base DN
• Incorrect search filter
• TLS certificate problems
• Network connectivity issues
• Missing role mappings

Review Wazuh Dashboard and Indexer logs to identify the exact failure.

Question: How Do I Troubleshoot LDAP Authentication Failures?

Start by testing each layer:

1. Verify network connectivity.
2. Test LDAP bind credentials.
3. Confirm user searches.
4. Verify group membership.
5. Check role mappings.
6. Review Wazuh logs.

Using ldapsearch is one of the most effective troubleshooting methods.

Question: Can LDAP Authentication Be Combined With SAML or OpenID Connect?

Yes. Modern identity architectures may combine LDAP-backed directories with federated authentication technologies such as SAML or OpenID Connect.

However, the exact implementation depends on the identity provider and Wazuh deployment architecture.

Question: Is LDAPS Required for Production Environments?

While technically not mandatory, LDAPS is strongly recommended for production environments.

Encrypting LDAP traffic protects:

• User credentials
• Directory information
• Group membership data

Production deployments should avoid transmitting authentication data over unencrypted LDAP connections.

Conclusion

Configuring Wazuh LDAP authentication allows organizations to integrate their security monitoring platform with existing identity infrastructure.

Instead of managing separate Wazuh accounts, teams can use centralized directory services such as Microsoft Active Directory or OpenLDAP to control authentication and authorization.

The integration process involves:

• Preparing the LDAP environment.
• Creating a dedicated service account.
• Configuring secure LDAP connectivity.
• Mapping directory groups to Wazuh roles.
• Testing authentication and permissions.
• Monitoring the environment after deployment.

The biggest advantages of LDAP integration include centralized identity management, simplified onboarding and offboarding, consistent security policies, improved auditing, and reduced administrative overhead.

For production deployments, always prioritize secure configurations:

• Use LDAPS encryption.
• Validate TLS certificates.
• Apply least-privilege permissions.
• Restrict LDAP network access.
• Monitor authentication activity.
• Regularly test authentication workflows.

With proper configuration and ongoing maintenance, Wazuh LDAP authentication provides a scalable and secure foundation for enterprise security operations.