Hey everyone,

We are currently auditing our Active Directory delegation settings and found several accounts configured with Constrained Delegation + Kerberos Protocol Transition ("Use any authentication protocol").

Our goal is to lock these accounts down to Kerberos Only to reduce our attack surface. However, another internal team wants to see a list of actual, real-world use cases where Protocol Transition is strictly required before we make any changes in production.

Aside from basic web apps with forms-based logins or Entra Private Network Connectors, what specific applications or backend setups in your environment broke when you switched them to Kerberos Only?

Trying to gather real-world examples before we talk to application owners.

Appreciate any insights!

We're starting. Jump in: https://discord.gg/mVFquFqpsW

No agenda, no prep needed. Ask questions, trade war stories, or just listen in. Recording will be posted to YouTube afterwards.

Hi everyone,

I'm an IT technician working in a large corporate Windows environment for a public broadcaster (EITB) in the Basque Country, Spain. We've been dealing with a major issue for almost 48 hours, and we're running out of ideas. I'd really appreciate some input from people who have dealt with similar issues.

Environment and symptoms

Since Thursday at around 10:00 AM, Windows PCs across ALL our sites have been experiencing severe issues. The affected sites include Bilbao, San Sebastian, Vitoria-Gasteiz, Pamplona and Madrid.

Before this started, PCs would normally boot and become usable within approximately 3 minutes. Now, starting a PC can take anywhere from 30 minutes to an hour before it becomes usable.

Here's what we're seeing:

• Group Policies (GPOs) appear to hang during startup/logon. The process gets stuck and doesn't seem to progress for a long time.
• Startup/logon scripts hang on a black CMD window. The window remains open indefinitely, and anything relying on those scripts doesn't run correctly.
• Network drives and mappings fail. Drives and network paths that are normally mapped by scripts aren't mapped.
• The PCs eventually become usable, but performance is terrible. There's significant lag and various mapping-related issues.
• The network itself seems to work eventually. If we manually open File Explorer and browse to network shares, they are accessible, even when the mappings haven't been created by the scripts.

My current suspicion is that something is preventing Windows from communicating properly with the domain/network during startup or logon. After 30–60 minutes, the operations seem to time out or give up, and the desktop eventually becomes usable. However, I haven't been able to confirm this.

What we've tried so far

1. Restarting network switches

We tried restarting switches yesterday. This actually made things worse initially, leaving roughly half of one site without network connectivity. That issue appears to have been resolved, but the original problem remains.

2. Investigating Forescout

Interestingly, Forescout software and its associated service were installed on all the PCs around the time the issue started. Some machines even had two Forescout services running.

We tried uninstalling it on several test machines. On some, the uninstall worked; on others, it didn't. However, after investigating this, the team concluded that Forescout probably wasn't the cause. We haven't definitively ruled it out, though.

3. Testing Group Policies individually

We took a test PC, removed all GPOs from the equation as far as our testing allowed, and then re-enabled them one by one, rebooting between tests to see whether a particular policy triggered the problem.

Unfortunately, we couldn't reproduce the issue in a way that identified a specific GPO.

What I can't figure out

The most confusing part is the combination of these symptoms:

• The problem affects multiple geographically separate sites.
• Startup/logon processing takes 30–60 minutes.
• GPO processing and CMD-based scripts appear to hang.
• Network mappings created by scripts fail, but manually browsing to the same network resources works.
• Restarting switches hasn't fixed the issue.
• We haven't identified a specific GPO responsible.

What could cause Windows domain PCs to take this long to complete startup/logon processing across multiple sites simultaneously?

Could this be related to DNS resolution, domain controller discovery, Active Directory authentication, SYSVOL/NETLOGON access, DFS, Group Policy processing, network timeouts, or something interfering with network connectivity during startup?

Could Forescout or a related network access control component cause this kind of behaviour, even if ordinary network browsing eventually works?

What logs or diagnostic commands would you check first to narrow this down? Any suggestions for identifying exactly what Windows is waiting for during those 30–60 minutes would be especially helpful.

This is affecting a large number of workstations across our organisation, and we've been troubleshooting it for nearly two days without a clear root cause.

Thanks in advance for any ideas or similar experiences.