Symptom
Control Center stays on the administrator login window. No wrong-password message, no error dialog, nothing in the UI to work with. Typically the failure appears on one server (often development) while production keeps working, and it starts after server maintenance or after a monitoring agent is deployed.
Cause
In the diagnosed case the root cause was a port collision: a monitoring agent (NSClient++, deployed as part of a Centreon setup) was configured to use the same port Exstream serves through its Apache web server. The competing listener prevented the Exstream web path from completing the login flow, and the UI had no way to express that, so it simply did nothing.
The general lesson: a login that hangs without an authentication error is usually not an authentication problem.
Fix
List the listening processes and ports on the affected server and compare them against the Exstream configuration for Apache, Management Gateway, Tomcat, and OTDS.
On Windows, netstat -abno run as administrator shows which executable owns each port.
Once you find the squatter, move the monitoring agent to another port, restart the affected service, and retest Control Center. Do not reset passwords or recreate tenants until port ownership is established; those actions add new variables to a problem that is not about credentials.
If the login still hangs after the ports are clean, verify that Tomcat, OTDS, Management Gateway, and the relevant Service Gateway are all running, then read the Management Gateway and web-server logs for the first failed request.
Put Exstream ports in the shared server inventory
Keep Exstream's port assignments in the server configuration inventory that the operations team actually consults before deploying agents. Monitoring, backup, and security agents are often deployed without checking an Exstream-only document. A shared inventory gives both teams the full port map.