Fixing Microsoft Graph API Authentication Failures in Wazuh

Microsoft Graph API has become a critical data source for organizations that rely on Microsoft 365 services such as Azure Active Directory, Exchange Online, Microsoft Defender, SharePoint, and Teams.

Wazuh can integrate with Microsoft Graph API to collect security-relevant events, user activity logs, audit records, and threat intelligence data, allo

wing security teams to monitor cloud environments alongside on-premises infrastructure from a centralized platform.

When Microsoft Graph API authentication fails, Wazuh loses visibility into important Microsoft 365 security events.

As a result, administrators may miss suspicious login attempts, privilege escalation activities, mailbox compromise indicators, or compliance-related audit events.

In many environments, these logs are essential for maintaining security monitoring, incident detection, and regulatory compliance.

Authentication failures can appear in several ways. Administrators may notice that Microsoft 365 logs suddenly stop appearing in the Wazuh Dashboard, integration modules begin generating errors, scheduled API queries fail, or Wazuh logs show OAuth-related authentication exceptions.

In some cases, the failures are intermittent, making them more difficult to diagnose.

According to Microsoft’s official documentation, Microsoft Graph uses OAuth 2.0-based authentication and authorization mechanisms, making correct application registration, permissions configuration, and token management essential for successful API access.

In this guide, you’ll learn how Wazuh authenticates to Microsoft Graph API, how to identify common authentication failures, how to interpret error messages, and how to systematically troubleshoot and resolve the underlying causes.

By the end, you’ll be able to restore Microsoft 365 log collection and ensure reliable communication between Wazuh and Microsoft Graph.

Related Guides:

Understanding How Wazuh Authenticates to Microsoft Graph API

Overview of the Authentication Flow

Before troubleshooting authentication failures, it is important to understand how Wazuh communicates with Microsoft Graph API.

Most authentication problems occur when one of the required components in the authentication chain is misconfigured.

The authentication process generally follows these steps:

An Azure AD application is registered.
Permissions are assigned to the application.
Wazuh uses stored credentials to request an OAuth access token.
Azure AD validates the request.
Azure AD issues an access token.
Wazuh uses the token to send requests to Microsoft Graph API.
Microsoft Graph returns the requested security or audit data.

Any failure during these steps can prevent log collection and trigger authentication-related errors.

Azure AD Application Registration

Microsoft Graph API integrations rely on an application registration within Azure Active Directory (now known as Microsoft Entra ID).

The application registration acts as Wazuh’s identity when accessing Microsoft cloud resources. During registration, Azure generates:

Application (Client) ID
Directory (Tenant) ID
Authentication credentials
Assigned API permissions

If the application registration is deleted, modified, or improperly configured, authentication requests will fail.

OAuth 2.0 Client Credentials Flow

Most Wazuh Microsoft Graph integrations use the OAuth 2.0 Client Credentials Flow.

This authentication model is designed for machine-to-machine communication where no user interaction is required.

Under this model:

Wazuh authenticates as an application.
No user login occurs.
Azure validates application credentials.
An access token is issued.
The token grants access to approved Microsoft Graph resources.

Security researchers frequently recommend the client credentials flow for automated security monitoring systems because it minimizes dependency on interactive user sessions while supporting granular permission assignments.

Access Token Acquisition

Before Wazuh can query Microsoft Graph API, it must obtain an access token from Azure AD.

The token request typically includes:

Tenant ID
Client ID
Client secret or certificate
OAuth scope information

Azure validates the request and returns a signed JSON Web Token (JWT).

The token contains information such as:

Issuing authority
Expiration time
Application identity
Granted permissions

If Azure rejects the request, Wazuh will be unable to access Microsoft Graph resources.

API Requests to Microsoft Graph

After receiving a valid token, Wazuh includes it in the Authorization header of API requests.

A typical request uses the following format:

Authorization: Bearer <access_token>

Microsoft Graph validates the token before returning data.

If the token is expired, invalid, revoked, or missing required permissions, Microsoft Graph returns authorization errors such as:

HTTP 401 Unauthorized
HTTP 403 Forbidden

These responses are among the most common indicators of authentication failures.

Components Involved

Wazuh Manager

The Wazuh Manager is responsible for executing integration scripts, requesting tokens, and retrieving Microsoft 365 data.

Configuration errors on the manager often lead to authentication problems.

Microsoft Graph API

Microsoft Graph API serves as Microsoft’s centralized API gateway for cloud services.

It enforces:

Authentication validation
Permission checks
Token verification
Rate limiting
Access controls

Azure Active Directory (Azure AD)

Azure AD (Microsoft Entra ID) acts as the identity provider.

Its responsibilities include:

Credential validation
Token issuance
Permission enforcement
Application authentication

Most authentication failures originate from Azure AD configuration issues.

Application Registrations

Application registrations define:

Which application can authenticate
Which APIs it can access
Which permissions are granted
Which credentials are valid

Improperly configured registrations are one of the most common root causes of Microsoft Graph authentication failures.

Client Secrets and Certificates

Authentication credentials are typically provided using:

Client secrets
X.509 certificates

Microsoft security guidance increasingly recommends certificate-based authentication because certificates offer stronger security and reduce the risk associated with exposed secrets.

Expired client secrets and expired certificates are frequent causes of unexpected authentication failures.

Expert Insight

Microsoft Identity Platform engineers consistently recommend implementing certificate-based authentication whenever possible because certificates provide stronger credential protection and reduce secret rotation challenges in automated environments.

Related Guides:

Common Symptoms of Microsoft Graph API Authentication Failures

Authentication issues can manifest in multiple ways depending on where the failure occurs within the authentication process.

Recognizing these symptoms early can significantly reduce troubleshooting time.

Wazuh Integration Stops Collecting Microsoft 365 Logs

One of the earliest indicators is a sudden interruption in Microsoft 365 event collection.

Administrators may notice:

Missing audit logs
Missing Azure AD sign-in events
Missing Microsoft Defender alerts
Large gaps in event timelines

While Wazuh itself may continue functioning normally, cloud-based security visibility becomes incomplete.

Authentication Errors in Wazuh Logs

Wazuh typically records authentication failures within its operational logs.

Common indicators include:

OAuth authentication failures
Token acquisition failures
Invalid credential errors
Authorization failures

These messages often contain valuable clues regarding the root cause.

HTTP 401 Unauthorized Responses

A 401 response indicates that authentication failed.

Typical causes include:

Invalid client secret
Incorrect tenant ID
Expired access token
Malformed token requests
Invalid application credentials

A 401 error generally means Microsoft Graph could not verify the application’s identity.

HTTP 403 Forbidden Responses

A 403 response indicates successful authentication but insufficient permissions.

Common causes include:

Missing API permissions
Missing admin consent
Conditional Access restrictions
Application access policies

In this scenario, Azure recognizes the application but denies access to the requested resource.

Invalid Token Errors

Microsoft Graph may reject tokens for reasons such as:

Expired tokens
Corrupted tokens
Incorrect audience values
Invalid signatures
Revoked credentials

These failures often appear in log entries referencing JWT validation problems.

Token Acquisition Failures

Sometimes Wazuh never receives a token at all.

Potential causes include:

Expired client secret
Incorrect client ID
DNS issues
Network connectivity problems
Azure service interruptions

When token acquisition fails, all subsequent Microsoft Graph requests also fail.

Intermittent Authentication Failures

Some environments experience sporadic authentication issues rather than permanent failures.

These may result from:

Network instability
Proxy interruptions
Time synchronization problems
Azure throttling
Temporary Microsoft service issues

Intermittent failures are often more difficult to diagnose because successful requests may occur between failed attempts.

Reviewing Wazuh Logs for Authentication Errors

Log analysis should always be the first troubleshooting step.

Wazuh logs frequently reveal the exact reason authentication is failing.

Locating Relevant Log Files

The primary location for troubleshooting integration failures is:

/var/ossec/logs/ossec.log

This file contains manager events, integration activity, API communication logs, and authentication-related errors.

Identifying Microsoft Graph Integration Errors

Search the log file for references to:

Microsoft Graph
OAuth
Azure
Token requests
Authentication failures

Look for repeated errors that occur during scheduled collection intervals.

Filtering Authentication-Related Events

A useful command for isolating authentication issues is:

grep -i "graph\|oauth\|token\|azure" /var/ossec/logs/ossec.log

This command filters log entries that reference:

Graph API activity
OAuth requests
Access tokens
Azure authentication services

Review the output chronologically to identify when failures first began occurring.

Common Error Messages and Their Meanings

Error Message	Likely Cause
Invalid client secret provided	Secret expired, deleted, or incorrectly configured
Unauthorized client	Incorrect application registration settings
Invalid audience	Wrong Graph API endpoint or OAuth scope
Access token validation failure	Expired or malformed token
Insufficient privileges	Missing Microsoft Graph permissions
Consent required	Administrator consent not granted
Authentication failed	Incorrect credentials or Azure AD configuration
Forbidden	Application authenticated but lacks authorization
Token acquisition timeout	Network, DNS, firewall, or proxy issue
AADSTS7000215	Invalid client secret supplied
AADSTS700016	Application ID not found in tenant
AADSTS500011	Resource principal not configured properly

Understanding these messages often points directly to the underlying issue, significantly reducing the time required to restore Microsoft Graph log collection within Wazuh.

Root Cause #1: Incorrect Client ID or Tenant ID

One of the most common causes of Microsoft Graph API authentication failures in Wazuh is an incorrect Client ID or Tenant ID.

Since Azure AD relies on these identifiers to locate and validate the application requesting access, even a single incorrect character can prevent authentication.

How Wazuh Uses Client and Tenant Identifiers

When Wazuh requests an OAuth access token, it submits several pieces of information to Azure AD, including:

Tenant ID
Client ID
Client secret or certificate
OAuth scope

The Tenant ID tells Azure which Microsoft Entra tenant should process the request, while the Client ID identifies the registered application requesting access.

If either value is incorrect, Azure cannot locate the application and token issuance fails.

Verifying Azure AD Application Registration

Begin by verifying the application registration within Azure Portal.

Navigate to:

Microsoft Entra Admin Center
→ Applications
→ App Registrations
→ Your Application

Review the following values:

Application (client) ID
Directory (tenant) ID
Display name
Supported account types

Ensure the application still exists and has not been deleted, recreated, or modified.

Confirming Values in Wazuh Configuration

Compare the values configured in Wazuh against those shown in Azure.

Pay special attention to:

Extra spaces
Missing characters
Incorrect tenant references
Copy-and-paste formatting issues

Administrators frequently encounter issues after:

Tenant migrations
Application recreation
Environment cloning
Configuration imports

Correcting Configuration Mistakes

If you discover discrepancies:

Copy the correct values directly from Azure.
Update the Wazuh integration configuration.
Save the configuration.
Restart affected services.
Retest authentication.

After correcting the identifiers, monitor Wazuh logs for successful token acquisition events.

Common Error Indicators

The following Azure errors frequently point to Client ID or Tenant ID problems:

AADSTS700016: Application with identifier was not found
AADSTS500011: Resource principal not found
Unauthorized client

These errors typically indicate Azure cannot locate the specified application within the target tenant.

Expert Insight

Microsoft identity engineers recommend avoiding manual entry of Client IDs and Tenant IDs whenever possible.

Copying values directly from the Azure Portal reduces the risk of formatting errors and misconfigured environments.

Internal Links:

Wazuh API Authentication Failed? Causes and Solutions
How to Fix Wazuh Certificate Errors
Wazuh Agent Not Connecting to Manager? 12 Proven Fixes

Root Cause #2: Expired or Invalid Client Secret

Client secrets are among the most frequent causes of Microsoft Graph authentication failures because they eventually expire.

Many administrators successfully deploy the integration and forget about the secret until it expires months later.

Why Client Secrets Expire

Microsoft Entra ID allows administrators to create client secrets with predefined lifetimes.

Depending on organizational policies, secrets may expire after:

6 months
12 months
24 months

Once the expiration date passes, Azure rejects all authentication requests using that secret.

This often causes integrations that have worked for months to suddenly stop functioning.

Checking Secret Expiration in Azure Portal

To verify secret validity:

Microsoft Entra Admin Center
→ App Registrations
→ Your Application
→ Certificates & Secrets

Review:

Secret description
Creation date
Expiration date
Status

If the secret has expired, authentication requests will fail immediately.

Creating a New Client Secret

To generate a replacement:

Open the application registration.
Navigate to Certificates & Secrets.
Select New Client Secret.
Add a description.
Choose an expiration period.
Save the new secret.

Important:

Microsoft only displays the secret value once. Copy it immediately and store it securely.

Updating Wazuh Configuration

After generating a new secret:

Update the secret within the Wazuh integration configuration.
Verify no extra spaces were introduced.
Save the changes.
Validate file permissions if credentials are stored in configuration files.

Incorrectly copied secrets are surprisingly common and can produce the same errors as expired credentials.

Restarting Wazuh Services

After updating the secret, restart the Wazuh Manager:

systemctl restart wazuh-manager

Then monitor:

tail -f /var/ossec/logs/ossec.log

Look for successful token generation and Microsoft Graph API requests.

Common Error Indicators

Expired secrets often produce:

AADSTS7000215: Invalid client secret provided
Invalid client credentials
Authentication failed

These messages almost always warrant immediate inspection of secret validity.

Security Best Practice

Microsoft recommends certificate-based authentication over client secrets for long-term integrations because certificates provide stronger protection and eliminate many secret expiration management issues.

Related Guides:

Root Cause #3: Missing Microsoft Graph API Permissions

Even when authentication succeeds, Microsoft Graph may deny access if the application lacks required permissions.

This situation commonly produces HTTP 403 errors.

Required Permissions for Microsoft 365 Monitoring

The exact permissions depend on the Microsoft 365 data sources being monitored.

Common Graph permissions include:

AuditLog.Read.All
Directory.Read.All
SecurityEvents.Read.All
User.Read.All
Reports.Read.All

Some organizations also require access to:

Microsoft Defender data
Exchange Online audit logs
Identity Protection events

Without appropriate permissions, Microsoft Graph refuses data access requests.

Reviewing Assigned API Permissions

To review permissions:

Microsoft Entra Admin Center
→ App Registrations
→ Your Application
→ API Permissions

Review:

Assigned permissions
Permission type
Admin consent status

Pay attention to permissions marked as:

Not granted

These often indicate incomplete setup.

Understanding Application vs Delegated Permissions

Microsoft Graph supports two permission models.

Application Permissions

Application permissions allow Wazuh to operate independently of a user account.

Characteristics:

Machine-to-machine authentication
Preferred for security monitoring
Supports background services
Commonly used with Wazuh

Delegated Permissions

Delegated permissions operate in the context of a signed-in user.

Characteristics:

Require user authentication
Depend on user privileges
Less suitable for automated monitoring

Most Wazuh deployments should use Application Permissions.

Granting Missing Permissions

If required permissions are absent:

Select Add Permission.
Choose Microsoft Graph.
Select Application Permissions.
Add the required permissions.
Save changes.

After permissions are assigned, Azure must process the updates before they become available.

Performing Admin Consent

Many Graph permissions require administrator approval.

To grant consent:

API Permissions
→ Grant Admin Consent

Without admin consent, permissions remain inactive even if they appear assigned.

Common Error Indicators

Missing permissions often generate:

HTTP 403 Forbidden
Insufficient privileges
Authorization_RequestDenied
Access denied

When authentication succeeds but API access fails, permissions should be one of the first areas investigated.

Expert Insight

Identity architects frequently report that missing admin consent is responsible for a large percentage of Graph API authorization failures.

Administrators often assign permissions but forget the final consent step required to activate them.

Root Cause #4: Certificate-Based Authentication Problems

Organizations that follow Microsoft’s security recommendations often replace client secrets with certificates.

While more secure, certificate-based authentication introduces its own failure scenarios.

How Certificate Authentication Works

Instead of using a client secret, Wazuh authenticates using a private key associated with a trusted certificate.

The process involves:

Azure stores the certificate’s public key.
Wazuh uses the private key to prove identity.
Azure validates the certificate.
An OAuth token is issued.

This approach significantly reduces credential theft risks.

Expired Certificates

Certificates have expiration dates similar to client secrets.

Once a certificate expires:

Authentication fails
Token requests are rejected
Graph API access stops

Certificate expiration is a common cause of unexpected integration outages.

Incorrect Certificate Thumbprints

Azure identifies certificates using thumbprints.

Authentication failures may occur when:

Wrong certificate uploaded
Thumbprint mismatch
Certificate replacement not updated
Duplicate certificates exist

Always verify the thumbprint configured in Azure matches the deployed certificate.

Certificate Trust Issues

Trust-related problems can also cause failures.

Potential issues include:

Corrupted certificate chains
Missing intermediate certificates
Invalid certificate formats
Improper key usage settings

These problems may generate cryptographic validation errors.

Replacing Expired Certificates

To replace an expired certificate:

Generate a new certificate.
Upload the public certificate to Azure.
Deploy the private key to the Wazuh host.
Update configuration references.
Remove obsolete certificates if appropriate.

Avoid deleting active certificates before confirming successful authentication.

Validating Certificate Configuration

Review the following items:

Certificate expiration date
Thumbprint
Key permissions
File paths
Certificate chain validity

Verification tools such as OpenSSL can help validate certificate integrity.

Example:

openssl x509 -in certificate.pem -text -noout

Common Error Indicators

Certificate-related failures may generate:

Invalid certificate
Certificate validation failed
Authentication failed
Key not found
Thumbprint mismatch

Related Guides:

Root Cause #5: OAuth Token Request Failures

Sometimes all credentials and permissions are configured correctly, but Wazuh still cannot obtain a token.

In these cases, the issue often lies within the OAuth token request process itself.

Understanding OAuth Token Endpoints

OAuth token requests are typically sent to:

https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token

Azure uses this endpoint to:

Validate credentials
Verify permissions
Generate access tokens

Any issue reaching this endpoint prevents authentication.

Verifying Endpoint URLs

Confirm the configured URL includes:

Correct tenant ID
Correct protocol (HTTPS)
Correct Microsoft endpoint
No typographical errors

Incorrect endpoints often produce immediate authentication failures.

Testing Token Requests Manually

Manual testing helps isolate whether the problem is in Azure or within Wazuh.

Example:

curl -X POST \
https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token \
-d "client_id=CLIENT_ID" \
-d "client_secret=CLIENT_SECRET" \
-d "scope=https://graph.microsoft.com/.default" \
-d "grant_type=client_credentials"

If Azure successfully returns a token, the issue likely resides within Wazuh configuration rather than Azure itself.

Inspecting Returned Error Messages

Azure typically returns highly descriptive error responses.

Examples include:

{
  "error": "invalid_client",
  "error_description": "AADSTS7000215: Invalid client secret provided."
}

Or:

{
  "error": "unauthorized_client"
}

These responses often identify the root cause directly.

Common Error Indicators

OAuth endpoint failures frequently produce:

Connection timeout
Name resolution failure
invalid_client
unauthorized_client
invalid_scope
AADSTS errors

When troubleshooting, compare Azure’s returned error messages with Wazuh log entries to quickly pinpoint the failing component.

Expert Insight

Microsoft’s identity engineering documentation emphasizes testing token acquisition manually before modifying production configurations.

This isolates authentication failures from application-specific issues and significantly accelerates root cause analysis.

Related Guides:

Root Cause #6: Conditional Access Policies Blocking Authentication

Conditional Access policies are a powerful Microsoft Entra security feature, but they can unintentionally block Wazuh from authenticating to Microsoft Graph API.

Many organizations implement strict access controls without realizing they may also affect service accounts, application registrations, and non-interactive authentication flows.

What Conditional Access Policies Do

Conditional Access policies allow administrators to control authentication based on factors such as:

User identity
Device compliance
Geographic location
Network location
Risk level
Authentication method

These policies help reduce unauthorized access but can also prevent legitimate integrations from functioning.

Common examples include:

Blocking legacy authentication
Restricting access from specific countries
Requiring compliant devices
Enforcing MFA requirements

Identifying Blocked Sign-In Attempts

When Conditional Access blocks authentication, Azure typically records the event.

Common symptoms include:

HTTP 401 responses
HTTP 403 responses
Successful token requests followed by denied access
Unexpected authentication failures after policy changes

The exact error message often references Conditional Access enforcement.

Reviewing Azure Sign-In Logs

Microsoft Entra sign-in logs provide the most reliable source of troubleshooting information.

Navigate to:

Microsoft Entra Admin Center
→ Monitoring & Health
→ Sign-in Logs

Look for:

Failure events
Conditional Access failures
Service principal authentication attempts
Application authentication records

Pay particular attention to entries containing:

Conditional Access Failure
Access blocked by policy
Grant controls not satisfied

These indicate policy-related authentication restrictions.

Creating Appropriate Exceptions

If Conditional Access is blocking Wazuh, administrators may need to create exclusions.

Possible approaches include:

Excluding the application registration
Excluding the service principal
Allowing specific trusted locations
Creating dedicated security monitoring policies

Avoid broad exemptions whenever possible.

Instead, implement narrowly scoped exceptions that satisfy security requirements while allowing required Graph API access.

Security Considerations Before Making Changes

Before modifying Conditional Access:

Review organizational security policies.
Understand why the policy was implemented.
Document all exceptions.
Limit exclusions to required applications.
Test changes in a non-production environment when possible.

Microsoft security teams generally recommend following the principle of least privilege when creating Conditional Access exceptions.

Common Error Indicators

Conditional Access blocks may produce:

Access blocked by Conditional Access
Grant controls not satisfied
AADSTS53003
AADSTS50105

These errors typically point directly to policy enforcement rather than credential problems.

Expert Insight

Microsoft identity architects frequently recommend reviewing sign-in logs before modifying Conditional Access policies.

The logs often reveal exactly which policy triggered the denial and why the request was blocked.

Root Cause #7: Multi-Factor Authentication (MFA) Misconfiguration

Multi-Factor Authentication strengthens account security, but improper MFA implementation can interfere with Microsoft Graph integrations.

This is especially common when administrators mistakenly apply user-focused controls to application-based authentication.

Why MFA Can Impact Certain Authentication Flows

MFA requires users to provide additional verification factors beyond a password.

Examples include:

Authenticator applications
SMS verification
Hardware security keys
Biometric authentication

While MFA is highly effective for user accounts, automated integrations cannot typically complete interactive MFA challenges.

Application Authentication vs User Authentication

Understanding the difference between these authentication models is critical.

Application Authentication

Characteristics include:

Uses client secrets or certificates
No interactive user login
Designed for automation
Commonly used by Wazuh

User Authentication

Characteristics include:

Requires a user identity
Supports MFA challenges
Depends on user permissions
Often used by interactive applications

If MFA is incorrectly enforced against application authentication flows, token requests may fail.

Recommended Configuration Approaches

For Microsoft Graph integrations:

Prefer application-based authentication.
Use client credentials flow.
Use certificates when possible.
Avoid dependencies on interactive user sessions.
Review Conditional Access and MFA policies together.

This approach minimizes operational disruptions while maintaining strong security controls.

Verifying Service Principal Access

The service principal associated with the application registration should be reviewed carefully.

Check:

Microsoft Entra Admin Center
→ Enterprise Applications
→ Your Application

Verify:

Application status
Assigned permissions
Sign-in activity
Conditional Access impact

A healthy service principal is essential for reliable authentication.

Common Error Indicators

MFA-related issues may generate:

Interaction required
AADSTS50076
AADSTS50079
Additional authentication required
User authentication required

These errors often indicate that an application authentication flow is being treated as a user authentication flow.

Security Best Practice

Microsoft recommends using service principals with certificate-based authentication for long-running security integrations because they avoid interactive authentication requirements while supporting strong security controls.

Root Cause #8: Network Connectivity Issues

Even perfectly configured credentials cannot authenticate if Wazuh cannot reach Microsoft services.

Network-related issues remain one of the most overlooked causes of Graph API failures.

Testing Connectivity to Microsoft Endpoints

Start by verifying that the Wazuh server can communicate with Microsoft infrastructure.

Test:

Internet connectivity
DNS resolution
HTTPS access
Proxy routing
Firewall policies

Connectivity issues often produce timeout-related errors rather than authentication-specific messages.

Verifying DNS Resolution

DNS failures prevent Wazuh from locating Microsoft Graph endpoints.

Use:

nslookup graph.microsoft.com

A successful response should return valid Microsoft IP addresses.

Potential issues include:

Internal DNS misconfiguration
DNS filtering
Split-horizon DNS problems
Resolver failures

Testing HTTPS Connectivity

Verify HTTPS communication using:

curl -I https://graph.microsoft.com

A successful response confirms:

DNS functionality
TLS negotiation
Network reachability

If the request times out, the issue is likely network-related rather than authentication-related.

Firewall and Proxy Troubleshooting

Review firewall and proxy settings carefully.

Common problems include:

Outbound HTTPS blocking
SSL inspection failures
Proxy authentication issues
Egress filtering restrictions

Check both:

Host-based firewalls
Network perimeter firewalls

Security teams sometimes unintentionally block Microsoft endpoints during hardening projects.

Required Microsoft Endpoints

Most Graph API integrations require access to:

graph.microsoft.com
login.microsoftonline.com
login.windows.net
graph.microsoft.us (government environments)

Verify these endpoints are reachable from the Wazuh Manager.

Common Error Indicators

Network-related issues often generate:

Connection timeout
Could not resolve host
Network unreachable
Connection refused
TLS handshake timeout

These errors generally indicate connectivity problems rather than credential failures.

Expert Insight

Microsoft support engineers frequently recommend validating connectivity before investigating permissions or authentication settings.

A simple DNS or firewall issue can produce symptoms that closely resemble authentication failures.

Root Cause #9: TLS and Certificate Validation Errors

Microsoft Graph API requires secure HTTPS communication.

If TLS validation fails, authentication requests may never reach Azure AD.

Common TLS-Related Failures

Typical TLS issues include:

Expired CA certificates
Unsupported TLS versions
Incorrect system time
SSL inspection problems
Broken certificate chains

These failures can prevent secure communication even when network connectivity exists.

Verifying System Time Synchronization

TLS relies heavily on accurate system time.

Check current time:

date

Verify synchronization:

timedatectl status

If the server clock drifts significantly, certificate validation may fail.

Common causes include:

Disabled NTP
Virtual machine clock drift
Misconfigured time sources

Updating Trusted CA Certificates

Outdated trust stores can prevent validation of Microsoft certificates.

On many Linux distributions:

update-ca-certificates

Or:

update-ca-trust

Keeping trusted root certificates current helps prevent TLS validation failures.

Testing TLS Handshakes

OpenSSL can verify TLS communication directly.

Use:

openssl s_client -connect graph.microsoft.com:443

Review output for:

Certificate validation errors
Expired certificates
Unsupported protocols
Trust chain failures

A successful handshake indicates TLS is functioning correctly.

Common Error Indicators

TLS problems often produce:

Certificate verify failed
SSL handshake failure
TLS negotiation failed
Unable to verify certificate chain
x509 certificate validation error

These errors typically occur before authentication credentials are even evaluated.

Related Guides:

Root Cause #10: Azure AD Application Disabled or Deleted

In some cases, authentication fails because the Azure application registration itself is no longer available.

This frequently occurs after tenant cleanup activities, security reviews, or accidental administrative changes.

Verifying Application Status

Start by reviewing the application registration.

Navigate to:

Microsoft Entra Admin Center
→ App Registrations
→ Your Application

Confirm:

Application exists
Application is enabled
Credentials are present
Permissions remain assigned

Checking Service Principal Health

Also verify the associated service principal.

Navigate to:

Microsoft Entra Admin Center
→ Enterprise Applications
→ Your Application

Review:

Status
Sign-in activity
Assigned roles
Access policies

An unhealthy service principal can prevent successful authentication.

Recovering Deleted Registrations

If the application was recently removed, administrators may be able to recover it through Azure recovery options.

Check:

Microsoft Entra Admin Center
→ Deleted Applications

Recovery options depend on Microsoft’s retention policies and tenant configuration.

Recreating Application Registrations

If recovery is impossible:

Create a new application registration.
Configure Microsoft Graph permissions.
Generate credentials.
Grant admin consent.
Update Wazuh configuration.
Test authentication.

Document all new identifiers to simplify future troubleshooting.

Testing Microsoft Graph Authentication Outside Wazuh

Before making additional changes to Wazuh, verify that Azure authentication works independently.

This isolates Azure-related issues from Wazuh-specific configuration problems.

Acquiring Access Tokens Manually

Request a token directly from Azure:

curl -X POST \
https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token \
-d "client_id=CLIENT_ID" \
-d "client_secret=CLIENT_SECRET" \
-d "scope=https://graph.microsoft.com/.default" \
-d "grant_type=client_credentials"

A successful response should include an access token.

Decoding JWT Tokens

After receiving a token, inspect its contents using a JWT decoder.

Review:

Issuer
Audience
Tenant ID
Application ID
Expiration timestamp
Granted roles

This helps confirm Azure is issuing the expected permissions.

Validating Token Claims

Important claims include:

aud
appid
tid
roles
exp

Incorrect claim values often explain authorization failures later in the process.

Testing Graph API Requests

Use the access token directly:

curl -H "Authorization: Bearer ACCESS_TOKEN" \
https://graph.microsoft.com/v1.0/organization

Successful responses indicate:

Authentication works
Authorization works
Graph API access works

At that point, remaining issues are likely within Wazuh configuration.

Comparing Successful and Failed Requests

Compare:

Component	Successful Request	Failed Request
Tenant ID	Correct	Incorrect or missing
Client ID	Valid	Invalid
Secret/Certificate	Valid	Expired or incorrect
Permissions	Granted	Missing
Token Claims	Expected values	Incorrect values
Graph Response	HTTP 200	HTTP 401/403

This side-by-side comparison often reveals the root cause quickly and prevents unnecessary configuration changes.

Expert Insight

Microsoft support engineers routinely use manual token acquisition and Graph API testing as the definitive method for separating Azure authentication problems from application-specific integration issues.

If authentication works outside Wazuh, administrators can focus their investigation on Wazuh configuration and connectivity rather than Azure identity services.

Verifying the Fix in Wazuh

After correcting the underlying authentication issue, it’s important to verify that Wazuh can successfully communicate with Microsoft Graph API and resume normal log collection.

Many administrators stop troubleshooting after fixing the suspected cause, only to discover later that data collection never actually resumed.

A structured validation process helps ensure the problem is fully resolved.

Restarting Wazuh Components

Start by restarting the affected Wazuh services so the updated configuration, credentials, or certificates are loaded into memory.

On most Wazuh Manager installations:

systemctl restart wazuh-manager

If your deployment includes additional integration services, restart them as required by your environment.

After restarting, confirm the service starts successfully:

systemctl status wazuh-manager

Look for:

Active (running) status
No startup errors
No integration failures
No authentication exceptions

If the service fails to start, review:

journalctl -u wazuh-manager -n 100

Monitoring Authentication Logs

Immediately after restarting, monitor authentication-related log activity.

Use:

tail -f /var/ossec/logs/ossec.log

Or filter specifically for Microsoft Graph activity:

grep -i "graph\|oauth\|token\|azure" /var/ossec/logs/ossec.log

Watch for:

Token requests
Successful authentication messages
Graph API requests
Event collection activity

The absence of new authentication errors is often the first indication that the fix was successful.

Confirming Successful Token Acquisition

The most important validation step is confirming that Wazuh can obtain an OAuth access token.

Successful authentication generally produces log entries indicating:

Token request submitted
Token received successfully
Authentication completed
Graph API access granted

You should no longer see errors such as:

AADSTS7000215
invalid_client
unauthorized_client
Authentication failed

Instead, the integration should proceed directly to Microsoft Graph queries.

Verifying Microsoft 365 Event Collection

After authentication succeeds, verify that Microsoft 365 data is flowing into Wazuh again.

Check for:

Azure AD sign-in events
Audit logs
Microsoft Defender alerts
User activity records
Compliance events

Compare timestamps to ensure newly generated events are arriving.

Large gaps may indicate collection has not fully resumed.

Checking Dashboard Data

Finally, confirm data visibility within the Wazuh Dashboard.

Review:

Security event dashboards
Audit log dashboards
Microsoft 365-related visualizations
Custom searches

Validate that:

New events are appearing
Dashboards are updating
Searches return recent records
Event ingestion timestamps are current

If logs are being collected but not displayed, investigate indexing and dashboard issues separately.

Related Guides:

Security Best Practices for Microsoft Graph Integrations

Successfully fixing an authentication issue is only part of the process.

Organizations should also implement security controls that reduce the likelihood of future authentication failures while maintaining strong protection for cloud resources.

Rotate Client Secrets Regularly

Client secrets should never remain unchanged indefinitely.

Establish a rotation schedule based on:

Organizational security requirements
Compliance mandates
Secret expiration timelines

Regular rotation reduces the risk associated with:

Credential theft
Accidental exposure
Long-lived compromised credentials

Document all rotation procedures to minimize operational disruption.

Prefer Certificate-Based Authentication

Microsoft increasingly recommends certificate-based authentication over client secrets.

Benefits include:

Stronger cryptographic protection
Reduced credential exposure risk
Improved automation capabilities
Easier compliance with security frameworks

For production Wazuh deployments, certificate authentication is often the preferred long-term solution.

Apply Least-Privilege Permissions

Grant only the Microsoft Graph permissions required by the integration.

Avoid assigning:

Broad administrative permissions
Unnecessary directory access
Excessive read/write privileges

A least-privilege approach limits the potential impact of compromised credentials.

Examples include granting:

AuditLog.Read.All
SecurityEvents.Read.All

Only when they are actually required.

Monitor Azure AD Sign-In Logs

Sign-in logs provide valuable visibility into authentication activity.

Monitor for:

Failed token requests
Conditional Access denials
Suspicious authentication attempts
Unexpected permission changes

Regular review helps identify issues before they affect production monitoring.

Microsoft’s security guidance consistently emphasizes sign-in log monitoring as a core detection mechanism for identity-related threats.

Secure Secret Storage

Never store secrets in:

Documentation files
Shared spreadsheets
Public repositories
Plain-text scripts

Instead, use:

Secret management platforms
Encrypted credential stores
Restricted configuration files
Managed identity solutions where applicable

Access should be limited to authorized administrators.

Audit Application Registrations Periodically

Application registrations often remain unchanged for long periods and can easily be forgotten.

Periodic reviews should verify:

Active credentials
Assigned permissions
Admin consent status
Certificate validity
Ownership information

A quarterly review cycle is common in mature security programs.

Expert Insight

Identity security specialists frequently identify abandoned application registrations as a significant source of risk.

Regular audits help detect expired credentials, excessive permissions, and unused integrations before they become operational or security problems.

Preventing Future Authentication Failures

The most effective way to handle Microsoft Graph authentication issues is to prevent them from occurring in the first place.

Proactive monitoring and operational controls can significantly reduce unexpected outages.

Implement Secret Expiration Monitoring

Expired client secrets remain one of the leading causes of Graph authentication failures.

Organizations should:

Track expiration dates centrally
Configure advance notifications
Schedule credential renewals
Document ownership responsibilities

Many teams implement alerts 30, 60, and 90 days before expiration.

This provides ample time for replacement and testing.

Track Certificate Expiration Dates

Certificate-based authentication requires similar oversight.

Monitor:

Expiration dates
Renewal schedules
Certificate inventory
Deployment status

Unexpected certificate expiration can completely halt Microsoft 365 log collection.

Maintaining a certificate lifecycle management process helps prevent outages.

Create Automated Health Checks

Automated validation can identify authentication problems before administrators notice missing logs.

Examples include:

Token acquisition tests
API connectivity checks
Microsoft Graph query validation
Event ingestion verification

Health checks should alert administrators when failures occur.

This reduces mean time to detection (MTTD) and improves operational reliability.

Monitor Token Acquisition Failures

Authentication failures often appear long before users notice missing data.

Create alerts for:

OAuth errors
Token request failures
AADSTS error codes
Authentication exceptions

Monitoring these indicators provides early warning of developing issues.

Consider integrating alerting with:

Email notifications
SIEM platforms
Incident management systems
Messaging tools

Establish Change Management Procedures

Many authentication failures occur immediately after administrative changes.

Examples include:

Secret rotation
Certificate replacement
Permission updates
Conditional Access modifications
Tenant migrations

Formal change management procedures help ensure changes are:

Documented
Reviewed
Approved
Tested

This significantly reduces configuration-related outages.

Maintain Integration Documentation

Comprehensive documentation makes future troubleshooting much easier.

Document:

Tenant IDs
Client IDs
Required permissions
Credential locations
Renewal schedules
Administrative contacts
Recovery procedures

Good documentation reduces dependency on individual administrators and accelerates incident response.

Building a Long-Term Operational Strategy

Organizations that treat Microsoft Graph integrations as production services generally experience fewer authentication problems.

A mature operational strategy should include:

Credential lifecycle management
Certificate monitoring
Permission audits
Sign-in log monitoring
Automated validation testing
Change management controls

Together, these practices create a resilient authentication framework that keeps Microsoft 365 telemetry flowing reliably into Wazuh.

Related Guides:

Frequently Asked Questions (FAQ)

Question: Why is Wazuh unable to authenticate with Microsoft Graph API?

Wazuh authentication failures typically occur because of one or more of the following issues:

Incorrect Client ID or Tenant ID
Expired client secrets
Invalid certificates
Missing Microsoft Graph permissions
Missing admin consent
Conditional Access restrictions
Network connectivity problems
TLS validation failures
Disabled Azure application registrations

Reviewing both Wazuh logs and Azure sign-in logs is usually the fastest way to identify the root cause.

Question: How do I find Microsoft Graph authentication errors in Wazuh logs?

Most authentication-related errors are recorded in:

/var/ossec/logs/ossec.log

To quickly locate Graph API-related entries, use:

grep -i "graph\|oauth\|token\|azure" /var/ossec/logs/ossec.log

This command helps identify token acquisition failures, OAuth errors, permission issues, and connectivity problems associated with Microsoft Graph integrations.

Question: What causes HTTP 401 errors when accessing Microsoft Graph?

An HTTP 401 Unauthorized response indicates that authentication has failed.

Common causes include:

Expired access tokens
Invalid client secrets
Incorrect Client IDs
Incorrect Tenant IDs
Invalid certificates
Malformed OAuth requests

A 401 error generally means Microsoft Graph could not successfully verify the application’s identity.

Question: What permissions does Wazuh need for Microsoft 365 integrations?

The required permissions depend on the Microsoft 365 services being monitored.

Common Microsoft Graph Application Permissions include:

AuditLog.Read.All
Directory.Read.All
SecurityEvents.Read.All
User.Read.All
Reports.Read.All

Always follow the principle of least privilege and grant only the permissions necessary for your monitoring objectives.

Question: How do I test Microsoft Graph API authentication manually?

You can request an OAuth token directly from Azure using curl:

curl -X POST \
https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token \
-d "client_id=CLIENT_ID" \
-d "client_secret=CLIENT_SECRET" \
-d "scope=https://graph.microsoft.com/.default" \
-d "grant_type=client_credentials"

If Azure returns a valid access token, authentication is working correctly outside of Wazuh.

You can then test Microsoft Graph directly:

curl -H "Authorization: Bearer ACCESS_TOKEN" \
https://graph.microsoft.com/v1.0/organization

This helps isolate Azure authentication problems from Wazuh configuration issues.

Question: Can expired client secrets cause authentication failures?

Yes.

Expired client secrets are one of the most common causes of Microsoft Graph authentication failures.

When a secret expires, Azure rejects authentication requests and may return errors such as:

AADSTS7000215
Invalid client secret provided

Administrators should routinely monitor expiration dates and rotate secrets before they expire.

Question: Are certificates more secure than client secrets?

In most environments, yes.

Certificate-based authentication offers several advantages:

Stronger cryptographic security
Reduced credential exposure
Improved compliance alignment
Better long-term management

Microsoft generally recommends certificate-based authentication for production integrations and automated workloads.

However, certificates still require lifecycle management and renewal planning.

Question: How do Conditional Access Policies affect Wazuh integrations?

Conditional Access policies can block authentication requests if configured improperly.

Examples include policies that:

Require interactive MFA
Restrict access by location
Enforce device compliance
Block specific authentication methods

When Conditional Access blocks an integration, Azure sign-in logs typically contain details explaining which policy caused the denial.

Question: What is the difference between a 401 and a 403 Graph API error?

The distinction is important during troubleshooting.

HTTP 401 Unauthorized

Authentication failed.

Examples:

Invalid credentials
Expired token
Invalid certificate
Incorrect Client ID

HTTP 403 Forbidden

Authentication succeeded, but authorization failed.

Examples:

Missing permissions
Missing admin consent
Access denied by policy

A 401 points to an authentication problem, while a 403 points to a permissions or authorization issue.

Question: How can I prevent Microsoft Graph authentication failures in the future?

The most effective preventative measures include:

Monitoring secret expiration dates
Tracking certificate renewals
Reviewing Azure sign-in logs regularly
Auditing application permissions
Implementing automated health checks
Monitoring token acquisition failures
Following formal change management procedures
Maintaining current integration documentation

These practices significantly reduce unexpected authentication outages and improve long-term reliability.

Conclusion

Microsoft Graph API integrations provide valuable Microsoft 365 visibility within Wazuh, enabling organizations to collect cloud audit logs, identity events, security alerts, and compliance data from a centralized security platform.

When authentication fails, however, that visibility can disappear entirely, creating potentially dangerous monitoring blind spots.

Throughout this guide, we examined the most common causes of Wazuh Microsoft Graph API Authentication Failures, including:

Incorrect Client IDs and Tenant IDs
Expired or invalid client secrets
Missing Microsoft Graph permissions
Certificate authentication problems
OAuth token acquisition failures
Conditional Access restrictions
MFA-related configuration issues
Network connectivity problems
TLS validation failures
Disabled or deleted Azure application registrations

One of the most important lessons is that successful troubleshooting requires examining both sides of the integration.

Administrators should verify Azure configuration and Wazuh configuration together rather than focusing exclusively on one platform.

Many authentication issues originate in Microsoft Entra ID, while others stem from Wazuh configuration, connectivity, or credential management.

Organizations can significantly reduce future authentication problems by implementing proactive operational controls such as:

Secret expiration monitoring
Certificate lifecycle management
Automated health checks
Azure sign-in log monitoring
Permission audits
Change management procedures
Regular application registration reviews

Final Troubleshooting Checklist

When Microsoft Graph authentication suddenly stops working, use the following checklist:

Verify the Client ID and Tenant ID.
Confirm the application registration still exists.
Check client secret expiration dates.
Validate certificate status and thumbprints.
Review Microsoft Graph API permissions.
Confirm admin consent has been granted.
Examine Azure sign-in logs for failures.
Review Conditional Access policies.
Test network connectivity to Microsoft endpoints.
Verify TLS certificate validation.
Request an OAuth token manually.
Test Microsoft Graph API access outside Wazuh.
Review /var/ossec/logs/ossec.log for errors.
Confirm Microsoft 365 events are flowing into Wazuh again.

Following this systematic approach will help you identify the root cause quickly, restore Microsoft 365 log collection, and maintain reliable Microsoft Graph integrations moving forward.

Recommended Additional Reading