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

Question

Question

Single Sign On with Directory server 10.3 without TLS 1.0 and 1.1

asked on September 5, 2019

Hi All,

 

Any has tried Directory server 10.3 Single Sign feature with ADFS Successfully. We are in the process of trying SSO initially with Web Access. But still struggling to get over it. Both are in 2 different servers, and LFDS and LFDSSTS are in the same machine. 

 

Every time the Directory server login happens, the below error is noted in LFDS System event log:

A fatal error occurred while creating a TLS server credential. The internal error state is 10013.

Meantime the below error is seen in WebAccess server logs:

  Message: The token XML does not appear to be valid.
Parameter name: tokenXml
  Stack trace:    at Laserfiche.SecurityTokenService.Ticket..ctor(String tokenXml)
   at Laserfiche.WebAccess.Common.ConnectionManager.AuthenticateSessionWithClaims(Session sess, RepositoryRegistration repoReg, ClaimsIdentity claimsId)
   at Laserfiche.WebAccess.Common.ConnectionManager.AutoLogon(String repoName, HttpContext context, Boolean forceLogin, WARepository waRepo)
   at Laserfiche.WebAccess.Common.ConnectionManager.<>c__DisplayClass46_0.<CheckConnectedInternal>b__1()
 

Certificates are installed and access to certificates also provided. Any one has configured Directory Server SSO feature with LFDS 10.3 by allowing only TLS 1.2? (TLS 1.0 and 1.1 are disabled in our environment)

 

Regards

Kirubaa

 

 

 

0 0

Replies

replied on September 5, 2019

How did you enable TLS 1.2?  We have found that using IISCrypto works best to get the initial starting point, then follow instructions found at https://support.laserfiche.com/kb/1013919/configuration-information-for-tls-1-2

Make sure to set all Servers the same.  We usually start in IISCrypto by applying "Best Practices" and then disabling all protocols except TLS 1.2.  Then we create/set the 6 registry values as directed by the KB 1013919.  Finally, we reboot the server and test.

2 0
replied on September 10, 2019

Thanks Bert for your reply!

 

The TLS 1.2 settings already been made in the servers related to Laserfiche, but no success till now. But have you tried this option using TLS 1.2 with LFDS 10.3?  

0 0
replied on September 6, 2019

Hi Kirubaa,

If what Bert suggested doesn't work for you, temporarily enable TLS 1.0 and 1.1 on both servers and try again. That will help verify if the issue is actually related to the TLS version

You can also try upgrading to the latest version of LFDS 10.4.x, which targets .NET 4.7.2 and thus uses TLS 1.2 by default. LFDS 10.4 is backwards compatible with other Laserfiche 10.3 components.

0 0
replied on September 10, 2019

Hi Samuel,

Thank you for the reply!

TLS 1.2 option is ruled out, as we tried this earlier. Also the ADFS \Windows authentication button also having the same issue, when going through LFDS.

I'm checking the option of Temporarily enabling the TLS version. But last option would be upgrading then.

 

 

0 0
replied on October 12, 2019

Hi Samuel,

 

We have upgraded LFDS to 10.4, and tested with internal web access with ADFS authentication. The scenario tested success was :

1. LFDS 10.4 with LFSTS 10.4 in the same machine - No Certificate authentication

2. Laserfiche Web access 10.3 configured to authenticate through Directory server

 

But the below scenario still failing, can you please provide your input on this:

1. LFDS 10.4 is in Internal network

2. LFSTS 10.4 and LF Web client 10.3 in DMZ server - Configured with internal CA certificate

The ADFS page passing the credentials and it is getting into multiple loop of redirection at DMZ server web Access. Below is the error writing in the Web Server Eventlog in the DMZ server.

Log Name:      Laserfiche-WebClient-Server/Operational
Source:        Laserfiche-WebClient-Server
Date:          10/9/2019 12:36:23 PM
Event ID:      3
Task Category: ImportantError
Level:         Error
Keywords:      Session0,Session1,Session2,Session3
User:          IIS APPPOOL\WebAccessAppPool
Computer:      ENDMZEMLUAT1.enochodmz.com
Description:
The token XML does not appear to be valid.
Parameter name: tokenXml
Operation: /laserfiche/browse.aspx?repo=TESTDEV
  Message: Exception encountered, stack trace:
  Laserfiche.WebAccess.Common.Util.ErrorHandler.LogException
  Laserfiche.WebAccess.Common.Util.ErrorHandler.Standardize
  Laserfiche.WebAccess.Common.<>c__DisplayClass46_0.<CheckConnectedInternal>b__1
  Web.Util.SingleComputationLock.Synchronize
Exception details:
  Message: The token XML does not appear to be valid.
Parameter name: tokenXml
  Stack trace:    at Laserfiche.SecurityTokenService.Ticket..ctor(String tokenXml)
   at Laserfiche.WebAccess.Common.ConnectionManager.AuthenticateSessionWithClaims(Session sess, RepositoryRegistration repoReg, ClaimsIdentity claimsId)
   at Laserfiche.WebAccess.Common.ConnectionManager.AutoLogon(String repoName, HttpContext context, Boolean forceLogin, WARepository waRepo)
   at Laserfiche.WebAccess.Common.ConnectionManager.<>c__DisplayClass46_0.<CheckConnectedInternal>b__1()

  Session: ettcszcj

 

 

 

0 0
replied on October 14, 2019 Show version history

Hi Kirubaa,

Thanks for replying back - I'm glad to hear the first scenario was successful.

For the second scenario, an infinite redirect between STS and Web Client usually means that Web Client is not accepting the STS auth token and kicking you back to STS. STS thinks you have a valid auth token and sends you back to Web Client. And so it repeats.

Can you verify that the DMZ STS instance is configured to meet all requirements specified here?:

https://www.laserfiche.com/support/webhelp/Laserfiche/10/en-US/administration/#../Subsystems/LFDS/Content/separate-sts.htm

Then, run the DMZ Web Client's endpoint utility to verify it is configured correctly as well.

 

Cheers,

Sam

DMZ-STS-WebClient-EndpointConfig.png
0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.