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

Question

Question

Laserfiche Quick Fields 11 - LFDSSTS Authentication Requires HTTP (80)

asked on November 13, 2023 Show version history

Laserfiche Quick Fields 11 added the ability to use LFDS Authentication (LFDSSTS) within sessions, which supports the use of SAML Accounts. However, I've note some odd behavior with the latest update to Quick Fields 11 (Update 3).

 

With the initial release version of Quick Fields 11 (11.0.0.498) we tested the LFDS Authentication functionality, and it worked as expected, and reached out to the LFDSSTS site purely using HTTPS (443).

 

After applying the latest update, which got it up to the latest release version (11.0.2303.30119), I've noted that it seems to be reaching out to the LFDSSTS site over HTTP (80) first, then being redirected to HTTPS (443).

In our environment, we restricted traffic to the LFDS Server to ONLY using HTTPS (443), so after upgrading Quick Fields 11, the LFDS Authentication wasn't working (the LFDSSTS page wouldn't load within the window; it remained as a blank page). After observing the network traffic, we opened communication over HTTP (80), and the LFDSSTS Authentication works without issue.

 

This seems like a step backwards in development and security. I attempted to override the initial HTTP (80) communication by placing the following registry key on the workstation hosting Quick Fields 11:

Registry key: HKEY_CURRENT_USER\Software\Laserfiche\Client8\Profile\{repositoryname}Settings
String Value (REG_SZ): LFDSSTSUrl
Value: https://<LFDSSTS_Site>/LFDSSTS/

 

I verified that it honors the hostname used in that registry key by pointing it to other LFDSSTS sites to confirm that it went to the correct one. However, even specifying HTTPS in the URL value there, it still seems to be hitting HTTP (80) first.

 

I'm not certain if it was specifically Update 3 that caused this change, but I know that the initial release version (11.0.0.498) is only communicating with the LFDSSTS server via HTTPS/443. The latest release version (11.0.2303.30119) is communicating with the LFDSSTS server via Ports 80, 443, and 5051.

 

Is this expected behavior?

If so, why the change in functionality?

Is there a way to override this behavior and restrict it to 443 only?

 

I'm not a fan of having to have HTTP/80 open for communication to the LFDS Server, but it seems it's required to utilize LFDSSTS Authentication with the latest version of Quick Fields 11.

 

Any additional information or insight is appreciated.

 

 

0 0

Answers

APPROVED ANSWER
replied on May 25

Laserfiche has released the update for 11 Update 3 Hotfix 1014569 with this issue fix (related Bug 498904), see more information from List of Changes for Quick Fields 11 Update 3 Hotfix 1014569 - Knowledge Base

1 0
SELECTED ANSWER
replied on December 14, 2023 Show version history

I opened a Laserfiche Support case for this issue, and they confirmed that this was a bug in this version of Quick Fields (11.0.2303.30119). Bug ID: 498904

 

They provided a hotfix within the case, and advised that this fix would be included in the next release of Quick Fields, though they were unsure at the time on the name of the next release, or when it would be released (they advised to keep an eye on the Release Notes for a line about this issue on the next release).

 

1 0
replied on December 14, 2023

A small correction, the version with the issue is 11.0.2303.30119 (Quick Fields 11 Update 3), the hotfix build is 11.0.2303.30132.

 

If anyone else is interested in applying the hotfix, please contact Laserfiche Support.

2 0
replied on December 15, 2023

Thanks @████████! I've adjusted the mistyped version to the correct one in my original comment (initially, I inadvertently grabbed the fixed version from the hotfix instructions, rather than the original problem version).

1 0

Replies

replied on November 13, 2023 Show version history

Dustin,

Ports 80 (inbound) and 5051 (outbound) are suspiciously both Laserfiche Server (LFS) ports. If you search "5051" in the Laserfiche Administration Guide, all networking-relevant hits are for firewall configuration sections with variants of this info:

By default, the Laserfiche Server listens on TCP port 80. The Laserfiche Server broadcasts notifications on port 5051. If there is a firewall between your Laserfiche Server instance and your Web Client/Forms Server/etc., make sure that ports 80 and 5051 are open on the firewall. You can use the Server Settings node of the Laserfiche Administration Console to modify the default port settings.

I cannot imagine any reason why Quick Fields would be attempting to communicate with Laserfiche Directory Server over 5051, when the only usage of that port I'm aware of is for Laserfiche Server to make outbound broadcasts of available repositories (and possibly other things). If you've ever wondered how the "Available Repositories" list in Windows Client gets automatically populated, that's the mechanism. LFDS doesn't even have a listener on 5051. I would honestly check if Laserfiche Server was somehow inadvertently installed on the Quick Fields machine.

For port 80, I do vaguely recall a Quick Fields issue when LFDS auth support was first introduced where it would attempt to load http://LFDS-Server-Hostname-In-QF-LF.licx-LicenseFile/LFDSSTS in the embedded browser and rely on being automatically redirected to https by LFDS, so that's potentially a regression bug and you should file a support case for it.

1 0
replied on November 14, 2023 Show version history

@████████ I believe that you nailed the issue I'm trying to address with this piece:

For port 80, I do vaguely recall a Quick Fields issue when LFDS auth support was first introduced where it would attempt to load http://LFDS-Server-Hostname-In-QF-LF.licx-LicenseFile/LFDSSTS in the embedded browser and rely on being automatically redirected to https by LFDS, so that's potentially a regression bug and you should file a support case for it.

That's what I'm seeing occur (the embedded browser reaching out over Port 80 and relying on the application redirect). I found it odd that even when specifying HTTPS in the override registry key, it's still hitting Port 80 first. I suspect this bug is present in this version of Quick Fields.

 

In terms of Port 5051, I believe that's expected functionality, after authentication. Laserfiche Server is on the same system as LFDS, and it houses the repository to which Quick Fields is connecting.

5051 is the port for what used to be the Laserfiche Broadcast Service, now known as the Laserfiche Repository Notification Protocol (LRNP), and I don't believe it's only used for broadcasting anymore. There's actually a listener for LFS on TCP 5051. I've also seen that many application reach to Laserfiche Server over that port (i.e. Windows Client, Web Client, Forms, etc.). In fact, the article that you quoted above from the LF Admin Guide is referencing the need to open Port 5051 in the firewall for Web Access to talk to Laserfiche Server over that port.

I'm not clear on the full functionality of that service (LRNP), but I know within the Windows Client, for example, when someone else moves an entry out of a folder that you're currently viewing, and you see it update (disappear) automatically without having to manually refresh, that's due to that service.

I don't believe it's responsible for the "Available Repositories" list, however:

If you've ever wondered how the "Available Repositories" list in Windows Client gets automatically populated, that's the mechanism.

As I understand that, Laserfiche Server has a Service Connection Point utility built-in, and publishes it's SCP to Active Directory when the service starts up (in the domain where the LF Server lives). When you open the Windows Client, it queries Active Directory for available SCPs, and that's what populates that "Available Repositories" list.

Those SCPs are actually the reason that a repository can still show up in that list, after the repository has been deleted. There's a Laserfiche KB on manually removing the SCPs from Active Directory, using the built-in tool in the LF Server installation folder. This KB references Laserfiche 8 and 9, but if I'm not mistaken, it's still applicable even up to the latest version of Laserfiche 11.

 

I do think in terms of this specific inquiry, we've identified a bug in the latest version of Quick Fields, as you noted, with the embedded browser hitting HTTP/80 first and relying on the application redirect, as opposed to reaching out over HTTPS/443 from the beginning.

I'll open a case with LF Support to report this bug. Thanks!

 

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

Sign in to reply to this post.