Organizations increasingly rely on centralized identity providers to secure access to business-critical applications. Security Information and Event Management (SIEM) platforms are no exception. Rather than maintaining separate usernames and passwords for security analysts, administrators, and incident responders, organizations can integrate their SIEM with an enterprise identity platform to simplify authentication while strengthening security. Integrating Wazuh with Azure AD allows organizations to replace locally managed Wazuh accounts with centralized authentication

Wazuh is an open-source SIEM and Extended Detection and Response (XDR) platform that provides log collection, security monitoring, file integrity monitoring (FIM), vulnerability detection, compliance reporting, malware detection, and incident response across cloud, on-premises, containers, and endpoint environments.

By correlating security events from multiple data sources, Wazuh helps organizations detect threats, investigate incidents, and maintain compliance with industry standards.

Azure AD, now officially known as Microsoft Entra ID, is Microsoft’s cloud-based identity and access management (IAM) platform.

It enables organizations to manage users, groups, applications, devices, and authentication policies from a centralized location while supporting modern authentication standards such as OpenID Connect (OIDC), OAuth 2.0, and SAML.

Security teams can sign in using their existing Microsoft Entra ID credentials while administrators retain centralized control over access policies, password requirements, Multi-Factor Authentication (MFA), Conditional Access, and user lifecycle management.

Benefits of Wazuh Azure AD Integration

This integration delivers several operational and security benefits, including:

Centralized user authentication
Single Sign-On (SSO) for Wazuh Dashboard
Strong Multi-Factor Authentication (MFA)
Reduced administrative overhead
Simplified onboarding and offboarding
Improved audit logging
Better compliance with security frameworks such as ISO 27001, NIST, CIS Controls, HIPAA, and PCI DSS

Microsoft recommends using modern authentication protocols such as OpenID Connect instead of legacy authentication mechanisms because they provide stronger security, better token handling, and support for Conditional Access policies.

Industry guidance from the Cybersecurity and Infrastructure Security Agency (CISA) also emphasizes centralized identity management, MFA, and strong identity governance as foundational Zero Trust security principles.

Throughout this guide, you’ll learn how to configure Azure AD authentication for Wazuh using OpenID Connect, register the required enterprise application, configure authentication settings within Wazuh Dashboard, validate user access, map identities to Wazuh RBAC roles, troubleshoot common issues, and implement security best practices for production deployments.

Related Guides

Understanding the Wazuh and Azure AD Integration

What Is Azure AD (Microsoft Entra ID)?

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft’s cloud-based Identity and Access Management (IAM) platform.

It serves as the central identity provider for Microsoft 365, Azure services, SaaS applications, custom web applications, and thousands of third-party enterprise services.

Instead of each application maintaining its own authentication database, users authenticate once against Microsoft Entra ID, which securely issues identity tokens to trusted applications.

This centralized model reduces password sprawl, improves security, and simplifies identity administration across the enterprise.

Core capabilities include:

Identity and Access Management

Microsoft Entra ID stores and manages organizational identities, including:

Users
Security groups
Administrative roles
Devices
Service principals
Managed identities
Guest accounts (B2B collaboration)

Administrators can control who has access to applications, enforce password policies, manage privileged accounts, and automate user lifecycle management from a single platform.

Authentication Services

Microsoft Entra ID supports several modern authentication protocols, including:

OpenID Connect (OIDC)
OAuth 2.0
SAML 2.0
WS-Federation (legacy)

For Wazuh, OpenID Connect is the preferred authentication method because it provides secure identity verification, standardized token exchange, and excellent compatibility with modern web applications.

Enterprise Applications

Enterprise Applications allow administrators to integrate cloud services with Microsoft Entra ID for authentication and authorization.

These applications support:

Single Sign-On
User assignment
Group-based access
Conditional Access policies
Audit logging
Access reviews

Wazuh can be configured as an enterprise application so authentication requests are delegated to Microsoft Entra ID instead of local credentials.

Conditional Access

Conditional Access evaluates multiple signals before granting authentication.

Policies may consider:

User identity
Group membership
Device compliance
Geographic location
IP address
Risk level
Application sensitivity

For example, administrators may require MFA only when users access Wazuh from unmanaged devices or unfamiliar locations.

Multi-Factor Authentication

Microsoft Entra ID supports multiple MFA methods, including:

Microsoft Authenticator
FIDO2 security keys
Passkeys
Windows Hello for Business
SMS verification
Voice calls (legacy environments)

By enforcing MFA, organizations significantly reduce the risk of compromised credentials leading to unauthorized access.

Microsoft reports that enabling MFA blocks the overwhelming majority of password-based account compromise attempts.

Identity Governance

Identity Governance extends beyond authentication by providing features such as:

Access reviews
Privileged Identity Management (PIM)
Entitlement management
Automated provisioning
User lifecycle workflows
Just-In-Time (JIT) administrative access

These capabilities help organizations satisfy compliance requirements while reducing excessive user permissions.

Why Integrate Wazuh with Azure AD?

Managing separate user accounts inside Wazuh quickly becomes difficult as organizations grow.

Integrating Microsoft Entra ID centralizes authentication while allowing security teams to leverage existing enterprise identity controls.

Centralized Identity Management

All user accounts remain managed within Microsoft Entra ID.

Administrators can:

Disable users immediately
Reset passwords centrally
Apply security policies
Manage user groups
Audit account activity

This eliminates duplicated identity management across multiple systems.

Single Sign-On (SSO)

Single Sign-On allows users to authenticate once with Microsoft Entra ID before accessing Wazuh Dashboard.

Benefits include:

Fewer passwords
Faster login experience
Reduced password reset requests
Improved productivity
Stronger security

Multi-Factor Authentication (MFA)

Rather than implementing MFA separately within Wazuh, organizations inherit Microsoft Entra ID’s authentication controls.

Administrators can require:

MFA for privileged users
MFA for remote access
Risk-based MFA
Passwordless authentication
Device compliance verification

Reduced Password Management

Since Wazuh no longer stores local user passwords, administrators spend less time:

Resetting passwords
Managing expired credentials
Removing inactive accounts
Synchronizing user databases

Improved Auditing

Every authentication event is logged within Microsoft Entra ID.

Security teams can review:

Successful logins
Failed login attempts
MFA challenges
Conditional Access evaluations
Risk detections
Administrative actions

These logs improve forensic investigations and compliance reporting.

Simplified Onboarding and Offboarding

When new analysts join the SOC:

Create the Microsoft Entra ID account.
Assign the Wazuh application.
Add the user to the correct security group.

When an employee leaves:

Disable the Entra ID account.
Wazuh access is automatically revoked.

This significantly reduces the chance of orphaned accounts.

Better Compliance

Many compliance frameworks recommend centralized identity management, least privilege, strong authentication, and detailed audit logging.

Azure AD integration helps organizations satisfy requirements found in:

ISO 27001
NIST Cybersecurity Framework
NIST SP 800-63
CIS Controls
PCI DSS
HIPAA
SOC 2

Related Guide:

How Wazuh Authenticates with Azure AD

Wazuh integrates with Microsoft Entra ID using the OpenID Connect (OIDC) authentication protocol.

Rather than validating usernames and passwords directly, Wazuh relies on Microsoft Entra ID to authenticate users and return signed identity tokens.

The process follows a secure standards-based authentication flow.

OpenID Connect (OIDC) Authentication Flow

When a user accesses Wazuh Dashboard:

The user selects Sign In.
Wazuh redirects the browser to Microsoft Entra ID.
Microsoft authenticates the user.
MFA or Conditional Access policies are evaluated.
Microsoft issues an ID Token.
The browser returns the token to Wazuh.
Wazuh validates the token.
A secure user session is created.

This process allows Wazuh to authenticate users without ever storing Microsoft account passwords.

OAuth 2.0 Authorization

OpenID Connect builds on OAuth 2.0.

OAuth provides secure authorization while OpenID Connect adds identity verification through ID tokens.

Together they provide:

Secure authentication
Authorization
Standardized token exchange
Session management

ID Tokens and Access Tokens

During authentication, Microsoft Entra ID issues different token types.

ID Token

Contains identity claims such as:

User ID
Display name
Email
Tenant ID
Group membership
Token expiration

Access Token

Allows authorized applications to securely access protected APIs if required.

Wazuh primarily relies on the ID Token for authentication.

User Authentication Sequence

A typical authentication sequence looks like this:

User opens Wazuh Dashboard.
Dashboard redirects to Microsoft Entra ID.
User enters credentials.
Conditional Access policies are evaluated.
MFA challenge is completed.
Microsoft signs and issues an ID Token.
Browser returns to Wazuh.
Wazuh validates the signature and token claims.
User session begins.

Token Validation

Before granting access, Wazuh validates:

Token signature
Issuing authority
Audience (Client ID)
Expiration time
Nonce
Token integrity

Only valid tokens issued by the trusted Microsoft Entra ID tenant are accepted.

Session Establishment

Once validation succeeds, Wazuh creates a secure authenticated session for the user.

Session duration is controlled by:

Wazuh session settings
Microsoft Entra ID token lifetime
Conditional Access policies
Session timeout configuration

This architecture ensures authentication remains centralized while Wazuh focuses on authorization and security monitoring.

Prerequisites

Before configuring the integration, verify that both your Wazuh deployment and Microsoft Entra ID environment meet the necessary requirements.

Wazuh Requirements

Supported Wazuh Version

Use a supported Wazuh release that includes OpenID Connect authentication support.

Running the latest stable version is recommended to benefit from recent security updates, bug fixes, and authentication enhancements.

Related Guide: How to Upgrade a Wazuh Agent

Wazuh Dashboard

The Wazuh Dashboard must be installed and accessible over HTTPS, as users authenticate through the web interface and are redirected to Microsoft Entra ID during the OIDC flow.

Wazuh Indexer

Ensure the Wazuh Indexer is healthy and communicating properly with the Dashboard, since authentication and role-based access depend on backend services being available.

Related Guide: The Ultimate Wazuh Indexer Guide

Administrative Privileges

You should have administrative access to:

Wazuh Dashboard
Wazuh server configuration
Configuration files
Service management
TLS certificates

Administrative privileges are required to configure OIDC settings and restart services.

Azure AD Requirements

Azure Subscription

An active Azure subscription is required to access Microsoft Entra ID administration features and register enterprise applications.

Microsoft Entra ID Tenant

You must have a Microsoft Entra ID tenant where users and groups are managed. This tenant will serve as the identity provider for Wazuh.

Global Administrator or Application Administrator Permissions

To register applications and configure authentication, you should have one of the following directory roles:

Global Administrator
Cloud Application Administrator
Application Administrator

These roles provide the permissions necessary to create and manage app registrations.

Enterprise Application Support

Your tenant must support Enterprise Applications so Wazuh can be integrated as a trusted application with assigned users or groups.

App Registration Permissions

You must be able to create an App Registration, configure redirect URIs, generate client secrets or certificates, and define API permissions required for OIDC authentication.

Network Requirements

HTTPS Connectivity

Secure HTTPS communication must be available between users, Wazuh Dashboard, and Microsoft Entra ID.

OIDC authentication depends on encrypted browser redirects and token exchanges.

TLS Certificates

Install valid TLS certificates on the Wazuh Dashboard to protect authentication traffic and prevent browser trust warnings.

Self-signed certificates may be suitable for testing but are generally not recommended for production deployments.

Firewall Configuration

Verify that firewalls allow outbound HTTPS (TCP port 443) connections from the Wazuh Dashboard to Microsoft Entra ID endpoints, and inbound HTTPS access for authorized users.

DNS Resolution

Both the Wazuh server and client browsers must be able to resolve Microsoft Entra ID endpoints reliably. Misconfigured DNS can prevent redirects, token validation, or metadata retrieval.

Time Synchronization (NTP)

Accurate system time is essential because OIDC tokens include issuance and expiration timestamps. Synchronize Wazuh servers using NTP to avoid authentication failures caused by clock drift.

Architecture Overview

Before configuring the integration, it’s helpful to understand how authentication requests flow between Wazuh and Microsoft Entra ID.

Unlike local authentication, Wazuh never validates usernames and passwords directly.

Instead, it delegates authentication to Microsoft Entra ID using the OpenID Connect (OIDC) protocol and trusts the signed identity tokens that Microsoft returns after successful authentication.

This architecture separates authentication from authorization:

Microsoft Entra ID authenticates the user.
Wazuh authorizes the user based on configured roles and permissions.
OpenID Connect securely exchanges identity information using signed tokens.
TLS encryption protects every step of the authentication process.

This model reduces password management overhead while allowing organizations to enforce centralized security policies such as Conditional Access, Multi-Factor Authentication (MFA), passwordless authentication, and identity governance.

Authentication Workflow

The authentication process consists of several secure steps.

1. User Accesses the Wazuh Dashboard

The user opens the Wazuh Dashboard in a web browser.

If the user is not already authenticated, the dashboard redirects them to Microsoft Entra ID rather than displaying a local login form.

2. Redirect to Azure AD Login

Using OpenID Connect, Wazuh sends an authentication request to Microsoft Entra ID that includes:

Client ID
Redirect URI
Requested scopes
Nonce value
Response type
Authentication state

The browser is redirected to Microsoft’s secure authentication endpoint.

3. User Authentication

Microsoft Entra ID verifies the user’s identity.

Depending on the organization’s configuration, users may authenticate using:

Username and password
Windows Hello for Business
Microsoft Authenticator
FIDO2 security keys
Passkeys
Certificate-based authentication
Passwordless authentication

Authentication always occurs within Microsoft Entra ID, not on the Wazuh server.

4. Multi-Factor Authentication (Optional)

If Conditional Access policies require additional verification, Microsoft Entra ID presents an MFA challenge.

Examples include:

Microsoft Authenticator approval
Push notification
Security key
One-time password
Biometric authentication

Microsoft evaluates Conditional Access policies before issuing any authentication token.

5. Token Issuance

Once authentication succeeds, Microsoft Entra ID issues signed identity tokens.

These typically include:

ID Token
Access Token (when required)
Refresh Token (if offline access is requested)

The ID Token contains user identity claims that Wazuh uses to establish the authenticated session.

6. Token Validation

After the browser returns to Wazuh, the Dashboard validates the received token.

Validation includes checking:

Digital signature
Issuer
Audience (Client ID)
Expiration
Token integrity
Nonce
Tenant ID

If validation fails, authentication is rejected.

7. Dashboard Access

After successful validation:

The user is authenticated.
RBAC permissions are applied.
A secure session is created.
The Wazuh Dashboard becomes available.

Depending on your RBAC configuration, different users may see different dashboards, APIs, management functions, or administrative features.

Related Guide: Troubleshooting Wazuh RBAC

Authentication Flow Diagram

User
 │
 ▼
Wazuh Dashboard
 │
 │ OIDC Authentication Request
 ▼
Microsoft Entra ID
 │
 │ User Login
 │
 │ MFA (if required)
 │
 ▼
Issues Signed ID Token
 │
 ▼
Browser Returns Token
 │
 ▼
Wazuh Dashboard
 │
 │ Validates Token
 ▼
Creates Session
 │
 ▼
User Access Granted

Components Involved

Several components work together during authentication.

Wazuh Dashboard

The Dashboard acts as the OpenID Connect client.

Its responsibilities include:

Redirecting users to Microsoft Entra ID
Receiving authentication responses
Validating identity tokens
Creating authenticated sessions
Applying RBAC permissions

Wazuh Indexer

Although the Indexer does not authenticate users directly, it stores:

Security events
Dashboard data
Authentication-related metadata
User activity logs

The Dashboard communicates with the Indexer after authentication succeeds.

Related Guide: The Ultimate Wazuh Indexer Guide

Azure AD (Microsoft Entra ID)

Microsoft Entra ID functions as the Identity Provider (IdP).

It is responsible for:

Authenticating users
Applying Conditional Access
Enforcing MFA
Issuing signed tokens
Managing enterprise identities
Logging authentication activity

OpenID Connect Provider

The OIDC provider exposes several endpoints, including:

Authorization endpoint
Token endpoint
Discovery endpoint
JWKS (JSON Web Key Set) endpoint
UserInfo endpoint (optional)

Wazuh uses these endpoints to discover configuration and validate tokens automatically.

The OpenID Foundation’s discovery specification defines how OIDC clients retrieve provider metadata dynamically.

Browser

The user’s web browser performs all authentication redirects between:

Wazuh Dashboard
Microsoft Entra ID

Authentication tokens are securely transmitted over HTTPS and should never be exposed or stored insecurely.

TLS Certificates

TLS protects every communication channel involved in authentication.

Certificates should be valid and trusted on:

Wazuh Dashboard
Reverse proxies
Load balancers
Microsoft Entra ID endpoints

Expired or invalid certificates commonly result in failed authentication or browser security warnings.

Related Guide: How to Fix Wazuh Certificate Errors

Step 1: Register an Application in Azure AD

Before Wazuh can authenticate users with Microsoft Entra ID, Azure must recognize Wazuh as a trusted application.

This is accomplished by creating an App Registration, which defines how Wazuh communicates with Microsoft Entra ID using the OpenID Connect protocol.

The registration provides Wazuh with a unique identity and generates the credentials required for secure token exchange.

Create a New App Registration

In the Microsoft Entra admin center:

Sign in to the Microsoft Entra admin center.
Navigate to Identity → Applications → App registrations.
Select New registration.
Configure the application details.
Click Register.

Name the Application

Choose a descriptive application name.

Examples include:

Wazuh Dashboard
Wazuh Production
Wazuh SOC
Wazuh Authentication
Wazuh Enterprise

Using consistent naming conventions simplifies administration in larger environments.

Choose Supported Account Types

Microsoft Entra ID asks which accounts can authenticate.

Most organizations should select:

Accounts in this organizational directory only (Single Tenant)

Other options include:

Multi-tenant organizations
Personal Microsoft accounts
Hybrid environments

Unless you specifically require external authentication, Single Tenant deployments offer a simpler and more secure configuration.

Configure Redirect URI

The Redirect URI tells Microsoft Entra ID where users should be returned after successful authentication.

A typical URI resembles:

https://wazuh.example.com/auth/openid/login

This URI must exactly match the value configured later within Wazuh.

Even minor differences, such as trailing slashes, ports, or protocol mismatches, can result in authentication errors.

Record the Application (Client) ID

After registration, Microsoft displays the Application (Client) ID.

This unique identifier tells Microsoft which application is requesting authentication.

You’ll use this value later when configuring the Wazuh Dashboard.

Record the Directory (Tenant) ID

Also record the Directory (Tenant) ID.

This identifies your Microsoft Entra tenant and allows Wazuh to validate tokens issued by the correct identity provider.

Create a Client Secret

The Client Secret functions similarly to a password for the application itself.

Wazuh uses it when securely exchanging authorization codes for tokens.

To create one:

Open the application.
Navigate to Certificates & secrets.
Select New client secret.
Enter a description.
Choose an expiration period.
Create the secret.

Generate a Client Secret

Once created, Microsoft displays the secret only once.

Copy it immediately and store it in a secure password manager or enterprise secrets vault.

If lost, you’ll need to generate a new secret.

Configure Expiration

Microsoft allows different expiration periods depending on current platform policies.

Shorter lifetimes reduce long-term exposure if a credential is compromised, while longer lifetimes reduce operational overhead.

Many organizations align secret expiration with their credential management policy and automate renewals where possible.

Securely Store the Secret

Treat the Client Secret like any privileged credential.

Avoid:

Saving it in documentation
Storing it in Git repositories
Hardcoding it into scripts
Sending it through email or chat
Leaving it in plaintext configuration backups

Instead, consider using secure secrets management platforms such as Azure Key Vault or another enterprise secrets manager.

Secret Rotation Recommendations

Security experts recommend rotating application secrets regularly.

Microsoft’s security guidance encourages organizations to prefer certificate-based authentication where appropriate and to implement regular credential rotation for application secrets.

Recommended practices include:

Rotate secrets before expiration.
Monitor secret expiration dates.
Remove unused credentials.
Use separate secrets for development and production.
Audit application credential usage.
Consider certificates instead of shared secrets for high-security environments.

Step 2: Configure API Permissions

After registering the application, configure the permissions that allow Microsoft Entra ID to authenticate users and provide Wazuh with basic identity information.

Most Wazuh deployments require only standard OpenID Connect permissions, following the principle of least privilege.

Required Permissions

Navigate to:

App Registration → API Permissions → Add a Permission → Microsoft Graph

Choose Delegated permissions and add the required scopes.

OpenID Permissions

The following OpenID Connect permissions enable secure authentication.

Profile

The profile scope allows Wazuh to receive basic user profile information, including the user’s display name and other standard identity claims.

Email

The email permission provides the user’s email address when available.

Many organizations use the email claim to identify users consistently across applications.

Offline Access

The offline_access permission allows refresh tokens to be issued, enabling longer-lived authenticated sessions without requiring users to sign in repeatedly.

Whether to enable this scope depends on your organization’s security and session management policies.

User.Read

User.Read is the standard delegated Microsoft Graph permission that allows applications to read the signed-in user’s basic profile.

It does not grant administrative access to directory data and is sufficient for most authentication scenarios.

Grant Admin Consent

After adding the permissions, select Grant admin consent for the tenant.

Without administrator consent, users may be prompted to approve permissions individually, or authentication may fail depending on tenant policies.

Why Consent Is Required

Administrator consent confirms that the organization trusts the application to use the requested Microsoft Graph permissions on behalf of users.

This helps prevent unauthorized applications from requesting access to organizational resources.

Tenant-Wide Approval

Granting tenant-wide consent provides a consistent authentication experience because individual users are not prompted to approve permissions during their first sign-in.

This is particularly important in enterprise SOC environments where dozens or hundreds of analysts may access the Wazuh Dashboard.

Verifying Granted Permissions

After consent is granted, verify that:

Every required permission appears in the API permissions list.
The Status column indicates that admin consent has been granted.
No unnecessary permissions have been assigned.
Warnings or pending consent requests are absent.

Following the principle of least privilege helps reduce risk and aligns with Microsoft’s identity security recommendations.

Related Guides:

Step 3: Configure Azure AD Authentication Endpoints

Once the application registration is complete, Wazuh needs to know where Microsoft Entra ID exposes its OpenID Connect (OIDC) services.

These endpoints allow the Wazuh Dashboard to redirect users for authentication, exchange authorization codes for tokens, retrieve user information, and validate token signatures.

Most modern OIDC clients, including Wazuh, can automatically discover these endpoints by using Microsoft’s OpenID Configuration (Discovery) endpoint, eliminating the need to manually configure each URL.

Microsoft publishes these endpoints according to the OpenID Connect Discovery specification, allowing applications to dynamically retrieve authentication metadata.

Identify the Required OIDC Endpoints

Several endpoints are involved in every authentication request.

Although automatic discovery is recommended, understanding each endpoint helps when troubleshooting authentication problems.

Authorization Endpoint

The Authorization Endpoint is where users authenticate.

When a user selects Sign In within the Wazuh Dashboard, their browser is redirected to this endpoint.

Its responsibilities include:

Displaying the Microsoft sign-in page
Authenticating the user
Evaluating Conditional Access policies
Triggering Multi-Factor Authentication (MFA)
Returning an authorization code

Typical request parameters include:

Client ID
Redirect URI
Response type
Scope
State
Nonce

This endpoint never returns passwords to Wazuh.

Token Endpoint

After the user successfully authenticates, Wazuh exchanges the authorization code for identity tokens using the Token Endpoint.

Microsoft returns:

ID Token
Access Token
Refresh Token (when offline access is enabled)

The communication occurs over HTTPS using the application’s Client ID and Client Secret.

This server-to-server exchange ensures tokens are issued securely without exposing sensitive credentials to the user’s browser.

UserInfo Endpoint

The UserInfo Endpoint allows applications to retrieve additional user attributes after authentication.

Depending on configuration, Wazuh may retrieve information such as:

Display name
Email address
User identifier
Preferred username
Locale

Not every deployment requires this endpoint, as many identity claims are already contained within the ID Token.

JWKS Endpoint

The JSON Web Key Set (JWKS) endpoint publishes Microsoft’s public signing keys.

Whenever Microsoft issues an ID Token, it digitally signs the token with a private key.

Wazuh retrieves the corresponding public keys from the JWKS endpoint to verify:

Token authenticity
Signature integrity
Trusted issuer
Key validity

Because Microsoft periodically rotates signing certificates, Wazuh should always obtain keys dynamically rather than storing them manually.

OpenID Configuration Endpoint

The Discovery Endpoint is arguably the most important OIDC endpoint because it provides all required configuration information automatically.

It typically includes:

Authorization Endpoint
Token Endpoint
JWKS Endpoint
UserInfo Endpoint
Supported scopes
Supported signing algorithms
Supported response types
Issuer information

A typical endpoint resembles:

https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration

Rather than manually entering every endpoint, configure Wazuh to use the Discovery URL whenever possible.

This reduces maintenance and automatically accommodates future endpoint updates from Microsoft.

The OpenID Foundation recommends using discovery metadata because it improves interoperability and simplifies client configuration across identity providers.

Step 4: Configure Wazuh for Azure AD Authentication

With the Microsoft Entra ID application registered and the OIDC endpoints identified, the next step is configuring the Wazuh Dashboard to use Microsoft Entra ID as its authentication provider.

The exact configuration file and parameter names may vary slightly between Wazuh releases, but the required settings remain largely the same.

After configuration, Wazuh will redirect users to Microsoft Entra ID whenever authentication is required.

Related Guide: How to Configure Wazuh OIDC

Configure the Authentication Settings

Access the Wazuh Dashboard authentication configuration and specify Microsoft Entra ID as the OpenID Connect provider.

Most deployments require configuring:

Identity provider
Client credentials
Discovery endpoint
Redirect URI
Logout endpoint
Session settings

Ensure every value matches the information configured in the Microsoft Entra application registration.

OIDC Provider Configuration

Set the authentication provider to use OpenID Connect.

The provider configuration defines how Wazuh communicates with Microsoft Entra ID throughout the authentication process, including authorization requests, token exchanges, and session validation.

If Wazuh supports automatic discovery, configure the Discovery URL rather than manually specifying individual endpoints.

Client ID

Enter the Application (Client) ID that was generated during Azure App Registration.

This identifier uniquely identifies the Wazuh Dashboard when communicating with Microsoft Entra ID.

Even a single incorrect character will prevent authentication from succeeding.

Client Secret

Enter the Client Secret created during the application registration process.

Because this credential authenticates the application itself:

Store it securely.
Restrict access.
Rotate it regularly.
Never commit it to source control.
Avoid storing it in plaintext backups.

Many organizations store application secrets in secure vaults such as Azure Key Vault or HashiCorp Vault instead of directly within configuration files.

Discovery URL

Specify the Microsoft Entra OpenID Configuration endpoint.

Using discovery allows Wazuh to automatically retrieve:

Authorization endpoint
Token endpoint
JWKS endpoint
Supported authentication methods
Issuer information
Signing algorithms

Automatic discovery significantly reduces configuration errors and simplifies future maintenance.

Redirect URI

Configure the Redirect URI so it exactly matches the URI registered within Microsoft Entra ID.

Common issues include:

HTTP instead of HTTPS
Incorrect hostname
Wrong port
Missing path
Trailing slash mismatch

Because Microsoft performs exact URI matching, even minor differences will result in authentication failures.

Logout URL

Optionally configure a logout endpoint that redirects users to Microsoft Entra ID after signing out of Wazuh.

Single Logout (SLO) behavior depends on both Wazuh capabilities and Microsoft Entra ID configuration.

Proper logout configuration helps prevent stale authenticated sessions on shared or public workstations.

Restart Wazuh Services

After updating the authentication configuration, restart the affected Wazuh services so the new settings are loaded.

Depending on your deployment, this may include:

Wazuh Dashboard
Reverse proxy (if used)
Authentication service
Supporting web services

Restarting ensures that cached authentication settings are cleared.

Verify Successful Startup

After the services restart:

Confirm all services are running.
Review startup logs.
Verify there are no configuration errors.
Ensure the Dashboard loads successfully.

Authentication-related errors often appear immediately during service initialization if configuration values are incorrect.

Validate Configuration

Before allowing production users to authenticate, perform several validation tests.

Verify that:

The Dashboard redirects to Microsoft Entra ID.
Login completes successfully.
MFA prompts appear when expected.
Tokens are accepted.
Sessions are established.
Logout functions correctly.
Role assignments are applied.
Authentication events appear in logs.

Testing with both administrative and standard user accounts helps identify RBAC configuration issues before deployment.

Step 5: Configure Role-Based Access Control (RBAC)

Authentication verifies who a user is. Authorization determines what that user is allowed to do.

After Microsoft Entra ID authenticates a user, Wazuh applies Role-Based Access Control (RBAC) to restrict access based on assigned permissions.

Proper RBAC configuration ensures that analysts, administrators, auditors, and executives receive only the access necessary for their responsibilities.

Following the principle of least privilege minimizes the impact of compromised accounts and reduces the risk of accidental configuration changes.

Related Guide: Troubleshooting Wazuh RBAC

Map Azure AD Users to Wazuh Roles

Users can be mapped to Wazuh roles individually or, preferably, through Microsoft Entra ID security groups.

Typical mappings include:

Azure AD User Type	Wazuh Role
Security Administrator	Administrator
SOC Analyst	SOC Analyst
Compliance Officer	Auditor
Executive	Read-only
Engineering Team	Custom Role

Group-based assignments are generally easier to manage than assigning permissions to individual users.

Administrator Role

Administrators typically receive unrestricted access.

Permissions commonly include:

User management
RBAC configuration
Rule management
Decoder management
Agent administration
Cluster management
API access
Dashboard administration
Index management

Administrator access should be limited to trusted personnel and protected with strong MFA and Conditional Access policies.

SOC Analyst Role

SOC analysts generally require access to:

Alerts
Security events
Threat hunting
Dashboards
Log searches
Active investigations
Case analysis

They usually do not require permissions to modify system-wide configuration or authentication settings.

Read-only Role

Read-only users can:

View dashboards
Search logs
Review alerts
Generate reports
Monitor system health

They cannot:

Delete data
Modify rules
Change configuration
Manage users
Restart services

This role is well suited for executives, management teams, and external stakeholders.

Auditor Role

Auditors often require visibility into compliance and security data without administrative privileges.

Typical permissions include:

Compliance dashboards
Security reports
Historical alerts
Audit logs
Vulnerability reports
Configuration review

Restricting modification privileges preserves audit integrity.

Custom Roles

Large organizations frequently create custom roles tailored to operational responsibilities.

Examples include:

Threat Hunter
Incident Responder
Detection Engineer
Vulnerability Management Team
Tier 1 Analyst
Tier 2 Analyst
MSSP Customer Administrator

Custom roles provide more granular control than broad administrator or analyst permissions.

Group-Based Authorization

Managing authorization through Microsoft Entra ID groups simplifies long-term administration.

Instead of assigning roles individually:

Users join security groups.
Groups map to Wazuh roles.
Permissions are assigned automatically.

This significantly reduces administrative effort in large environments.

Azure AD Security Groups

Create dedicated security groups for different operational teams.

Examples include:

Wazuh Administrators
Wazuh SOC Analysts
Wazuh Auditors
Wazuh Read Only
Wazuh Detection Engineers

Using dedicated groups keeps identity management centralized within Microsoft Entra ID.

Group Claims

Microsoft Entra ID can include a user’s group memberships as claims within the ID Token.

Wazuh evaluates these claims during authentication to determine the appropriate RBAC role.

When organizations have a large number of groups, review Microsoft’s guidance on group claim limits and overage handling to avoid unexpected authorization behavior.

Automatic Role Assignment

With group claims configured, role assignment becomes automatic:

The user signs in.
Microsoft Entra ID authenticates the user.
Group claims are included in the ID Token.
Wazuh validates the token.
Wazuh maps the groups to RBAC roles.
The user receives the appropriate permissions.

No manual intervention is required after group membership changes.

Least Privilege Access

Microsoft, NIST, and CISA all recommend implementing the principle of least privilege, granting users only the permissions necessary to perform their responsibilities.

Best practices include:

Avoid assigning Administrator access by default.
Use dedicated administrative accounts.
Regularly review group memberships.
Remove inactive users promptly.
Conduct periodic access reviews.
Enable MFA for privileged roles.
Monitor administrative activity through audit logs.

Organizations that combine centralized identity management, strong authentication, and least-privilege RBAC are better positioned to reduce insider risk, improve compliance, and strengthen the overall security posture of their Wazuh deployment.

Related Guide:

Step 6: Test the Integration

After completing the configuration, thoroughly test the integration before allowing production users to access the Wazuh Dashboard.

Validation should confirm that authentication, authorization, and session management all function as expected.

Testing with multiple user accounts, including administrators, SOC analysts, auditors, and read-only users, helps identify configuration issues early and ensures each role receives the correct permissions.

A comprehensive test plan should validate:

Authentication
Multi-Factor Authentication (MFA)
Role-Based Access Control (RBAC)
Session management
Logout behavior
API authorization
Group synchronization

Related Guides:

Verify User Authentication

The first objective is confirming that Microsoft Entra ID successfully authenticates users and establishes secure sessions within Wazuh.

Successful Login

Begin by logging into the Wazuh Dashboard using a standard Microsoft Entra ID account.

Verify that:

The browser redirects to Microsoft Entra ID.
Authentication succeeds without errors.
The user returns to Wazuh automatically.
The Dashboard loads successfully.
No authentication warnings appear in the logs.

If the Dashboard displays immediately without redirecting to Microsoft Entra ID, review your authentication configuration.

MFA Validation

If Multi-Factor Authentication is required, verify that the configured challenge occurs during sign-in.

Depending on your organization’s policies, this may include:

Microsoft Authenticator approval
Push notification
Passkey authentication
Windows Hello for Business
FIDO2 security key
One-time verification code

Also confirm that users who are exempt from MFA follow the expected authentication flow.

Logout Functionality

Test the logout process to ensure authentication sessions terminate correctly.

Verify that:

The Wazuh session ends.
Browser cookies are removed.
Returning to the Dashboard requires authentication again.
Users are redirected appropriately after logout.

If Single Logout (SLO) is configured, confirm that the Microsoft Entra ID session also behaves as expected.

Session Expiration

Allow an authenticated session to remain idle until the configured timeout expires.

Confirm that:

Users are logged out automatically.
Expired sessions cannot continue accessing protected resources.
Reauthentication occurs when required.
Session renewal follows organizational security policies.

Proper session expiration reduces the risk of unauthorized access from unattended workstations.

Validate Authorization

Authentication only proves identity. Authorization determines what authenticated users can access.

Test authorization using accounts assigned to different Wazuh roles.

Dashboard Permissions

Verify that users only see the dashboards and administrative features assigned to their role.

For example:

User Role	Expected Access
Administrator	Full platform management
SOC Analyst	Alerts, investigations, threat hunting
Auditor	Reports and compliance dashboards
Read-only User	View-only access

Attempt to access restricted administrative features while logged in as a non-administrative user.

API Access

If users interact with the Wazuh API, verify that API requests respect RBAC permissions.

Confirm that:

Authorized API calls succeed.
Unauthorized operations return appropriate HTTP status codes.
Tokens are accepted.
API endpoints enforce access controls consistently.

Role Assignments

Confirm that users receive the appropriate Wazuh role after authentication.

Review:

Assigned role
Dashboard visibility
Administrative permissions
API authorization
Feature availability

Incorrect role mapping is one of the most common causes of post-login access issues.

Group Synchronization

If role assignments depend on Microsoft Entra ID groups:

Verify that:

Group memberships appear in the ID Token.
Wazuh recognizes the group claims.
Correct RBAC roles are assigned.
Newly added users receive access automatically.
Removed users lose access after synchronization.

Testing user lifecycle events ensures onboarding and offboarding processes work as expected.

Security Best Practices

Integrating Wazuh with Microsoft Entra ID significantly strengthens authentication security, but the integration should also follow modern identity security best practices.

Microsoft, CISA, and NIST all emphasize Zero Trust principles that assume no user, device, or application should be trusted automatically.

Instead, every authentication request should be continuously verified based on identity, device health, location, and risk signals.

Enforce Multi-Factor Authentication

Multi-Factor Authentication (MFA) is one of the most effective defenses against credential theft and account compromise.

Microsoft has consistently reported that MFA can prevent the overwhelming majority of password-based attacks by requiring additional verification beyond a password.

MFA Policies

Require MFA for:

Wazuh administrators
SOC analysts
Incident responders
Remote users
Privileged accounts

Risk-based Conditional Access policies can require MFA only when elevated risk is detected.

Passwordless Authentication

Where supported, consider replacing passwords with stronger authentication methods.

Examples include:

Windows Hello for Business
Passkeys
FIDO2 security keys
Certificate-based authentication

Passwordless authentication reduces phishing risks while improving user experience.

Microsoft Authenticator

Microsoft Authenticator remains one of the most widely deployed MFA solutions.

Benefits include:

Push notifications
Number matching
Device binding
Reduced phishing exposure
Integration with Conditional Access

FIDO2 Security Keys

FIDO2 hardware security keys provide phishing-resistant authentication.

These devices:

Resist credential theft
Prevent replay attacks
Support passwordless sign-in
Meet modern Zero Trust recommendations

They are particularly valuable for privileged administrator accounts.

Apply Conditional Access Policies

Conditional Access allows organizations to evaluate multiple risk signals before granting access.

Rather than trusting every login equally, Microsoft Entra ID can make context-aware access decisions.

Device Compliance

Require users to authenticate only from:

Managed devices
Intune-compliant endpoints
Corporate laptops
Devices meeting security requirements

This reduces the likelihood of unmanaged systems accessing sensitive security infrastructure.

Location-Based Access

Restrict authentication based on:

Geographic regions
Trusted IP ranges
Corporate networks
VPN connections

High-risk countries or unexpected locations can trigger additional verification or block access entirely.

Risk-Based Authentication

Microsoft Entra ID Identity Protection can evaluate:

Impossible travel
Anonymous IP usage
Leaked credentials
Malware indicators
Suspicious login behavior

High-risk logins can automatically require MFA or be blocked.

Session Controls

Configure session policies to:

Limit idle session duration.
Require periodic reauthentication.
Restrict persistent browser sessions.
Protect privileged administrative access.

Shorter session lifetimes reduce exposure if a workstation is left unattended.

Protect Client Secrets

The Client Secret authenticates Wazuh to Microsoft Entra ID and should be treated as a highly sensitive credential.

Secure Storage

Store secrets only in trusted locations.

Avoid:

Source control repositories
Documentation
Plaintext configuration backups
Shared network folders
Email messages

Access should be restricted to authorized administrators.

Secret Rotation

Establish a regular credential rotation policy.

Best practices include:

Rotate secrets before expiration.
Remove unused credentials.
Monitor expiration dates.
Maintain documented rotation procedures.
Test new credentials before deleting old ones.

Use Azure Key Vault

Rather than storing secrets locally, many organizations use Azure Key Vault to centralize credential management.

Benefits include:

Secure secret storage
Hardware-backed protection
Access policies
Audit logging
Automatic rotation support
Integration with Azure services

Minimize Secret Exposure

Limit who can:

View secrets
Export credentials
Create new secrets
Modify authentication settings

Restricting visibility reduces insider risk and accidental credential exposure.

Secure Communications

Authentication traffic should always be protected using modern encryption standards.

HTTPS Everywhere

All communication between:

Browsers
Wazuh Dashboard
Reverse proxies
Microsoft Entra ID

should use HTTPS exclusively.

Never expose authentication traffic over unencrypted HTTP.

Trusted Certificates

Deploy certificates issued by trusted Certificate Authorities whenever possible.

Monitor certificates for:

Expiration
Revocation
Hostname accuracy
Proper trust chains

Disable Insecure Protocols

Disable outdated protocols and weak cryptographic algorithms such as:

SSL 2.0
SSL 3.0
TLS 1.0
TLS 1.1
Weak cipher suites

Modern deployments should use current versions of TLS with strong cipher suites.

Certificate Monitoring

Implement proactive certificate monitoring to avoid unexpected authentication outages.

Monitor:

Expiration dates
Renewal status
Trust validation
Certificate chain health

Related Guide: How to Fix Wazuh Certificate Errors

Follow the Principle of Least Privilege

Every account should receive only the permissions required to perform its assigned responsibilities.

Least privilege limits the impact of compromised credentials and accidental administrative changes.

Restrict Administrative Roles

Only designated administrators should receive full platform access.

Avoid granting administrative privileges to:

SOC analysts
Auditors
Executives
Contractors
Temporary users

Use Dedicated Admin Accounts

Administrators should maintain separate accounts for privileged activities.

For example:

Daily user account
Dedicated Wazuh administrator account

This reduces exposure during routine email, web browsing, and document handling.

Regular Access Reviews

Review access permissions periodically.

Verify:

Role assignments
Group memberships
Administrative privileges
Disabled accounts
Service accounts

Quarterly reviews help identify excessive or outdated permissions.

Remove Unused Accounts

Immediately remove or disable:

Former employees
Contractors
Dormant accounts
Temporary project accounts

Automated provisioning and deprovisioning through Microsoft Entra ID simplifies this process and helps maintain a secure environment.

Common Integration Issues and Troubleshooting

Even properly configured integrations can encounter authentication or authorization issues.

Most problems stem from configuration mismatches between Wazuh and Microsoft Entra ID, incorrect OpenID Connect settings, or RBAC misconfigurations.

The following troubleshooting steps address the issues administrators encounter most frequently.

Login Redirect Loops

One of the most common problems is an endless authentication loop in which users authenticate successfully with Microsoft Entra ID but are continuously redirected back to the login page.

Possible causes include:

Incorrect redirect URI
Invalid session cookies
Browser cache
Token validation failures
Misconfigured reverse proxy

Incorrect Redirect URI

Microsoft Entra ID requires an exact match between the registered Redirect URI and the URI configured in Wazuh.

Verify:

HTTPS is used.
Hostnames match exactly.
Ports are correct.
Paths are identical.
Trailing slashes are consistent.

Even a minor mismatch can prevent authentication from completing.

Browser Cache

Cached authentication information can sometimes interfere with new configuration changes.

Try:

Clearing browser cache.
Removing cookies.
Testing in a private browsing session.
Using another browser.

If authentication succeeds in an incognito session, cached browser data is likely the cause.

Session Cookies

Incorrect cookie settings, particularly when Wazuh is deployed behind a reverse proxy, can prevent authenticated sessions from persisting.

Review:

Cookie domain
Secure flag
SameSite configuration
Proxy headers

Related Guide: Fixing Wazuh API SameSite Cookie Errors

Invalid Client Credentials

If Wazuh cannot exchange the authorization code for tokens, client credential problems are often responsible.

Incorrect Client ID

Verify that the configured Client ID exactly matches the Application (Client) ID shown in the Microsoft Entra App Registration.

Copy-and-paste errors are common.

Expired Client Secret

Client Secrets eventually expire.

Check:

Expiration date
Secret value
Active credentials
Rotation history

If necessary, generate a new secret and update the Wazuh configuration.

Tenant Mismatch

Authentication may fail if Wazuh points to the wrong Microsoft Entra tenant.

Verify:

Tenant ID
Discovery URL
Issuer
Client registration

All values must reference the same tenant.

Token Validation Errors

If Wazuh receives a token but rejects it, validation checks are usually failing.

Issuer Mismatch

The token issuer must match the configured Microsoft Entra ID tenant.

Review the configured Issuer URI and Discovery URL to ensure they correspond to the correct tenant.

Audience Mismatch

The aud (audience) claim inside the ID Token must equal the application’s Client ID.

If these values differ, Wazuh rejects the token.

Clock Skew

OIDC tokens contain strict issuance and expiration timestamps.

Even a few minutes of clock drift can cause authentication failures.

Ensure all systems synchronize time using NTP.

Invalid Signing Certificates

Microsoft periodically rotates signing keys.

If Wazuh cannot retrieve updated signing certificates from the JWKS endpoint, token validation may fail.

Using the Discovery endpoint allows Wazuh to retrieve updated signing keys automatically.

Missing Group Claims

Users may authenticate successfully but receive incorrect permissions because group information is missing.

Azure AD Group Configuration

Verify that:

Security groups are assigned.
Group claims are enabled.
The correct claim type is configured.
Required groups are included in tokens.

Token Size Limitations

Organizations with users belonging to hundreds of groups may encounter token size limitations.

When group memberships exceed supported limits, Microsoft Entra ID may omit groups from the token.

Group Overage Claims

Instead of embedding every group, Microsoft Entra ID can return a group overage claim, requiring applications to query Microsoft Graph for complete membership information.

Review Microsoft’s guidance if users belong to a large number of security groups.

Permission Denied After Login

If authentication succeeds but users cannot access expected features, RBAC configuration should be reviewed.

Incorrect RBAC Mapping

Confirm that Microsoft Entra ID groups map to the intended Wazuh roles.

A successful login does not guarantee that the correct permissions have been assigned.

Missing Group Membership

Verify the user’s current Microsoft Entra ID group memberships.

Recently added users may require time for directory synchronization or a new sign-in before updated group claims appear in their token.

Wazuh Role Configuration

Review the RBAC configuration within Wazuh.

Confirm that:

Roles exist.
Permissions are assigned correctly.
Group mappings are accurate.
Role inheritance behaves as expected.

Related Guide: Troubleshooting Wazuh RBAC

TLS Certificate Problems

Certificate issues commonly prevent secure OIDC communication.

Certificate Trust Issues

Ensure that:

Certificates are issued by trusted Certificate Authorities.
Intermediate certificates are installed.
Clients trust the certificate chain.
Browsers report no certificate warnings.

Expired Certificates

Authentication requests may fail if certificates have expired.

Monitor certificate expiration proactively and renew certificates before they become invalid.

Hostname Mismatch

The certificate’s Common Name (CN) or Subject Alternative Name (SAN) must match the hostname users access.

For example:

Certificate: wazuh.company.com
Browser URL: wazuh.company.com ✅

Using a different hostname than the certificate covers will result in browser trust errors and may prevent successful authentication.

Related Guide: How to Fix Wazuh Certificate Errors

Performance and High Availability Considerations

Integrating Wazuh with Microsoft Entra ID improves authentication security and simplifies identity management, but enterprise deployments should also consider availability, scalability, and operational resilience.

Authentication becomes a critical dependency because users cannot access the Wazuh Dashboard if the identity provider is unavailable or incorrectly configured.

Organizations running production Security Operations Centers (SOCs) should design authentication processes that remain reliable during service interruptions, scaling events, and credential lifecycle changes.

Azure AD Service Availability

Microsoft Entra ID is designed as a highly available cloud identity platform with global infrastructure, redundancy, and automated failover capabilities.

However, organizations should still understand how identity availability impacts Wazuh access.

Microsoft Service Redundancy

Microsoft operates Entra ID using globally distributed infrastructure designed to minimize service interruptions.

Key reliability features include:

Multiple datacenters
Automatic failover mechanisms
Global service replication
Redundant authentication endpoints
Continuous service monitoring

Because Wazuh delegates authentication to Microsoft Entra ID, organizations benefit from Microsoft’s identity platform availability model instead of maintaining their own authentication infrastructure.

Regional Availability

Although Microsoft Entra ID operates globally, organizations should consider regional dependencies.

Factors that may affect authentication include:

Internet connectivity
Regional network outages
Firewall restrictions
DNS failures
Proxy availability
Identity service disruptions

Organizations with globally distributed SOC teams should validate authentication from different geographic locations.

Authentication Resilience

To improve resilience:

Maintain emergency administrator accounts.
Document authentication recovery procedures.
Monitor Microsoft Entra ID service health.
Maintain backup access methods.
Test authentication during disaster recovery exercises.

Privileged accounts should have secure break-glass access that does not depend on standard user workflows.

Authentication Latency

Authentication performance directly affects user experience, especially when analysts frequently access Wazuh Dashboard during security investigations.

Several factors influence login speed:

Network latency
Microsoft Entra ID response time
MFA verification speed
Token validation
DNS resolution
Reverse proxy performance

Token Validation Performance

During authentication, Wazuh validates Microsoft Entra ID tokens by checking:

Digital signatures
Token issuer
Audience
Expiration timestamps
Claims

Token validation is generally lightweight, but large deployments should ensure that Wazuh Dashboard resources are properly sized.

Performance considerations include:

Adequate CPU resources
Sufficient memory allocation
Efficient network connectivity
Proper TLS configuration

Network Optimization

Authentication requires communication between:

User browsers
Wazuh Dashboard
Microsoft Entra ID endpoints

Optimize authentication performance by:

Reducing unnecessary network hops.
Using reliable DNS servers.
Avoiding excessive proxy inspection delays.
Ensuring outbound HTTPS connectivity.
Placing Wazuh components close to primary user locations when possible.

Session Caching

Session management reduces repeated authentication requests.

After successful authentication, Wazuh maintains an authenticated session so users do not need to contact Microsoft Entra ID for every Dashboard action.

Benefits include:

Faster navigation
Reduced authentication traffic
Improved analyst productivity

Session caching should balance usability with security requirements.

Session Management

Proper session management prevents unauthorized access while maintaining a convenient user experience.

Session Timeout Configuration

Configure session timeout policies based on user risk.

Examples:

Short sessions for administrators
Longer sessions for read-only users
Automatic logout on inactivity
Forced reauthentication for sensitive operations

Privileged security accounts should generally use stricter session policies.

Refresh Tokens

Refresh tokens allow applications to obtain new access tokens without requiring users to authenticate repeatedly.

Organizations should evaluate:

Token lifetime
Refresh behavior
Persistent sessions
Device trust requirements

Long-lived refresh tokens should only be used when appropriate and protected through strong identity policies.

Re-authentication Policies

Microsoft Entra Conditional Access allows organizations to require periodic reauthentication.

Examples:

Require sign-in every 8 hours.
Require authentication after risk changes.
Require MFA for privileged operations.
Require reauthentication from unfamiliar locations.

These controls reduce the risk of stolen sessions being reused.

Scaling Enterprise Deployments

Large organizations may have hundreds or thousands of security users accessing Wazuh.

Enterprise deployments should plan for user growth, dashboard availability, and authentication workload.

Supporting Thousands of Users

Microsoft Entra ID can support large-scale authentication scenarios, but Wazuh authorization design becomes increasingly important as user numbers grow.

Recommended practices:

Use group-based authorization.
Avoid individual user mappings.
Automate onboarding workflows.
Separate administrative and analyst roles.
Regularly review access permissions.

Multiple Wazuh Dashboard Instances

Large SOC environments may deploy multiple Wazuh Dashboard instances for:

High availability
Geographic distribution
Disaster recovery
Performance optimization

All Dashboard instances should share:

Consistent OIDC configuration
Matching redirect URIs
Identical RBAC mappings
Consistent TLS settings

Load Balancing Considerations

When placing Wazuh Dashboard instances behind a load balancer:

Consider:

Session persistence
TLS termination
Health checks
Authentication callback routing
Certificate management

Incorrect load balancer configuration can cause:

Login loops
Failed callbacks
Lost sessions
Token validation failures

Client Secret and Certificate Lifecycle

Application credentials require ongoing maintenance. Expired secrets or certificates can immediately interrupt authentication.

Automated Secret Rotation

Organizations should automate credential rotation whenever possible.

Recommended practices:

Monitor expiration dates.
Generate replacement credentials before expiration.
Test new credentials.
Remove expired secrets.
Document rotation procedures.

Automation prevents unexpected authentication outages.

Certificate Renewal

For deployments using certificate-based authentication:

Monitor:

Certificate expiration
Certificate authority status
Private key protection
Renewal completion

Certificates should be renewed before expiration and tested before replacing production credentials.

Monitoring Credential Expiration

Track:

Client Secret expiration dates
Application certificates
TLS certificates
Service account credentials

Microsoft Entra ID administrators should configure notifications before credentials expire.

Monitoring Authentication Services

Authentication activity should be monitored like any other security service.

Authentication logs provide valuable information for:

Threat detection
Compliance reporting
Incident investigations
Access reviews

Azure AD Sign-in Logs

Microsoft Entra ID provides detailed sign-in logs containing:

User identity
Authentication result
Location
Device information
MFA status
Conditional Access evaluation
Risk information

These logs help detect suspicious authentication behavior.

Wazuh Authentication Logs

Monitor Wazuh logs for:

Successful authentication
Failed authentication
Token validation failures
RBAC assignment errors
Session problems

These events provide visibility into the Wazuh side of authentication.

Related Guide: How to Configure Wazuh Audit Logs

Failed Login Monitoring

Repeated failed authentication attempts may indicate:

Incorrect configuration
User mistakes
Password attacks
Compromised accounts
Conditional Access failures

Organizations should establish alert thresholds for abnormal login activity.

Alerting for Authentication Failures

Create monitoring rules for:

Multiple failed logins
Administrator authentication failures
Impossible travel events
MFA failures
Disabled user access attempts

Security teams can integrate these alerts into existing incident response workflows.

Related Guide: How to Configure Wazuh Alerts

Disaster Recovery Planning

Identity integration should be included in disaster recovery planning because authentication failures can prevent access to security monitoring systems.

Backup Authentication Configuration

Maintain secure backups of:

OIDC configuration
Client IDs
Tenant information
Redirect URIs
RBAC mappings
Certificate information
Secret rotation procedures

Never store secrets in unsecured backup locations.

Emergency Administrator Accounts

Maintain emergency administrator accounts for situations where standard authentication is unavailable.

Best practices:

Protect accounts with strong authentication.
Store credentials securely.
Monitor usage.
Test access periodically.
Limit account privileges.

Recovery Procedures

Document recovery steps for:

Microsoft Entra ID outages
Expired credentials
Lost configuration
Failed Dashboard deployments
RBAC mapping failures

A documented recovery process reduces downtime during incidents.

Business Continuity Testing

Regularly test:

Authentication recovery
Administrator access
Backup configurations
Credential replacement
Disaster scenarios

Testing ensures the organization can restore Wazuh access during real-world failures.

Real-World Example

A large enterprise operates a Security Operations Center (SOC) responsible for monitoring thousands of endpoints, cloud workloads, and network devices using Wazuh.

The SOC includes multiple teams:

Tier 1 security analysts
Incident responders
Threat hunters
Security engineers
Wazuh administrators
Compliance auditors

Previously, each user maintained separate Wazuh accounts, creating administrative overhead and inconsistent access management.

The organization decided to integrate Wazuh with Microsoft Entra ID to centralize authentication and improve security governance.

Azure AD Application Registration

The security engineering team creates a dedicated Microsoft Entra ID application named:

Production Wazuh Dashboard Authentication

The application is configured with:

Single-tenant authentication
OpenID Connect support
HTTPS redirect URI
Required identity permissions
Dedicated production credentials

The team records:

Application Client ID
Tenant ID
Authentication endpoints

OIDC Authentication Configuration

The Wazuh administrators configure the Dashboard to use Microsoft Entra ID as the OpenID Connect provider.

The configuration includes:

Discovery URL
Client ID
Client Secret
Redirect URI
Logout configuration

After restarting Wazuh services, pilot users authenticate through Microsoft Entra ID instead of local Wazuh credentials.

Azure AD Group Synchronization

The organization creates dedicated security groups:

Wazuh Administrators
Wazuh SOC Analysts
Wazuh Incident Responders
Wazuh Auditors

Each group maps to a corresponding Wazuh RBAC role.

Examples:

Azure AD Group	Wazuh Role
Wazuh Administrators	Administrator
Wazuh SOC Analysts	Analyst
Wazuh Incident Responders	Investigator
Wazuh Auditors	Read Only

When a new analyst joins the SOC, administrators only add the employee to the appropriate Microsoft Entra ID group.

Wazuh permissions are automatically applied during authentication.

Conditional Access and MFA Enforcement

The organization creates Conditional Access policies requiring:

MFA for all Wazuh users
Strong authentication for administrators
Compliant devices for privileged access
Additional verification for risky sign-ins

Administrators require phishing-resistant authentication using FIDO2 security keys.

Secure Credential Management

Instead of storing the application secret directly on administrative workstations, the organization stores credentials securely using Azure Key Vault.

The security team:

Monitors secret expiration.
Automates credential rotation.
Restricts access to authorized administrators.
Maintains audit records.

Pilot Testing Before Deployment

Before organization-wide rollout, the SOC performs a controlled pilot.

Testing includes:

Administrator login
Analyst access
MFA validation
RBAC permissions
Group synchronization
Session expiration
Logout behavior

After successful validation, the organization enables Azure AD authentication for all Wazuh users.

Operational Benefits

The Azure AD integration provides several improvements:

Simplified Identity Management

User accounts are managed from one identity platform.

Benefits include:

Faster onboarding
Immediate account removal
Centralized policies
Reduced administrative effort

Improved Security

Security improves through:

MFA enforcement
Conditional Access
Centralized authentication monitoring
Stronger password policies
Reduced credential exposure

Streamlined Provisioning and Deprovisioning

When employees change roles or leave the company:

Microsoft Entra ID groups are updated.
Wazuh permissions automatically change.
Access is removed immediately.

Compliance Visibility

Authentication logs from Microsoft Entra ID combined with Wazuh security monitoring provide evidence for:

Access reviews
Compliance audits
Incident investigations
Security reporting

The integration creates a scalable identity architecture suitable for enterprise SOC environments.

Frequently Asked Questions

Question: Can Wazuh integrate with Azure AD?

Yes. Wazuh can integrate with Azure AD (Microsoft Entra ID) using modern authentication protocols such as OpenID Connect.

This allows organizations to authenticate Wazuh Dashboard users through their existing Microsoft identity infrastructure.

Question: Does Wazuh use OpenID Connect with Azure AD?

Yes. OpenID Connect provides the authentication framework between Wazuh and Microsoft Entra ID. It enables secure token-based authentication without requiring Wazuh to store user passwords.

Question: Is Azure AD now called Microsoft Entra ID?

Yes. Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023. The underlying identity platform remains the same, but Microsoft uses the Entra ID name for current documentation and branding.

Question: Can I enable MFA when using Azure AD with Wazuh?

Yes. MFA is configured through Microsoft Entra ID policies, including Conditional Access. Wazuh inherits these authentication requirements automatically.

Question: Can Azure AD groups be mapped to Wazuh roles?

Yes. Microsoft Entra ID security groups can be included as token claims and mapped to Wazuh RBAC roles.

This allows automatic permission assignment based on group membership.

Question: What permissions are required for the Azure AD application?

Most Wazuh deployments require standard OpenID Connect permissions, including:

OpenID
Profile
Email
Offline access
User.Read

Administrative consent may be required depending on tenant policies.

Question: Does Wazuh support Single Sign-On (SSO) with Azure AD?

Yes. OpenID Connect authentication provides SSO capabilities by allowing users to authenticate through Microsoft Entra ID instead of maintaining separate Wazuh credentials.

Question: Can multiple Azure AD tenants authenticate to Wazuh?

Yes, depending on application registration configuration. Organizations can configure multi-tenant authentication scenarios, although single-tenant deployments are generally recommended for enterprise SOC environments.

Question: How do I troubleshoot Azure AD login failures?

Common troubleshooting steps include:

Verify Redirect URI configuration.
Check Client ID and Client Secret.
Confirm Tenant ID.
Review Microsoft Entra sign-in logs.
Validate token claims.
Check Wazuh authentication logs.
Verify TLS certificates.
Review RBAC mappings.

Question: Is Azure AD integration available in the free version of Wazuh?

Yes. Wazuh is an open-source platform, and authentication integrations such as OpenID Connect are available without requiring a commercial license.

However, Microsoft Entra ID features such as Conditional Access, Identity Protection, and advanced governance capabilities depend on your Microsoft licensing level.

Conclusion

Integrating Wazuh with Azure AD (Microsoft Entra ID) provides organizations with a centralized, secure, and scalable authentication architecture for security monitoring environments.

By connecting Wazuh with Microsoft Entra ID, organizations gain:

Centralized identity management
Single Sign-On capabilities
Multi-Factor Authentication enforcement
Conditional Access policies
Automated user provisioning and removal
Improved audit visibility
Enterprise-grade access control

OpenID Connect allows Wazuh to delegate authentication securely while Microsoft Entra ID manages identity verification, authentication policies, and security controls.

For enterprise SOC environments, combining Microsoft Entra ID authentication with Wazuh RBAC creates a powerful access management model where users receive only the permissions required for their responsibilities.

Organizations should regularly review:

Authentication policies
Conditional Access rules
RBAC mappings
Group memberships
Client secrets
Certificates
Application permissions

Continuous review ensures the Wazuh deployment remains secure, compliant, and resilient as the organization grows.

Related Guide:

How to Integrate Wazuh with Azure AD

Benefits of Wazuh Azure AD Integration

Understanding the Wazuh and Azure AD Integration

What Is Azure AD (Microsoft Entra ID)?

Identity and Access Management

Authentication Services

Enterprise Applications

Conditional Access

Multi-Factor Authentication

Identity Governance

Why Integrate Wazuh with Azure AD?

Centralized Identity Management

Single Sign-On (SSO)

Multi-Factor Authentication (MFA)

Reduced Password Management

Improved Auditing

Simplified Onboarding and Offboarding

Better Compliance

How Wazuh Authenticates with Azure AD

OpenID Connect (OIDC) Authentication Flow

OAuth 2.0 Authorization

ID Tokens and Access Tokens

User Authentication Sequence

Token Validation

Session Establishment

Prerequisites

Wazuh Requirements

Supported Wazuh Version

Wazuh Dashboard

Wazuh Indexer

Administrative Privileges

Azure AD Requirements

Azure Subscription

Microsoft Entra ID Tenant

Global Administrator or Application Administrator Permissions

Enterprise Application Support

App Registration Permissions

Network Requirements

HTTPS Connectivity

TLS Certificates

Firewall Configuration

DNS Resolution

Time Synchronization (NTP)

Architecture Overview

Authentication Workflow

1. User Accesses the Wazuh Dashboard

2. Redirect to Azure AD Login

3. User Authentication

4. Multi-Factor Authentication (Optional)

5. Token Issuance

6. Token Validation

7. Dashboard Access

Authentication Flow Diagram

Components Involved

Wazuh Dashboard

Wazuh Indexer

Azure AD (Microsoft Entra ID)

OpenID Connect Provider

Browser

TLS Certificates

Step 1: Register an Application in Azure AD

Create a New App Registration

Name the Application

Choose Supported Account Types

Configure Redirect URI

Record the Application (Client) ID

Record the Directory (Tenant) ID

Create a Client Secret

Generate a Client Secret

Configure Expiration

Securely Store the Secret

Secret Rotation Recommendations

Step 2: Configure API Permissions

Required Permissions

OpenID Permissions

Profile

Email

Offline Access

User.Read

Grant Admin Consent