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

Question

Question

LFDSSTS In A Forms IIS Cluster

asked on September 5 Show version history

We have Forms IIS (LF 12) on a single DMZ server currently and have LFDSSTS installed/configured on that same server to handle the authentication (Active Directory) to LFDS, which is on a different internal server.  We are adding a second Forms IIS server and setting them up to run as an NLB cluster following these instructions. The question I have is where the LFDSSTS should reside that the DMZ Forms IIS cluster uses for user authentication. Should I:

  • Install LFDSSTS on the second Forms IIS server in the cluster and thus the user connects to whichever LFDSSTS is on the same Forms IIS server the cluster directs them to
  • Install LFDSSTS on the second Forms IIS server in the cluster and there is some other configuration I need to account for LFDSSTS in a clustered environment
  • Install LFDSSTS on a different DMZ server that is not clustered and have all Forms authentication go to the non-clustered server
  • Something else entirely that I am not thinking of

 

I appreciate any advice that can be provided for how this LFDSSTS setup has been successfully deployed in for an NLB Forms IIS cluster using Laserfiche 11 or 12.

0 0

Answer

APPROVED ANSWER SELECTED ANSWER
replied on September 5

Hi Beau,

The simplest configuration is to have a single STS on one of the Forms IIS instances, as you have today. Let's call that server "Web1" and the other one with just Forms IIS "Web2".

Because Windows Network Load Balancing (NLB) is a layer 4 TCP load balancer and can't do "path-based" routing like a layer7 http load balancer/reverse proxy can, you need a separate DNS entry to use for STS that points to that server rather than the NLB IP. For example:

  • forms.example.com -> NLB IP
  • lfsso.example.com -> Web1 IP

Then:

  1. Ensure Web1 has a server TLS certificate covering both hostnames, since it needs to respond to requests to both. This can be:
    1. One certificate with multiple Subject Alternative Name (SAN) entries for the hostnames
    2. A wildcard certificate for "*.example.com" covering the hostnames
    3. Multiple certificates each with a single hostname, with Server Name Indication (SNI) hostname https bindings in IIS so IIS knows which cert to present for which hostname.
  2. Update the STS instance's token encryption mode to "Encrypt for single [STS] instance" from the STSEndpointUtility.exe config tool if necessary. This is the default for new LFDSSTS 12 installs, but encryption isn't automatically set if you upgrade from a previous version.
  3. Update the Forms DMZ instances' LFDSSTS URL to https://lfsso.example.com/LFDSSTS/ so users are redirected there.

 

If you have a layer 7 http load balancer with path-based routing capability, the "single STS" setup is even simpler because you can stick with a single hostname, e.g., forms.example.com.

  1. Define two backend "target groups" (term varies by load balancer)
    1. "Forms", with servers Web1 and Web2
    2. "LFDSSTS", with only Web 1
  2. Configure the load balancer to send requests with path:
    1. "/Forms*" to the "Forms" target group
    2. "/LFDSSTS/*" to the "LFDSSTS" target group

 

For any DMZ deployment, I recommend using the IIS IP Address and Domain Restrictions feature (see IIS 8.0 Dynamic IP Address Restrictions for useful screenshots) to restrict access to the "FormsConfig" and any other applicable admin/config IIS applications, such as WebLink Designer to only localhost (127.0.0.1) traffic with a Deny Action type of "Not Found - 404".

1 0
replied one day ago

Samuel,

Thanks a ton for the guidance & great detail!  The customer has backed off the IIS Cluster for the moment but I know we will be revisiting this soon enough for several of our high volume forms customers.  

1 0

Replies

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

Sign in to reply to this post.