Got it thank you!

Question on this. As soon as I save after switching on Directory Server the entire config page gets replaced by the STS page.

We wanted to enable STS for Web Client but we didn't expect to lose access to the config from the server.

I try logging in to STS anyways, using the windows credentials I am logged into the server with, then it tells me that the configuration page can only be accessed locally. I am locally on the server.

Where do we go to access Web Client config after changing this setting?

Hi Chad, 

It sounds like you're locked out of your Web Client config page. You say that you're accessing the config page on the local server. You're access it locally from the Web Client server machine? 

You can unlock the config page by editing the Web Client config files to disable LFDS SSO authentication. You can then access the config page again and reconfigure STS and remote access if you choose. 

Here are the instructions to unlock the config page:

1. Go to C:\Program Files\Laserfiche\Web Access\Web Files\Config\WebAccessConfig.xml

2. Go to the LFDSSettings node and change the 'Enabled' attribute to 'False'

3. Go to C:\Program Files\Laserfiche\Web Access\Web Files\web.config

4. ctrl+F search for 'Authentication

5. in the Authentication node, change the 'Mode' attribute from 'None' to 'Windows'

6. reset IIS or recycle the Web Client app pool. 

Oh I don't want to disable, let me re-phrase. They want to use STS for Web Client login, but they also want to be able to configure the web client as they always have been able to.

For example, they configured Forms to use STS for login, but the Forms configuration is still available, it was not replaced by STS.

They would like the same setup with Web Client for consistency.

After enabling STS, where do we go to get to the web client config?

You access the Web Client Config from the same place. However, once SSO is configured, you have to sign into the STS page to access the config page. 

It' unclear to me why you're getting the 'Config is only allowed for local access' error if you're accessing the config page from the server where Web Client is installed. You could try enabling remote access by:

1. Opening C:\Program Files\Laserfiche\Web Access\Web Files\Config\WebAccessConfig.xml in a text editor

2. Going to the <Security> node and setting the attribute   AllowRemoteAccess to "1"

For some reason we don't have this option. There is no AllowRemoteAccess setting and there is no Security node, only a terminator <Security/>

Looks like I need to open another support case.

When you say login to STS to access the config? What account do we login with, since we are not logging into Laserfiche, this config is accessed by an IT Windows User who had administrative rights to the server.

Once you configure Laserfiche Directory Sever SSO, you DO need to log into Laserfiche in order to access the Web Client config page. Specifically, IT administrators need to log into some account that's licensed in Laserfiche Directory Server.

This is because supporting LFDS SSO in the Web Client requires changing  the authentication mode in IIS for Web Client. Since the Config page is under Web Client's virtual directory, the authentication mode applies to the Config page as well. As a result, local admin domain accounts will no longer be able to access the config page through built-in IIS Windows Authentication. They need to authenticate through the LFDS sign-in page as if they were signing into Web Client or Forms.

You can add the AllowRemoteAccess attribute to the <Security/> node as follows:

<Security AllowRemoteAccess="1" />

"licensed in Laserfiche Directory Server." Just to clarify, there is now a need to buy and and pay LSAP on a license to access configuration utilities?

Is there a licenseless user (like "Admin" in the repository) for DS?

Also, does this grant access to configuration utilities for all names users?

The configuration utility was only meant for configuring services, by IT.

Also had support login to the server, they said that Allowing Remote Access is required when using STS if you want to access the configuration, I think this should be added to the config as part of enabling the switch. I have no idea how I would know to do this.

Update: From my testing, it does not appear to require any licensing, that would be very strange. I removed my full license on my windows account and was still able to get in. This is just a configuration utility after all.

Actually, I was incorrect. The user needs to be defined in Directory Server, but it doesn't need to be licensed. I was able to access the config page and save changes using credentials to a Laserfiche account that was created in LFDS but had no license applied. 

Chad, are you by chance using a DNS alias for your Web Client instance that differs from the actual server hostname?

e.g. users access the web client at https://lf.company.com/laserfiche while the actual web server hostname is lfweb.internal.company.com. 

I've seen that make a server not correctly detect local traffic before.

If so, you can try adding the following to the web server's hosts file (C:\Windows\System32\drivers\etc\hosts):

127.0.0.1       lf.company.com

Where "lf.company.com" is the host portion of the Web Client Host URL:

Hi Samuel

Yes, I mean. Users always access the Web Client by the public DNS A Record http://lf.company.com.

I am on the server, so I am using http://localhost/laserfiche/configuraiton to access the configuration utility.

The thing is, we can always access our IIS websites and all Laserfiche sites using localhost or whatever DNS entry we choose internally. Our Binding host names are always left blank for this reason, so that anyone can use any DNS entry they choose.

What I noticed is that after enabling STS, if you enter http://localhost/laserfiche/configuration it is automatically changing to the official DNS name using javascript or some other intrinsic coded method inside of the Laserfiche System (Not an IIS config)

This has never happened with config utilities before.

I just tested though, removing the Allow Remote Access and updating the hosts file so that the official dns name resolves to 217 on the server. This DOES work and seems more secure. It is not a common configuration though, I would expect everyone would  be running into this problem.