How to Fix Wazuh SSO Login Error

A Wazuh SSO login error occurs when a user cannot authenticate to the Wazuh Dashboard through an external Identity Provider (IdP), such as Microsoft Entra ID, Okta, Keycloak, or another SAML-compatible identity platform. Depending on where the authentication flow fails, users may see an authentication error, an endless redirect loop, a blank login page, a 403 Forbidden response, or a message indicating that the SSO response is invalid.

Wazuh uses the Wazuh Dashboard and Wazuh Indexer security configuration to integrate external identity providers.

Wazuh’s current documentation describes SAML-based SSO integrations with providers including Microsoft Entra ID, Okta, Keycloak, authentik, PingOne, and others.

How Authentication Works

At a high level, the authentication flow works like this:

1. A user opens the Wazuh Dashboard.
2. The Dashboard redirects the user to the configured IdP.
3. The user authenticates with the IdP.
4. The IdP returns a SAML response to Wazuh’s Assertion Consumer Service (ACS) endpoint.
5. The Wazuh Indexer validates the assertion, including the configured identity-provider metadata and other SAML parameters.
6. User attributes or backend roles are extracted from the authentication response.
7. Wazuh maps those attributes or backend roles to the appropriate permissions.
8. The user is granted access to the Wazuh Dashboard.

For example, Wazuh’s documented SAML integrations commonly use an ACS endpoint similar to:

https://<WAZUH_DASHBOARD_URL>/_opendistro/_security/saml/acs

and an SP Entity ID such as:

wazuh-saml

The exact values must match between Wazuh and the IdP.

Related Guide: How to Configure Wazuh SSO

A Wazuh SSO login failure can therefore originate at several different layers.

The most common causes include:

• Incorrect Wazuh SSO configuration
• Incorrect IdP configuration
• Incorrect SAML metadata
• Invalid SAML assertions
• Incorrect OIDC parameters where an OIDC-based integration is being used
• Expired or untrusted certificates
• Incorrect ACS, redirect, or callback URLs
• Missing or incorrectly named user and group attributes
• Wazuh SSO role mapping failures
• Clock synchronization problems
• DNS or network connectivity problems
• Wazuh Indexer security configuration errors
• Stale browser sessions or cached authentication data

The most effective way to troubleshoot the problem is to work through the authentication chain systematically rather than changing several settings at once.

Start with the Wazuh Dashboard configuration, then compare its values against the IdP configuration.

Next, inspect SAML metadata and assertions, verify certificates and system time, check role mappings, and finally examine Wazuh Dashboard and Indexer logs.

This approach helps identify the exact layer where authentication is failing.

Authentication Failures vs Authorization Failures

It is also important to distinguish authentication failures from authorization failures.

A user may successfully authenticate with the IdP but still be unable to access Wazuh because the returned backend role or group does not map to an appropriate Wazuh role.

Wazuh’s documentation specifically uses backend roles and Dashboard role mappings to connect IdP-provided roles with Wazuh permissions.

Related Guide: Troubleshooting Wazuh RBAC: Why Your Custom User Roles Aren’t Applying

After making a correction, do not assume the problem is fixed simply because the login page appears.

Restart the affected Wazuh service when required, clear the browser session, perform a fresh SSO login, and verify that the authenticated user receives the expected Wazuh role and access permissions.

Wazuh’s own SSO examples restart wazuh-dashboard after modifying the Dashboard SSO configuration and then test the login through the Dashboard.

What Causes Wazuh SSO Login Errors?

A Wazuh SSO login error usually results from a mismatch between the Wazuh components and the external Identity Provider.

SSO depends on several systems agreeing on URLs, identifiers, certificates, attributes, roles, and authentication protocols.

A single incorrect value can prevent the entire authentication transaction from completing.

Incorrect SSO Configuration

An incorrect Wazuh SSO configuration is one of the first things to check.

The Wazuh Indexer contains the security configuration responsible for processing the SSO authentication request.

The Wazuh Dashboard also needs to be configured to use the appropriate authentication mechanism.

For SAML authentication, parameters such as the IdP metadata location, IdP Entity ID, SP Entity ID, Dashboard URL, roles attribute, and other security settings must be configured consistently.

For example, Wazuh’s documented SAML configurations include parameters such as:

idp:
  metadata_file: '/etc/wazuh-indexer/opensearch-security/wazuh-idp-metadata.xml'
  entity_id: 'wazuh-saml'

sp:
  entity_id: 'wazuh-saml'

kibana_url: https://<WAZUH_DASHBOARD_URL>
roles_key: Roles

The exact configuration depends on the Identity Provider and Wazuh version.

Even a small discrepancy between the IdP and Wazuh can result in an SSO failure.

Incorrect Identity Provider (IdP) Settings

The Identity Provider must be configured with values that correspond exactly to the Wazuh deployment.

Common IdP configuration mistakes include:

• Incorrect Entity ID
• Incorrect ACS URL
• Incorrect Sign-on URL
• Incorrect redirect URL
• Incorrect NameID configuration
• Missing role or group claims
• Incorrect attribute names
• Incorrect certificate
• Incorrect application assignment
• Users not assigned to the SSO application

For example, Microsoft Entra ID’s Wazuh integration uses wazuh-saml as the SAML Identifier and the Wazuh Dashboard ACS endpoint as the Reply URL.

It also uses a Roles claim to provide role information to Wazuh.

If those values differ from the values configured in Wazuh, authentication can fail even though the IdP itself is working correctly.

Incorrect Wazuh Dashboard Configuration

The Wazuh Dashboard is part of the SSO authentication path, so a valid IdP configuration alone is not sufficient.

Check:

/etc/wazuh-dashboard/opensearch_dashboards.yml

For SAML configurations, Wazuh’s documentation shows settings such as:

opensearch_security.auth.multiple_auth_enabled: true
opensearch_security.auth.type: ["basicauth","saml"]

The SAML endpoints may also need to be included in the Dashboard’s XSRF allowlist:

server.xsrf.allowlist:
  - "/_opendistro/_security/saml/acs"
  - "/_opendistro/_security/saml/logout"
  - "/_opendistro/_security/saml/acs/idpinitiated"

These settings are used in Wazuh’s documented SAML integrations.

After changing the Dashboard configuration, restart the service:

sudo systemctl restart wazuh-dashboard

Related Guide: How to Configure Wazuh SAML Authentication

SAML Metadata or Assertion Problems

SAML authentication depends heavily on metadata and assertions.

The Wazuh Indexer needs information about the IdP, including its identity and certificate information.

Wazuh supports specifying IdP metadata using either a metadata URL or a metadata file.

Problems can occur when:

• The metadata file is outdated.
• The metadata URL is inaccessible.
• The IdP certificate has changed.
• The Entity ID does not match.
• The assertion is issued for the wrong audience.
• The assertion is sent to the wrong ACS URL.
• Required attributes are missing.
• The assertion is incorrectly signed.
• The assertion has expired.

For example, Wazuh’s Microsoft Entra ID documentation requires the Identifier, Reply URL, and claims configuration to correspond to the Wazuh SAML configuration.

If the IdP administrator recently changed certificates, endpoints, or SAML application settings, refreshing the metadata and comparing the current IdP configuration against Wazuh is particularly important.

OIDC Configuration Errors

If your Wazuh deployment uses an OIDC-based authentication flow or an intermediary identity platform that exposes OIDC, verify the OIDC-specific parameters rather than assuming the problem is related to SAML.

Typical OIDC problems include:

• Incorrect client ID
• Incorrect client secret
• Incorrect issuer URL
• Incorrect authorization endpoint
• Incorrect token endpoint
• Incorrect redirect URI
• Incorrect scope configuration
• Invalid or expired client credentials
• Incorrect claims
• TLS certificate problems

Do not mix SAML and OIDC parameters when troubleshooting.

The endpoints, tokens, claims, and validation mechanisms are different.

Related Guide: How to Configure Wazuh OIDC

Invalid or Expired Certificates

Certificates are another common source of SSO failures.

A SAML response may be correctly generated by the IdP but rejected by Wazuh because the signing certificate is invalid, expired, missing, or no longer trusted.

Check both sides of the integration:

• IdP signing certificate
• Wazuh trust configuration
• Wazuh Dashboard TLS certificate
• Wazuh Indexer certificates
• Certificate expiration dates
• Certificate chains
• Hostnames covered by certificates

Certificate problems can become particularly confusing after an IdP certificate rotation.

The IdP may already be using the new certificate while Wazuh still has metadata containing the old certificate.

Related Guide: How to Fix Wazuh Certificate Errors

Incorrect Redirect or Callback URLs

SSO endpoints must match exactly.

For SAML, the Assertion Consumer Service URL is particularly important. Wazuh’s documented integrations commonly use:

https://<WAZUH_DASHBOARD_URL>/_opendistro/_security/saml/acs

For example, the Microsoft Entra ID integration uses the Wazuh ACS endpoint as the Reply URL.

A mismatch involving any of the following can break authentication:

http://
https://
hostname
FQDN
IP address
port
path
trailing slash

For example:

https://wazuh.example.com/_opendistro/_security/saml/acs

is not necessarily equivalent to:

https://wazuh.example.com:443/_opendistro/_security/saml/acs/

Use the exact URL expected by the Wazuh configuration and IdP.

Incorrect User or Group Attributes

Successful authentication does not necessarily mean successful authorization.

The IdP must provide the attributes that Wazuh expects.

Depending on the configuration, these can include usernames, groups, roles, or backend roles.

For example, Wazuh’s documented integrations can use a Roles attribute and then map the resulting backend role to a Wazuh role.

A common problem is an attribute-name mismatch:

IdP: Groups
Wazuh expects: Roles

or:

IdP: roles
Wazuh expects: Roles

Depending on the configuration, that difference can prevent the expected role information from being extracted.

SSO Role Mapping Failures

A user can successfully authenticate and still receive insufficient permissions because the returned IdP role or group does not map to a Wazuh role.

Wazuh’s SSO examples demonstrate mapping a backend role such as:

wazuh-admins

to an administrator role in the Wazuh Dashboard.

Check:

1. The user’s IdP group membership.
2. The role or group attribute returned by the IdP.
3. The roles_key configuration.
4. The resulting backend role.
5. The Wazuh role mapping.
6. The permissions assigned to the mapped role.

Related Guides:

• How to Configure Wazuh SSO Role Mapping
• How to Configure Wazuh RBAC

Clock Synchronization Problems

SAML assertions contain time-related conditions.

If the IdP and Wazuh server have significantly different system times, an otherwise valid assertion can be rejected because it appears to be issued too early, too late, or outside its validity period.

Check the system time on the relevant Wazuh hosts:

timedatectl status

Then verify that NTP or another time-synchronization mechanism is active.

For clustered Wazuh deployments, check the time on all relevant nodes rather than only the Dashboard server.

Clock drift is particularly worth investigating when SSO suddenly stops working without any configuration changes.

DNS and Network Connectivity Issues

SSO requires communication between multiple components.

Depending on your architecture, the authentication flow can involve:

Browser
   ↓
Wazuh Dashboard
   ↓
Wazuh Indexer
   ↓
Identity Provider

A DNS failure, firewall rule, proxy problem, or TLS connectivity issue can interrupt this flow.

Check that the Wazuh host can resolve and reach the configured IdP endpoints.

For example:

nslookup <IDP_HOSTNAME>

and:

curl -I https://<IDP_HOSTNAME>

If the Wazuh Dashboard is behind a reverse proxy, verify that the externally visible hostname and protocol match the URLs configured in the IdP.

Related Guide: How to Configure a Wazuh Proxy

Wazuh Indexer Security Configuration Problems

The Wazuh Indexer is an important part of SSO authentication because its security plugin processes authentication and authorization information.

A configuration problem in the Indexer can cause SSO authentication to fail even when the Dashboard and IdP appear correctly configured.

Review:

/etc/wazuh-indexer/opensearch-security/config.yml

Look for errors involving:

• saml_auth_domain
• IdP metadata
• Entity IDs
• kibana_url
• roles_key
• Authentication order
• Certificates
• Security plugin configuration

Wazuh’s documented SAML integrations show the saml_auth_domain configuration under the Indexer’s authc section and require the relevant SAML parameters to match the IdP configuration.

Related Guide: The Ultimate Wazuh Indexer Guide

Browser Session and Cached Authentication Issues

Sometimes the Wazuh configuration is correct but an existing browser session continues using stale authentication data.

This can happen after:

• Changing the IdP configuration
• Rotating certificates
• Changing SSO endpoints
• Changing user roles
• Switching between authentication methods
• Upgrading Wazuh

Test the login using a private/incognito browser window.

If SSO works in the private window but fails in the normal browser session, clear the cookies and site data associated with the Wazuh Dashboard and IdP.

This is also useful for diagnosing an apparent infinite redirect loop.

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

Check the Wazuh SSO Configuration

Before changing individual settings, establish exactly how SSO is configured in your environment.

The goal is to compare the Wazuh configuration against the corresponding IdP application configuration one parameter at a time.

Locate the Wazuh Dashboard SSO Configuration

Start by inspecting the Wazuh Dashboard configuration:

sudo nano /etc/wazuh-dashboard/opensearch_dashboards.yml

Look for authentication-related parameters such as:

opensearch_security.auth.type:
opensearch_security.auth.multiple_auth_enabled:
server.xsrf.allowlist:

The exact configuration depends on the authentication method and Wazuh version.

For SAML integrations, Wazuh’s documentation uses opensearch_security.auth.type with saml and configures the SAML ACS, logout, and IdP-initiated endpoints in the XSRF allowlist.

Verify the Authentication Method

Confirm whether your deployment is actually configured for the authentication protocol you intend to use.

For example:

opensearch_security.auth.type: ["basicauth","saml"]

indicates a SAML authentication configuration alongside basic authentication.

Do not troubleshoot an OIDC client configuration when the Wazuh Dashboard is actually configured for SAML, or vice versa.

Also confirm whether basic authentication remains enabled as a fallback.

This can be useful during troubleshooting because it provides an alternative way to access the Dashboard while SSO is being repaired.

Check SAML Configuration Parameters

If you are using SAML, review the Wazuh Indexer security configuration:

sudo nano /etc/wazuh-indexer/opensearch-security/config.yml

Pay particular attention to:

idp:
  metadata_url:
  entity_id:

sp:
  entity_id:

kibana_url:
roles_key:

Compare every value against the IdP application.

For example, if Wazuh expects:

sp.entity_id = wazuh-saml

the IdP application should use the corresponding SP Entity ID.

Likewise, if Wazuh expects a Roles attribute, make sure the IdP actually sends that attribute in the SAML assertion.

Wazuh’s Microsoft Entra ID, Okta, and other documented integrations demonstrate this type of role-attribute mapping.

Check OIDC Configuration Parameters

For an OIDC-based deployment, verify the complete OIDC configuration rather than focusing only on the client ID.

Check:

Issuer
Client ID
Client secret
Authorization endpoint
Token endpoint
UserInfo endpoint
Redirect URI
Scopes
Claims
TLS configuration

The redirect URI is especially important.

It must correspond exactly to the URI registered with the Identity Provider.

If the IdP reports that the redirect URI is invalid, compare the URL character-for-character with the configured Wazuh endpoint.

Verify IdP URLs

Open the IdP’s application configuration and compare its URLs against Wazuh.

For SAML, verify at minimum:

IdP Entity ID
SP Entity ID
ACS URL
Sign-on URL
Logout URL
Metadata URL

For example, Wazuh’s Keycloak documentation specifies wazuh-saml as the client ID/SP Entity ID and configures Wazuh Dashboard URLs for the relevant SAML endpoints.

Verify Client IDs and Secrets

For OIDC configurations, confirm that the Wazuh configuration contains the client ID registered with the IdP.

If a client secret is required, verify that:

• The secret has not expired.
• The secret was copied correctly.
• The secret belongs to the correct client.
• The client is enabled.
• The client is registered in the correct IdP tenant or realm.

Do not confuse the OIDC client ID with the SAML SP Entity ID.

They serve different purposes in their respective authentication protocols.

Check Redirect and Callback URLs

Compare the configured callback or ACS URL with the URL actually exposed by the Wazuh Dashboard.

This is particularly important when Wazuh is deployed behind:

• Nginx
• HAProxy
• Apache
• A cloud load balancer
• A reverse proxy
• A TLS termination proxy

For example, users may access:

https://wazuh.example.com

while the Dashboard internally sees:

https://wazuh.internal:5601

If the IdP is configured with the internal URL instead of the externally accessible URL, the SSO flow can fail.

Related Guide: Fixing Nginx Upstream Timeouts When Proxying Wazuh Dashboard Traffic

Confirm the Configured Domain and Endpoints

Verify that the hostname users actually use to access Wazuh is consistent throughout the SSO configuration.

Check for differences such as:

wazuh.example.com
wazuh.internal.example.com
10.0.0.25
localhost

Also check whether HTTP has accidentally been configured where HTTPS is required.

A useful practice is to establish one canonical Wazuh Dashboard URL and use it consistently across the reverse proxy, Dashboard configuration, IdP application, SAML ACS configuration, and any redirect or callback settings.

Restart Affected Wazuh Services After Configuration Changes

Configuration changes do not necessarily take effect until the affected service is restarted.

After modifying the Wazuh Dashboard configuration:

sudo systemctl restart wazuh-dashboard

Check its status:

sudo systemctl status wazuh-dashboard

For Indexer security configuration changes, follow the appropriate Wazuh security-administration procedure rather than simply restarting services blindly.

Wazuh’s documented SAML integrations use the security administration tooling to load Indexer security configuration changes and restart the Dashboard after Dashboard configuration changes.

After restarting, perform a fresh login test using a private browser window.

If the login still fails, continue to the next troubleshooting stage by examining the Wazuh Dashboard and Indexer logs.

The objective is to determine whether the failure occurs before the SAML/OIDC request leaves Wazuh, while the IdP is processing authentication, when the assertion/token returns to Wazuh, or during role mapping and authorization.

Check the Identity Provider Configuration

If the Wazuh Dashboard configuration looks correct but users still encounter a Wazuh SSO login error, inspect the Identity Provider (IdP).

The IdP controls the authentication process and supplies Wazuh with the identity information, attributes, groups, and roles required to establish the user’s session.

The exact settings depend on whether you use SAML or OIDC and which provider you have configured, such as Microsoft Entra ID, Okta, Keycloak, or another supported identity platform.

Related Guide: How to Configure Wazuh SSO

A useful troubleshooting technique is to compare the Wazuh configuration and IdP configuration side by side.

Check each URL, identifier, certificate, claim, and role mapping rather than assuming that a setting is correct because the IdP application was previously working.

Verify the Wazuh Application Registration

Start by locating the application registration created specifically for Wazuh in your Identity Provider.

For example, depending on the provider, this may be an enterprise application, SAML application, OIDC client, or application integration.

Verify that:

• The application exists.
• The application is enabled.
• The application is configured for the correct authentication protocol.
• The application points to the correct Wazuh Dashboard.
• The application has the expected users and groups assigned.
• The application’s credentials and certificates are still valid.

If multiple Wazuh environments exist, make sure you are inspecting the registration for the correct environment.

Using the production IdP application while testing a development Wazuh Dashboard can produce confusing authentication failures.

Confirm the Correct SAML or OIDC Application

Organizations sometimes have multiple applications registered with the same IdP.

For example:

Wazuh Production - SAML
Wazuh Development - SAML
Wazuh Production - OIDC
Wazuh Test - OIDC

Make sure Wazuh is configured to communicate with the intended application.

For SAML, compare the Wazuh SP Entity ID and ACS URL against the SAML application’s configuration.

For OIDC, compare the Wazuh client ID and issuer against the OIDC client registration.

Using the wrong application can result in errors such as:

Invalid client
Unknown client
Invalid audience
Invalid issuer
Reply URL mismatch
Redirect URI mismatch

Check the IdP Entity ID or Issuer

For SAML, verify the IdP Entity ID.

The Entity ID uniquely identifies the Identity Provider and is included in the SAML metadata and authentication exchange.

For OIDC, check the issuer instead.

An OIDC issuer typically looks similar to:

https://idp.example.com/realms/security

The issuer configured in Wazuh must correspond to the issuer advertised by the Identity Provider.

A trailing slash or hostname difference can matter depending on how the identity platform validates the issuer:

https://idp.example.com/realms/security

versus:

https://idp.example.com/realms/security/

If the issuer does not match, the returned ID token may be rejected even though the user successfully authenticated with the IdP.

Verify ACS/Redirect URLs

The Assertion Consumer Service (ACS) URL is one of the most important SAML settings.

For Wazuh SAML integrations, the ACS endpoint commonly follows this structure:

https://<WAZUH_DASHBOARD_URL>/_opendistro/_security/saml/acs

The URL registered with the IdP must correspond to the endpoint exposed by Wazuh.

For OIDC, verify the registered redirect URI instead.

Check the entire value:

Scheme
Hostname
Port
Path
Trailing slash

For example, these may be treated as different URLs:

https://wazuh.example.com/callback
https://wazuh.example.com/callback/

A reverse proxy can make this problem harder to identify because the public URL may differ from the internal Dashboard URL.

Related Guide: How to Configure a Wazuh Proxy

Check Client Credentials

If you use OIDC, verify the client ID and client secret.

The client ID must identify the same OIDC application registered with the IdP.

If the client secret is used, check whether it:

• Has expired.
• Was recently regenerated.
• Was copied incorrectly.
• Belongs to another client.
• Is being read correctly by Wazuh.
• Is being used against the correct IdP tenant or realm.

An expired client secret can produce an authentication failure even when every other OIDC parameter is correct.

Do not expose client secrets in screenshots, support tickets, configuration examples, or log files.

Confirm User Assignment

Many Identity Providers require users to be explicitly assigned to an application.

If the Wazuh application is restricted to assigned users, verify that the affected user has access.

For example, check whether the user is:

• Directly assigned to the Wazuh application.
• A member of an assigned group.
• Included through a dynamic group.
• Blocked by an application assignment policy.

A user who is not assigned to the application may be redirected to the IdP successfully but still receive an access-denied error.

This is different from a Wazuh authentication failure: the IdP may be correctly rejecting a user who does not have permission to use the application.

Confirm Group Assignment

If your Wazuh SSO configuration uses groups for authorization, confirm that the user belongs to the expected group.

For example:

Wazuh-Admins
Wazuh-Analysts
Wazuh-Responders
Wazuh-Auditors

Then verify that the IdP actually includes the user’s group membership in the SAML assertion or OIDC token.

A user may be assigned to the Wazuh application but still receive the wrong Wazuh permissions if their group membership is missing from the authentication response.

Related Guide: How to Configure Wazuh SSO Role Mapping

Verify Required Claims and Attributes

SSO authentication depends on the attributes Wazuh receives from the IdP.

For SAML, inspect attributes such as:

NameID
Username
Email
Groups
Roles

For OIDC, inspect claims such as:

sub
email
preferred_username
name
groups
roles

The names must correspond to what Wazuh expects.

For example, if Wazuh is configured to obtain roles from:

Roles

but the IdP sends:

roles

the role mapping may fail.

Likewise, an IdP might send group membership as:

groups

while the Wazuh configuration expects a different attribute.

This can produce a situation where authentication succeeds but authorization fails.

Related Guide: How to Configure Wazuh Field Level Security

Check Whether the IdP Is Blocking Authentication

Finally, check the IdP’s own authentication and audit logs.

Look for events indicating:

• User denied access.
• Application assignment failure.
• Conditional access failure.
• MFA failure.
• Invalid credentials.
• Disabled account.
• Suspicious-login detection.
• IP-based restrictions.
• Device compliance failure.
• Expired credentials.
• Application policy restrictions.

This distinction is important.

If the IdP never generates a successful SAML assertion or OIDC authorization response, the problem is likely on the IdP side.

If the IdP successfully authenticates the user but Wazuh rejects the returned assertion or token, focus on the Wazuh Dashboard, Wazuh Indexer, certificates, claims, and role mappings.

Fix Wazuh SAML Login Errors

SAML login failures are commonly caused by mismatched metadata, Entity IDs, ACS URLs, claims, certificates, or assertion-validation parameters.

The most effective approach is to trace the SAML transaction from the initial authentication request through the assertion returned by the Identity Provider.

A typical flow looks like:

User
  ↓
Wazuh Dashboard
  ↓
Identity Provider
  ↓
SAML Authentication
  ↓
SAML Assertion
  ↓
Wazuh Dashboard / Indexer
  ↓
Role Mapping
  ↓
Wazuh Session

If the user reaches the IdP but receives an error after authentication, concentrate on the assertion and its validation.

Verify SAML Metadata

SAML metadata contains information Wazuh needs to communicate with the IdP, including the IdP’s Entity ID and certificate information.

Depending on the configuration, Wazuh can use metadata supplied through a URL or a local metadata file.

For a local metadata file, verify that the configured path exists:

sudo ls -l /etc/wazuh-indexer/opensearch-security/

If your configuration references:

wazuh-idp-metadata.xml

inspect the file:

sudo cat /etc/wazuh-indexer/opensearch-security/wazuh-idp-metadata.xml

Check whether the metadata is current.

This becomes particularly important after:

• IdP certificate rotation.
• IdP hostname changes.
• SAML application changes.
• Identity-provider migrations.
• Changes to SAML signing certificates.

If the IdP has issued new metadata, update the Wazuh configuration according to the provider’s documentation.

Check the IdP Entity ID

Compare the IdP Entity ID in the Wazuh configuration with the Entity ID contained in the IdP metadata.

For example:

idp:
  entity_id: "https://idp.example.com/entity"

Do not assume that the IdP’s login URL is its Entity ID. They are separate configuration values.

If Wazuh expects one Entity ID while the SAML response identifies another provider, the authentication response can be rejected.

Verify the Service Provider Entity ID

The Service Provider Entity ID identifies Wazuh to the Identity Provider.

A Wazuh SAML configuration may contain:

sp:
  entity_id: "wazuh-saml"

The corresponding SAML application must use the same value as its Identifier, Audience, or Entity ID, depending on the terminology used by the IdP.

For example:

Wazuh:
wazuh-saml

IdP:
Identifier = wazuh-saml

If the IdP sends an assertion intended for a different audience, Wazuh may reject it.

Related Guide: How to Configure Wazuh SAML Authentication

Check the Assertion Consumer Service URL

The ACS URL tells the IdP where to send the SAML response.

For Wazuh, verify the configured endpoint:

https://<WAZUH_DASHBOARD_URL>/_opendistro/_security/saml/acs

Compare it against the Reply URL or ACS URL configured in the IdP.

Check for:

• Wrong hostname.
• Wrong protocol.
• Wrong port.
• Incorrect path.
• Missing path components.
• Unexpected trailing slash.
• Internal hostname instead of public hostname.

If Wazuh is behind a reverse proxy, make sure the IdP uses the public Dashboard URL.

Verify NameID Configuration

The NameID identifies the authenticated subject in the SAML assertion.

Check what the IdP sends and what Wazuh expects.

Common NameID formats include:

emailAddress
persistent
transient
unspecified

The exact format required depends on the integration.

If the IdP has recently changed the NameID format from an email address to an opaque identifier, for example, an existing Wazuh configuration may no longer behave as expected.

Also verify that the NameID corresponds to a valid user identity.

Check SAML Claims and Attributes

Inspect the SAML response and verify that required attributes are present.

Depending on the configuration, you may need attributes such as:

Username
Email
Groups
Roles

For Wazuh role mapping, the roles attribute is particularly important.

For example:

Roles = wazuh-admins

may be used to map the user to an administrative Wazuh role.

If the assertion instead contains:

Groups = wazuh-admins

but Wazuh is configured to read Roles, the user may authenticate without receiving the expected permissions.

Related Guide: How to Configure Wazuh RBAC

Validate SAML Assertions

A SAML assertion contains multiple values that must pass validation.

Check:

• Issuer.
• Audience.
• Subject.
• NameID.
• Recipient.
• Destination.
• Conditions.
• NotBefore.
• NotOnOrAfter.
• Signature.
• Signing certificate.
• Attribute statements.

An assertion can be correctly signed and still be rejected if its audience or destination is wrong.

Likewise, an assertion can contain the expected roles but still fail because its validity period has expired.

When diagnosing a SAML problem, use a SAML inspection tool or your IdP’s diagnostic tooling to examine the returned assertion.

Do not paste production SAML responses containing personal information into public websites or support forums.

Check Certificate Configuration

Verify the certificate used to sign the SAML assertion.

Check:

Certificate validity
Certificate expiration
Certificate chain
Certificate fingerprint
Certificate issuer
Metadata certificate
Configured Wazuh certificate

If the IdP recently rotated its signing certificate, compare the certificate in the current IdP metadata with the certificate Wazuh is using.

A mismatch can produce signature-validation errors even though the user’s credentials are correct.

Related Guide: How to Fix Wazuh Certificate Errors

Fix Invalid or Expired Signing Certificates

First determine whether the IdP is signing the assertion with the certificate Wazuh trusts.

If the IdP has replaced an expired certificate, obtain the current IdP metadata and update Wazuh’s SAML configuration as required.

Do not simply disable certificate validation to make SSO work. Certificate validation is a security control that prevents an attacker from successfully impersonating the Identity Provider.

After updating the certificate or metadata, reload the affected configuration using the appropriate Wazuh procedure and restart the Dashboard if required.

Then test with a fresh browser session.

Troubleshoot SAML Signature Validation Errors

Signature validation errors commonly indicate that Wazuh cannot verify the cryptographic signature on the SAML response or assertion.

Potential causes include:

• Wrong IdP signing certificate.
• Expired certificate.
• Rotated certificate not yet imported.
• Corrupted metadata.
• Incorrect metadata file.
• Assertion signed with an unexpected certificate.
• Incorrect certificate chain.
• Configuration pointing to the wrong IdP.
• SAML response modified by an intermediary.

Start by checking the Wazuh Indexer and Dashboard logs around the exact time of the failed login.

Then compare the signing certificate reported by the IdP with the certificate contained in the metadata currently used by Wazuh.

Do not regenerate Wazuh TLS certificates unnecessarily.

The certificate used for the Dashboard’s HTTPS connection and the IdP’s SAML signing certificate serve different purposes.

Fix Wazuh OIDC Login Errors

OIDC authentication uses a different protocol flow from SAML.

Instead of validating a SAML assertion, Wazuh’s OIDC integration relies on OpenID Connect endpoints, client credentials, tokens, and claims.

A simplified OIDC flow looks like:

User
  ↓
Wazuh Dashboard
  ↓
Authorization Endpoint
  ↓
Identity Provider
  ↓
Authorization Code
  ↓
Token Endpoint
  ↓
ID Token / Access Token
  ↓
Wazuh
  ↓
Claims and Role Mapping

An error anywhere in this sequence can produce a Wazuh SSO login failure.

Related Guide: How to Configure Wazuh OIDC

Verify the OIDC Issuer

The issuer identifies the Identity Provider responsible for issuing the OIDC tokens.

Verify that the configured issuer exactly matches the issuer advertised by the IdP’s OpenID Connect discovery document.

A typical discovery endpoint follows this pattern:

https://<IDP_HOST>/.well-known/openid-configuration

For a realm-based provider such as Keycloak, the URL may contain the realm:

https://<IDP_HOST>/realms/<REALM>

Check for:

• Wrong hostname.
• Wrong realm.
• Wrong tenant.
• HTTP instead of HTTPS.
• Incorrect path.
• Trailing-slash differences.

An issuer mismatch can cause Wazuh to reject an otherwise valid ID token.

Check the Authorization Endpoint

The authorization endpoint is where the user’s browser is redirected to authenticate.

Verify that the configured endpoint corresponds to the OIDC provider’s discovery metadata.

For example:

https://idp.example.com/oauth2/authorize

The exact endpoint varies between providers.

If the authorization endpoint is incorrect, the user may receive a 404 response, an IdP error, or a redirect loop before authentication completes.

Check the Token Endpoint

After the user authenticates, the authorization code is exchanged for tokens through the token endpoint.

Verify that the configured token endpoint is correct and reachable from the Wazuh environment.

A wrong token endpoint can produce errors after the user successfully enters their credentials, making it appear as though the login succeeded before suddenly failing.

Check:

Token endpoint URL
TLS certificate
DNS resolution
Network connectivity
Client authentication
Client ID
Client secret

Verify the Client ID

Confirm that the OIDC client ID configured for Wazuh matches the client registered with the IdP.

For example:

Wazuh:
client_id = wazuh-dashboard

IdP:
Client ID = wazuh-dashboard

If Wazuh is using a different client ID, the IdP may return:

invalid_client

or:

unauthorized_client

Make sure you are testing against the correct IdP tenant, realm, or environment.

Verify the Client Secret

If the OIDC client uses a client secret, verify that it is still valid.

Common causes include:

• Secret expiration.
• Secret rotation.
• Incorrect secret value.
• Secret copied from another environment.
• Wrong client.
• Disabled client authentication.

If the IdP reports invalid_client, inspect the client credentials before changing unrelated OIDC parameters.

Never place production client secrets in publicly accessible configuration examples.

Check the Redirect URI

The redirect URI must be registered with the Identity Provider and must match the URI used during the OIDC authorization flow.

Compare:

Wazuh configured redirect URI

against:

IdP registered redirect URI

Check the complete URI, including:

Scheme
Hostname
Port
Path
Trailing slash

A reverse proxy can also introduce a mismatch if Wazuh internally uses one hostname while users access the Dashboard through another.

Verify Scopes Such as openid, profile, and email

OIDC uses scopes to determine which information is requested from the Identity Provider.

At minimum, the openid scope is fundamental to an OpenID Connect authentication request.

Depending on the integration, additional scopes may include:

openid
profile
email

The resulting token or UserInfo response should contain the claims required by the Wazuh authentication configuration.

For example:

openid → establishes the OpenID Connect authentication context
profile → requests profile information
email → requests email-related identity information

If a required scope is missing, the expected claim may not be returned.

Check ID Token Claims

Inspect the claims contained in the ID token and compare them with what Wazuh expects.

Common OIDC claims include:

iss
sub
aud
exp
iat
email
name
preferred_username
groups
roles

The most important claims for troubleshooting include:

• iss — verifies the token issuer.
• aud — identifies the intended audience.
• sub — identifies the authenticated subject.
• exp — determines when the token expires.
• iat — indicates when the token was issued.

Group and role claims may also be required for Wazuh authorization.

A token can therefore be validly signed but still be rejected because the issuer or audience is incorrect.

Troubleshoot Issuer and Audience Mismatches

Two particularly common OIDC validation failures involve the iss and aud claims.

The iss claim must correspond to the configured OIDC issuer.

For example:

{
  "iss": "https://idp.example.com/realms/security"
}

The aud claim must identify the intended client.

For example:

{
  "aud": "wazuh-dashboard"
}

If Wazuh expects:

wazuh-dashboard

but the token contains:

another-application

the token may be rejected.

Similarly, a token issued by:

https://idp.example.com/realms/security

should not be accepted as though it were issued by an unrelated realm or tenant.

When troubleshooting these errors, compare the actual token claims with the OIDC client configuration rather than changing the issuer or audience values blindly.

Troubleshoot Invalid Client Errors

An invalid_client error usually points toward the OIDC client configuration rather than the user’s password.

Check:

1. Client ID.
2. Client secret.
3. Client authentication method.
4. Client status.
5. Token endpoint.
6. IdP tenant or realm.
7. Secret expiration.
8. Application permissions.

For example, if the Wazuh configuration uses:

Client ID: wazuh-dashboard

but the client registered in the IdP is:

wazuh-prod-dashboard

the IdP can reject the token request.

Likewise, an expired client secret can produce the same general class of failure.

After correcting the client configuration, perform a fresh authentication attempt rather than relying on an existing browser session.

Related Guide: How to Configure Wazuh OIDC

Once the OIDC client successfully authenticates, continue troubleshooting any remaining authorization problems by examining the returned claims and Wazuh SSO role mappings.

Related Guide: How to Configure Wazuh SSO Role Mapping

Fix Wazuh SSO Role Mapping Errors

A Wazuh SSO login can fail even after the user successfully authenticates with the Identity Provider.

This happens because authentication and authorization are separate processes.

Authentication answers:

Who is this user?

Authorization answers:

What is this user allowed to do?

A successful SAML or OIDC authentication only proves that the Identity Provider has authenticated the user.

Wazuh must then map the identity, group, or role information returned by the IdP to an appropriate Wazuh role.

For example:

IdP
  ↓
User authenticates successfully
  ↓
SAML assertion / OIDC token
  ↓
Groups or roles extracted
  ↓
Wazuh role mapping
  ↓
Wazuh security role
  ↓
Permissions

If the role-mapping stage fails, the user may reach the Wazuh Dashboard but see missing permissions, inaccessible tenants, 403 Forbidden responses, or an interface that does not contain the expected administrative functions.

Related Guide: Mastering Wazuh Security: The Complete Access Control Guide

Verify User-to-Role Mappings

Start by determining exactly which identity information the IdP sends to Wazuh.

For example, an IdP might return:

User: alice@example.com
Group: Wazuh-Analysts

The Wazuh configuration must then map that group or backend role to an appropriate Wazuh security role.

A conceptual mapping might look like:

Wazuh-Admins     → all_access
Wazuh-Analysts   → wazuh_analyst
Wazuh-Auditors   → wazuh_auditor

Verify that:

1. The user belongs to the expected IdP group.
2. The group is included in the SSO response.
3. Wazuh extracts the group or role attribute.
4. The extracted value matches the configured backend role.
5. The backend role maps to the intended Wazuh role.
6. The Wazuh role contains the required permissions.

Do not troubleshoot the user’s permissions by immediately assigning administrator access.

First identify where the mapping chain is breaking.

Check SAML Group Attributes

For SAML authentication, inspect the attributes returned in the SAML assertion.

Depending on the IdP, group information may be represented as:

Groups
group
Role
Roles
http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

Your Wazuh configuration needs to reference the attribute that the IdP actually sends.

For example, if Wazuh expects:

roles_key: Roles

but the IdP sends:

Groups = Wazuh-Admins

Wazuh may not extract the expected backend role.

This can produce a particularly confusing symptom: the user authenticates successfully but receives the wrong permissions.

Inspect the SAML assertion and compare the attribute name and value against the Wazuh configuration.

Related Guide: How to Configure Wazuh SSO Role Mapping

Check OIDC Group Claims

OIDC providers typically place group or role information in token claims.

For example:

{
  "sub": "123456",
  "email": "alice@example.com",
  "groups": [
    "Wazuh-Analysts"
  ]
}

Another IdP might return:

{
  "roles": [
    "Wazuh-Admins"
  ]
}

The important point is that there is no universal claim name for group or role information.

Check the actual token claims and determine whether the provider is sending:

groups
roles
group
realm_access.roles
resource_access

or another provider-specific claim.

Then make sure the Wazuh configuration and role-mapping configuration use the corresponding value.

Verify Wazuh Role Names

Check that the Wazuh roles referenced by your mapping actually exist.

A mapping that references a misspelled or nonexistent role cannot provide the intended permissions.

For example:

Wazuh-Admins → wazuh_admin

may not work if the actual configured Wazuh role is:

all_access

Use the Wazuh security configuration and role-management interface to verify the exact role names.

Pay attention to:

• Spelling.
• Capitalization.
• Underscores.
• Hyphens.
• Custom role names.
• Backend roles versus security roles.

Do not assume that an IdP group name and a Wazuh role name are interchangeable.

Check Administrator Role Assignments

If the affected user is supposed to be a Wazuh administrator, verify that the administrator role is actually being assigned.

A typical administrator mapping conceptually looks like:

IdP group
    ↓
Wazuh-Admins
    ↓
Wazuh administrator role
    ↓
Administrative permissions

If the user authenticates but does not receive administrator privileges, determine whether the problem occurs at the group, backend-role, or Wazuh-role level.

Avoid giving every SSO user the highest-privilege role as a workaround.

Doing so defeats the purpose of role-based access control and can create unnecessary security exposure.

Related Guide: How to Configure Wazuh RBAC

Troubleshoot Users Authenticating Successfully but Receiving Incorrect Permissions

This is one of the most useful distinctions when diagnosing Wazuh SSO.

Suppose a user can successfully log in but receives an analyst-level interface instead of administrator access.

The authentication process is probably working:

User → IdP → SAML/OIDC → Wazuh
                         ✓

The failure is more likely here:

SSO attributes
      ↓
Backend role
      ↓
Wazuh security role
      ↓
Permissions

Check the user’s actual IdP group membership first.

Then determine what group or role Wazuh receives.

Finally, verify which Wazuh role is assigned to that backend role.

A useful troubleshooting table is:

This makes role-mapping problems much easier to isolate.

Verify Multi-Tenancy and Role Configuration

Multi-tenancy can add another authorization layer.

A user may have a valid Wazuh role but still be unable to access the expected tenant or data.

Check:

• The user’s assigned role.
• Backend roles.
• Tenant permissions.
• Default tenant.
• Tenant mappings.
• Index permissions.
• Dashboard permissions.

This is particularly important in environments where analysts, administrators, responders, and auditors are intentionally separated.

Related Guide: How to Set Up Wazuh Multi-Tenancy

If SSO authentication succeeds but the user receives a tenant-access error, investigate the multi-tenancy configuration before modifying the SSO authentication settings.

Use the Dedicated Wazuh SSO Role-Mapping Guide

For a deeper walkthrough of backend roles, SAML groups, OIDC claims, role mappings, administrator assignments, and multi-tenancy, continue with the dedicated guide:

Related Guide: How to Configure Wazuh SSO Role Mapping

That guide should be used when the core SSO authentication flow is working but users continue receiving incorrect permissions.

Fix Wazuh SSO Certificate Errors

Certificates are another major source of Wazuh SSO login failures.

An SSO authentication flow can depend on several different certificates, including:

Wazuh Dashboard TLS certificate
Wazuh Indexer certificates
IdP SAML signing certificate
Certificate Authority certificates
Reverse-proxy certificates

Do not assume that every certificate involved in the environment serves the same purpose.

For SAML, the IdP signing certificate is particularly important because Wazuh uses it to validate the authenticity of the SAML response or assertion.

Identify Certificate-Related Login Errors

Certificate-related errors can appear in the browser, Wazuh logs, or IdP logs.

Look for messages containing terms such as:

certificate
SSL
TLS
x509
PKIX
trust
signature
certificate verify failed
unable to get local issuer certificate
certificate expired
unknown CA

A browser warning about the Wazuh Dashboard certificate is different from a SAML signature-validation error.

For example:

Browser → Wazuh HTTPS certificate problem

is different from:

Wazuh → IdP SAML signing certificate problem

Identify which certificate is actually failing before replacing anything.

Related Guide: How to Fix Wazuh Certificate Errors

Check Certificate Expiration

Check the expiration date of the relevant certificates.

For a PEM-encoded certificate:

openssl x509 -in /path/to/certificate.pem -noout -dates

You can also inspect the subject and issuer:

openssl x509 -in /path/to/certificate.pem -noout -subject -issuer -dates

Look for:

notBefore
notAfter

If the certificate’s notAfter date has passed, it is expired.

Certificate expiration should also be checked on the Identity Provider side, particularly for SAML signing certificates.

An expired certificate can cause authentication to stop suddenly even though no Wazuh configuration was changed.

Verify Certificate Chains

A certificate can be valid by itself but still fail validation if the complete certificate chain is not trusted.

Check:

Server certificate
      ↓
Intermediate CA
      ↓
Root CA

Make sure the relevant intermediate and root certificates are available to the component performing validation.

For HTTPS connectivity, you can inspect a remote certificate with:

openssl s_client -connect <HOST>:443 -servername <HOST>

Look for verification-related errors in the output.

For production systems, make sure the certificate chain is complete and correctly configured rather than bypassing TLS verification.

Confirm Trusted Certificate Authorities

Verify that Wazuh trusts the Certificate Authority that issued the relevant certificate.

This matters particularly when your organization uses:

• Internal CAs.
• Private PKI.
• Enterprise proxies.
• Custom intermediate CAs.
• Self-managed identity infrastructure.

A certificate signed by an internal CA may work correctly in employee browsers while still failing from the Wazuh server if the server does not trust that CA.

Do not solve the problem by disabling certificate verification.

Properly install or reference the required CA certificate according to the Wazuh component and authentication architecture.

Check Certificate Paths and Permissions

If Wazuh references certificates from local files, verify that the files exist and are readable by the appropriate service.

For example:

sudo ls -l /path/to/certificate.pem

Check:

File exists
Correct owner
Correct group
Appropriate permissions
Correct path
Correct certificate

A certificate can therefore be perfectly valid but unusable because the Wazuh service cannot read it.

Avoid making private keys world-readable as a quick fix.

Replace Expired Certificates

If a certificate has expired, obtain a replacement from the appropriate Certificate Authority or Identity Provider.

For an IdP SAML signing certificate, obtain the current IdP metadata or signing certificate through the provider’s supported process.

For Wazuh TLS certificates, follow the certificate replacement procedure appropriate to your Wazuh deployment.

Before replacing a production certificate:

1. Back up the current configuration.
2. Confirm which component uses the certificate.
3. Verify the new certificate’s expiration date.
4. Verify the certificate chain.
5. Confirm the certificate matches the expected hostname where applicable.
6. Replace the certificate.
7. Verify ownership and permissions.
8. Reload or restart the affected service.

Verify Certificate Configuration After Replacement

After replacing a certificate, verify that Wazuh is actually using the new certificate.

Check:

openssl x509 -in /path/to/new-certificate.pem -noout -subject -issuer -dates

For a network service, verify what is presented over the connection:

openssl s_client -connect <WAZUH_DASHBOARD_HOST>:443 \
  -servername <WAZUH_DASHBOARD_HOST>

Compare the presented certificate against the certificate you intended to deploy.

For SAML, verify that the certificate contained in the current IdP metadata corresponds to the certificate currently used to sign the assertion.

Restart the Required Wazuh Services

After changing certificates, restart or reload the service that consumes the certificate according to the Wazuh configuration.

For the Wazuh Dashboard:

sudo systemctl restart wazuh-dashboard

Then verify:

sudo systemctl status wazuh-dashboard

If the Indexer configuration or certificates were changed, follow the appropriate Wazuh Indexer procedure.

Do not restart every Wazuh component automatically.

Identify which component consumes the changed certificate and restart only the services necessary for the configuration to take effect.

Afterward, perform a fresh SSO login and check the logs for any remaining TLS, certificate, or signature-validation errors.

Check Wazuh Logs for SSO Errors

When configuration checks do not immediately identify the problem, Wazuh logs are usually the next place to investigate.

Logs can tell you whether the failure occurs during:

Authentication request
       ↓
IdP communication
       ↓
SAML/OIDC response processing
       ↓
Certificate validation
       ↓
Token/assertion validation
       ↓
Role extraction
       ↓
Authorization

The key is to correlate the log entries with the exact time of a failed login attempt.

Check Wazuh Dashboard Logs

Start with the Wazuh Dashboard because it handles the user’s web authentication flow.

Check the service status:

sudo systemctl status wazuh-dashboard

Then inspect recent logs:

sudo journalctl -u wazuh-dashboard --since "15 minutes ago"

For a live troubleshooting session:

sudo journalctl -u wazuh-dashboard -f

Perform a new SSO login while watching the output.

Look for messages related to:

SAML
OIDC
authentication
authorization
redirect
callback
certificate
TLS
role
backend role

The exact error message is usually more useful than the browser’s generic SSO error.

Check Wazuh Indexer Logs

The Wazuh Indexer is especially important for SAML authentication because the OpenSearch security layer participates in authentication and authorization.

Check:

sudo systemctl status wazuh-indexer

Then review recent service messages:

sudo journalctl -u wazuh-indexer --since "15 minutes ago"

Depending on the deployment, additional Indexer logs may be located under:

/var/log/wazuh-indexer/

Search for authentication-related messages:

sudo grep -RiE "saml|oidc|auth|certificate|ssl|tls|role" /var/log/wazuh-indexer/

Look for errors involving:

SAML assertion
Signature validation
Entity ID
Roles
Backend roles
Authentication domain
Certificate
SSL
TLS

Check Wazuh API Logs Where Applicable

The Wazuh API is not necessarily the source of every SSO problem, but API logs can help when the authentication flow involves API authorization or when the Dashboard is making API requests after authentication.

Check the API service:

sudo systemctl status wazuh-manager

Then inspect relevant Manager logs:

sudo journalctl -u wazuh-manager --since "15 minutes ago"

Depending on the issue, also inspect the Wazuh API logs available in the Manager’s logging configuration.

If the user can log into the Dashboard but API requests return authorization errors, this may indicate a role or permission problem rather than an SSO authentication failure.

Identify Authentication-Related Messages

Search the logs for authentication keywords:

sudo grep -RiE "authentication|authenticate|login|auth" /var/log/wazuh-dashboard/ /var/log/wazuh-indexer/ 2>/dev/null

Look for messages indicating:

Authentication failed
Authentication succeeded
Invalid credentials
Unauthorized
Forbidden
Invalid token
Invalid assertion

The distinction between 401 and 403 can also be useful.

Generally:

401 → authentication problem
403 → authorization or access-control problem

The exact behavior depends on the component, so use the surrounding log messages to confirm the cause rather than relying on the status code alone.

Identify SAML Errors

Search specifically for SAML-related messages:

sudo grep -RiE "saml|assertion|entity.?id|signature|acs" \
  /var/log/wazuh-dashboard/ \
  /var/log/wazuh-indexer/ 2>/dev/null

Potential clues include:

Invalid SAML response
Invalid assertion
Invalid audience
Invalid destination
Invalid issuer
Signature validation failed
Unknown IdP
Expired assertion
Missing attribute

These messages can point directly toward the corresponding SAML configuration parameter.

For example:

Invalid audience

suggests checking the SP Entity ID or audience configuration.

Whereas:

Signature validation failed

suggests checking the IdP signing certificate and SAML metadata.

Identify OIDC Errors

For OIDC problems, search for:

sudo grep -RiE "oidc|openid|oauth|token|issuer|client|redirect" \
  /var/log/wazuh-dashboard/ \
  /var/log/wazuh-indexer/ 2>/dev/null

Look for errors such as:

invalid_client
invalid_grant
invalid_token
invalid_issuer
invalid_audience
redirect_uri_mismatch
unauthorized_client

These messages help narrow the problem.

For example:

invalid_client

usually warrants checking the client ID and secret.

redirect_uri_mismatch

points toward the registered callback URL.

invalid_issuer

points toward the OIDC issuer configuration.

Identify TLS and Certificate Errors

Search for certificate-related messages:

sudo grep -RiE "certificate|x509|SSL|TLS|PKIX|trust" \
  /var/log/wazuh-dashboard/ \
  /var/log/wazuh-indexer/ 2>/dev/null

Common indicators include:

certificate expired
unable to verify certificate
unknown CA
certificate verify failed
PKIX path building failed
SSL handshake failed

Use the timestamp to correlate the certificate error with the exact failed login.

Identify Authorization and Role-Mapping Errors

If authentication succeeds but the user receives incorrect permissions, search for role-related messages:

sudo grep -RiE "role|backend.?role|permission|authorization|tenant" \
  /var/log/wazuh-dashboard/ \
  /var/log/wazuh-indexer/ 2>/dev/null

Look for evidence that:

User authenticated
      ↓
Backend role extracted
      ↓
Role mapping performed
      ↓
Wazuh role assigned

If the log shows successful authentication but no expected backend role, inspect the SAML attributes or OIDC claims.

However, if the backend role is present but the wrong Wazuh role is assigned, inspect the role mapping.

If the correct role is assigned but access remains denied, inspect the role’s permissions and multi-tenancy configuration.

Use Logs to Correlate Failed Login Attempts

The most effective troubleshooting method is to reproduce the problem while actively monitoring the logs.

Open one terminal for the Dashboard:

sudo journalctl -u wazuh-dashboard -f

Open another for the Indexer:

sudo journalctl -u wazuh-indexer -f

Then:

1. Open a private browser window.
2. Navigate to the Wazuh Dashboard.
3. Start the SSO login.
4. Authenticate through the IdP.
5. Wait for the failure.
6. Immediately record the timestamp.
7. Review the corresponding log entries.

For example:

01:24:31  User opens Wazuh Dashboard
01:24:32  Dashboard redirects to IdP
01:24:38  User authenticates successfully
01:24:39  SAML response returned
01:24:39  Signature validation fails

This immediately narrows the investigation to SAML assertion validation rather than user credentials or the initial Dashboard configuration.

A similar sequence for OIDC might show:

01:30:12  Authorization request
01:30:15  Authorization code received
01:30:15  Token request sent
01:30:15  invalid_client

That points toward the OIDC client ID, client secret, or client authentication configuration.

Related Guide: Wazuh SSO Role Mapping Guide

The objective is to identify the first meaningful error in the authentication chain.

Later errors are often consequences of the original failure, so fixing the earliest relevant error is usually more effective than chasing every message generated during the failed login.

Verify Time Synchronization

Accurate system time is an important requirement for reliable SSO authentication.

SAML assertions and OIDC tokens contain timestamps that allow the receiving system to determine whether an authentication response is currently valid.

If the Wazuh server and Identity Provider have significantly different system times, Wazuh may reject an otherwise valid authentication response.

For example, a SAML assertion can contain validity conditions similar to:

NotBefore:     01:10:00
NotOnOrAfter:  01:15:00

If the Wazuh server’s clock is several minutes behind or ahead of the IdP, the assertion may appear to be invalid.

This can produce errors associated with:

Assertion expired
Assertion not yet valid
Invalid authentication response
Invalid token
Clock skew

Time synchronization is therefore one of the first infrastructure checks to perform when SSO suddenly stops working.

Explain Why SSO Depends on Accurate System Time

SAML and OIDC use timestamps to prevent authentication messages from being reused indefinitely.

For SAML, an assertion can contain conditions defining when it becomes valid and when it expires.

For OIDC, tokens commonly contain claims such as:

iat
exp
nbf

where applicable.

These timestamps help prevent replay attacks and ensure that authentication responses are processed within their intended validity period.

If the IdP says:

Current time = 12:00

but Wazuh believes:

Current time = 12:08

a recently issued assertion could appear to Wazuh as already expired.

Likewise, if Wazuh’s clock is significantly behind the IdP, an assertion may appear to have been issued in the future.

Check the Wazuh Server Time

Start by checking the system time on the Wazuh Dashboard server:

date

Then check the complete time-synchronization status:

timedatectl status

A healthy system should show the correct date, time zone, and synchronization status.

For example:

System clock synchronized: yes
NTP service: active

The exact output depends on the Linux distribution and time-management service.

If Wazuh is deployed across multiple nodes, check the time on each relevant node:

Wazuh Dashboard
Wazuh Indexer
Wazuh Manager

Do not assume that correcting the Dashboard server’s clock automatically fixes every node.

Related Guide: The Complete Wazuh Cluster Architecture Guide

Check the Identity Provider Time

The Identity Provider’s system time must also be accurate.

This can be more difficult to inspect when using a cloud-based provider such as Microsoft Entra ID or another hosted identity service because you typically do not manage the provider’s underlying servers.

In that situation, verify that:

• The IdP is operational.
• The provider has not reported authentication or clock-related incidents.
• Your SAML/OIDC application is not using a custom intermediary whose clock is incorrect.
• Any self-hosted IdP infrastructure is synchronized.

For self-hosted providers such as Keycloak, check the host running the IdP:

date

and:

timedatectl status

If the IdP runs in a container or virtual machine, also verify the underlying host’s time synchronization.

Verify NTP Synchronization

Network Time Protocol (NTP) keeps system clocks synchronized with reliable time sources.

Check whether the system is synchronized:

timedatectl show-timesync --all

On systems using chrony, check:

chronyc tracking

and:

chronyc sources -v

You want to see evidence that the system is communicating with a valid time source and maintaining a small clock offset.

If NTP is not active, enable the time-synchronization service appropriate to your operating system.

For example, on systems using chronyd:

sudo systemctl status chronyd

On systems using systemd-timesyncd:

sudo systemctl status systemd-timesyncd

Do not run multiple competing time-synchronization services unless your operating system specifically supports that configuration.

Troubleshoot SAML Assertion Expiration

If the Wazuh logs indicate that a SAML assertion has expired or is not yet valid, check the timestamps in the assertion.

Relevant SAML conditions can include:

NotBefore
NotOnOrAfter

Compare those values with the actual Wazuh server time.

For example:

Assertion:
NotOnOrAfter = 14:30:00

Wazuh server:
Current time = 14:35:12

The assertion is already outside its validity period from Wazuh’s perspective.

If the IdP and Wazuh clocks differ by several minutes, correct the underlying time synchronization rather than attempting to permanently work around the assertion’s validity period.

Also check whether an intermediate component is modifying or delaying the authentication request.

Fix Clock Drift Between Systems

If the Wazuh server has incorrect time, restore synchronization rather than manually changing the clock as a permanent solution.

After correcting NTP, verify:

timedatectl status

Then compare the time across your Wazuh nodes.

For example:

Wazuh Dashboard:  14:42:01
Wazuh Indexer:    14:42:02
Wazuh Manager:    14:42:01
IdP:              14:42:01

A small difference is generally expected in distributed systems, but significant clock drift should be investigated.

If you operate a multi-node Wazuh cluster, consistent time synchronization is important beyond SSO because clock differences can also complicate cluster operations, log correlation, certificates, and security event timelines.

Related Guide: Fixing Wazuh Cluster Desync Caused by Master-Worker Time Drift

After correcting the time synchronization issue, retry SSO using a fresh browser session.

Troubleshoot Wazuh SSO Network and DNS Problems

SSO authentication depends on network connectivity between the Wazuh environment, the Identity Provider, and any reverse proxies or security appliances in between.

A configuration can be technically correct but still fail if Wazuh cannot resolve or reach the required IdP endpoints.

A typical authentication path may look like:

User
  ↓
Reverse Proxy
  ↓
Wazuh Dashboard
  ↓
Wazuh Indexer
  ↓
Identity Provider

The exact path varies by deployment, but every connection in the authentication chain needs to work correctly.

Verify DNS Resolution

Start by checking that the Wazuh server can resolve the IdP hostname.

For example:

nslookup idp.example.com

or:

dig idp.example.com

If those utilities are unavailable, try:

getent hosts idp.example.com

A successful result should return the expected IP address.

If DNS resolution fails, investigate:

• /etc/resolv.conf
• Internal DNS servers
• DNS forwarding
• Split-horizon DNS
• Firewall rules
• Search domains
• DNSSEC configuration where applicable
• Container DNS configuration

If the Wazuh Dashboard is running inside a container, Kubernetes pod, or other isolated environment, test DNS from that environment, not only from your workstation.

Related Guide: How to Monitor Kubernetes Using Wazuh

Test Connectivity to the IdP

Once DNS works, test basic network connectivity.

For HTTPS-based IdPs:

curl -I https://idp.example.com

If the IdP returns a redirect or HTTP error, that can still demonstrate that network connectivity exists.

For more detailed testing:

curl -v https://idp.example.com

Look for:

DNS resolution
TCP connection
TLS handshake
HTTP response
Certificate verification

The goal is not necessarily to receive a successful application response.

The test is primarily determining whether the Wazuh host can establish the expected network and TLS connection.

Check HTTPS Connectivity

If the Identity Provider uses HTTPS, verify the TLS connection directly:

openssl s_client -connect idp.example.com:443 \
  -servername idp.example.com

Check for:

• Certificate errors.
• TLS handshake failures.
• Incorrect hostname.
• Untrusted CA.
• Connection resets.
• Proxy-generated certificates.

If the command succeeds but Wazuh still reports TLS errors, investigate whether Wazuh uses a different trust store or network path.

Related Guide: How to Fix Wazuh Certificate Errors

Verify Firewall Rules

Check whether outbound traffic from the Wazuh server is restricted.

A firewall may allow normal Dashboard traffic while blocking outbound HTTPS connections to the IdP.

Depending on your environment, inspect:

UFW
firewalld
iptables
nftables
Cloud firewall rules
Network ACLs
Proxy policies

For example, check local firewall status:

sudo ufw status

or:

sudo firewall-cmd --list-all

The exact command depends on the operating system.

Remember that cloud-level firewalls and corporate network controls can block traffic even when the local Linux firewall allows it.

Check Proxy Configuration

Corporate environments often require outbound HTTPS traffic to pass through a proxy.

If the Wazuh server requires a proxy but the Wazuh component is not configured to use it, the IdP may be unreachable.

Check for environment variables such as:

env | grep -i proxy

Look for:

HTTP_PROXY
HTTPS_PROXY
NO_PROXY
http_proxy
https_proxy
no_proxy

Also check whether the Wazuh Dashboard, Indexer, or other relevant services run with a different environment from your interactive shell.

A common troubleshooting mistake is running:

curl https://idp.example.com

successfully from a shell while the Wazuh service itself cannot reach the IdP because the systemd service has different proxy settings.

Verify Outbound Connectivity From the Wazuh Dashboard

The connectivity test should originate from the Wazuh environment.

Do not rely exclusively on a browser test from your workstation.

For example:

curl -v https://idp.example.com

Run this on the Wazuh Dashboard host.

If Wazuh runs in a container, execute the test inside the relevant container.

This distinction matters because:

Your workstation → IdP       ✓
Wazuh Dashboard → IdP        ✗

can still produce an SSO login failure.

If the Dashboard cannot reach the IdP, investigate routing, firewall rules, proxy configuration, DNS, and TLS before changing SSO application settings.

Check TLS Inspection or Reverse-Proxy Interference

Security appliances and reverse proxies can modify HTTPS traffic.

Examples include:

• TLS inspection gateways.
• Corporate web proxies.
• Nginx.
• HAProxy.
• Apache.
• Cloud load balancers.
• WAFs.

TLS inspection can cause certificate validation failures if Wazuh does not trust the inspection authority.

A reverse proxy can also modify:

Host
X-Forwarded-Proto
X-Forwarded-Host
X-Forwarded-Port

This can result in Wazuh generating or expecting a URL that differs from the URL registered with the IdP.

For example, users may access:

https://wazuh.example.com

while the backend receives:

http://wazuh-dashboard:5601

If the external URL is not represented correctly, SSO redirects and callback URLs can break.

Related Guides:

• How to Configure a Wazuh Proxy
• Fixing Nginx Upstream Timeouts When Proxying Wazuh Dashboard Traffic

Clear Browser Sessions and Test SSO Again

After correcting the Wazuh, IdP, certificate, network, or role configuration, perform a clean authentication test.

An existing browser session can contain stale:

Cookies
Session tokens
Redirect state
Cached authentication data
IdP sessions

This can make a correctly repaired SSO configuration appear to remain broken.

Sign Out of the IdP

First, sign out of the Identity Provider.

If the provider has multiple active sessions, make sure the affected account is fully signed out.

For example, if you have recently changed:

• Group membership.
• SSO application assignment.
• User attributes.
• MFA configuration.
• Role assignments.

an existing IdP session may continue using information from before the change.

A fresh authentication session ensures that the IdP generates a new SAML assertion or OIDC token using the current configuration.

Clear Wazuh Dashboard Cookies

Clear cookies and site data associated with the Wazuh Dashboard.

This is particularly useful after:

• Changing SSO providers.
• Switching authentication methods.
• Changing the Dashboard URL.
• Fixing redirect loops.
• Changing certificates.
• Upgrading Wazuh.
• Modifying SAML or OIDC configuration.

You generally do not need to clear every cookie in the browser. Start with the Wazuh Dashboard’s site data and the relevant IdP session.

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

Test in a Private/Incognito Window

A private browser window is one of the fastest ways to determine whether stale browser state is involved.

Open an incognito/private window and access the Wazuh Dashboard.

Then perform the complete SSO flow again.

If:

Normal browser → SSO fails
Private browser → SSO succeeds

the Wazuh configuration is less likely to be the primary problem.

Focus instead on:

• Cookies.
• Cached authentication state.
• Existing IdP sessions.
• Browser extensions.
• Stored credentials.
• Previous redirect state.

If both sessions fail, continue investigating the server-side configuration.

Test With Another Browser

Try a different browser to eliminate browser-specific behavior.

For example:

Chrome → fails
Firefox → succeeds

This suggests that the problem may be browser-specific.

Check whether the affected browser has:

• Privacy extensions.
• Cookie restrictions.
• Third-party cookie blocking.
• Tracking protection.
• Stored authentication sessions.
• Security software integrations.

Do not immediately assume the IdP or Wazuh server is broken if only one browser is affected.

Test With Another User

Testing another account is one of the most useful ways to distinguish a user-specific problem from an environment-wide SSO failure.

For example:

User A → fails
User B → succeeds

suggests investigating:

• User assignment.
• Group membership.
• IdP claims.
• User-specific policies.
• Role mapping.
• Account status.

Whereas:

User A → fails
User B → fails
User C → fails

suggests a broader problem with:

• Wazuh SSO configuration.
• IdP application configuration.
• Certificates.
• Network connectivity.
• SAML/OIDC metadata.
• Wazuh Indexer security configuration.

Related Guide: How to Configure Wazuh SSO Role Mapping

Determine Whether the Issue Affects One User or All Users

Create a simple scope matrix during troubleshooting:

This prevents you from making broad configuration changes when the problem affects only one account.

If only one user is affected, inspect that user’s:

Application assignment
Group membership
Roles
Claims
Account status
MFA requirements

If every user is affected, focus on shared infrastructure:

Wazuh SSO configuration
IdP application
SAML metadata
OIDC endpoints
Certificates
DNS
Network connectivity
Wazuh Indexer security configuration

Once the corrected configuration has been tested successfully in a clean browser session, verify both authentication and authorization.

The final test should confirm that the user can log in, receives the intended Wazuh role, can access the appropriate tenant, and can perform only the actions permitted by that role.

Real-World Wazuh SSO Login Error Troubleshooting Example

Consider an enterprise Security Operations Center (SOC) running a multi-node Wazuh deployment.

The environment consists of:

Wazuh Manager
Wazuh Indexer cluster
Wazuh Dashboard
Microsoft Entra ID
Nginx reverse proxy

The organization uses SAML-based SSO so that analysts and security administrators can access the Wazuh Dashboard using their existing corporate identities.

The organization has separate IdP groups:

Wazuh-Admins
Wazuh-Analysts
Wazuh-Auditors

These groups are mapped to different Wazuh roles.

Show the Initial Login Error

An administrator suddenly reports that the Wazuh Dashboard SSO login no longer works.

The user:

1. Opens the Wazuh Dashboard.
2. Is redirected to Microsoft Entra ID.
3. Successfully authenticates.
4. Completes MFA.
5. Is redirected back to Wazuh.
6. Receives an SSO authentication error.

The user can authenticate successfully with the IdP, so the problem is unlikely to be the user’s password.

The initial symptoms suggest that the failure occurs after the Identity Provider authenticates the user.

Identify the Failed SAML or OIDC Configuration

The administrator compares the Wazuh configuration with the IdP application configuration.

The Wazuh configuration contains:

sp:
  entity_id: "wazuh-saml"

kibana_url: "https://wazuh.example.com"

roles_key: "Roles"

The Microsoft Entra ID application, however, has recently been modified.

Its Reply URL now points to:

https://wazuh.example.com/saml/acs

while Wazuh expects:

https://wazuh.example.com/_opendistro/_security/saml/acs

The ACS URL mismatch is therefore a strong candidate for the failure.

This is a common type of SSO configuration problem: the IdP can successfully authenticate the user but cannot deliver the SAML response to the endpoint expected by Wazuh.

Inspect Wazuh Dashboard Logs

The administrator watches the Wazuh Dashboard logs while reproducing the problem:

sudo journalctl -u wazuh-dashboard -f

During the failed login, the logs show an authentication-related error.

The administrator also checks the Wazuh Indexer:

sudo journalctl -u wazuh-indexer -f

The logs indicate that the expected SAML authentication transaction is not completing successfully.

The timing of the messages is important:

User opens Dashboard
        ↓
Redirect to IdP
        ↓
Authentication succeeds
        ↓
SAML response returned
        ↓
Wazuh authentication fails

This confirms that the failure occurs after the IdP authentication stage.

Inspect IdP Configuration

The administrator opens the Wazuh SAML application in Microsoft Entra ID and checks:

Identifier
Reply URL
Claims
Groups
Certificate
User assignment

The Reply URL does not match the Wazuh ACS endpoint.

The correct value should correspond to the ACS endpoint configured for the Wazuh deployment.

The administrator also verifies that the Roles claim is still configured correctly because fixing the ACS URL alone will not guarantee that authorization works afterward.

Related Guide: How to Configure Wazuh SAML Authentication

Correct the Configuration

The administrator updates the IdP Reply URL to the correct Wazuh ACS endpoint:

https://wazuh.example.com/_opendistro/_security/saml/acs

The administrator then verifies that the Wazuh Dashboard is configured to permit the required SAML endpoints.

After confirming the configuration, the affected Wazuh service is restarted where required:

sudo systemctl restart wazuh-dashboard

The administrator then performs a fresh SSO test using a private browser session.

Verify SSO Authentication

The user is redirected to Microsoft Entra ID.

After authentication and MFA, the IdP returns the SAML response to the corrected ACS URL.

The Wazuh Dashboard accepts the response and establishes the user’s session.

The authentication flow is now:

Browser
   ↓
Wazuh Dashboard
   ↓
Microsoft Entra ID
   ↓
Successful authentication
   ↓
Correct ACS URL
   ↓
Wazuh
   ↓
Authenticated session

The initial SSO login error has been resolved.

Verify Role Assignment

The administrator does not stop after confirming that the login works.

The user belongs to:

Wazuh-Admins

The SAML assertion contains the expected role attribute:

Roles = Wazuh-Admins

Wazuh maps that backend role to the intended administrative security role.

The administrator verifies that the user receives the expected permissions rather than assuming that successful authentication automatically means administrator access.

This distinction is critical:

Authentication
      ✓
       ↓
Role extraction
      ✓
       ↓
Role mapping
      ✓
       ↓
Authorization
      ✓

Validate Access to Wazuh Dashboard Resources

Finally, the administrator verifies actual access.

The user can:

• Log into the Wazuh Dashboard.
• Access the expected tenant.
• View authorized security data.
• Access the appropriate Dashboard features.
• Perform authorized administrative tasks.
• Remain blocked from resources outside the assigned role.

The administrator also checks that an analyst account still receives analyst permissions rather than administrator permissions.

This final validation is important because an SSO configuration can successfully authenticate users while still incorrectly assigning permissions.

Related Guide: Mastering Wazuh Security: The Complete Access Control Guide

The completed troubleshooting sequence is therefore:

Initial SSO failure
       ↓
Check Dashboard logs
       ↓
Check Indexer logs
       ↓
Compare Wazuh and IdP configuration
       ↓
Identify ACS URL mismatch
       ↓
Correct IdP configuration
       ↓
Restart affected service
       ↓
Test clean SSO session
       ↓
Verify authentication
       ↓
Verify role mapping
       ↓
Validate Dashboard permissions

This systematic approach avoids changing unrelated settings and provides a repeatable method for diagnosing Wazuh SSO failures.

Wazuh SSO Login Error Troubleshooting Checklist

Use the following checklist whenever users encounter a Wazuh SSO login error.

Wazuh Dashboard Configuration

• Verify the Wazuh Dashboard SSO configuration.
• Confirm whether the deployment uses SAML or OIDC.
• Verify the configured authentication type.
• Check SAML or OIDC endpoints.
• Confirm the Dashboard URL.
• Verify the relevant SSO configuration files.
• Restart the affected service after configuration changes.

Identity Provider Configuration

• Verify the Wazuh application registration.
• Confirm the correct SAML or OIDC application.
• Verify the IdP Entity ID or OIDC issuer.
• Verify the SP Entity ID for SAML.
• Check the ACS URL.
• Check the OIDC redirect URI.
• Verify client IDs and secrets.
• Confirm user assignment.
• Confirm group assignment.
• Verify SAML attributes or OIDC claims.

Certificates

• Verify Wazuh TLS certificates.
• Check IdP signing certificates.
• Check certificate expiration dates.
• Verify certificate chains.
• Confirm trusted Certificate Authorities.
• Check certificate file paths.
• Verify certificate permissions.
• Replace expired certificates.
• Confirm that Wazuh is using the replacement certificate.

SAML and OIDC Validation

• Verify SAML metadata.
• Check the IdP Entity ID.
• Check the SP Entity ID.
• Verify the ACS URL.
• Verify NameID configuration.
• Check SAML claims and attributes.
• Validate SAML assertion timestamps.
• Verify SAML signatures.
• Verify the OIDC issuer.
• Verify the authorization endpoint.
• Verify the token endpoint.
• Verify the OIDC client ID.
• Verify the client secret.
• Verify the redirect URI.
• Check required OIDC scopes.
• Check ID token claims.
• Verify issuer and audience values.

Role Mapping and Authorization

• Verify user-to-role mappings.
• Check SAML group attributes.
• Check OIDC group claims.
• Verify Wazuh role names.
• Check administrator role assignments.
• Verify backend roles.
• Check multi-tenancy configuration.
• Verify tenant permissions.
• Confirm the user receives the expected Wazuh role.

Time and Network

• Check the Wazuh server time.
• Check self-hosted IdP time where applicable.
• Verify NTP synchronization.
• Check for clock drift.
• Verify DNS resolution.
• Test connectivity to the IdP.
• Test HTTPS connectivity.
• Check firewall rules.
• Check proxy configuration.
• Verify outbound connectivity from the Wazuh Dashboard.
• Check TLS inspection.
• Check reverse-proxy configuration.

Logs and Browser Testing

• Check Wazuh Dashboard logs.
• Check Wazuh Indexer logs.
• Check Wazuh Manager/API logs where applicable.
• Search for SAML errors.
• Search for OIDC errors.
• Search for TLS and certificate errors.
• Search for role-mapping errors.
• Correlate errors with the exact login timestamp.
• Sign out of the IdP.
• Clear Wazuh Dashboard cookies.
• Test in a private/incognito window.
• Test with another browser.
• Test with another user.
• Determine whether the issue affects one user or all users.
• Retest both authentication and authorization.

Wazuh SSO Login Error Best Practices

Preventing SSO failures is preferable to troubleshooting them after users lose access to the Wazuh Dashboard.

A reliable Wazuh SSO implementation should therefore include configuration management, certificate monitoring, time synchronization, least-privilege role mappings, and an emergency access strategy.

Keep Wazuh and IdP Configurations Synchronized

Document the values that must match between Wazuh and the Identity Provider.

For SAML, maintain a record of:

IdP Entity ID
SP Entity ID
ACS URL
Metadata URL
Roles attribute
Signing certificate

For OIDC:

Issuer
Authorization endpoint
Token endpoint
Client ID
Redirect URI
Scopes
Claims

Review these values whenever the Wazuh Dashboard URL, reverse proxy, IdP application, or authentication provider changes.

Related Guide: How to Configure Wazuh SSO

Use Valid TLS Certificates

Use properly issued and trusted TLS certificates for Wazuh and the Identity Provider.

Avoid disabling certificate validation simply to make authentication work.

For production environments, certificate validation is part of the security boundary protecting the SSO transaction.

Monitor Certificate Expiration

Certificate expiration can cause previously functioning SSO integrations to fail without any user configuration changes.

Maintain monitoring for:

• Wazuh Dashboard certificates.
• Wazuh Indexer certificates.
• Reverse-proxy certificates.
• IdP signing certificates.
• Relevant intermediate certificates.

Where possible, configure alerts well before expiration so certificates can be renewed without an authentication outage.

Synchronize System Clocks

Use reliable NTP synchronization across Wazuh infrastructure.

Verify time synchronization on:

Wazuh Manager
Wazuh Dashboard
Wazuh Indexer
Self-hosted IdP
Reverse proxies

Accurate time reduces the likelihood of SAML assertion and OIDC token validation failures and also improves the reliability of security-event timestamps.

Related Guide: Fixing Wazuh Cluster Desync Caused by Master-Worker Time Drift

Document SSO Configuration

Maintain an internal SSO configuration document containing:

Wazuh Dashboard URL
IdP URL
Authentication protocol
SAML Entity IDs
ACS URL
OIDC issuer
Client ID
Redirect URI
Required claims
Role mappings
Certificate locations
Certificate expiration dates
Emergency administrator procedure

Do not store plaintext passwords, private keys, or client secrets in an unsecured document.

Documentation makes troubleshooting substantially faster because administrators can compare the current environment against a known-good configuration.

Use Least-Privilege Role Mappings

Map IdP groups to the minimum Wazuh permissions required for each job function.

For example:

Wazuh-Admins
    ↓
Administrative role

Wazuh-Analysts
    ↓
Analyst role

Wazuh-Responders
    ↓
Response role

Wazuh-Auditors
    ↓
Read-only role

Avoid mapping every authenticated SSO user to an administrator role.

Least-privilege mappings reduce the impact of compromised accounts and make authorization easier to audit.

Test SSO Changes Before Production Deployment

Do not make major SSO changes directly in production when a test environment is available.

Test changes such as:

• IdP certificate rotation.
• SAML metadata updates.
• OIDC client changes.
• Redirect URL changes.
• Role mappings.
• Group claims.
• Dashboard URL changes.
• Reverse-proxy changes.

Verify both:

Authentication

and:

Authorization

A change that fixes login but grants excessive permissions is not a successful SSO deployment.

Maintain a Local Administrative Account for Emergency Access

Maintain a carefully controlled local administrative authentication method so that administrators are not completely dependent on the external IdP.

This provides a recovery path if:

IdP is unavailable
SAML configuration breaks
OIDC configuration breaks
Certificate expires
Role mapping fails
Network connectivity fails

The emergency account should be protected with strong credentials and appropriate access controls.

Do not use the emergency account as a replacement for SSO. Its purpose is to provide controlled administrative access during an SSO outage.

Monitor Authentication Failures

Monitor Wazuh and IdP authentication logs for unusual patterns.

Look for:

• Repeated failed logins.
• SAML signature failures.
• OIDC token errors.
• Invalid client errors.
• Repeated authorization failures.
• Unexpected role changes.
• Sudden increases in authentication failures.

Authentication monitoring can help distinguish configuration problems from potential security incidents.

Related Guide: How to Configure Wazuh Audit Logs

Regularly Review SSO Permissions

SSO role mappings should be reviewed periodically.

Check:

• Which IdP groups can access Wazuh.
• Which groups receive administrator privileges.
• Which users belong to privileged groups.
• Whether obsolete groups remain mapped.
• Whether former employees retain application assignments.
• Whether tenant permissions remain appropriate.
• Whether custom Wazuh roles are still required.

Remove obsolete mappings and unnecessary privileged access.

A well-maintained SSO deployment should ensure that authentication proves identity while authorization consistently enforces least privilege.

Following these practices reduces the likelihood of recurring Wazuh SSO login errors while also improving the security and maintainability of the overall Wazuh access-control architecture.

Frequently Asked Questions

Question: What is a Wazuh SSO login error?

A Wazuh SSO login error occurs when a user cannot successfully authenticate to the Wazuh Dashboard through an external Identity Provider (IdP) such as Microsoft Entra ID, Okta, or Keycloak.

The failure can occur at several stages of the SSO process, including:

• Redirecting the user to the IdP.
• Authenticating the user.
• Returning the SAML assertion or OIDC response.
• Validating certificates and signatures.
• Processing claims and attributes.
• Mapping the user to a Wazuh role.
• Authorizing access to Dashboard resources.

The first step is therefore to determine where in the authentication chain the failure occurs.

Question: Why is Wazuh SSO not working?

Wazuh SSO can stop working for several reasons, including incorrect Dashboard configuration, incorrect IdP settings, expired certificates, invalid redirect URLs, missing SAML attributes, incorrect OIDC claims, network connectivity problems, DNS failures, clock drift, or role-mapping errors.

Start by determining whether the problem affects:

• One user or all users.
• One browser or all browsers.
• Authentication or authorization.
• SAML or OIDC.
• The Wazuh Dashboard or the Identity Provider.

Then inspect the Wazuh Dashboard and Wazuh Indexer logs around the exact time of the failed login.

Related Guide: Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Question: Why does Wazuh SSO redirect back to the login page?

A continuous SSO login loop can occur when Wazuh cannot establish or maintain the authenticated session after the IdP successfully authenticates the user.

Common causes include:

• Incorrect SAML configuration.
• Incorrect OIDC redirect URI.
• Invalid cookies.
• Reverse-proxy configuration problems.
• Incorrect Host or X-Forwarded-* headers.
• Session configuration problems.
• Authentication or authorization failures.
• Browser privacy or cookie restrictions.

First test the login in a private/incognito window.

If the problem persists, inspect the Dashboard logs and reverse-proxy configuration.

Question: Why does Wazuh SAML authentication fail?

Wazuh SAML authentication can fail because of incorrect Entity IDs, ACS URLs, SAML metadata, signing certificates, assertion attributes, NameID configuration, or clock synchronization.

Verify that the following values match between Wazuh and the IdP:

IdP Entity ID
SP Entity ID
ACS URL
SAML signing certificate
NameID
Required attributes
Group/role attributes

Also check the Wazuh logs for messages indicating assertion-validation or signature-validation failures.

Related Guide: How to Configure Wazuh SAML Authentication

Question: Why does Wazuh OIDC authentication fail?

Common OIDC problems include:

• Incorrect issuer.
• Incorrect authorization endpoint.
• Incorrect token endpoint.
• Invalid client ID.
• Invalid client secret.
• Incorrect redirect URI.
• Missing openid scope.
• Missing required claims.
• Issuer mismatch.
• Audience mismatch.
• Invalid or expired tokens.

Compare the OIDC configuration in Wazuh with the configuration registered at the Identity Provider.

If the logs show invalid_client, check the client credentials.

Also, if they show invalid_issuer, check the issuer URL.

If they show redirect_uri_mismatch, verify the registered callback URL.

Related Guide: How to Configure Wazuh OIDC

Question: Why does Wazuh say the SAML assertion is invalid?

An invalid SAML assertion can result from an incorrect signature, expired assertion, invalid audience, incorrect destination, wrong Entity ID, missing claims, or clock synchronization problems.

Check the assertion’s:

Issuer
Audience
Destination
Recipient
NotBefore
NotOnOrAfter
NameID
Attributes
Signature

Compare these values against the Wazuh SAML configuration and the IdP application configuration.

If the error specifically mentions signature validation, investigate the IdP signing certificate and SAML metadata.

If it mentions expiration or validity, check system time on the Wazuh infrastructure and self-hosted IdP.

Question: Why is my Wazuh SSO certificate failing?

Certificate failures can occur because a certificate is:

• Expired.
• Not yet valid.
• Signed by an untrusted CA.
• Missing an intermediate certificate.
• Configured at the wrong path.
• Inaccessible to the Wazuh service.
• Different from the certificate advertised by the IdP.
• Replaced without updating dependent configuration.

Check the certificate with:

openssl x509 -in /path/to/certificate.pem -noout -subject -issuer -dates

For a remote HTTPS endpoint, inspect the certificate presented by the server:

openssl s_client -connect example.com:443 \
  -servername example.com

Question: Why can I authenticate but not access Wazuh Dashboard?

Successful authentication does not necessarily mean successful authorization.

The IdP may correctly authenticate the user while Wazuh assigns the wrong role or no appropriate role at all.

Check:

1. The user’s IdP group membership.
2. SAML group attributes or OIDC role/group claims.
3. Wazuh backend-role mappings.
4. Wazuh security roles.
5. Tenant permissions.
6. Index permissions.
7. Dashboard permissions.

If the user receives a 403 Forbidden response after successfully authenticating, investigate authorization and role mapping rather than changing the user’s credentials.

Question: Why is Wazuh SSO role mapping not working?

SSO role mapping commonly fails when Wazuh receives a different group or role attribute than expected.

For example, the IdP might send:

groups = Wazuh-Admins

while Wazuh expects:

roles = Wazuh-Admins

The user can authenticate successfully, but Wazuh cannot map the identity to the intended security role.

Check the actual SAML assertion or OIDC token claims and compare them with the Wazuh role-mapping configuration.

Also verify that the target Wazuh role exists and has the expected permissions.

Question: How do I check Wazuh SSO logs?

Start with the Wazuh Dashboard and Wazuh Indexer logs.

Dashboard:

sudo journalctl -u wazuh-dashboard --since "15 minutes ago"

 Indexer:

sudo journalctl -u wazuh-indexer --since "15 minutes ago"

For live troubleshooting:

sudo journalctl -u wazuh-dashboard -f

and:

sudo journalctl -u wazuh-indexer -f

Search for terms such as:

saml
oidc
authentication
authorization
certificate
tls
issuer
assertion
role
backend role
tenant

Reproduce the failed login while monitoring the logs and record the exact timestamp.

This makes it much easier to correlate the user’s failed authentication with the corresponding server-side error.

Question: How do I troubleshoot Wazuh SSO with Microsoft Entra ID?

Start by checking the Wazuh application registration in Microsoft Entra ID.

Verify:

• Application assignment.
• SAML or OIDC protocol.
• Identifier/Entity ID.
• Reply URL or redirect URI.
• Claims.
• Group assignments.
• Signing certificate.
• Client credentials when using OIDC.

Then compare the Microsoft Entra ID configuration with Wazuh.

For SAML, pay particular attention to the Entity ID, Reply URL/ACS URL, claims, and signing certificate.

For OIDC, verify the issuer, client ID, client secret, redirect URI, scopes, and token claims.

Related Guide: How to Integrate Wazuh with Azure AD

Question: How do I troubleshoot Wazuh SSO with Okta?

For Okta, verify that the Wazuh application is configured with the correct authentication protocol and that the required users and groups have been assigned.

1. For SAML, check:

• Single sign-on URL.
• Audience URI/SP Entity ID.
• NameID.
• Group attributes.
• Signing certificate.

2. For OIDC, check:

• Issuer.
• Client ID.
• Client secret.
• Redirect URI.
• Scopes.
• ID token claims.

If authentication succeeds but the user receives incorrect permissions, focus on group claims and Wazuh role mapping.

Related Guide: How to Integrate Wazuh with Okta

Question: How do I troubleshoot Wazuh SSO with Keycloak?

For a Keycloak integration, verify both the Keycloak realm/client configuration and the Wazuh SSO configuration.

Check:

• Realm.
• Client ID.
• Client protocol.
• Valid redirect URIs.
• Client credentials where applicable.
• OIDC issuer.
• Required scopes.
• User groups.
• Group or role claims.
• Signing certificates.
• Wazuh role mappings.

For self-hosted Keycloak deployments, also verify DNS, HTTPS connectivity, certificates, and system time.

If the user authenticates but receives the wrong Wazuh permissions, inspect the groups or roles contained in the token and compare them with Wazuh’s role mappings.

Related Guide: How to Integrate Keycloak with Wazuh

Question: Can I use Wazuh SSO with SAML?

Yes. Wazuh can be configured for SSO using SAML-based authentication.

A SAML deployment typically involves:

User
 ↓
Wazuh Dashboard
 ↓
Identity Provider
 ↓
SAML authentication
 ↓
SAML assertion
 ↓
Wazuh
 ↓
Role mapping
 ↓
Dashboard access

The exact configuration depends on the Wazuh version and Identity Provider, so use the appropriate Wazuh documentation and your IdP’s current configuration requirements when implementing SAML.

Related Guide: How to Configure Wazuh SAML Authentication

Question: Can I use Wazuh SSO with OIDC?

Yes. Wazuh can be configured to use OpenID Connect (OIDC) for authentication.

An OIDC flow generally involves:

User
 ↓
Wazuh Dashboard
 ↓
OIDC Provider
 ↓
Authorization
 ↓
Authorization code
 ↓
Token exchange
 ↓
ID token
 ↓
Wazuh
 ↓
Role mapping

When troubleshooting OIDC, verify the issuer, endpoints, client credentials, redirect URI, scopes, and token claims.

Related Guide: How to Configure Wazuh OIDC

Question: How do I test Wazuh SSO after changing the configuration?

Use a controlled, repeatable test rather than simply checking whether the login screen disappears.

First:

1. Save or back up the existing configuration.
2. Apply the SSO change.
3. Restart or reload the affected Wazuh service when required.
4. Verify service status.
5. Sign out of the IdP.
6. Clear relevant browser sessions.
7. Open a private/incognito window.
8. Start a fresh SSO login.
9. Monitor Wazuh logs during authentication.

Then verify both authentication and authorization:

SSO redirect       ✓
IdP authentication ✓
SAML/OIDC response ✓
Certificate        ✓
User authentication ✓
Role mapping       ✓
Tenant access      ✓
Dashboard access   ✓
Permissions        ✓

Finally, test with at least one additional account with a different role to make sure the change has not accidentally granted excessive privileges.

Conclusion

A Wazuh SSO login error can originate from almost any stage of the authentication and authorization chain.

The most effective approach is to troubleshoot that chain systematically instead of changing multiple configuration parameters at once.

Start with the Wazuh Dashboard and Identity Provider configuration.

Then verify the SAML or OIDC endpoints, certificates, claims, role mappings, system time, DNS, network connectivity, and Wazuh logs.

If the server-side configuration appears correct, eliminate browser session issues with a clean authentication test.

The most important distinction is between authentication and authorization.

A user who successfully authenticates but receives incorrect permissions is not necessarily experiencing an SSO authentication failure.

In that situation, investigate SAML attributes, OIDC claims, backend roles, Wazuh RBAC, and multi-tenancy.

For recurring problems, document the complete SSO configuration, monitor certificate expiration, synchronize system clocks, maintain least-privilege role mappings, and keep a controlled local administrative recovery method.

Following these practices makes Wazuh SSO easier to troubleshoot, reduces the risk of unexpected authentication outages, and helps ensure that users receive exactly the Dashboard access their roles require.

Related Guide: Mastering Wazuh Security: The Complete Access Control Guide