You are viewing limited content. For full access, please sign in.



How does Web Client get the users Windows Credentials automatically - Troubleshooting a break in the system

asked on February 17, 2022

This setting to auto login with windows auth has been around in the web client config forever but it always worked so I never understood how it works under the hood.

After an upgrade of the LF Services, all workstations  across the organization get the standard IIS Windows Auth prompt when visiting Web Client, meaning the browser is no longer able to acccess the credentials automatically.

It does work when using a browser directly on the server, likely because the browser has more functionality with less hops?

So far the only troubleshooting we can do is flip the switch for Windows Auth on the IIS app back and forth to see if it fixes it which it does not.

What is going on under the hood here? What is the name of the technology LF uses to ask the browser of the local workstation to pass the credentials?

0 0


replied on February 17, 2022

The browser to IIS is just normal Windows authentication. If the user is prompted for credentials, it's usually either 1) the user isn't recognized on the server (e.g. server is on a different AD) or 2) the browser isn't configured to send credentials automatically, because e.g. the server isn't in a "trusted zone".

Where things get more complicated is passing those credentials on to LFS. You'll need to follow the Kerberos whitepaper for that. If that isn't correctly configured, the user will be able to get to the web client login page, but they will get an access denied error when LFS doesn't accept their authentication.

0 0
replied on February 18, 2022 Show version history

Brian, What could have possibly changed in the update process that would change a configuration for this to stop working. I was on 10.4 for LFDS and Server and Web Client, pretty much everything and the auto-login worked. As soon as I updated to LF 11 for LFDS, Server, and Web client, it broke. It works when I'm on the server itself, but not on my workstation. I even tried rolling back web client to 10.4 and I'm still getting the popup. All my machines are on the same domain. and I have read the white pages multiple times and followed them. My users can log in if they type in their user name and password and if they open another tab, it logs them in just fine. 

Even hitting the STS site causes the prompt to come up, And this was NOT a problem last week before my update. 

0 0
replied on February 18, 2022

In this case we do not seem to have any Kerberos problems, the users can still login, but they are getting the IIS Windows Auth prompt instead of auto logging in even from their workstations which are on the same domain as the server.

That only leaves the browser trusted zone issue, however after upgrading to version 11, all workstations company wide are getting this prompt indicating the upgrade changed a setting on the server. Obviously it couldn't have changed a setting across all workstations at once.

I am thinking it is an IIS configuration somewhere.

0 0
replied on February 21, 2022

Any chance the URLs got changed at some point during the upgrade? Before worrying about what might have changed server-side, validate that the exact hostname (or matching wildcard entry) for the LFDSSTS URL is in end user workstation's "Local intranet" zone with one of these two settings selected:

All IIS controls are:

  1. If it throws a 401 Windows Authentication challenge
  2. The providers (Negotiate/Kerberos/NTLM) supported for WinAuth and their priority
  3. A few server-side WinAuth security settings like Kernel-mode Authentication

Whether or not the client auto-responds to the 401 auth challenge is up to the client's settings.

That said, sometimes what happens is that the clients attempt to automatically login, that fails, and the Win Auth prompt is immediately re-thrown. This can happen fast enough it makes it seem like the auto-login attempt isn't happening. Any chance you're running LFDS/LFDSSTS as AD service accounts instead of their default Network Service identity? Or changed the service/app pool identities in either direction during the upgrade? If you're using custom identities and tinker with the useAppPoolCredentials setting it's possible to screw things up:

0 0
replied on February 21, 2022 Show version history

No change to the URL. I have internal programs that use the URL to launch documents, and that is when everyone started noticing the issue. 

Local internet is configured by group policies, so those are set and have not changed. I checked with my network admin and he ensured that my LF servers are in the zones. 

Yes, I'm running an AD service account for almost everything in my environment. I have changed it between that and Network Service identity multiple times and nothing changes. 

In your screenshot of the IIS configuration Editor, are you saying that it should be False for useAppPoolCredentials? Mine is set to False. 

Something else I want to make sure is known is that on the server hosting LFDS and Web client, I get signed in automatically just fine. 

0 0
replied on February 21, 2022

Per, if you're using a domain account for the LFDSSTS, try setting useAppPoolCredentials to True so it uses the service account credentials instead of the machine account to decrypt the Kerberos ticket.

0 0
replied on February 22, 2022

I gave that a shot with no success. It seems like this bug is not on the surface with some easy settings. I have no idea what else to try. I have read the Configuring Kerberos for Laserfiche 10 document so many times. 

0 0
replied on February 24, 2022

Brina and Samuel, I was able to get it working by rearranging the providers in the Windows Authentication options in IIS. All the LF documentation shows NTLM first and then Negotiate. As soon as I switched them and made Negotiate first, it started working. 

I would recommend something in the installer that would leave these settings alone in IIS. Obviously, I had it working before I installed LF 11(LFDS and Web Client). I'm not sure which install did it or if both of them did it. 

This is the screen I'm talking about. 

3 0
You are not allowed to follow up in this post.

Sign in to reply to this post.