Very slow admin logon

Help for v3
1

We have a small network running Windows 2003 and are using COMODO V3. When one of the regular users logs in to his/her computer they log right in without a problem but when I try to log in to their PC with my admin account it takes a good 10-15 minutes to get to the desktop. It sits at “applying personal settings” the whole time then slowly will load the desktop.

I had to reimage a machine and installed COMODO last, I could log in and out very quickly with my account UNTIL I installed COMODO, as soon as i installed comodo i logged off then back on and it sat there for 10 minutes. Before the install I was in in less than 1

What could be causing this lag on the admin account? where can i start troubleshooting this?

2

Sounds like there might be a possible software conflict.

Can you name some Security Software on your machine?

Josh

3

We are running symantec 10.1 (i know i know). If it is a software conflict how come the standard users can log on to the very same PC and get in immediately, it’s only the admin account that is slow to log on

4

bump…any ideas?

5

Make sure that all Symantec components have permission in D+. Also make them Trusted applications in D+. Open Comodo → Defense+ → Common Tasks → My own safe files. Use browse running processes under Add to add all Symantec related stuff.

6

Bump…still having this slow admin logon issue. Even with Defense+ disabled it still takes me a long time to get to the desktop with my admin account, regular users log in quickly with no issues.

Any ideas?

7

This sounds a lot like the authentication problem that showed up in another topic https://forums.comodo.com/help_for_v3/cfp3_in_a_domain_environment_resolved-t23841.0.html right down to the 15 minute delay.

Short summary is that Windows domain authentication is using UDP for kerberos, causing all manner of delay. The fix is to force authentication to use TCP, as described in How to force Kerberos to use TCP instead of UDP in Windows - Windows Server | Microsoft Learn

8

Thank you Grue! That thread mentions the exact problems I am having, long login times and messed up drive mappings. I guess the regular users could get in becasue their profiles are very small.

One question though, is there any security concerns with using TCP instead of UDP for Kerberos?

9
One question though, is there any security concerns with using TCP instead of UDP for Kerberos?

Not that I’m aware of. In my opinion, TCP is a better choice as it is considerably harder to spoof. I don’t know the reasoning in why Kerberos uses UDP, and I’m sure that at that time, it made sense. I don’t know that it does these days.