Troubleshooting SSO Authentication Failures: HTTP 404 on STS Endpoint

By Bikram Bhujel  |  April 2026  |  6 min read  |  Category: Networking, Windows, Home Server

Users on corporate networks sometimes hit a wall during single sign-on login, seeing a "We can't connect you" error backed by an HTTP 404 on the Security Token Service endpoint. The application is running. The credentials are correct. The issue is the network underneath. This guide explains why it happens, how to confirm the diagnosis, and the exact steps to resolve it.

Table of Contents

1. What Is Actually Happening
2. Root Causes: Three DNS Scenarios
3. Confirming the Diagnosis
4. Step 1: The Network Swap Test
5. Step 2: Clear the DNS Cache
6. Step 3: Reset the Application Identity
7. What IT Teams Need to Do
8. Quick Reference Table
9. Frequently Asked Questions

THE PROBLEM

What Is Actually Happening

Single sign-on authentication relies on a Security Token Service (STS) to issue and validate identity tokens. When a user clicks sign-in, the application redirects their request to the STS endpoint, for example sts.example.com. That service validates the credentials and returns a token the application trusts.

An HTTP 404 on that request means the client machine successfully reached a server but received a "resource not found" response. That is different from a connection timeout or a refused connection. A 404 specifically means the address resolved to something, but what it found at that address was not the STS service the application expected.

In plain terms: the machine is being directed to the wrong place. It thinks it knows where the authentication server lives, but the address it has on file is stale, incorrect, or being intercepted by something in the network path.

Common misconception: Users and helpdesk staff often assume a 404 during login means the authentication server is down. In most cases the server is running fine. The problem is that the client machine cannot find the correct IP address for it because of a DNS issue on the local network segment.

ROOT CAUSE

Root Causes: Three DNS Scenarios

1. Stale DNS Records

DNS servers cache records to reduce lookup time. When an STS endpoint moves to a new IP address, or when the authentication infrastructure is updated, local DNS servers sometimes hold onto the old address longer than they should. The Time to Live (TTL) value on the record controls how long a cache entry stays valid, but network equipment does not always honor these values correctly, particularly on older hardware or manually managed DNS configurations.

A client machine asking its local DNS server for the IP address of sts.example.com may receive an outdated address that no longer hosts the authentication service. The request reaches a server that exists, which is why you get a 404 rather than a timeout, but it is not the right server.

2. Firewall or Traffic Filtering Rules

Corporate networks often run deep packet inspection, URL filtering, or proxy rules that intercept requests to certain endpoints. If a security appliance or proxy configuration has an outdated rule for the authentication service URL, it may redirect authentication traffic to an internal page rather than allowing it to pass through to the STS. That internal redirect page returns a 404 because it has no content to serve for that request path.

This scenario is more common after infrastructure changes such as migrating the STS to a new platform or updating authentication URLs, where the firewall rules are not updated in sync with the endpoint changes.

3. VLAN Specific DNS Configuration

Many enterprise networks segment users into different VLANs: standard user networks, guest networks, executive networks, IT networks, and so on. Each VLAN may be configured to use a different DNS server, and those DNS servers do not always have identical records. A user on the standard corporate VLAN may be assigned a DNS server that has a stale or misconfigured record for the STS endpoint, while the same lookup from a guest VLAN resolves correctly because it uses a different DNS server that has the current record.

This VLAN discrepancy is the most common pattern in enterprise SSO failures of this type. The issue is not the user's machine. It is the DNS infrastructure on their specific network segment.

DIAGNOSIS

Confirming the Diagnosis

Before spending time on fixes, confirm that DNS is actually the problem. Open Command Prompt and run a DNS lookup against the STS hostname:

nslookup sts.example.com

Note the IP address returned. Then run the same command specifying a public DNS resolver:

nslookup sts.example.com 8.8.8.8

If the two IP addresses differ, the local DNS server is returning a different record than the authoritative global DNS. That confirms a stale or misconfigured local DNS entry is the root cause. If the addresses match but the 404 persists, the issue is more likely a firewall or proxy rule intercepting the traffic.

Quick check using ping: Run ping sts.example.com and note the IP address it resolves to. If that address is different from what you see when the same hostname is accessed from a machine outside the corporate network, the local DNS is the culprit.

STEP 1

Step 1: The Network Swap Test

Action

Disconnect from the primary corporate network and connect to either a guest Wi-Fi network or a mobile hotspot from a phone. Then attempt the SSO login again.

This test immediately tells you whether the problem is the machine or the network. A guest network and a mobile hotspot both use DNS servers outside the corporate infrastructure. If login succeeds on either of these networks but fails on the corporate LAN, the diagnosis is confirmed: the corporate network's DNS is the issue, not the user's device, not the credentials, and not the authentication service itself.

This also doubles as a temporary workaround that lets affected users stay productive. They can connect to guest Wi-Fi to complete authentication, then return to the corporate network for other tasks. It is not a permanent fix but it keeps work moving while IT investigates the underlying DNS problem.

Security note for IT teams: Allowing users to authenticate through guest networks is a reasonable short term workaround, but it bypasses the network controls on the primary corporate LAN. Document this workaround, monitor for it, and treat it as temporary rather than a long term solution.

STEP 2

Step 2: Clear the DNS Cache

Action

Open Command Prompt as administrator and run the following command:

ipconfig /flushdns

This clears all cached DNS records from the local machine. The next time the machine needs to resolve any hostname, including the STS endpoint, it will send a fresh query to the DNS server rather than using a locally cached address.

On its own, flushing the DNS cache only helps if the problem is a stale record stored on the user's machine rather than on the network's DNS server. If the corporate DNS server itself holds a bad record, flushing the local cache will just result in the machine fetching the same bad address again from the network DNS. However, it is a quick and harmless step that eliminates one variable before moving to network-level investigation.

After running the flush, attempt the SSO login again while still on the corporate network. If it now succeeds, the stale record was cached locally. If it still fails, the DNS server on the network is the source of the problem and the fix needs to happen there.

STEP 3

Step 3: Reset the Application Identity

Action

Sign out of the application completely. Clear the cache of the system's default web browser. Then attempt sign-in again while connected to the alternate network (guest Wi-Fi or hotspot) confirmed to work in Step 1.

Applications that use browser-based authentication flows store session tokens and authentication state in the browser cache. If a failed authentication attempt created a corrupted or partial token, subsequent sign-in attempts on the same session may inherit that broken state even after the DNS issue is resolved.

Clearing the browser cache forces the application to start the authentication flow from scratch. Combined with being on a network where DNS resolves correctly, this ensures a clean token exchange with the STS.

In most browsers, cache clearing is found under Settings or Preferences, in the Privacy or History section. The specific option to clear is "Cached images and files" or "Browsing data." Cookies can be cleared as well if sign-out alone did not fully remove the application session.

Shortcut: In most browsers, pressing Ctrl and Shift and Delete together opens the clear browsing data dialog directly. Select "All time" as the time range to ensure nothing is left behind from previous sessions.

FOR IT ADMINISTRATORS

What IT Teams Need to Do

The user-side steps above are workarounds. The permanent fix requires correcting the DNS records on the corporate network infrastructure. Once the network swap test has confirmed DNS as the root cause, the following actions should be taken on the network side.

Flush DNS Cache on the Internal DNS Server

On Windows Server DNS, open DNS Manager, right click the server name, and select "Clear Cache." On Linux-based DNS servers running BIND, restart the named service or run rndc flush. This forces the DNS server to pull fresh records from upstream authoritative servers rather than serving stale cached data.

Verify the STS Hostname Resolution

From the DNS server itself, run an nslookup or dig query against the STS hostname and confirm the IP address matches what the STS is actually hosted at. If it does not match, either the DNS zone record needs updating or the upstream provider has changed their IP and the change has not yet propagated to the internal DNS server.

Check Firewall and Proxy Rules

If DNS records look correct but the 404 persists on the corporate network, review firewall policies and proxy configurations for rules that match the STS URL or IP range. Look for redirect rules, SSL inspection policies, or content filtering rules that might be intercepting authentication traffic. Temporarily bypassing the proxy for the STS hostname is a useful diagnostic step.

Review VLAN-Specific DNS Configuration

If only users on specific VLANs are affected, compare the DNS server assignments across those VLANs. The affected VLAN's DNS server may not be syncing correctly with the primary internal DNS, or it may have a manually configured record that was not updated when the STS was last modified.

Quick Reference Table

Symptom	Likely Cause	Fix	Who Resolves It
404 on corporate LAN, works on guest Wi-Fi	Stale DNS on corporate network	Flush DNS server cache, update STS record	IT administrator
404 on corporate LAN, works on hotspot	Same as above or firewall rule	DNS flush plus proxy/firewall review	IT administrator
404 after recent STS migration	Firewall or proxy rule pointing to old IP	Update firewall rules to new STS IP	Network/security team
Only specific VLAN users affected	VLAN-specific DNS misconfiguration	Sync DNS records across VLANs	Network team
Immediate fix needed for user	Any of the above	Connect to guest Wi-Fi or mobile hotspot	End user (temporary)
404 persists after DNS flush	DNS server itself has bad record	ipconfig /flushdns then check server-side DNS	IT administrator

Frequently Asked Questions

What does HTTP 404 mean during SSO login?

An HTTP 404 during SSO authentication means the client machine successfully reached a server but that server returned a "not found" response for the requested resource. In the context of SSO, this typically means the machine resolved the Security Token Service hostname to the wrong IP address, either because of a stale DNS cache entry or a misconfigured DNS record on the local network. The STS itself is usually running normally. The client is just being directed to the wrong location.

Why does SSO work on guest Wi-Fi but not on the corporate network?

Guest Wi-Fi networks typically use a different DNS server than the corporate LAN, often a public resolver or the ISP's DNS. If the corporate network's internal DNS server has a stale or incorrect record for the SSO authentication endpoint, users on that network get directed to the wrong address. Users on the guest network bypass the corporate DNS entirely and get a fresh, correct resolution. This behavior is a reliable confirmation that DNS on the corporate network is the root cause.

How do I flush the DNS cache on Windows?

Open Command Prompt as administrator and run the command: ipconfig /flushdns. This clears all DNS records cached locally on the machine. After running it, the machine will query the network DNS server fresh for any hostname it needs to resolve. Note that this only clears the local machine's cache. If the DNS server on the network also holds a stale record, the machine will simply fetch the bad address again from the server. A persistent problem after flushing points to the server-side DNS as the source.

What is a Security Token Service (STS)?

A Security Token Service is a server that issues, validates, and renews security tokens used in authentication systems. When a user signs into an application that uses single sign-on, the application redirects the login request to the STS. The STS validates the identity, issues a token, and returns it to the application. The application trusts the token without needing to handle credential verification itself. Common STS implementations include Active Directory Federation Services (ADFS), Azure AD, and various third-party identity providers.

Can a firewall cause SSO 404 errors?

Yes. A firewall or proxy with SSL inspection or URL filtering rules can intercept authentication traffic and return a 404 if its rules are not updated to reflect the current STS endpoint. This is common after infrastructure migrations where the STS moves to a new URL or IP address but the firewall rules reference the old location. In this scenario, DNS may resolve correctly but the traffic is still being redirected to the wrong destination by a network security appliance. Reviewing proxy bypass rules and firewall policies for the STS hostname is the appropriate diagnostic step when DNS appears clean but the 404 persists.

How do I check if DNS is returning the wrong IP address for the STS?

Open Command Prompt and run nslookup followed by the STS hostname. Note the IP address returned. Then run the same command specifying a public DNS resolver such as 8.8.8.8 by adding it after the hostname. If the two commands return different IP addresses, the local or corporate DNS server is holding a different record than the authoritative global DNS. The address returned by the public resolver is the correct current address. The address returned by the local resolver is stale and needs to be corrected on the internal DNS server.

Is it safe to use guest Wi-Fi as a workaround for SSO authentication?

Using guest Wi-Fi to complete the initial authentication handshake is a reasonable short term workaround that keeps users productive while the underlying DNS issue is being resolved. The security trade-off is that the authentication happens outside the corporate network controls. IT teams should be informed when this workaround is in use and should treat it as temporary. Once the DNS records on the corporate network are corrected, authentication should work normally on the primary LAN and the workaround is no longer needed.

---