While troubleshooting a password rotation failure on a server, an unusual issue came to light: the server was no longer updating credentials. Diving into the logs, the following recurring error stood out:
Error: MainThread : System.Exception: Error posting information about Domain with CentralHost.
This error indicated a breakdown in communication between the affected server and the TechIDManager server.
1st thing to check:
The most likely culprit is when the TechIDAgent cannot reach the TechIDHost. This can be caused by DNS or certificate issues along with the Host simply being offline. This can be tested by going to https://ch001.ruffiansoftware.com/management/time, thus sending a get request to the TechIDHost. If it returns the time of the day, this is not your issue.
2nd thing to check:
The second culprit to check is when the TechIDAgent attempted to initiate a connection with the TechIDHost, the request was being silently ignored.
The root cause here might have to do with our security features.
In our zero trust environment, all communication between a TechIDAgent and the TechIDHost must be verified using public-private key pairs. This security mechanism was introduced with TechIDManager 5.0 to ensure strict identity validation and secure data exchange.
However, issues arise when one of these keys is altered, becomes invalid, or gets corrupted. When a TechIDAgent presents a mismatched or faulty key, the TechIDHost cannot verify its identity. As a result, the host server rejects the request without response. In zero trust terms: no verification means no trust—and no trust means no action.
The Fix: Re-establishing Trust
To resolve this issue, follow these steps in the TechIDPortal:
- Locate the affected TechIDAgent within the portal.
- Open the agent’s detail screen.
- Scroll to the bottom of the page and click “Clear Public Key.”
This action clears the existing key and prompts the TechIDAgent to generate and upload a new public key. The TechIDHost will then accept this new key as the trusted one, restoring secure communication between the two endpoints.
Conclusion:
Communication failures in zero trust systems can be subtle but impactful. It is important to determine if there is NO communication or if communication is being ignored. If no communication, most likely there is a DNS or certificate issue or the TechIDHost is offline. When key mismatches occur, resolving the issue is as simple as revalidating the identity of the TechIDAgent. Using the Clear Public Key option allows trust to be re-established, ensuring that automated processes like password rotation continue smoothly and securely.
