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

Question

Question

Laserfiche Web Client Configuration Permissions

Web Client
Updated December 13, 2024
asked on December 12, 2024

After upgrading the web client to version 12.0.2411.504, I can use the web client without issue, but I cannot get to the configuration page. 

When I try, I get prompted to log in through LFDS (SSO with MS), after letting me log in, the configuration page that should be there is just an access denied page. I am an admin across the board. I can get to all the other component configuration pages without any issue. I do wonder if configuration should not be challenging me with LFDS, but just forms authentication like the config pages for Forms and LFDS and Mobile do.

0 0

Answer

SELECTED ANSWER
replied on December 13, 2024 • Show version history

I'm guessing you have the Web Client Host URL set to https://cname.example.com/laserfiche? That's the only URL that matters here because you'll always be sent there after the LFDS auth redirect no matter what the hostname in the initial request was (localhost/FQDN/IPaddress/etc.).

Which makes me suspect this is a Windows Authentication Kerberos issue.

  1. First, confirm that the IIS WebAccessAppPool is running as the default AppPoolIdentity.
     
  2. Try changing the Web Client Host URL to https://fqdn.example.com/laserfiche, in the same WebAccessConfig.xml file (should be easy enough to find) with the true machine FQDN, recycle the app pool, and see if you can authenticate to the config page after.
     
  3. If that works, you (most likely) definitely have a Kerberos issue, and the access denied is from a WinAuth failure, not any missing permissions. Configure whatever you immediately need to while you're in the config interface, then swap the Web Client Host URL back.
     
  4. Fix the root cause by replacing your existing CNAME with a Computer Name Alias, which handles both the DNS and Kerberos sides of things at the same time. They are very easy to set configure, literally a one-line command. Refer to this Microsoft article for instructions: Using Computer Name Aliases in place of DNS CNAME Records | Microsoft Community Hub
     
  5. Validate the fix by seeing if you can log in with the Web Client Host URL set to the aliased name.
2 0

Replies

replied on December 12, 2024 • Show version history

You're likely running into the "Allow remote access to the Windows Administrators and Laserfiche Web Configuration Managers groups." setting being off, potentially in combination with using a DNS aliased name (anything other than the machine FQDN) to access the configuration site, even the request is made from the local machine.

You mentioned you were "an admin across the board" so I'll assume your AD account is a member of at least one of the aforementioned groups.

This can seem like a Catch-22 since you can't get into the configuration page to update the setting that's locking you out. However, all the /laserfiche/configuration page does is update an XML config file on the local machine, which we can go to directly.

Here's how to troubleshoot:

  1. Find the config page settings file at "C:\Program Files\Laserfiche\Web Access\Web Files\Config\WebAccessConfig.xml" (default location) and check for the"AllowRemoteAccess" value in "Security" node, which will look like this: 
    <Security AllowRemoteAccess="1" UseRepositoryIdleDisconnect="1" ShowRepositoryPicker="1" />
  2. If you're trying to access the configuration page from a remote machine and AllowRemoteAccess="0", first make a backup copy of WebAccessConfig.xml, then change the value to "1", save the file, recycle the WebAccessAppPool in IIS, then try again.
     
  3. If you're using a non-FQDN name to access the site from the local machine, add a local hosts file entry for "$alias 127.0.0.1" mapping that name to the localhost IP, then try again.
1 0
View 1 previous reply
replied on December 12, 2024

Thanks for the info. I hadn't gotten to which files held all the configuration data yet. I double checked all of that. I have tried accessing using localhost and the ip from the server. I also tried the actual FQDN and the CName. All result in the same for now. I checked the config file and it was set to allow remote access. I'm not sure if I want to try to disable LFDS login or SSO temporarily to try to gain access. I tried putting the default xml and the app pool wouldn't start again until putting the current xml back in place. 

None of the other configuration pages seem to pass authentication to LFDS either, just this one is and then saying access is denied and only after upgrading web access to version 12.

0 0
SELECTED ANSWER
replied on December 13, 2024 • Show version history

I'm guessing you have the Web Client Host URL set to https://cname.example.com/laserfiche? That's the only URL that matters here because you'll always be sent there after the LFDS auth redirect no matter what the hostname in the initial request was (localhost/FQDN/IPaddress/etc.).

Which makes me suspect this is a Windows Authentication Kerberos issue.

  1. First, confirm that the IIS WebAccessAppPool is running as the default AppPoolIdentity.
     
  2. Try changing the Web Client Host URL to https://fqdn.example.com/laserfiche, in the same WebAccessConfig.xml file (should be easy enough to find) with the true machine FQDN, recycle the app pool, and see if you can authenticate to the config page after.
     
  3. If that works, you (most likely) definitely have a Kerberos issue, and the access denied is from a WinAuth failure, not any missing permissions. Configure whatever you immediately need to while you're in the config interface, then swap the Web Client Host URL back.
     
  4. Fix the root cause by replacing your existing CNAME with a Computer Name Alias, which handles both the DNS and Kerberos sides of things at the same time. They are very easy to set configure, literally a one-line command. Refer to this Microsoft article for instructions: Using Computer Name Aliases in place of DNS CNAME Records | Microsoft Community Hub
     
  5. Validate the fix by seeing if you can log in with the Web Client Host URL set to the aliased name.
2 0
replied on December 13, 2024

That was it, thanks. I think previous versions didn't redirect to LFDS for config pages. I assume that when I do upgrade forms, it will be the same.

1 0
replied on December 13, 2024

Forms will be different because /FormsConfig is a separate IIS application from /Forms and not (currently) gated behind LFDS auth.

However, you should set Computer Name Aliases for all Laserfiche servers that have DNS aliases to help ensure Kerberos Window Authentication works with services and app pools running as built-in computer identities. In many cases, Win Auth in these scenarios has only "worked" in customer environments because after Kerberos failed, it fell back to NTLM, and older and insecure protocol. Now that Microsoft has deprecated Windows NTLM authentication and more and more IT departments are disabling it every day, this insecure fallback option isn't working any more. You must have a valid configuration for Kerberos for Win Auth to work.

0 0
replied on December 12, 2024

Thanks for the info. I hadn't gotten to which files held all the configuration data yet. I double checked all of that. I have tried accessing using localhost and the ip from the server. I also tried the actual FQDN and the CName. All result in the same for now. I checked the config file and it was set to allow remote access. I'm not sure if I want to try to disable LFDS login or SSO temporarily to try to gain access. I tried putting the default xml and the app pool wouldn't start again until putting the current xml back in place. 

None of the other configuration pages seem to pass authentication to LFDS either, just this one is and then saying access is denied and only after upgrading web access to version 12.

You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...