We have been working on a system where the main STS is not on the same server as Directory Server. It appears that the client applications assume that is where the STS resides and so they will not connect correctly. Is there a way to update where they look for the STS?
Question
Question
Client Application SSO Support When STS is Not on LFDS Server
Replies
I've ran into this same issue, and wanted to add my findings in this behavior for further review. What I've found with the LF Desktop Client (aka- Windows Client):
When you attach a repository and select "Laserfiche Directory Server" for authentication, it auto-populates with the value that's in the LF Server license file for LFDS. You can manually change it to the correct STS URL (whether it's a DNS Alias or on a separate server) the first time, and authenticate successfully. However, if you do that, it doesn't stick (subsequent login attempts do not give you the option to use "Laserfiche Directory Server Authentication"). This results in needing to manually delete/reattach the repository from the Windows Client each time you login in order to utilize an LFDSSTS URL that is different from the FQDN for LFDS in the license file (if there's an LFDSSTS on the LFDS Server, and you use the same FQDN that's in the license, and not a DNS Alias, it will hold, and you'll retain the LFDS Auth option for all subsequent login attempts).
With the LF Office Integration, I've found that if you choose LFDS Auth when attaching a repository, it auto-populates with the LFDS FQDN that's in the LF Server license file, but there it DOES NOT allow you to change it (it's greyed out and read-only).
This poses an issue for SAML Users, as their only option for authentication is via LFDSSTS (they don't have the option of manually typing username/password like Laserfiche Users and Windows Users).
Since LFDS supports placing the LFDSSTS on other servers (other than the server where LFDS is), as well as using a DNS Alias to hit the LFDSSTS URL (rather than having to use the full server FQDN), then shouldn't the Desktop applications (i.e. LF Windows Client, LF Office Integration, etc.) support specifying your own LFDSSTS URL for authentication, instead of requiring the use of the LFDS Server FQDN for proper functionality?
Hi Dustin,
Assuming you have the latest LF Office Integration version and the latest hotfix for it, you should be able to alter the STS url using the registry key mentioned at the bottom of this documentation page.
With regards to the Windows Client, there is a bug currently that causes the needed registry key to differ slightly, as seen here.
That's what I needed; thanks Chase!!
After applying the latest Office Integration Hotfix to my Desktop Client, and placing these 2 registry keys in-place, all seems to be working properly. Thanks again!
Hi Blake, does this post answer your question?
Is that registry key used for all client applications in Laserfiche 11?
There is a registry key to set the LFDSSTS url, see this post: https://answers.laserfiche.com/questions/190263/How-to-change-windows-client-directory-server-url#190359
Note that there is a bug when attaching a repository, the registry key to use is slightly different. See my comment in the above post.
The registry key is used by the desktop client, Office Plugin, Scanning.
Edit: Snapshot too