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

Discussion

Discussion

SSO issues with Web Access and LFDSSTS

Directory Server Web Client How To Installation and Upgrades
Updated March 1, 2024
posted on February 28, 2024

Hi,

We force SSO.  When users try and access Web Access they get a browser popup requesting user credentials. Even if user credentials are added, it sill does not allow any access. We have tried this in a few different browsers and get the same response.

We have added addresses to trusted sites in security and have the Endpoint utility using the appropriate SSL certificates (wildcard SSL) and server details. IIS has Windows Authentication Enabled and the appropriate SSL bindings are also included there too. We have recycled the LicenseManagerSTSAppPool and confirmed it is running as network service. We are a bit stumped as to where to go from here.  We have also added the address in trusted sites via GP for the browsers.

We do have a DNS A record for their domain/wildcard SSL pointing at the LFDS server IP address, but no CNAME.

We have seen this issues before (with the browser pop up when using SSO), but our fixes listed above have, at some point, fixed the issue.

Anyone have any ideas/suggestion. 

Anthony

0 0
replied on February 28, 2024

Hi Anthony,

This:

When users try and access Web Access they get a browser popup requesting user credentials. Even if user credentials are added, it still does not allow any access.

Almost certainly indicates some sort of Kerberos issue. I would start by checking the LFDS and Windows->Application event logs and looking for anything Kerberos/auth related that correlates with a failed login attempt. The event log messages, if present, may provide useful additional information to help diagnose the issue.

We have recycled the LicenseManagerSTSAppPool and confirmed it is running as network service.

The the Laserfiche Directory Server Windows Service (a) on the same machine as LFDSSTS, and (b) also running as Network Service?

We have also added the address in trusted sites via GP for the browsers.

This instructs the browser to automatically respond to the Windows Authentication challenge with the current user's credentials. If manual entry of those credentials is failing, providing them automatically isn't going to have a different result.

0 0
View 4 previous replies
replied on February 29, 2024 • Show version history

Hi

 

Almost certainly indicates some sort of Kerberos issue. I would start by checking the LFDS and Windows->Application event logs and looking for anything Kerberos/auth related that correlates with a failed login attempt. The event log messages, if present, may provide useful additional information to help diagnose the issue.

 

LFDS and STS are on the same server.  When the popup error is received, there are no errors listed on the LFDSSTS server or the Web Server.

 

As you can see from the screenshot, the user is getting to the LFDSSTS site.

 

The the Laserfiche Directory Server Windows Service (a) on the same machine as LFDSSTS, and (b) also running as Network Service?

 

LFDS is on the same server as LFDSTS.  LFDS service is running as Laserfiche Admin AD credentials (which is our standard roll out for clients).  The LicenseManagerSTSAppPool in IIS is running as NetworkService which is the required setup suggested from Laserfiche.  This is also our usual setup for clients which we do not usual change (other clients do not have this issue).

 

Our Wildcard SSL is installed on the LFDS server and the Web Server.  Both IIS servers have port 443 bound to this SSL certificate with their domain https://lf.domain.co.uk.  This domain is setup in DNS to point to the LFDS server IP address as an A Name record.

Could the fact that we are using this domain address (with wildcard SSL) and not FQDN in all our setups (including STSEnpointUtilitity and XmlEnpointUtility for) and in IIS be the reason for the issues we are experiencing?

 

0 0
replied on February 29, 2024

I am also dealing with a similar issue with a new client system. 

0 0
replied on February 29, 2024

Could the fact that we are using this domain address (with wildcard SSL) and not FQDN in all our setups (including STSEndpointUtilitity and XmlEndpointUtility for) and in IIS be the reason for the issues we are experiencing?

Yes, absolutely. I'd try removing the DNS record and replacing it with a Computer Name Alias that automatically handles setting all the necessary Kerberos SPNs in addition to DNS records.

See Microsoft article: Using Computer Name Aliases in place of DNS CNAME Records (the CNAME part isn't important).

I generally advise using the true LFDS FQDN in the STS/XMLEndpointUtility configurations. Tends to avoid lots of potential problems (not necessarily yours here). The TLS certificate bound to LFDS on port 5049 needs to include the machine FQDN if you want to enable HTTPS for those backend service-to-service communications. I usually don't enable HTTPS in the EndpointUtility configs if all relevant apps are on the same server, as the traffic never touches the network. Otherwise, every time.

1 0
replied on March 1, 2024 • Show version history

Hi Samuel,

We have replaced all the domain names in EndPointUtilities with the true LFDS FQDN and updated, where necessary, in IIS and the same issues persist.

*scratches head

Anthony

0 0
replied on March 1, 2024

I am sorry to hear that Anthony, I replaced the internal LFDS Endpoints with the LFDS FQDN and every web product including DMZ worked. If you have not done so, consider enabling the kerberos logging in the LFDS server registry(instructions in the Laserfiche kerberos white paper). Those kerberos errors might provide some further context.

0 0
replied on March 1, 2024

Just so I am not missing one, these would be the LFDS endpoints that would need updating:

XmlEndpointUtility in \Laserfiche\Directory Server\

  • Under general configuration 
  • Under Laserfiche User Password Reset Configuration
  • Approved Security Tokens Services

 

STSEndpointUtility in \Laserfiche\Directory Server\Web\WebSTS\

LFDS Server name in Web Configuration

0 0
replied on March 1, 2024

Yes, those were the endpoints that I had to use the FQDN for. 

0 0
replied on February 28, 2024

Can you clarify:

  1. When the user is presented with the popup authentication dialog, what is the page url? Are they still at web client, or have they been redirected to LFDS?
  2. What happens when the user enters their credentials? Are they prompted again immediately, or is there a redirect first? It could be fast, so using the dev tools with "persist log" is a good tool. Are they at the same site as 1?

 

From a troubleshooting perspective, you want to distinguish between:

  1. Web client is prompting for credentials, which it shouldn't do. That's a configuration problem in web client.
  2. LFDS doesn't accept the credentials at all. That's a problem in LFDS.
  3. LFDS accepts the credentials but can't complete the SSO with web client. That's something in between, maybe the Endpoint Utility could help.
  4. User can get to web client, but is somehow sent back to LFDS anyway. That's probably configuration in web client.

 

0 0
replied on February 28, 2024

Hi,

1) When the user is presented with the popup authentication dialog, what is the page url? Are they still at web client, or have they been redirected to LFDS?

 

No, they are at the LFDSSTS domain.  We have force SSO enabled.  But if this is disabled, when the user clicks “Use Windows Authentication” from the Web Access login page, they are directed to the STS site with the blue “Use Windows Authentication” button.  When they click the button, It is now when then are presented with the pop up window.

 

2) What happens when the user enters their credentials? Are they prompted again immediately, or is there a redirect first? It could be fast, so using the dev tools with "persist log" is a good tool. Are they at the same site as 1?

 

If we enter AD credentials for this user when the pop up appears, authentication fails and the pop up immediately reappears.  If we cancel out we are back to the blue “use windows authentication” button again.

0 0
replied on February 28, 2024 • Show version history

If the browser is popping up a login box to authenticate and not taking you to the https://a.domain.com/LFDSSTS site that sounds like you are seeing a NTLM box from more than likely IIS and not the LFDSSTS website. I would test by turning off windows authentication in IIS and turning on anonymous just to see what happens.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...