FIM 2010 R2 SP1: Unexpected HTTP 400 Bad Request During Password Reset Registration

In legacy FIM 2010 R2 SP1 environments, deploying the Password Reset Registration and Authentication portals can trigger unexpected HTTP errors. This post addresses a specific HTTP 400 Bad Request encountered during the password reset registration process and offers guidance for resolving it.

Issue

During deployment of the FIM Password Reset Registration and Authentication portals, users encountered a generic browser error:

“HTTP 400 Bad Request”

This error appeared immediately after launching the Registration Portal. No further diagnostic data was available via the browser.

Possible Causes

The portal’s application pool identity lacking required permissions.
Browser/client time mismatch with the server.
Improper DNS configuration or alternate access mapping issues.
Token generation errors due to misconfiguration.

Troubleshooting Steps

Try the following to isolate and resolve the issue:

Check Time Synchronization:
- Ensure the client and server clocks are closely synchronized.
- Time skew can cause token validation failures.
Review IIS Application Pool Identity:
- Verify that the application pool for the portal runs under an appropriate service account.
- Ensure necessary permissions are granted.
Use FQDN in URLs:
- Avoid using localhost or IP addresses.
- Use fully qualified domain names (FQDN) consistently across configurations.
Check HTTP Logs and Event Viewer:
- Examine IIS logs for HTTP 400 entries and reasons.
- Review Event Viewer for .NET or FIM-related messages.

Solution

A confirmed resolution from community feedback:

The issue was resolved after ensuring that the computer clock was synchronized. Once the time was corrected, the HTTP 400 error no longer appeared.

This implies that time skew between client and server was the underlying issue affecting token validation.

Notes

For password reset portals, time synchronization is critical due to time-sensitive tokens used during registration and authentication.
Consider configuring NTP or domain time services to avoid future issues.

Reference

Reconstructed from a Wayback Machine snapshot dated 2013-05-05