ADFS 3.0 WAP not working with SSL acceleration turned on

0

Hello
I've seen some posts that indicate similar issues, but I'm not clear where they left that.

We have 2 internal ADFS 3.0 servers and 2 WAPs in the DMZ.
I'm following this doc to load balance the internal servers: https://support.kemptechnologies.com/hc/en-us/articles/204250925-AD-FS-v3
and they seem to work fine, but the web application proxy servers in the DMZ are then unable to talk to internal servers. You get the events 422:
Unable to retrieve proxy configuration data from the Federation Service.

According to this article: http://blogs.technet.com/b/applicationproxyblog/archive/2014/05/28/understanding-and-fixing-proxy-trust-ctl-issues-with-ad-fs-2012-r2-and-web-application-proxy.aspx
this behaviour is totally normal, because ADFS generates an internal certificate that is being used to communicate with the WAPs. And if you put a load balancer with SSL acceleration in between, you start using a different certificate and it doesn't like that.
So for a test, I deactivate the SSL acceleration and that restores the connectivity.

But since the Kemp documentation recommends to do this with SSL acceleration, I would like to fix that. What's my mistake here?
Our ADFS address is sts.ourdomain.com. Internally, this is pointing at the load balancer VS IP. The WAPs resolve that to the same address. From the internet, sts.ourdomain.com is pointing at the WAPs.
For the SNI host name, I've put in that sts.ourdomain.com.
We use a *.ourdomain.com certificate which is installed on all 4 servers and the load balancer VS. This is the certificate we specify when initiating the trust from the WAP with the Install-WebApplicationProxy command.

thanks in advance
Felix

10 comments

Avatar
kempsupportaccount Official comment

The WAPS are using the internal DNS and therefore point at therefore get the internal ADFS servers for the STS address. Only the STS requests from the internet are pointing at the WAPs.

We've got rid of the SSL acceleration on the internal service, and re-created the VS on the WAPs load balancers (Kemp suspected the VS to be somehow corrupted) and now everything seems to work.

Avatar
0
Christian Scheller

Hello Felix,

is there any good reason as to why external DNS points sts to the WAPs? This may add to confusion, in particular with SNI coming into play that requires the correct host name in the URI, which is being determined by reverse resolution.

In addition, run a tcpdump on the Loadmaster under Logging Options ==> Debug Options and check which host sends the RST packet. Then check the logs to find a reason for this behaviour.

Avatar
0
kempsupportaccount

Hi Christian

the only reason why external DNS points sts to one of the WAPs is because this is how our consultants had set it up and to our knowledge this is how it's supposed to work. I'm happy to change this if there is a better way of doing it. Eventually we'll point the external sts DNS record to the WAP load balancer, once the internal ADFS load balancing is figured out.
How would you change the DNS setup?

Thanks, I will check on that RST packet in the next maintenance window

Regards,
Felix

Avatar
0
Christian Scheller

Hi Felix,

the reason why I mentioned this is because of the way the requests are supposed to be routed. The way I understand it, and please correct me if I am wrong, is that the WAPs would be used as the "Real Servers" with the ADFS virtual service as these proxy for the ADFS servers. In which case the DNS should point to the virtual service IP address though.

Best Regards,
Christian

Avatar
0
kempsupportaccount

No, the WAPs are not (yet) real servers of the ADFS virtual service.
First, we are trying to load balance the internal servers. So the ADFS servers in our LAN are the real servers of the virtual service. And that works for internal, but the WAPs in the DMZ are unable to communicate with the load balanced internal servers. From the WAP point of view, they are resolving the sts address to the internal ADFS virtual service on the load balancer.

Once we have figured that out, we will then load balance the WAPs on the DMZ load balancers and then the external sts DNS record would point at the WAPs virutal service and the WAPs being real servers of that. If I would try that now, just to see if it fixes our issue, the virtual service for the WAPs would see the WAPs as down, because they can't initiate the communication with the internal ADFS servers and bring up their services.

Avatar
0
Christian Scheller

Hi,

try and add a hosts entry in the external WAPs pointing to the real ADFS instead. Or use a different DNS server for these machines.

Regards
Christian

Avatar
0
abentley

I have the same issue, with the same configuration as Felix. The certificate thumbprint is being changed by the Loadmaster and causing the issue documented as 'Root Cause 6' here: http://blogs.technet.com/b/applicationproxyblog/archive/2014/05/28/understanding-and-fixing-proxy-trust-ctl-issues-with-ad-fs-2012-r2-and-web-application-proxy.aspx

Using a hosts file on the WAP server is not ideal as they don't support DNSRR so you introduce single points of failure. The only option is to introduce a different DNS server, but this is overkill.

There needs to be an option to pass-through SSL traffic unaltered by the Kemps. i.e. not 'terminate and reencrypt' but 'forward'. Is this possible?

Avatar
0
kempsupportaccount

forwarding instead of re-encrypting would just disabling the whole SSL acceleration, which is what we did on the internal load balancer and it fixed it.

Avatar
0
abentley

Of course, thanks. Brain not working this morning.

Avatar
0
kwokyin.wong

I have similar issue but my setup is sightly different. I have 2 WAP servers(cluster setup) which Load master place in front of them.  and in the trust zone only 1 ADFS server.

 

My problem is , when SSL acceleration turn on.  The ADFS authentication will fail after some times later.. . especially in Android device

And 2nd problem .  We've Publish OWA in the WAPs , in Android device (native browser / firefox) . After fill in the credentails, browser show the CAS internal host and fail.... but no problem in iOS or PC...