Slow AD logon if username longer than 8 chars

  • Thread starter Thread starter TheBlob
  • Start date Start date
T

TheBlob

Hi all.

I have a problem with some (not all) remote sites clients that take a
veeeery long long time to login, and I'm talking about 30+ minutes, if
they ever manage to logon.

This happens only on some clients and only with some users.

At first I pinpointed the problem to the "home directory" setting, that
pointed to w: -> \\myserver\users$\%username%
By coincidence I discovered that removing the home directory mapping
from the user profile (in the AD management console), the logon was
almost instantaneous.
I simply started to map the home directory within the login script, with
a line like this:

net use W: \\myserver\users$\%username%

If I use instead this other line I get the slow logon again

net use w: /HOME

NOW, the problem has returned...logon sloooow again.

Only way I managed to find was to shorten the username to something
equal or shorter than 8 chars...

My AD DC are all Win2000 , I have primary and secondary DNS and WINS
located on the first two servers, which are in the central site.
The "slow logon" pcs are in peripheric sites, connected with slower
lines.
The problem is very curious because in these very same "slow" sites I
have lots of "fast logon" pcs.

Some things I tried are:

- recreate the user profile from scratch
- check DNS settings, including suffixes
- gpupdate (or "secedit /refreshpolicy user_policy /enforce" and secedit
/refreshpolicy machine_policy /enforce on win2000 clients)
- disable slow link detection

All machines (servers and clients) are patched with WSUS.

Please help me!

Thank you in advance

Michele
 
I'll try a network monitor capture when you do that mapping and see exactly
what is happening.
 
someting @ said:
I'll try a network monitor capture when you do that mapping and see exactly
what is happening.
Click to expand...

Hello Andrei, do you mean something like NetMon from Sysinternals or
something like tcpdump?

By the way this morning I tried to add the registry key as Larry
suggested but it worsened the slowness!
And, also, I must say that by shortening the username in the user
profile (both "user logon name" and "user logon name (pre-Windows2000)")
to make it 8 chars (before it was 9) the logon process took 21 seconds
instead of 35 minutes!

There really is some correlation for this "short username-fast logon"
thing...all it comes to my mind that there could be some ancient DOS
thing involved. But I can't put my finger on it...

Bye

Michele
 
Try Wireshark (ex-ethereal).
www.wireshark.org
I do not think it is related to the user name. If you remove the home folder
from the user profile what is happening?
Try moving that home folder to another server.
 
someting @ said:
Try Wireshark (ex-ethereal).
www.wireshark.org
I do not think it is related to the user name. If you remove the home folder
from the user profile what is happening?
Click to expand...

Before this "new" slowdown , removing the home folder mapping from the
user profile did work, and I got a fast logon.
Now not anymore, as a matter of fact the users with slow logon already
had the home folder mapping removed BEFORE it re-slowed down.
And they did actually work ok for weeks until now.
Try moving that home folder to another server.
Click to expand...

You mean, move the "normal shared folder" which isn't a home folder
anymore to another server?
I could try...I'll try...at the moment I'm a little clueless so I guess
I could try almost anything 8-)

By the way this evening I took the time to make a tcpdump of all the
traffic going to and from the remote site where the pc is.
Of course I dumped when the pc was making an attempt to logon.
Since it's quite a long dump I haven't had time to analyze, but I
noticed some errors in the application log and system log of the client.

Here they are: (I translated the messages because they are in italian)

-------- APPLICATION LOG: ------------

Event Source: Userenv
Event Category: None
Event ID: 1053
Data: 19/11/2007
Ora: 18.30.49
User: NT AUTHORITY\SYSTEM
Computer: IMPIANTIST01-SO

Windows cannot determine the user or computer name. (An internal error
occurred.) Group policy processing abotred.

---------- SYSTEM LOG: -------------

Event Source: LSASRV
Event Category: SPNEGO (Negoziatore)
Event ID: 40960
Date: 19/11/2007
Time: 17.58.07
User: N/A
Computer: IMPIANTIST01-SO

The Security System detected an attempted downgrade attack for server
cifs/srv-asl01.asl.sondrio.it. The failure code from authentication
protocol Kerberos was "No logon server is actually available to satisfy
the logon request. (0xc000005e)".

Event Source: LSASRV
Event Category: SPNEGO (Negoziatore)
Event ID: 40961
Data: 19/11/2007
Ora: 17.58.07
User: N/D
Computer: IMPIANTIST01-SO

The Security System could not establish a secured
connection with the server cifs/srv-asl01.asl.sondrio.it. No
authentication protocol was available

-------------------------------------------

Hope it helps!!

Thank you

Have a nice evening

Michele
 
In
TheBlob said:
Before this "new" slowdown , removing the home folder mapping from the
user profile did work, and I got a fast logon.
Now not anymore, as a matter of fact the users with slow logon already
had the home folder mapping removed BEFORE it re-slowed down.
And they did actually work ok for weeks until now.


You mean, move the "normal shared folder" which isn't a home folder
anymore to another server?
I could try...I'll try...at the moment I'm a little clueless so I
guess I could try almost anything 8-)

By the way this evening I took the time to make a tcpdump of all the
traffic going to and from the remote site where the pc is.
Of course I dumped when the pc was making an attempt to logon.
Since it's quite a long dump I haven't had time to analyze, but I
noticed some errors in the application log and system log of the
client.

Here they are: (I translated the messages because they are in italian)

-------- APPLICATION LOG: ------------

Event Source: Userenv
Event Category: None
Event ID: 1053
Data: 19/11/2007
Ora: 18.30.49
User: NT AUTHORITY\SYSTEM
Computer: IMPIANTIST01-SO

Windows cannot determine the user or computer name. (An internal error
occurred.) Group policy processing abotred.

---------- SYSTEM LOG: -------------

Event Source: LSASRV
Event Category: SPNEGO (Negoziatore)
Event ID: 40960
Date: 19/11/2007
Time: 17.58.07
User: N/A
Computer: IMPIANTIST01-SO

The Security System detected an attempted downgrade attack for server
cifs/srv-asl01.asl.sondrio.it. The failure code from authentication
protocol Kerberos was "No logon server is actually available to
satisfy the logon request. (0xc000005e)".

Event Source: LSASRV
Event Category: SPNEGO (Negoziatore)
Event ID: 40961
Data: 19/11/2007
Ora: 17.58.07
User: N/D
Computer: IMPIANTIST01-SO

The Security System could not establish a secured
connection with the server cifs/srv-asl01.asl.sondrio.it. No
authentication protocol was available

-------------------------------------------

Hope it helps!!

Thank you

Have a nice evening

Michele
Click to expand...

Usually creating a reverse zone with a PTR for the DC will eliminate the
40960 and 40961 errors, and should take care of the 1053's, but it may not.
Do you h ave a reverse zone and a PTR?

--
Regards,
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT,
MVP Microsoft MVP - Directory Services
Microsoft Certified Trainer

Infinite Diversities in Infinite Combinations
 
Usually creating a reverse zone with a PTR for the DC will eliminate the
40960 and 40961 errors, and should take care of the 1053's, but it may not.
Do you h ave a reverse zone and a PTR?
Click to expand...

The DNS *is* the DC :-)
And it's an AD integrated DNS.
And it has a reverse zone for the subnet where the DNS is and it also
has the correct PTR in that zone.

Tomorrow I hope to have some time to analyze the tcpdump I captured
earlier.
I also hope to have time to install Wireshark on the DC and grab some
captures with that too.

I'll keep you updated!

- Live long and prosper -

Michele
 
In
TheBlob said:
The DNS *is* the DC :-)
And it's an AD integrated DNS.
And it has a reverse zone for the subnet where the DNS is and it also
has the correct PTR in that zone.
Click to expand...

Is the DC only pointing to itself for DNS (meaning no ISP or otehr external
DNS) in ip properties?
Tomorrow I hope to have some time to analyze the tcpdump I captured
earlier.
I also hope to have time to install Wireshark on the DC and grab some
captures with that too.

I'll keep you updated!
Click to expand...

Looking forward to it.
- Live long and prosper -

Michele
Click to expand...

Likewise, my friend... ;-)

Ace
 
In

Is the DC only pointing to itself for DNS (meaning no ISP or otehr external
DNS) in ip properties?
Click to expand...

In the tcp/ip configuration of the DC the only DNS configured is the
DC's IP address.

Also, in the DNS server configuration I have a forwarder, which is
another DNS server, a djbdns instance which covers the Internet part and
two other domains which aren't on the Internet nor in our lan/wan.
(another company).
It's configured to select its own forwarder basing the choice on the
requested domain name.

Internet domains -> OpenDNS servers
the AD domain name -> the DC address (so it won't start resolving my LAN
addresses with the Internet DNS!)
domain a -> external DNS of domain A
domain b -> external DNS of domain B

Now I really have to go to work!!

See you later!

Michele
 
I think I've found the problem.

Kerberos authentication packets , which use UDP protocol, were getting
fragmented by the VPN gateways because they were longer than my MTU
(1500 bytes).
I've discovered that kerberos packets get longer if a user is in more
groups or OUs.
I strongly suspect they even do as the username gets longer...

Anyway, I tried to apply the solution here:

http://support.microsoft.com/kb/244474

It's a way to tell the client to use TCP packets for kerberos.
And it worked, so I was sure of the UDP fragmentation problem.

Then I removed the registry key and tried to login again, and it was
slow again.

So I investigated the problem on the VPN gateway side.
My VPNs use OpenVPN, so I searched and found a solution to the problem.

I'm posting it here hoping it will help someone other!!

You only need to add the following two lines at the bottom of the
configuration file of the server and clients (all of them!).

fragment 1300
mssfix

Then you restart the VPN (server&clients) and you're good to go!
Logon has returned to be LAN-like, even on a 640Kbit ADSL line.

I preferred this solution over the registry one because it was easier
and , more importantly, wasn't a workaround.
However both solution work, and in the KB article there even was a
template to make a GPO to distribute the registry change through the AD.

I'll let you know if there are more developements (I had time to try it
only on a client, tomorrow on another, I hope)

- Peace, and long life -

Michele
 
In
TheBlob said:
I think I've found the problem.

Kerberos authentication packets , which use UDP protocol, were getting
fragmented by the VPN gateways because they were longer than my MTU
(1500 bytes).
I've discovered that kerberos packets get longer if a user is in more
groups or OUs.
I strongly suspect they even do as the username gets longer...

Anyway, I tried to apply the solution here:

http://support.microsoft.com/kb/244474

It's a way to tell the client to use TCP packets for kerberos.
And it worked, so I was sure of the UDP fragmentation problem.

Then I removed the registry key and tried to login again, and it was
slow again.

So I investigated the problem on the VPN gateway side.
My VPNs use OpenVPN, so I searched and found a solution to the
problem.

I'm posting it here hoping it will help someone other!!

You only need to add the following two lines at the bottom of the
configuration file of the server and clients (all of them!).

fragment 1300
mssfix

Then you restart the VPN (server&clients) and you're good to go!
Logon has returned to be LAN-like, even on a 640Kbit ADSL line.

I preferred this solution over the registry one because it was easier
and , more importantly, wasn't a workaround.
However both solution work, and in the KB article there even was a
template to make a GPO to distribute the registry change through the
AD.

I'll let you know if there are more developements (I had time to try
it only on a client, tomorrow on another, I hope)

- Peace, and long life -

Michele
Click to expand...

Interesting. Glad you figured it out. The captures apparently helped. Were
you also getting EventID 5719 or is that just one of the symptoms based on
the article?

Do you like OpenVPN? Have you tried Cisco or NetScreen NetExtender?

Ace
 
Interesting. Glad you figured it out. The captures apparently helped. Were
you also getting EventID 5719 or is that just one of the symptoms based on
the article?
Click to expand...

No, I wasn't getting event 5719.
And, by the way, yesterday I verified another client, this time a
2000SP4 and the problem was resolved there too.
The first client was an XPSP2.

I'd also like to verify if now, setting the HOME folder again in the
profile does give problems or they are resolved too.
Just curious ;-)
Do you like OpenVPN? Have you tried Cisco or NetScreen NetExtender?
Click to expand...
Yes, I do.
In the past I had tried the following:

Netscreen, awful, never got it to actually create a stable tunnel
between two of *its own* appliances!
The firewall also wasn't user friendly to manage.

Linux IPSec tunnels (based on IPCop), not flexible enough for my routing
and firewalling needs.

OpenVPN simply is too much better, tunnel is waaaay flexible, has tons
of options and supports both L2 and L3 tunnels.
I currently use it on small linux "home made" appliances with solid
state (CF) hard drives, in conjunction with RIPv2 and firewall scripts
managed with Firewall Builder.
Awesome!

As for Cisco, I never tried it, mostly because of lack of hardware to
try it on, but if it's based on IPsec I'd chose OpenVPN over it every
time.

I'll keep you posted if there are further developements.

- Live long and prosper -

Michele
 
In
TheBlob said:
As for Cisco, I never tried it, mostly because of lack of hardware to
try it on, but if it's based on IPsec I'd chose OpenVPN over it every
time.

I'll keep you posted if there are further developements.

- Live long and prosper -

Michele
Click to expand...

Try it sometime. :-)

- Live long and prosper - as well as your family -

Ace
 
Did you mange to re-apply the home directory to the user profilesafter this fix? Did the slow logon come back?
We are having the same issue at one of our offices with two users, one with W2k machine, one with XP. User names are not the issue as we have other users with longer usernames with no problems. If we disable the home directory mapping, logon is as it should be, if turned on, logon is really slow( up to 45 mins on W2K machine).

EggHeadCafe - .NET Developer Portal of Choice
http://www.eggheadcafe.com
 
Did you mange to re-apply the home directory to the user profilesafter this fix?
Did the slow logon come back?
Click to expand...

Didn't get a chance today, sorry!
I hope to do that soon, but this week is already filled with "other
higher priority projects" (sigh!)

We are having the same issue at one of our offices with two users, one with W2k machine, one with XP.
User names are not the issue as we have other users with longer usernames with no problems.
If we disable the home directory mapping, logon is as it should be, if turned on,
logon is really slow( up to 45 mins on W2K machine).
Click to expand...

Why don't you try yourself? At least the registry modification, only
with one client, and you can always roll back in case it doesn't work.

Good luck!

Michele
 
Back
Top