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

Discussion

Discussion

Upgrade to LF 11 broke auto login to Web Client

posted on February 16, 2022

Hello, I upgraded my environment to LF 11 with the most recent installer. Now all my web users have to type in their user name and password which they did not have to on 10.4. I see a ton of these errors on the event viewer for WebSTS.

ID4243: Could not create a SecurityToken. A token was not found in the token cache and no cookie was found in the context.

I have gone through all my settings and everything looks normal. Do I need to roll back LFDS? can I do that with the LF server being on 11 now? 

0 0
replied on February 21, 2022

You can generally use Laserfiche 11 applications with LFDS 10.4.x.

The one case I'm aware of is that if your users use Laserfiche Scanning URLs either standalone or via Laserfiche Connector you need to use LFDS 11 with Web Client 11. 

0 0
replied on February 21, 2022

I did roll back LFDS to 10.4 and I still have the issue. 

0 0
replied on February 18, 2022 Show version history

Hi Lucas,

Were you using a custom IIS application pool identity for LicenseManagerSTSAppPool on the STS machine? If so, you may need to reset that identity to what it was before the upgrade.

1 0
replied on February 18, 2022 Show version history

I gave it a shot and I still get the popup. Whats really weird is that if I close the popup and get this screen,

the Windows Authentication button doesn't do anything. I have changed almost all the application pool identity to my server account I use for everything LF. 

I keep getting this in the event viewer for WebSTS >Operations.

ID4243: Could not create a SecurityToken. A token was not found in the token cache and no cookie was found in the context.

System.IdentityModel.Tokens.SecurityTokenException: ID4243: Could not create a SecurityToken. A token was not found in the token cache and no cookie was found in the context.
   at System.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(XmlReader reader, SecurityTokenResolver tokenResolver)
   at System.IdentityModel.Tokens.SessionSecurityTokenHandler.ReadToken(Byte[] token, SecurityTokenResolver tokenResolver)
   at System.IdentityModel.Services.SessionAuthenticationModule.ReadSessionTokenFromCookie(Byte[] sessionCookie)
   at System.IdentityModel.Services.SessionAuthenticationModule.TryReadSessionTokenFromCookie(SessionSecurityToken& sessionToken)
   at System.IdentityModel.Services.SessionAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs eventArgs)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

0 0
replied on February 21, 2022

If you can, I'd try uninstalling and reinstalling LFDS/STS under the default Network Service identity. This won't affect the LFDS database and it should automatically re-connect because uninstalling doesn't remove the LFDS SQL connection profile which resides in a config file in \ProgramData\Laserfiche\*.

0 0
replied on February 21, 2022

Hi Samuel. I tried this already. Did that this weekend when no one was on the system. Still have the issue...

0 0
replied on February 22, 2022

Hi Lucas, it looks like we need to do some deeper investigation so I recommend having your SP open a support ticket with our Support team for this issue.

1 0
replied on February 24, 2022

Thanks Chase, I did open a case. 

My network admin ended up finding the fix. It was in the provider settings for Windows Authentication in IIS. As soon as we switched it to Negotiate first, then NTLM, it started working. The install for LF 11 must have switched it to defaults. All the documentation that LF provides shows NTLM first and Negotiate second so I never thought to change it myself. 

0 0
replied on February 24, 2022 Show version history

Hi Lucas, Laserfiche actually doesn't control the priority of enabled Windows Authentication providers, as that is a system setting. I am not sure how automatic Windows Authentication was working before with your providers out of order but I'm glad it's working now with the correct settings as you show in your screenshot!

1 0
replied on February 25, 2022

Negotiate (Kerberos) followed by NTLM is the default on clean IIS installations.

1 0
replied on April 15, 2022

Is it recommended to switch the order of those to:

  1. NTLM
  2. Negotiation (Kerberos)

for new installations or only for specific configurations?

0 0
replied on April 15, 2022

@████████  I do not recommend that. I would leave the order as Negotiate followed by NTLM unless you are experiencing issues.

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

Sign in to reply to this post.