You are viewing limited content. For full access, please sign 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.

asked on June 29, 2022 Show version history

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?

0 0

Replies

replied on June 29, 2022

Hi Charles,

I believe you can change this default in the registry as detailed here.

0 0
replied on June 29, 2022

Thank you Chase.  I did see that post and the customer tried it.  It is still prompting them.   Any other ideas?

0 0
replied on June 29, 2022

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.)

0 0
replied on June 29, 2022

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!

0 0
replied on June 29, 2022

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.

0 0
replied on June 30, 2022

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.

0 0
replied on July 5, 2022

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.

2 0
replied on July 25, 2022

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.

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

Sign in to reply to this post.