OAuth2-Tokenabruf per client_credentials von dediziertem Linux-Server scheitert mit sofortigem HTTP 404 vom Microsoft Gateway

Hello @Nasgol Bakhtiari
Thank you for the additional details.

Based on the information provided, an immediate HTTP 404 Not Found response returned directly by the Microsoft Gateway, while the identical request succeeds from a different network, suggests that the application configuration and client credentials are likely valid. The behavior appears to be network-specific and may be related to DNS resolution, proxy configuration, firewall inspection, request modification, or routing from the affected environment.

To further investigate, please help us with the following:

Verify that the token endpoint URL is correctly formatted and accessible from the affected Linux server. https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token

Test access to the OpenID configuration endpoint from the same server and share the results.
curl -v https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration

Compare DNS resolution results between the affected server and a network where the request succeeds.
nslookup login.microsoftonline.com

If a proxy, WAF, firewall, or SSL inspection device is present, review its logs to determine whether the request is being modified or redirected before reaching Microsoft services.

Capture and share verbose output from the request (with sensitive information removed), including the complete response headers.
curl -vvv -X POST <token-endpoint>

Additionally, please provide:

• The public source IP address of the affected server.  
• The full HTTP response headers associated with the 404 responses.  
• Any proxy or network security devices present in the outbound path.

This information will help determine whether the request is reaching the Microsoft Entra endpoint as expected or whether the traffic is being altered before it arrives at the service.

References: Troubleshooting-signature-validation-errors
v2-oauth2-client-creds-grant-flow

We look forward to your update.

Hi, many thanks for your response. following is the curl call from affected server.

curl -v -X POST "https://login.microsoftonline.com/18a94d4e-931b-4393-86da-76f0015f6990/oauth2/v2.0/token" -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=48af8abd-275a-4bc5-b753-56df254b63c9" -d "client_secret=<mysecret>" -d "scope=https://graph.microsoft.com/.default" -d "grant_type=client_credentials"

Note: Unnecessary use of -X or --request, POST is already inferred.

• Host login.microsoftonline.com:443 was resolved.
• IPv6: (none)
• IPv4: 40.126.32.68, 40.126.32.138, 40.126.32.74, 20.190.160.132, 20.190.160.14, 40.126.32.72, 40.126.32.140, 20.190.160.2
• Trying 40.126.32.68:443...
• ALPN: curl offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / secp384r1 / RSASSA-PSS
• ALPN: server did not agree on a protocol. Uses default.
• Server certificate:
• subject: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; CN=stamp2.login.microsoftonline.com
• start date: Jun 12 00:00:00 2026 GMT
• expire date: Dec 9 23:59:59 2026 GMT
• subjectAltName: host "login.microsoftonline.com" matched cert's "login.microsoftonline.com"
• issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
• SSL certificate verify ok.
• Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
• Connected to login.microsoftonline.com (40.126.32.68) port 443
• using HTTP/1.x

POST /18a94d4e-931b-4393-86da-76f0015f6990/oauth2/v2.0/token HTTP/1.1

Host: login.microsoftonline.com

Accept: /

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Content-Type: application/x-www-form-urlencoded

Content-Length: 174

• upload completely sent off: 174 bytes
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):

< HTTP/1.1 404 NotFound

< Content-Type: text/HTML

< Set-Cookie: x-ms-gateway-slice=estsfd; path=/; secure; samesite=none; httponly

< client-request-id: 1dfdf13c-cc00-4c28-a6df-7d1ef7f25010

< Date: Mon, 10 Aug 2026 18:37:02 GMT

< Content-Length: 10

<

• Connection #0 to host login.microsoftonline.com left intact

Title:

HTTP 404 NotFound at the Entra OAuth2 token endpoint only from public IP 212.227.203.51 during client_credentials flow

Description:

We are consistently receiving HTTP/1.1 404 NotFound when requesting an OAuth2 token through the client_credentials flow from our dedicated Linux server with public IP 212.227.203.51 against the Microsoft Entra token endpoint:

https://login.microsoftonline.com/18a94d4e-931b-4393-86da-76f0015f6990/oauth2/v2.0/token

The identical raw request succeeds from a different network and returns HTTP/1.1 200 OK with a JSON response.

Behavior from the affected server:

• HTTP/1.1 404 NotFound
• Content-Type: text/HTML
• Content-Length: 10
• Response body: Not Found.
• x-ms-gateway-slice=estsfd

Example identifiers:

• client-request-id: dc2906c1-5447-416f-ae1f-ca665186bec4
• client-request-id: 1dfdf13c-cc00-4c28-a6df-7d1ef7f25010
• client-request-id: 83c50176-5593-402d-b158-2416d4165fdf

Example timestamps:

• 11 Aug 2026 12:49:47 GMT
• 10 Aug 2026 18:37:02 GMT
• 06 Aug 2026 14:46:20 GMT

Checks already completed:

• DNS resolution for login.microsoftonline.com is correct
• TLS handshake succeeds
• Certificate is valid and issued to Microsoft
• No local proxy is configured, and testing with --noproxy '*' still fails
• No difference between HTTP/1.1 and HTTP/2
• Different User-Agent tests had no impact
• Request path, host, Content-Type, Content-Length, and request body are effectively identical between the working and failing traces
• No sign-in logs are generated in the tenant for these failed requests

Technical assessment:

The request reaches Microsoft edge successfully, but for the affected source IP it is terminated before normal Entra token processing with a generic HTML 404 response. Because the exact same raw request is processed successfully from another network, the evidence strongly suggests a source-IP-specific edge, routing, or access issue, or a very early service-side behavior before normal Entra authentication logic is reached.

Please investigate a source-IP-specific issue affecting public IP 212.227.203.51 when accessing the token endpoint above.

Hello, I would like to know how to open a support ticket regarding a blocked IP address. Thank you for your reply.

Hello, is there any chance to get support here?