Microsoft Sentinel Destination OAuth Token Request Timeout with Error Code "Unknown"

Symptom

The Microsoft Sentinel destination logs intermittent OAuth authentication failures. Destination logs show http request error with code: "unknown" and the OAuth token request timing out after 30 seconds:

"message":"Request timeout url: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token, method: post, timeoutMS: 30000"

Cascading errors follow:

• oauth authentication failed - with exponential backoff retry (nextRetryInMS increasing from 1000ms to 60000ms)
• Sender has too many buffers waiting for retry
• begin backpressure [blocking]
• error while flushing / Sender is at capacity

The failures are intermittent where worker processes cycle in and out of failure independently and the destination may recover for periods before failing again.

If the Sentinel destination's sending source is pushed based and receiving data during the OAuth failure, upstream symptoms may also appear:

• TCP receive window oscillation (reported by the upstream sender).
  • TCP window sizes fluctuate responding to the backpressure signals. This means data flow can stop or slow down.
• When data flow slows down, events can have a timestamp delay (~30+ minutes behind wall clock) due to upstream queuing.

Environment

• Cribl Stream
• Sentinel Destination
• Self-managed/hybrid Workers
• Applies to any version using the Sentinel destination using OAuth authentication
• Customer network includes a firewall using DNS-resolved IPs to allow outbound HTTPS traffic

Resolution

1. Collect a packet capture filtered to login.microsoftonline.com on the affected Cribl worker during a failure window:
   nohup sudo tcpdump -i any -nnvvXSs0 host login.microsoftonline.com and port 443 -C 10 -W 10 -w /tmp/oauth_capture.pcap &
   • This runs in the background and persists across sessions.
   • To stop it, run pgrep -a tcpdump to find the PID.
   • To kill it cleanly, sudo kill <PID>.
   • To validate the nohup tcpdump ended, run pgrep -a tcpdump again and the output should include [1]+  Done.
     [ec2-user@cribl-worker ~]$ nohup sudo tcpdump -i any -nnvvXSs0 host login.microsoftonline.com and port 443 -C 10 -W 10 -w /tmp/oauth_capture.pcap & [1] 4168221 [ec2-user@cribl-worker ~]$ nohup: ignoring input and appending output to 'nohup.out' ^C [ec2-user@cribl-worker ~]$ pgrep -a tcpdump 4168224 tcpdump -i any -nnvvXSs0 host login.microsoftonline.com and port 443 -C 10 -W 10 -w /tmp/oauth_capture.pcap [ec2-user@cribl-worker ~]$ sudo kill 4168224 [ec2-user@cribl-worker ~]$ pgrep -a tcpdump [1]+ Done nohup sudo tcpdump -i any -nnvvXSs0 host login.microsoftonline.com and port 443 -C 10 -W 10 -w /tmp/oauth_capture.pcap
2. Correlate the pcap timestamps with the Cribl destination error logs. If the capture shows SYN packets with no SYN-ACK (TCP retransmissions), the TCP handshake is not completing and the connection is being silently dropped before it reaches Azure.

   

3. Investigate the customer's firewall or proxy rules for outbound access to login.microsoftonline.com. If the firewall allows traffic based on DNS-resolved IPs rather than full subnets, it may cache only a subset of the IPs behind the FQDN. Azure rotates IPs and when DNS resolves to an IP not in the firewall's cached set, the SYN is silently dropped.
4. Replace DNS-based firewall rules with the full subnet ranges published by Microsoft for Azure AD/Entra ID authentication endpoints. The list is maintained at Microsoft 365 URLs and IP address ranges. The ID 56 block will provide both IPv4 and IPv6 subnets.
5. After applying the subnet rules, monitor the Sentinel destination logs to confirm stability.

Cause

In this example, the user’s firewall allowed outbound HTTPS traffic to login.microsoftonline.com based on DNS-resolved IP addresses. However, Azure rotates the IPs behind this FQDN and when the DNS resolved to an IP that the firewall had not cached or included in its allow list, the firewall silently dropped the SYN packet.

The Stream Worker's worker process would retransmit the SYN until the 30-second timeout fired, at which point Cribl logged code: "unknown" because no HTTP response was ever received.

Because each worker process independently manages its own OAuth token lifecycle (~57-minute refresh cycle), the failures appeared to rotate across workers and worker processes, whichever process attempted a token refresh during a window when DNS resolved to a blocked IP would fail, while others with still-valid tokens continued operating normally.

The cascading effects (destination backpressure → TCP push source throttling → upstream queuing → timestamp delay) all traced back to this root cause and resolved once the firewall rules were corrected.

Last Validated

4.16.1

Additional Information

• Distinguish this from other Sentinel OAuth errors. If destination logs show an actual HTTP response code (401, 403, 429), the TCP connection succeeded and the issue is at the application layer (credentials, throttling). The code: "unknown" with a 30-second timeout indicates a network-layer failure where no HTTP response was received at all.
• A curl -v https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token from the worker host may succeed even during a failure window because a single request may resolve to a different (allowed) IP than the one the Stream worker process is attempting.
• Microsoft's Service Principal sign-in logs (Azure Portal → Entra ID → Monitoring → Sign-in logs → Service principal sign-ins) will only show successful authentications. Requests that are dropped at the firewall never reach Azure and will not appear in these logs.
• The Microsoft documentation for the current list of required endpoints and IP ranges: Microsoft 365 URLs and IP address ranges.