Troubleshooting SSO Pre-Logon Failures on Windows Server After Restart

Table of Contents

This article addresses a specific issue where Single Sign-On (SSO) profiles configured with pre-logon capabilities may fail during the user logon process immediately following a system restart. While SSO is designed to streamline access, this particular scenario can disrupt expected functionality and prevent successful authentication upon the initial login attempt after the operating system has been rebooted. Understanding the root cause and potential workarounds is crucial for administrators managing environments utilizing this feature.

Pre-logon SSO is a feature primarily used with 802.1X authentication, allowing a machine to authenticate to the network before a user logs on. This is essential for applying Group Policy Objects (GPOs), running startup scripts, and ensuring network connectivity is established and secure even when no user is actively logged into the system. The machine authenticates using its own credentials (typically machine certificates or machine account credentials), and then the user can log on, with the authentication process often leveraging the established machine connection.

Symptoms of Pre-Logon Failure¶

When this issue occurs, users attempting to log on for the first time after a system restart will encounter an authentication failure. The system will not be able to connect to the domain controller or logon server required to validate the user’s credentials. This failure is not silent; the user is typically presented with an explicit error message indicating the problem.

The error message commonly displayed is:

There are currently no logon servers available to service the logon request.

This message clearly points to a failure in reaching the necessary infrastructure (like a domain controller) required for user authentication. This situation prevents the user from logging on to their domain account, effectively locking them out until the underlying issue is resolved or a workaround is applied. The visual representation of this error is a standard Windows logon error dialog.

The Underlying Cause: A Race Condition¶

The root cause of this specific pre-logon failure after a restart is identified as a race condition during the Windows boot sequence. A race condition occurs when the output of a process depends on the sequence or timing of other uncontrollable events. In this context, the timing of different service starts is critical.

The issue involves the interaction between the Pre-Logon Authentication Provider (PLAP) logon filter and the services responsible for network interface configuration and 802.1X authentication. These services are primarily the Wired AutoConfig service for wired Ethernet connections and the WLAN AutoConfig service for wireless connections.

During startup, the PLAP logon filter initiates queries for SSO profiles that should be applied. However, the Wired AutoConfig or WLAN AutoConfig services, which are necessary for establishing the 802.1X connection needed for pre-logon authentication, may not have fully initialized by the time PLAP makes its query. If the respective Autoconfig service is still starting up or in an uninitialized state when PLAP checks for configuration, the system will not correctly recognize itself as being SSO-configured with pre-logon capabilities.

Consequently, the machine fails to perform the necessary pre-logon authentication via 802.1X because the underlying network configuration service isn’t ready. This lack of pre-logon network connectivity means the system cannot reach a domain controller when the user attempts to log on, leading to the “no logon servers available” error. The system behaves as if no SSO profile is active, even though one is configured, purely because of the timing mismatch during the boot process.

Deeper Dive into the Components¶

To fully appreciate the race condition, it’s helpful to understand the roles of the involved components:

• Pre-Logon Authentication Provider (PLAP): This is a credential provider loaded during the Windows logon process. Its role is to handle authentication requirements that occur before the standard user logon interface appears, specifically for scenarios like machine authentication for network access. It’s designed to facilitate network connectivity needed for subsequent user logon tasks like profile loading and policy application.
• Wired AutoConfig Service (dot3svc): This Windows service is responsible for implementing the 802.1X authentication protocol for wired Ethernet connections. It manages the configuration and authentication process with network switches or access devices that enforce 802.1X.
• WLAN AutoConfig Service (wlansvc): Similar to its wired counterpart, this service handles 802.1X authentication for wireless networks (WLAN). It manages wireless profiles, scanning, connection establishment, and the authentication exchange with wireless access points.
• 802.1X Authentication: This is a network access control standard that uses EAP (Extensible Authentication Protocol) to authenticate devices connecting to a network. It requires both the supplicant (the client machine) and the authenticator (network switch/AP) to communicate with an authentication server (like RADIUS) to verify the client’s identity before granting network access. Pre-logon SSO relies heavily on the machine performing this 802.1X authentication successfully before the user logs in.

The race condition occurs because PLAP’s dependency on the state of dot3svc or wlansvc isn’t robust enough to wait for their full initialization during a potentially fast or variable boot sequence. If PLAP queries the state or configuration derived from these services too early, it concludes that pre-logon is not configured or possible, leading to the failure.

Workaround¶

While the issue is a confirmed bug, a simple workaround exists to bypass the race condition for the initial logon attempt after a restart. The workaround leverages the fact that subsequent logons or logons from a less restricted network can cache user credentials.

The recommended workaround is to connect the affected client system to a network segment that does not enforce 802.1X authentication for the first logon attempt after a restart. This could be a guest network, a maintenance VLAN, or a network port configured differently.

By connecting to a non-802.1X network, the system isn’t reliant on the potentially problematic pre-logon 802.1X authentication during the boot race. The user can then log on using cached credentials or by successfully authenticating directly over the non-802.1X network connection. Once the user has successfully logged on this first time, the necessary services and configurations related to SSO and 802.1X typically stabilize. Subsequent logons on the 802.1X protected network should then succeed without issue until the next system restart.

This workaround is temporary and applies only to the first logon after a reboot. It does not fix the underlying race condition but provides a method for users to gain access without requiring administrative intervention on the system configuration itself.

Status¶

As per the original information related to this issue, Microsoft has acknowledged and confirmed that this behavior is a problem within their products affecting the interaction of SSO with pre-logon and the 802.1X authentication services during the boot process. This classification as a “confirmed problem” typically indicates that the issue is recognized by the development team.

While confirmation means the problem is known, it doesn’t always immediately imply a forthcoming patch or specific fix outside of standard update cycles. Administrators encountering this frequently in their environment should be aware that it stems from a known timing sensitivity within the operating system boot process.

In-Depth Troubleshooting and Log Collection¶

For administrators facing this issue repeatedly, especially in large deployments, detailed troubleshooting and log collection are essential steps if deciding to open a support case with Microsoft. Simply observing the error message provides the symptom, but understanding why the race condition occurred on a specific system requires digging into system logs and network traces.

Here’s a more detailed approach to gathering information:

1. Check Event Viewer¶

Event Viewer is the first place to look for clues. After a failed logon attempt following a restart, examine the System, Security, and Application logs. Key logs to review include:

• System Log: Look for errors or warnings related to service startup failures, particularly for dot3svc (Wired AutoConfig) and wlansvc (WLAN AutoConfig). Also, check for events related to network adapter initialization and connectivity.
• Security Log: Filter for logon and authentication failures (Event IDs related to 4625 - An account failed to log on). While the primary error is lack of logon servers, the security log might show attempts that failed.
• Microsoft-Windows-Wired-AutoConfig/Operational Log: This specific log (found under Applications and Services Logs -> Microsoft -> Windows) provides detailed information about the 802.1X authentication process for wired connections. Look for authentication failures, timeouts, or service state changes around the boot time.
• Microsoft-Windows-WLAN-AutoConfig/Operational Log: Similarly, this log tracks detailed events for wireless 802.1X authentication. Check for connection attempts, failures, and service status.
• Microsoft-Windows-CAPI2/Operational Log: If certificate-based authentication is used for machine authentication, issues with certificate validation can prevent 802.1X from succeeding. This log provides details on certificate chain validation, trust errors, etc.

Correlate timestamps across these logs during the boot period and the first logon attempt to identify the sequence of events.

2. Verify Service Status¶

Even if services start, their initialization state is key. Manually check the status of the “Wired AutoConfig” and “WLAN AutoConfig” services via the Services console (services.msc) after a successful boot where the issue occurred (e.g., after applying the workaround and logging in). Ensure they are running and set to start automatically. While this doesn’t directly reveal the past race condition, it confirms the services are healthy after the fact.

3. Network Tracing¶

Advanced troubleshooting involves capturing network traffic during the boot process and logon attempt. Tools like netsh trace or Wireshark can be invaluable.

• netsh trace: This built-in command-line tool allows capturing network events system-wide, including detailed information from network components and drivers. You can start a trace before restarting the computer, capture the boot sequence and logon attempt, and then stop and analyze the trace file.

  • Example: netsh trace start scenario=NetConnection,wlan_dbg,lan_dbg capture=yes persistent=yes maxsize=1024
  • Restart the computer.
  • Attempt logon and observe the failure.
  • Log in using the workaround or locally if possible.
  • netsh trace stop
  • Analyze the generated .etl file using Network Monitor or Message Analyzer. Look for EAP packets (specifically EAP- เริ่มຕົ້ນ, EAP- Request/Identity, etc.) around the time of boot and check for responses or lack thereof.

• Wireshark: While more complex to capture during early boot, if the issue is reproducible slightly later or on a test system, a Wireshark capture can provide packet-level details of the 802.1X exchange or the failed attempts to reach a domain controller (e.g., Kerberos errors).

Analyze traces for signs of delayed 802.1X authentication starting, EAP packets not being sent/received, or ARP/DNS failures when trying to contact domain controllers.

4. Configuration Review¶

Review the client’s 802.1X configuration (often distributed via Group Policy or SCCM). Ensure the SSO/pre-logon settings are correctly configured for both machine authentication and user authentication. Verify the authentication method (certificates, PEAP/MSCHAPv2), trusted roots, and server validations are correct. Incorrect configuration, while less likely to cause a race condition specifically, can contribute to general 802.1X failures that might be misattributed.

5. System Information¶

Collect standard system information:
* Operating system version and build number.
* Details of applied Windows updates.
* Network adapter driver versions.
* Group Policy Objects applied to the machine regarding wired/wireless networks and logon settings.

This comprehensive data collection will provide Microsoft support with the necessary context to analyze the issue specific to your environment.

Potential Avenues for Mitigation (Theoretically)¶

While the official status is a confirmed problem, and the primary solution is often awaiting a patch, understanding the race condition might lead to exploring theoretical mitigations, although these should be approached with caution and thorough testing as they involve modifying core system behavior:

• Service Dependencies: Can dependencies be added or modified to ensure dot3svc or wlansvc are fully initialized before components of PLAP or the logon process attempt to leverage their state? This is a complex area and incorrect modifications could lead to boot issues.
• Delayed Tasks: Could a scheduled task be configured to run at startup with a delay, performing a check or action that might ‘kickstart’ the process? This is hacky and not a recommended enterprise solution.
• Registry Modifications: Are there undocumented registry keys that control timing or retry behavior for PLAP or the Autoconfig services? Modifying the registry without specific guidance from Microsoft is highly risky.

Given the status, the most prudent approach is to utilize the provided workaround and engage Microsoft support if the issue causes significant operational disruption, providing them with the detailed logs collected. This helps Microsoft understand the prevalence and impact of the bug, potentially prioritizing a fix.

Conclusion¶

The failure of SSO pre-logon after a Windows restart, manifesting as the “no logon servers available” error, is a specific issue caused by a timing conflict during the system boot process between the Pre-Logon Authentication Provider and the Wired/WLAN AutoConfig services responsible for 802.1X authentication. While a confirmed problem by Microsoft, it can be temporarily mitigated by connecting the affected system to a non-802.1X network for the initial logon after a reboot.

Administrators encountering this issue should leverage system event logs and network tracing tools to gather detailed information if pursuing a support case. Understanding the interaction of the involved services and the nature of the race condition is key to both applying the workaround effectively and assisting in the potential development of a future resolution.

Have you encountered this specific SSO pre-logon failure? What troubleshooting steps did you find most useful? Share your experiences and insights in the comments below.