A cloud-based identity and access management service for securing user authentication and resource access
The failure pattern points to Pass-through Authentication request timeout between Microsoft Entra ID and the on-premises Authentication Agent, not MFA.
Most relevant facts from the symptoms:
-
AADSTS80002means the Authentication Agent password validation request timed out. - A single active PTA agent is a single point of failure. If that agent faults or loses its cloud connection during sign-in, the request is dropped and is not handed off to another on-premises agent.
- Agent logs showing the PTA listener went offline/faulted and that the connection was forcibly closed by the remote host aligns with a PTA connectivity or agent health problem.
Recommended troubleshooting path:
- In Microsoft Entra admin center → Microsoft Entra Connect, confirm:
- Pass-through Authentication is still Enabled.
- The Authentication Agent status is Active.
- On
PMPIL-DC01.pmpil.cloud, review PTA logs in these locations:- Event Viewer → Application and Service Logs\Microsoft\AzureAdConnect\AuthenticationAgent\Admin
- Trace logs:
%ProgramData%\Microsoft\Azure AD Connect Authentication Agent\Trace\
- For the failed sign-ins, correlate the timestamp in Entra sign-in logs with the agent trace entries. For PTA failures, the trace logs record the reason for the failed sign-in. If a numeric reason appears, decode it with:
Net helpmsg <error number> - Validate that Active Directory is reachable from the Authentication Agent during the failure window. For
80002, the documented resolution is to check whether Active Directory is reachable from the Authentication Agent. - Validate outbound connectivity from the Authentication Agent server to the required Microsoft service URLs and ports. Registration and enablement failures caused by blocked ports use the same prerequisite requirement, and a listener going offline or losing connection is consistent with connectivity interruption.
- Because only one PTA agent is deployed, add at least one more Authentication Agent for high availability. This reduces sign-in impact if the current agent faults or disconnects.
- If users are restricted with the Active Directory Logon To setting, ensure servers hosting PTA agents are included in the allowed server list. PTA agents validate credentials through the Win32
LogonUserAPI, and missing PTA servers in that list can block sign-in. - If the issue continues after connectivity checks, install and register a new Authentication Agent, then remove the current one only after the replacement is healthy. This is specifically documented for persistent agent-side decryption issues, and it is also the safest recovery path when the only agent appears unstable. Risk: removing the only working agent before a replacement is active can break all PTA sign-ins.
- If the problem persists, collect the agent logs and open a Microsoft support case. This is the documented next step for unexpected Authentication Agent errors. Include the error code, correlation ID, and timestamp from affected sign-ins.
About checking recent authentication or Conditional Access policy changes:
- The available guidance supports using Entra ID → Sign-ins to inspect failed sign-ins and their details.
- The provided material does not include a supported method to determine whether a Conditional Access or authentication policy changed at the time the issue started.
- Since the failures are occurring at single-factor stage with
AADSTS80002, the strongest supported conclusion is PTA agent timeout/connectivity rather than MFA policy enforcement.
Given the evidence already collected, the highest-priority actions are:
- Review PTA trace and event logs on
PMPIL-DC01.pmpil.cloudat the exact failure times. - Verify outbound connectivity from that server to required PTA service endpoints over port 443.
- Add a second PTA Authentication Agent.
- Escalate with collected logs if the listener continues to fault or go offline.
References: