Access to all the web-based products is working well with our authentication, but the client login is not for the repository. Each time we log in, we have to attach the repository and edit the Laserfiche Directory Server URL, removing the ".ad" portion to route the authentication correctly. It needs to read "https://"SERVERNAME"."DOMAINNAME".edu/LFDSSTS". Do you know which config file this address is hard coded to so we do not have to complete this step each time we log in?
Question
Question
Is it possible to Hard code the Directory Server Login information so that it does not need to be manually entered each time.
Replies
Hi Charles,
I believe you can change this default in the registry as detailed here.
Thank you Chase. I did see that post and the customer tried it. It is still prompting them. Any other ideas?
Just to double check, they tried adding and/or editing both of these keys?
HKEY_CURRENT_USER\Software\Laserfiche\Client8\Profile\MyRepositoryNameSettings\LFDSSTSUrl HKEY_CURRENT_USER\Software\Laserfiche\Client8\Profile\Settings
(Where "MyRepositoryName" is replaced with your actual repo name.)
Chase,
That is correct. We added both of these keys onto a machine the window client was installed on.
We utilize SAML for our MFA and have been able to find all the configurations to allow logging in on all web client applications. However, this is the last piece we cannot find. During a clean install it is still placing the ".ad" in the Directory Server Address. We can either change the registry keys for each machine (which is a work-around), or we can change it every time we log into the client. Is there somewhere else we have missed that needs updated for the LFDS authenication to occur without this step every time? Thank you!
Hi Emilee,
Sorry to ask for more clarification, but I notice you mentioned "We can either change the registry keys for each machine (which is a work-around)". Do you mean that adding the keys does in fact work, but you don't want to alter the keys on every client machine? If this is the case, I recommend you push out these keys with a group policy to all the client machines so you don't have to do so by hand. I believe this is the expected solution to alter the default on a wide scale. If I'm mistaken and the registry keys don't seem to be changing anything, we can loop in someone from the client team for input.
Chase,
No worries. Yes, changing the keys does correct the issue on the machines with an existing client application. However, when another instance of the client application is installed on a different machine, it still populates the incorrect address. It seems that the incorrect address is stored somewhere, but we cannot seem to find where. This is the solution we are attempting to find.
The incorrect address is likely the true fully qualified domain name of the LFDS machine, but this value is not necessarily accessible by the client machines. Try executing "[System.Net.DNS]::GetHostEntry('localhost').HostName" in PowerShell on the LFDS machine to see if this is the case.
Unfortunately there is not a whole lot that Laserfiche can do to predict which host name the customer will want to use, especially if aliases are involved. In these cases, pushing out those registry keys to all machines with the client installed via group policy is the recommended approach.
Would be nice to be able to change this in the LFDS console since many are using SSL Certs with specific domains and will not use the machine name here.