Multiple machines experience extremely slow login to Windows machines with WSS Agent

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

A number of users reporting experiencing a issue with WSS Agent version 9.7.1, where multiple machines show extremely slow login times.

Although SAML authentication is enabled, the delay visible it to the local Windows login page and not the Cloud SWG SAML Identity provider authentication page.

Some of these users hosts were upgraded to 9.8.1 but without any changes.

Users report boot times of between 4 and 10 minutes before the local login succeeds.

Removing the WSS agent reduces login time to approximately 1 minute, while reinstalling it reintroduces the delay.

Environment

WSS Agent.

Windows Active Directory.

Kerberos authentication.

SAML Authentication.

Cause

Local AD communication required for authentication going outside the region.

Resolution

Enabled Windows AD sites policy for local local network users to restrict communication locally and avoid going to KDC servers in other regions.

Additional Information

Taking a Symdiag with the reboot enabled option confirmed that the delays were with local login only (visible from the Windows event logs); when the local login completed, the WSS Agent initialisation and SAML login went through quickly.

In the snippet below, we see a huge delay authenticating the local user ... the logs which shows the auth process starts at 16:40:00 local time, and completes where we see user1 user at 16:44:07. This means that it has taken the host 4 mins 7 seconds to log the user in.

[10-31-2025 16:39:55 (UTC+5:30)]: Initial routing configuration - waiting for route to ctc.threatpulse.com
[10-31-2025 16:40:00 (UTC+5:30)]: Waiting for console user to log in
[10-31-2025 16:40:29 (UTC+5:30)]: Routing has changed - traffic to ctc.threatpulse.com now routed through interface with address: 10.1.1.1
[10-31-2025 16:44:07 (UTC+5:30)]: User USER1 has logged in - continuing CTC

The actual SAML authentication takes place much later and completes very quickly.

[10-31-2025 16:44:37 (UTC+5:30)]: Waiting for user authentication (DOMAIN\USER1)
[10-31-2025 16:44:44 (UTC+5:30)]: Authentication succeeded (DOMAIN\USER1)
[10-31-2025 16:44:45 (UTC+5:30)]: Sending traffic as [email protected]

Symdiag with reboots do not offer ability to capture PCAPs unfortunately, making it hard to understand the communication from the host at startup.

Mirroring a port on the local switch allowed us to gather PCAP at startup, and found communication to a KDC IP address (TCP port 88) in another region completely that was not responding. The user credentials should be taken from cache, yet we still saw the KDC comms.

Assumption is that the KDC communication retries a few times before eventually doing a fallback to cached credentials.

 

Slow Windows domain logins are often caused by DNS issues (DCs not primary DNS), Group Policy (GPO) processing, slow startup programs, network latency, or profile issues. If the user does not log quickly in a WSS Agent environment, a number of issues could be happening: :

• Agents are not installed with AU=unauthenticated, so SAML authentication is required
  • Until SAML is authenticated, we will block network access
• Agent have a login script that is trying to run that it accessing an external service and is blocked
  • User may not log in until the script is completed (but it will time out because we're blocking it)
• WSS Agent cannot launch the UI to prompt for SAML until they are logged in (because it requires a console user to be able to launch the UI)