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

Question

Question

Configuring Forms DMZ server, LFDS not authenticating

asked on May 20, 2019

Hello all,

 

Hopefully someone here will be able to help me, as I have been stuck for a few weeks now.

 

I have followed the white paper on setting up a Forms Server in the DMZ using internal Directory Server. It seems however that our internal server does not want to authenticate my DMZ server. For example; When in /formsConfig#forms if we click 'Test Connection' we get an error that says "The caller was not authenticated by the service.". If I perform a packet capture, I get the message "The request for security token could not be satisfied because authentication failed.". I have confirmed that it is reaching out to internalserver/LicenseManager/service when making the request and not some internal service. I have performed a full uninstall and repeated the steps in the whitepaper for 10+ multiple times.

 

All ports are currently open for testing, it is not a firewall issue. I feel like I have performed every troubleshooting step I can. The systems are able to fully communicate and I am getting an Active rejection from the LicenseManager.

 

I should state for clarification that the DMZ server is NOT on the domain. This leads me to believe the problem may lie in the fact that the IIS service is running using local systems that have no authorization on the internal systems, but we do not want to open the DMZ server to the domain controller for obvious reasons.

 

Has anyone else run into this issue or found a better solution for creating public forms? I'm at my limit.

 

Thank you very much for any responses/help.

1 0

Replies

replied on May 21, 2019 Show version history

You are on the right track when you point out that the DMZ is not on the domain.

However, the communication/authorization between Forms and LFDS that's failing is communication using WCF (a framework separate from IIS). By default, it makes use of Windows Authentication to secure your connection --- which will end poorly if one of the machines isn't on a domain (and a trusted domain at that).

The good news is that I have a suggestion, though it's not a configuration we recommend: try turning on the certificate authentication mode for Forms, the STS, and LFDS. In the SSO whitepaper, the instructions are under "Configuration of Directory Server and the STS when both are on different computers and you want to use certificate authentication".

We recommend separating the STS (hosts the SSO login page) and putting it in the DMZ because end users must be able to access the that authentication page. As such, you would likely need to create a firewall hole through to the STS in your internal network, somewhat defeating the goal of hosting Forms in the DMZ.

May I ask why you want to host Forms in the DMZ but not the STS? (Edited because it appears that a separated STS is in use, as recommended).

1 0
replied on May 22, 2019

Thank you for your response! I had actually started attempting certificate authentication before your message yesterday and had some success. I got my DMZ LFDSSTS to successfully contact the LFDS and it seems to be working properly!

 

That's the end of my good news I'm afraid. My DMZ Forms server is still acting up. I have followed multiple tutorials and keep running into the same issue. My LicenseManager endpoints in Web.config in /Forms and /Config are all setup to use the certificate, the thumbprint is correct in both, and yet whenever I try to update the "Directory Server STS URL" to my https://dmz/LFDSSTS it tells me "The client certificate is not provided. Specify a client certificate in ClientCredentials". But all three endpoints (AltLicenseManagerService, AltLicenseManagerService2, and AltLicenseManagerSTS) are all pointed at the correct BehaviorConfiguration pointing at the certificate. I am at a total loss once again. It is saying it doesn't have a cert, but it does. Unless there is an additional endpoint I need to add to the Web.config, I'm not sure what to do. Web diagnostics and packet captures unfortunately can't show me which 'endpoint' is being targeted when I get the prompt.

 

Any suggestions would be greatly appreciated.

2 0
replied on May 22, 2019

At this point, it's best to open a support case through your reseller for more detailed troubleshooting assistance, since it could be an issue with your certificate, your configuration, or something else entirely --- and to better troubleshoot, we might need to see some information you don't want to post publicly.

0 0
replied on May 24, 2019

Hi Blake, I solved this exact issue by making sure the certificates being used are located in the trusted certificate store on each the LFDS server and the STS/DMZ server. This fixed the issue for me. Also ensuring that the legitimate LFDS FQDN is used accross all forms, STS and LFDS end point utilities aswell as leaving the local service account blank. Additionally i added the FQDN and ip address of the LFDS to the DMZ hosts file allowed the resolution of the internal ip address. 

https://success.outsystems.com/Support/Enterprise_Customers/Installation/Install_a_trusted_root_CA__or_self-signed_certificate

2 0
replied on May 23, 2019

Im having the exact same issue as you are having now Blake, any luck?

You are not allowed to follow up in this post.

Sign in to reply to this post.