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

Question

Question

Forms STS error

Forms Version 10
Updated November 13, 2019
asked on November 1, 2018

When users try to log into forms, they are redirected to the public facing LFDSSTS site and get an error page stating only that an error occurred.  It does not matter if they are trying to log into the public or internal forms server, they still get sent to the external STS site.

If I go to the external forms server and open https://localhost/forms I get error about client cert not provided

When I go to the external forms server and open https://localhost/LFDSSTS/configuration I also get a message about client certificate not provided.

I have run the EndPointUtility on both the external and internal forms server and set them both to use alternative service.

I have tried following the instructions in both Hosting Laserfiche Forms 10 In A Perimeter Network (DMZ) and Configuring Single Sign-On for Laserfiche Web Products without any change.

Any ideas on where my configuration is wrong?

0 0

Answer

APPROVED ANSWER SELECTED ANSWER
replied on November 6, 2018

A support case was opened and the SSO configuration was effectively re-done from the beginning.

On the internal LFDS server:

  1. Made sure that the internal LFDS XmlEndpointUtility was properly configured. The proper LFDS FQDN, service user principal name, and alternate STS certificate was used.
  2. Made sure that the internal STSEndpointUtility was properly configured. The proper LFDS FQDN and service user principal name was used. Alternate STS is not configured.
  3. Made sure that the internal Forms EndpointUtility was properly configured. The proper LFDS FQDN and service user principal name was used. Alternate STS is not configured. However, because they had previously tried to configure Alternate STS for internal Forms, the Forms web.config files needed to be additionally modified where under appSettings, the LfdsInDmz key needed to be set to False.
  4. Made sure that the internal FormsConfig site was configured with the proper Primary Forms Server URL, STS URL, and realm URL.

 

On the DMZ server:

  1. Made sure that the DMZ STSEndpointUtility was properly configured. The proper LFDS FQDN was used. The service user principal name should be left blank. Alternate STS is enabled and a valid certificate selected.
  2. Opened a web browser and made sure that https://localhost/lfdssts/configuration properly loads. There was a message indicating that the expected DNS identity didn't match up with the DNS identity provided. To remedy this, follow the steps in the addendum of the SSO white paper from https://support.laserfiche.com/resources/3878/configuring-single-sign-on-for-laserfiche-web-products
  3. Made sure that the DMZ Forms EndpointUtility was properly configured. The proper LFDS FQDN was used. The service user principal name should be left blank. Alternate STS is enabled and a valid certificate selected. Make the same change from the previous step regarding the DNS identity in the Forms web.config files under the Config and Forms subfolders.
  4. Made sure that the DMZFormsConfig site was configured with the proper Primary Forms Server URL, STS URL, and realm URL.

 

Now, both internal Forms and DMZ Forms are properly configured for SSO and it was confirmed that user login was successful to both.

4 0

Replies

replied on November 1, 2018 • Show version history

It sounds like both Forms instances are sharing the same database.  If internal users are being redirected to the external LFDSSTS site then the internal Forms Configuration user authentication page is incorrect.  The internal Forms configuration should point to the internal LFDSSTS site, and the DMZ Forms configuration should point to the LFDSSTS instance on the DMZ.  (The LFDSSTS instance on the DMZ should point to the internal LFDS)  In this case you should probably do the following:

 

#1:  Fix the internal Forms Configuration Page to point to the internal LFDSSTS instance.  Get the internal instance working before you move to the DMZ instance.  

#2:  Once the internal instance is working point the DMZ Forms instance to the LFDSSTS page on the DMZ.  (Make sure the STS on the DMZ is pointing to the internal LFDS server.

#3:  Turn off the Forms services specified in the white paper in the DMZ, and test externally.  

 

Here are the detailed step by step instructions with some caveats:

 

#1:  Configuring Directory Server-

•a.  Run the LFDS XML Utility “XmlEndPointUtility.exe” located in “C:\Program Files\Laserfiche\Directory Server”. 

•b.  Verify the FQDN of the LFDS server and listening port.

•c.   When you select “USE ALTERNATE SERVICE” do not specify a service user.  (Leave blank) 

•d.  Select a trusted SSL certificate that was issued by the same CA as the SSL certificate that the Forms DMZ STS and Forms instance will be using.  (Wildcard certificate that covers all subdomains would be best)  The SSL certificate must also be allowed for Server and Client authentication.  The LFDS service user account must have “READ” permissions to the certificates private key.  

 

#2:  Configure STS on internal LFDS Server-

•a.  Run the STS endpoint utility “STSEndpointUtility.exe” located in “C:\Program File\Laserfiche\Directory Server\Web\WebSTS”

•b.    Verify the FQDN of the Directory Server and the LFDS port.

•c.     Choose “USE ALTERNATE SERVICE”, but leave the “SERVICE USER” field blank. 

•d.     Choose the SSL certificate that was issued by the same CA as the SSL certificate that will be used in the Forms DMZ instance. 

•e. (Wildcard certificate that covers all subdomains would be best)  The SSL certificate must also be allowed for Server and Client authentication.  The LFDS service user account must have “READ” permissions to the certificates private key.  

 

#3:    On the internal “Forms Configuration Site” open the “USER AUTHENTICATION” tab and put the internal LFDSSTS address in the “Directory Server STS URL” field:  (Based on the SSL certificate name, and what the internal users would be using)  For example it would be:

https:\\LFDSInternalFormsServer\LFDSSTS

 

#4:  Configure STS on DMZ Forms Server-

•a.  Run the STS endpoint utility “STSEndpointUtility.exe” located in “C:\Program File\Laserfiche\Directory Server\Web\WebSTS”

•b.  Point the STS to the internal LFDS FQDN.  (You may need to have a host entry in the DMZ for LFDS)

 

#5: Configure Forms EU Utility on the DMZ-

•a.  Verify that the LFDS port is open on the firewall.

•b.    Open the Forms EndPoint Configuration Utility located in “C:\Program Files\Laserfiche\Laserfiche Forms\Forms\bin\EndpointUtility.exe”.

•c.  In the “Forms Installation Path” field specify the Forms install folder:  “C”Program Files\Laserfiche\Laserfiche Forms”

•d.  In the “Laserfiche Directory Server Address” option put the FQDN of the internal LFDS server.

•e.  Select “Use Alternative Service” and select the SSL certificate used by the DMZ Forms instance. 

 

#6:  Forms Site Configuration on DMZ-

•a.  On the “Forms Configuration Site” open the “USER AUTHENTICATION” tab and put the DMZ LFDSSTS address in the “Directory Server STS URL” field:  (Based on the SSL certificate name, and what the public users would be using)  For example it would be:

https:\\companyname\LFDSSTS

 

b.   Grant the “FormsAppPool” full control of the private key of the SSL certificate used by the Forms DMZ web site:

-c.    Verify the FQDN of the internal Directory Server and the LFDS port.

•d.     Choose “USE ALTERNATE SERVICE”, but leave the “SERVICE USER” field blank. (

•e.     Choose the SSL certificate that was issued by the same CA as the SSL certificate that is being used on the internal LFDS server. 

•f. (Wildcard certificate that covers all subdomains would be best)  The SSL certificate must also be allowed for Server and Client authentication.  The LFDS service user account must have “READ” permissions to the certificates private key.  

 

#7:  Add DNS entries to various Forms and STS "web.config" files to Forms server in DMZ.

 

#8:  Forms in a DMZ Perimeter Security Config:-

•After you confirm a successful log in from the DMZ you can proceed with configuring the DMZ Forms configuration per the whitepaper named “Hosting Laserfiche Forms 10 In A Perimeter Network (DMZ)”

 

1 0
replied on November 2, 2018

Hi Jonathan,

When configuring STS on the internal server (#2), you generally wouldn't use the alternate service option. Otherwise, this is a decent write-up.

Thanks

0 0
replied on November 2, 2018

I run the “XmlEndPointUtility.exe”, make the changes from Step #1 and hit the save button.  It "saves" and restarts the Directory Server service.  If I then run the “XmlEndPointUtility.exe” again, none of the changes are there.

I run the “STSEndpointUtility.exe” and remove the “SERVICE USER” field data and save.  But every time I run the “STSEndpointUtility.exe”, the “SERVICE USER” field is populated.

I log into the FormsConfig site on the internal forms server and try to make the changes to the “USER AUTHENTICATION” tab and when I click save, I get an error:

Any ideas on this?

0 0
replied on November 2, 2018

If this is a time sensitive issue you should file a Laserfiche case, as this is a fairly complicated set up; and it may require a lot of back and forth.  From my experience the steps below are sequential, so if there are problems with step #1 then the following steps will not work either.  If the changes you are making using the XML Configuration Utility are not saving to the XML configuration file then you should try running the XML Configuration Utility as an Administrator, and then open the XML config file using notepad to see if the changes are saving; the XML config file is located in:

C:\Program Files\Laserfiche\Directory Server

0 0
replied on November 5, 2018

Now when I try to change the Authentication tab data and save it, I am getting

Any thoughts on where I need to look to fix the metadata?

0 0
replied on November 5, 2018

From the screenshot it looks like the server name has a ".loc" on the end; is this the correct FQDN of the LFDS server?  

If the FQDN of the LFDS server is something like "LFDSSERVER.loc" then this is not going to match the wildcard certificate, and you should have a DNS entry that will match the wildcard certificate.  (EXAMPLE:  "LFDSSERVER.yourcompany.com")

 

0 0
replied on November 5, 2018 • Show version history

LFDS is on a server inside the company private domain and does not have access from a company.com address.  So you are saying that we should apply the *.company.com cert to the LFDS server and place an entry for it in the local domain DNS so that the address resolves for the local domain PCs?

0 0
replied on November 5, 2018

Yes; I worked with a client whose internal LFDS server had a FQDN of "LFDSSERVER.local", which did not match their wildcard cert of "yourcompanyname.com" so they made a DNS entry for "LFDSSERVER.yourcompanyname.com".  

0 0
replied on November 5, 2018

Any input from someone with Laserfiche?  I get through steps 1 and 2 (changing it all to the company.com address), but when I try to configure the User Authentication I get the error about the metadata contains reference...

Any ideas on how to resolve this?

0 0
replied on November 5, 2018

You can open a support case. It's easier to start from the beginning, making sure your configuration is correct right from the start because as Jonathan stated, if you misconfigured something at the outset, then it cascades.

In terms of what information you should provide in the support case:

  1. Get the FQDN of the internal LFDS server. On the internal LFDS server, open PowerShell and run 
    [System.Net.DNS]::GetHostEntry('localhost')

    Make sure this value is used as the LFDS FQDN in every endpoint utility that you use.

  2. Get screenshots of the LFDS XmlEndpointUtility and DMZ STSEndpointUtility.

  3. Get a screenshot showing https://localhost/lfdssts/configuration  from the DMZ

  4. Provide copies of the DMZ STS web.config and DMZ Forms web.config files. For Forms, include both web.config files under the Config and Forms folders.

0 1
APPROVED ANSWER SELECTED ANSWER
replied on November 6, 2018

A support case was opened and the SSO configuration was effectively re-done from the beginning.

On the internal LFDS server:

  1. Made sure that the internal LFDS XmlEndpointUtility was properly configured. The proper LFDS FQDN, service user principal name, and alternate STS certificate was used.
  2. Made sure that the internal STSEndpointUtility was properly configured. The proper LFDS FQDN and service user principal name was used. Alternate STS is not configured.
  3. Made sure that the internal Forms EndpointUtility was properly configured. The proper LFDS FQDN and service user principal name was used. Alternate STS is not configured. However, because they had previously tried to configure Alternate STS for internal Forms, the Forms web.config files needed to be additionally modified where under appSettings, the LfdsInDmz key needed to be set to False.
  4. Made sure that the internal FormsConfig site was configured with the proper Primary Forms Server URL, STS URL, and realm URL.

 

On the DMZ server:

  1. Made sure that the DMZ STSEndpointUtility was properly configured. The proper LFDS FQDN was used. The service user principal name should be left blank. Alternate STS is enabled and a valid certificate selected.
  2. Opened a web browser and made sure that https://localhost/lfdssts/configuration properly loads. There was a message indicating that the expected DNS identity didn't match up with the DNS identity provided. To remedy this, follow the steps in the addendum of the SSO white paper from https://support.laserfiche.com/resources/3878/configuring-single-sign-on-for-laserfiche-web-products
  3. Made sure that the DMZ Forms EndpointUtility was properly configured. The proper LFDS FQDN was used. The service user principal name should be left blank. Alternate STS is enabled and a valid certificate selected. Make the same change from the previous step regarding the DNS identity in the Forms web.config files under the Config and Forms subfolders.
  4. Made sure that the DMZFormsConfig site was configured with the proper Primary Forms Server URL, STS URL, and realm URL.

 

Now, both internal Forms and DMZ Forms are properly configured for SSO and it was confirmed that user login was successful to both.

4 0
replied on November 13, 2019

Can you give more details on what is happening with the error that you received on the DMZ server in Step 2? The white paper does not really explain what is happening when you receive that error and a good example of what you enter as the value for the entry in the web.config file.

0 0
replied on August 29, 2019

Follow up on this. A couple of Clients I have are seeing the following behavior.

  1. They have the internal Forms LFDSSTS pointing to the internal LFDSSTS, lets say https://internal.com/LFDSSTS
  2. So the DMZ forms also has the LFDSSTS set to https://internal.com/LFDSSTS since they share the same database. If we switch the external Forms to point to https://external.com/LFDSSTS , that changes the internal one too.

 

How do we maintain the correct STS on both Forms Instances?

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

Sign in to reply to this post.

Details
Related Posts
Loading ...