At Empower 2020 in the IT Admin 205: Securing Your Network Environment class it was said (and the notes in the PowerPoint presentation) that a whitepaper for reverse proxies is being worked on. Is there a date that whitepaper is expected to be released?
Question
Question
Replies
We will be using Kemp. Regardless of the solution we adopt I guess we are looking for is a best practice recommendation of various settings that work best with Laserfiche Web Client.
Thanks.
Hey Blake,
Still on our radar, though it got sidelined for the moment due to COVID/WFH-related craziness. Happy to field any specific questions you might have in the meantime.
Cheers,
Sam
Any white papers using Windows Server 2019?
Sam, is there any new timeline for when the whitepaper will be available?
Hi Blake,
Not at this time. I'm the only person tasked with it and I haven't had any extra bandwidth to work on side projects like that for months now.
I might be able to knock out a shorter Support site KB FAQ sooner though. What would be the most important information for you to have in an FAQ vs a full white paper?
Sam,
Thanks for the quick reply. I think the main thing is just having the details of how the different Laserfiche web applications need to be configured when using a reverse proxy and not so much the details of how the specific reverse proxy needs to be configured. A high overview of how a reverse proxy needs to be configured would be nice though.
Sam,
What I believe we are missing are requirements for the web applications to work correctly over the proxied connection. Those may translate into Laserfiche configurations or specific proxy configurations to support the Laserfiche apps.
Thanks!
In tests a client set up with HA proxy, they were able to log in to the Laserfiche web client, but the content would not display. So we would need the specific configurations for each web application to work properly.
Hi Everyone,
Any news on the reverse proxy white paper?
Thanks.
Any particular proxies/load balancers you're interested in?
Nginx
Hello,
Any updates on the Whitepaper?
We have a customer who we setup the Forms Portal using NGINX and we are unable to connect to the Forms URL.
We believe we have all of the necessary Ports opened and SSL WC cert in place.
Appreciate any feedback,
Jeff Curtis
Hi Jeff,
What error are you getting in the browser? Can you post the nginx conf file with server names and IPs replaced with placeholders ("FormsServerIP", "nginxFQDN", etc.)? I can take a look.
Hello Sam,
We get the following error:
DNS_PROBE_FINISHED_NXDOMAIN
Attached is the nginx.conf file
Appreciate the help,
Jeff Curtis
That's a client-side DNS error indicating the client can't resolve the hostname. Is there a DNS entry (public or internal, as applicable) mapping the desired hostname to the nginx instance?
If the Laserfiche hostname served through the proxy is supposed to be "lf.example.com", try running "nslookup lf.example.com" in PowerShell on the client machine and see if it (a) resolves and (b) resolves to the nginx instance.
Hello Sam,
The site is resolvable from public DNS.
Customer opened port 9443 as well for testing as well for transparent proxy testing site Forms URL:9443
Both resolve publicly to the NGINX server.
Customer is checking on the nslookup.
If I have the Forms Site URL, should I run the nslookup from my laptop?
Appreciate the feedback,
Jeff Curtis
Thanks for the info. And yes, if the site is supposed to be externally resolvable and accessible, run the nslookup from your own laptop as well.
From your laptop I'd also run:
Test-NetConnection 'lf.example.com' -Port 443
@████████any movement on this whitepaper?
Not at the moment. Do you have a specific question?
We will be implementing a reverse proxy or a DMZ setup for Laserfiche in the next couple of months. I am hoping for reverse proxy. Is there anything with the Laserfiche Web products or Mobile Server that have any specific configurations when using a reverse proxy?
Our current setup is we have 3 load balanced web servers. Each with Laserfiche Forms and Web Client. We will be installing Laserfiche App Server for this project. We want to be able to use these 3 servers with the reverse proxy. At this point we don't know what we don't know about configuring Laserfiche to work correctly with a reverse proxy, so any details you can share would be very helpful.
What's the external access use case?
Would you use the same Citrix ADC you're currently load balancing with as the external-facing reverse proxy?
Approvers want to be able to approve documents while outside of the organization's network. Our organization does not have a mobile VPN, so making it external-facing is the next option.
I am not sure if we will be using Citrix ADC yet. I should have more information after I meet with our server team tomorrow.
Funny, I have a slide about this.
Of course, implementing a mobile VPN solution at your org's scale is neither a trivial undertaking nor likely something within your scope to even influence much.
Anyway, let me know what the server team says.
Just had a 2nd meeting with our team. Reverse Proxy is still on the table. The part that I need to figure out is if traffic to Laserfiche comes from the Reverse Proxy vs internal, how do we force them to use MFA authentication (Okta)? I just barely got off the phone and haven't had time to run scenarios through my head yet, but if you have any suggestions, I'm open to hearing them.
We are currently using AD accounts for authentication, but have Okta configured and working. I have not looked into the Linked Identity Provider as an option yet, but wondering if that may be the answer since we could force everyone, internally and externally, to use MFA going forward by hiding the Laserfiche and Windows Authentication buttons on the STS.
For the MFA bit, I believe you'd use an Okta App-level multifactor authentication policy with the "Location" set as appropriate (likely "Not in Zone", where the zone is your intranet).
If you want everyone to use MFA, you'd assign a policy requiring everyone to MFA from everywhere.
Before going the Linked Provider route, you need to make sure that AD Group SIDs are getting sync'd up to Okta so they can be sent in the SAML group claim. Group names won't work.