Web Access uses last user's credentials when using NLB

asked on January 30, 2023 • Show version history

My client has a security issue when using Network Load Balancing for the Web Access 9 Server: when they access using the DNS entry that points to the NLB (e.g. nlb.company.com) they will not be prompted to login with their AD account, instead they are automatically shown the credentials/folders/files/repository of the last AD user to login using nlb.company.com. This does not happen when bypassing the NLB (e.g. navigating directly to the Web Access server using webaccessserver.company.com).

When this second insecure login occurs, we can verify that there is an additional session listed for this AD account in the Administration Console (under Activity\Sessions).

I have ensured that Failover Clustering is not installed. I have also verified that the session is, indeed, using the first AD user's credentials (i.e. it's not just a display issue that would make it *appear* that the second user was logged-in as the first user).

Has anybody seen this before? Any ideas on where to troubleshoot the configuration? Does the load balancer cache data from anywhere?

Thanks

0 0

replied on January 30, 2023

How do they authenticate? Is it kerberos or are users entering their domain credentials in the web client login dialog? What exactly is the NLB server doing - is it acting as an http reverse proxy?

You probably know that version 9 is now several years out of support. If it turns out that this is a bug in the web client, they will need to upgrade to receive a fix.

0 0

replied on January 31, 2023

Microsoft Network Load Balancing (NLB) is a Layer 4 TCP/IP reverse proxy. Kerberos/NTLM (WinAuth) over reverse proxies/load balancers is messy in the best of circumstances. This is almost certainly not a Web Client bug.

The Kerberos configuration is likely incorrect. Kerberos does not play nicely with load balancers and requires special configuration.
See: On Load Balancers and Kerberos and Kerberos and Load Balancing

There are various troubleshooting steps you could take to try sort out what's going on. Wireshark/Fiddler tracing on both sides, various Kerberos configuration diagnostic utilities, etc., but I honestly wouldn't go down that route because WinAuth through a load balancer isn't a great idea in the first place.

If the customer must have automatic WinAuth, and the load balancing is in place for:

Performance reasons - use one web server and allocate it double the compute (vCPU) and memory resources
Availability reasons - use one web server with virtualization-level protection from something like VMware vSphere High Availability. VM-level HA does not add additional implementation/configuration complexity

If load balancing is still critical, we'd still recommend doing one or both of the above as a temporary measure to address the serious security scenario. Then, implement one of the following configurations we currently recommend for AD users in a load balancing scenario:

First, upgrade everything to Laserfiche 11 with Laserfiche Directory Server (LFDS). Do not put LFDS behind an NLB/proxy. Then:

Configure LFDS for Windows Authentication. Configure Web Client 11 to integrate with Directory Server for authentication. When an unauthenticated user goes to Web Client, it will redirect them to LFDS where they will log in with WinAuth, then LFDS will issue them a Laserfiche STS (Security Token Service) auth token and send them back to Web Client, which will use that STS auth token to authenticate them.
If AD is synchronized to a SAML 2.0 identity provider (IdP) like Azure AD or Okta, configure LFDS with both the AD and SAML IdPs, then configure the SAML IdP to have the AD IdP as a Linked Provider. This configuration links SAML logins to AD user accounts. Configure Web Client 11 to integrate with Directory Server for authentication. The auth flow is then the same as above, except LFDS will redirect users to the SAML provider rather than using WinAuth before issuing them an STS token. The main benefit of this approach is the ability to easily require multi-factor authentication (MFA) through the SAML IdP.

As Brian already mentioned, Laserfiche version 9 has been out of support for years now. Laserfiche 11 includes numerous feature and performance enhancements and bug and security fixes since Laserfiche 9.

0 0

Question

Question

Web Access uses last user's credentials when using NLB

Replies

Sign in to reply to this post.