Log Name:      Laserfiche-WebClient-Server/Operational
Source:        Laserfiche-WebClient-Server
Date:          11/13/2019 10:21:46 PM
Event ID:      3
Task Category: ImportantError
Level:         Error
Keywords:      Session0,Session1,Session2,Session3
User:          IIS APPPOOL\WebAccessAppPool
Computer:      XXX
Description:
ID4037: The key needed to verify the signature could not be resolved from the following security key identifier 'SecurityKeyIdentifier
    (
    IsReadOnly = False,
    Count = 1,
    Clause[0] = System.IdentityModel.Tokens.Saml2SecurityKeyIdentifierClause
    )
'. Ensure that the SecurityTokenResolver is populated with the required key.
Operation: /laserfiche/
  Message: Exception encountered, stack trace:
  Laserfiche.WebAccess.Global.Application_Error
  System.EventHandler.Invoke
  System.Web.HttpApplication.RaiseOnError
  System.Web.HttpApplication.RecordError
Exception details:
  Message: ID4037: The key needed to verify the signature could not be resolved from the following security key identifier 'SecurityKeyIdentifier
    (
    IsReadOnly = False,
    Count = 1,
    Clause[0] = System.IdentityModel.Tokens.Saml2SecurityKeyIdentifierClause
    )
'. Ensure that the SecurityTokenResolver is populated with the required key.
  Stack trace:    at System.IdentityModel.EnvelopedSignatureReader.ResolveSigningCredentials()
   at System.IdentityModel.EnvelopedSignatureReader.OnEndOfRootElement()
   at System.IdentityModel.EnvelopedSignatureReader.Read()
   at System.Xml.XmlReader.ReadEndElement()
   at System.IdentityModel.Tokens.Saml2SecurityTokenHandler.ReadAssertion(XmlReader reader)
   at System.IdentityModel.Tokens.Saml2SecurityTokenHandler.ReadToken(XmlReader reader)
   at System.IdentityModel.Tokens.SecurityTokenHandlerCollection.ReadToken(XmlReader reader)
   at System.IdentityModel.Services.TokenReceiver.ReadToken(String tokenXml, XmlDictionaryReaderQuotas readerQuotas, FederationConfiguration federationConfiguration)
   at System.IdentityModel.Services.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequestBase request)
   at System.IdentityModel.Services.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   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)

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Laserfiche-WebClient-Server" Guid="{e1931bbe-b561-55ce-776e-86d128b8cd81}" />
    <EventID>3</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>65531</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000f00000000000</Keywords>
    <TimeCreated SystemTime="2019-11-14T03:21:46.400494400Z" />
    <EventRecordID>319</EventRecordID>
    <Correlation />
    <Execution ProcessID="6192" ThreadID="6244" />
    <Channel>Laserfiche-WebClient-Server/Operational</Channel>
    <Computer>XXXX</Computer>
    <Security UserID="XXXX" />
  </System>
  <EventData>
    <Data Name="message">ID4037: The key needed to verify the signature could not be resolved from the following security key identifier 'SecurityKeyIdentifier
    (
    IsReadOnly = False,
    Count = 1,
    Clause[0] = System.IdentityModel.Tokens.Saml2SecurityKeyIdentifierClause
    )
'. Ensure that the SecurityTokenResolver is populated with the required key.
Operation: /laserfiche/
  Message: Exception encountered, stack trace:
  Laserfiche.WebAccess.Global.Application_Error
  System.EventHandler.Invoke
  System.Web.HttpApplication.RaiseOnError
  System.Web.HttpApplication.RecordError
Exception details:
  Message: ID4037: The key needed to verify the signature could not be resolved from the following security key identifier 'SecurityKeyIdentifier
    (
    IsReadOnly = False,
    Count = 1,
    Clause[0] = System.IdentityModel.Tokens.Saml2SecurityKeyIdentifierClause
    )
'. Ensure that the SecurityTokenResolver is populated with the required key.
  Stack trace:    at System.IdentityModel.EnvelopedSignatureReader.ResolveSigningCredentials()
   at System.IdentityModel.EnvelopedSignatureReader.OnEndOfRootElement()
   at System.IdentityModel.EnvelopedSignatureReader.Read()
   at System.Xml.XmlReader.ReadEndElement()
   at System.IdentityModel.Tokens.Saml2SecurityTokenHandler.ReadAssertion(XmlReader reader)
   at System.IdentityModel.Tokens.Saml2SecurityTokenHandler.ReadToken(XmlReader reader)
   at System.IdentityModel.Tokens.SecurityTokenHandlerCollection.ReadToken(XmlReader reader)
   at System.IdentityModel.Services.TokenReceiver.ReadToken(String tokenXml, XmlDictionaryReaderQuotas readerQuotas, FederationConfiguration federationConfiguration)
   at System.IdentityModel.Services.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequestBase request)
   at System.IdentityModel.Services.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args)
   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&amp; completedSynchronously)

</Data>
  </EventData>
</Event>

Can you run .\Program Files\Laserfiche\Web Access\EndpointUtility.exe and verify the STS config settings are correct/match what you did for Forms?

If you're using the LFDS Alternate Binding (certificate auth) which I think you are, double check that the correct cert is selected in the Web Client EndpointUtility config.

Yes, the value in the Laserfiche Directory Server Address has the DMZ server address in it, there is no value in Service user's principal name, and the option for Alternate Service is selected with the correct Certificate selected.

I noticed you said both the Internal and DMZ server are running Windows Server 2019 in the support case you filed for this issue. Server 2019 appears to disable TLS version 1.0 and 1.1 by default. Please try running the following PowerShell commands to force Web Client to use TLS 1.2:

# ----------------------------------------------------------------------
# Set .NET Framework Schannel (TLS) reg keys
# ----------------------------------------------------------------------
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -PropertyType 'DWord' -Force | Out-Null

Those set the last set of reg keys described here:

https://support.laserfiche.com/kb/1013919/configuration-information-for-tls-1-2

Might need to restart the server for the change to take effect.

Web Client 10.4.1 doesn't support authenticating with STS in the DMZ over TLS 1.2, but Forms 10.4.1 does.  If TLS1.0 and 1.1 are disabled on your server, that would explain why Forms can authenticate through STS but Web Client cannot. We added support for this in Web Client 10.4.2.

As a troubleshooting step, I'd recommend explicitly enabling TLS 1.1 on the DMZ machine and the LFDS machine (you can disable it again right after testing). To enable it, follow the directions here under 'Turn on TLS 1.2', except tweak the registry path for TLS 1.1 (i.e. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client, etc). Recycle the app pool or reset IIS after the registry change. If Web Client can authenticate after adding the keys with no other changes, the problem is TLS 1.2. Be sure to allow it under both Client and Server keys on DMZ and LFDS machine. 

I ran the PowerShell script and restarted the server and I get the same result as before. I will try Ryan's suggestion next.

Do I also need to follow the instructions under 'Enable TLS 1.2 by default for WinHTTP' and 'Block RC4 in .NET TLS'?

You shouldn't. I recall that RC4 is blocked by default in Server 2019. I don't think WinHTTP plays any role in the STS handshake, though it certainly wouldn't hurt to enable TLS 1.2 there anyway. 

I followed the instructions from the KB article on both servers and followed Ryan's instructions, but no luck.

Thanks for the update Blake, glad you were able to resolve the issue. Can you elaborate on what specifically "Adding DNS information" means here?

The information is in the SSO whitepaper, but essentially adding the following:

<identity>
<dns value="company.com" />
</identity>

Blake, do you recall where in the Web Client web.config file did you add the identity?

You add it inside the affected endpoints:

<endpoint
address="https://subdomain.domain.net/SampleServiceName" …> 
  <identity>
    <dns value="www.subdomain.domain.net"/>
  </identity>
</endpoint>