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

Discussion

Discussion

Forms User Authentication - Directory Server STS URL (internal & DMZ)

posted on August 30, 2019

With the advent of the Perpetual Participant Licenses, the need to install and configure Directory Server WebSTS in the DMZ is a necessity to allow External Participant Users to be able to login to Forms.

 

The issue that I have observed and hoping that others have too and can provide a resolution is that with a setup where you have two forms instances (internal and DMZ) sharing a Single Database, when you set the Directory Server STS URL to either internal/DMZ WebSTS address, it changes it for both.

One of the consequences of this depending on the DMZ setup is that at only one group of users can login. Meaning either  Internal or External users can login to Forms. If the URL is set to the WebSTS of the DMZ Server, only external users can access Forms and if set to the Internal Server's WebSTS, only Internal Users can log in.

How do you achieve both since the setting for one overwrites the other? I have encountered this behavior with at least a couple of Clients already.

Any ideas on this or working example configs will be highly appreciated.

 

With one particular Client, internal Users are unable to hit the DMZ server's Public address internally but external users can.

1 0
replied on August 30, 2019 Show version history

Hi Karim,

You need to set the Directory Server STS URL for the DMZ Forms instance to the DMZ WebSTS in the DMZ Forms web.config file directly.

Do not use the /FormsConfig UI for this step.

This is a variant on the instructions in the Hosting Laserfiche Forms 10 In A Perimeter Network (DMZ) whitepaper. For the "Standard DMZ Configuration: Two Forms Servers, One SQL Server" instructions, it says:

For step 7.c, you instead must change the issuer variable to the location of the DMZ WebSTS instance in the DMZ Forms instance config file.

\Program Files\Laserfiche\Laserfiche Forms\Forms\Web.config

  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="true" name="LMAuth" path="/Forms" />
      <wsFederation persistentCookiesOnPassiveRedirects="true" passiveRedirectEnabled="false" realm="https://dmz.company.com/Forms/" reply="https://dmz.company.com/Forms/" issuer="https://dmz.company.com/LFDSSTS/" homeRealm="urn:laserfiche:lfdsdb:LFDS" requireHttps="true" />
      <configuration autoAppendSlash="true" enableReferenceMode="true" />
    </federationConfiguration>
  </system.identityModel.services>

 

1 0
replied on August 30, 2019 Show version history

Thanks Samuel for feedback.

I'll check with Client and get back to you. So no changes are needed for the homeRealm?

homeRealm="urn:laserfiche:lfdsdb:LFDS"

Also, I want to believe that I made these changes for one other Client and that resulted in an endless loop when you enter the creds. There are about 3 Clients at present having the same issue.

Will report back.

0 0
replied on August 30, 2019

Hi Karim - you should not need to modify the homeRealm value.

If you're getting an infinite redirect loop, it usually means Forms cannot validate the STS token. Try running the DMZ Forms LFDS EndpointUtility, located at:

\Program Files\Laserfiche\Laserfiche Forms\Forms\bin\EndpointUtility.exe

If you're using the Alternative Service binding, make sure to check that option in the EndpointUtility and verify that it is configured correctly on both the DMZ WebSTS and LFDS. 

Check all involved Laserfiche application event logs, including the Windows>Application log. Specifically look for certificate, token creation, and network connection errors that could point to a clear issue.

0 0
replied on December 6, 2023

@████████ if you are using the option to have an STS in the DMZ, would you enter the DMZ LFDSSTS FQDN in the 'Laserfiche Directory Server Address' field or still enter the internal Directory Server FQDN?

 

0 0
replied on December 6, 2023

"Laserfiche Directory Server Address" is always for the machine (or failover cluster) hosting the LFDS Windows Service. Among other reasons, when Forms etc. receives an STS token, it has to validate that it's legitimate and unmodified. It does that by asking the LFDS service, and so needs to know where that is. Possibly also for licensing checks.

That said, this utility is going away in Forms 11 Update 5 because Forms is updating from using WCF (old method) to HTTPS to communicate with LFDS and will simply pull the LFDS FQDN from its license file. You still need to make sure that address resolves from the DMZ machine (via hosts file entry or otherwise).

1 0
replied on December 6, 2023

Just wanted to verify. Thanks! Looking forward to Forms 11 Update 5.

0 0
replied on December 22, 2023

Here is a video that shows the new utility:

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

Sign in to reply to this post.