Windows authentication performance with Web Client - 90x slower vs Windows Client

asked on October 9, 2017

As an LF Admin I always login with Repository accounts. The other day a Windows user asked why it was slow logging in. We are using ldap.

We timed their login from the time they clicked login, to when they could see the repository and it was 10 seconds for them, where it was 1 second for me using the built in Admin account. The 1 second is really just the browser loading the received data.

I had them create a domain user for myself to look into this a bit more. Tried testing from external, directly on the server, Web Client vs Windows Client.

It is only slow for domain authentication using the Web Client. The Windows Client is a 10th of a second. Something extra is going on with the Web Client.

I wanted to see where the hold up is, so I setup a Wireshark to monitor the traffic going to and from the domain controller. There is a 9 second delay before the server sends the final auth requests to the domain, as if something is being processed. This explains the 9 second addition to login between a Windows Account and a repository user.

What is happening during these 9 seconds for the web users? Wouldn't the authentication requirements be the same regardless of which app they are logging in with?

172 is the LF Server, 162 is the Domain Controller

0 0

replied on October 13, 2017

The fundamental difference between Windows authentication in Web Access and the desktop client is that on the desktop there is already a Windows session for the user, while in Web Access that session is created from the provided credentials at the time of authentication. If for some reason there is a delay in this process, the Web Access user will experience it when logging in to Web Access, whereas the desktop user will experience it when logging in to their workstation - and that's assuming that the delay is not particular to one machine or the other.

All of that said, the network trace doesn't support the idea that there is a delay in that process. As I read it, the packets on either side of the timespan are outgoing and don't imply that Web Access was waiting for a response. On the other hand, the sequence numbers imply that Web Access isn't waiting for a network response from another service, like LFS.

I would suggest opening a support case, and they can help you capture a process dump, which will allow us to see what is going on during this time.

1 0

View 5 previous replies

replied on November 17, 2017

We are experiencing the same delay with Web Access 10. Did you ever find a solution or explanation for this 9 second delay?

0 0

replied on November 20, 2017 • Show version history

Are you using LDAP on a server that is not part of the domain? This is what I think causes the problem. I have not found a solution, I guess the problem with dumping memory is that its only useful if a program crashes, leaving the memory in a non-cleaned up state. We need something that captures the memory usage over time and that does not appear to exist. There has to be a better way to see what the computer is working on during time delays.

0 0

replied on November 20, 2017

A process dump will include the state of all of the threads in the process, which should allow us to see what the thread responsible for handling the current login request is doing. With a login as long as the one you report, there's a good chance of catching the thread while it is performing the slow operation.

0 0

replied on November 20, 2017

The problem I am running into for taking a process dump, is that I can't specify an amount of time to capture, like I can with Wireshark. Do you know how I can select to dump over an amount of time, so I can capture during that 9 seconds?

0 0

replied on November 20, 2017 • Show version history

Not sure if it is related here, but we have had similar issues for servers when the Laserfiche server was unable to determine the hostname of the webserver/client machines that was authenticating to it. We sometimes end up disabling the reverse lookup and in one case, fully disabled netbios over tcp/ip and it instantly fixed this issue for forms.

This was figured out using Wireshark as well, not sure if you are seeing dns/netbios requests in your capture or anything like that.

1 0

replied on November 20, 2017

Chad: The kind of dump you can take with Task Manager is just a point-in-time snapshot of the process state. You have to perform the capture at the exact time you want; it can be tricky but in this case it sounds like you have a large enough window. I think it's possible to use something like Windbg to take a series of thread snapshots over time, but I'm not sure that's necessary here, at least as a first step.

John: Yes, that is a cause of slow connections that it's good to be aware of. I suspect it's not the issue here since the report is that repository users can log in quickly.

0 0

replied on November 22, 2017

We are going to reach out to support on this soon, just trying to wrap up another 9 second delay that is more critical with them right now. Could be related even, but we don't know yet.

0 0

replied on February 20, 2020

This post was helpful for pointing us towards DNS as a potential cause of our horrible response times with the Web Client & WebLink for authentication. We were seeing ~30 second response time for Windows Authentication for the web clients, with <= 1sec. response time for the Windows client.

Our issue ultimately was missing Reverse Lookup Zone (PTR) records for our LF hosts (the web host being the critical one). Once these were added our response time dropped to ~5 seconds through the LFDS Single Sign-on, which is completely acceptable for us.

4 0

Question

Question

Windows authentication performance with Web Client - 90x slower vs Windows Client

Replies

Sign in to reply to this post.