Note: For information about configuring the Citrix NetScaler to perform IP-HTTPS preauthentication, click here. For information about configuring Windows Server 2012 R2 to perform IP-HTTPS preauthentication natively, click here.
Introduction
Recently I wrote about security challenges with DirectAccess and the IP-HTTPS IPv6 transition technology. Specifically, IP-HTTPS transition tunnel connections are not authenticated by the DirectAccess server, only the client. This allows an unauthorized device to obtain an IPv6 address on the DirectAccess client network. With it, an attacker can perform network reconnaissance using ICMPv6 and potentially launch a variety of Denial-of-Service (DoS) attacks. For more details, click here.
Note: DirectAccess IPsec data connections not at risk. Data is never exposed at any time with the default configuration.
Mitigation
To mitigate these issues, it is recommended that an Application Delivery Controller (ADC) be used to terminate SSL connections and enforce client certificate authentication. Doing this will ensure that only authorized connections will be accepted by the DirectAccess server. In addition, there are some scalability and performance benefits to implementing this configuration when supporting Windows 7 clients.
Important Considerations
Performing IP-HTTPS preauthentication on the F5 BIG-IP is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the F5 appliance breaks OTP authentication.
F5 BIG-IP Configuration
To configure the F5 BIG-IP to perform SSL offload for DirectAccess IP-HTTPS, follow the guidance documented here. In addition, to configure the F5 BIG-IP to perform preauthentication for DirectAccess clients, when creating the client SSL profile, click Custom above the Client Authentication section and choose Require from the Client Certificate drop-down list and Always from the Frequency drop-down list. In addition, choose your internal PKI’s root Certification Authority (CA) certificate from the Trusted Certificate Authorities drop-down list and from the Advertised Certificate Authorities drop-down list.
Summary
Enabling client certificate authentication for IP-HTTPS connections ensures that only authorized DirectAccess clients can establish a connection to the DirectAccess server and obtain an IPv6 address. It also prevents an unauthorized user from performing network reconnaissance or launching IPv6 Denial-of-Service (DoS) attacks.
Endre Igesund
/ April 6, 2018In the trusted and advertised certification authorities list, would you use the root or issuing ca when using a 2-tier CA for Client certs?
Richard M. Hicks
/ April 6, 2018I typically use the root CA here. I like the deployment flexibility it provides, as it allows me to authenticate certificates from multiple issuing CAs. I see no reason why it wouldn’t work though if you specified your issuing CA.
Endre Igesund
/ April 11, 2018Reason asking is we have a new setup, and some clients seems to be sending “wrong” client certificate. they have client certs from a local CA that we want, but they end up sending some Intune/Azure ad cert and the F5 then rejects.
Any experience on this?
Richard M. Hicks
/ April 14, 2018I’ve not had any personal experience with this, but others have reported the same issue. I think you’ll end up having to write a custom iRule to ensure the client certificate presented is the one you need. Unfortunately I don’t have any guidance to share with you on that. You may need to engage the F5 community or support for assistance on this.
Endre Igesund
/ April 17, 2018Thanks, but i think the error might be on the client. Have to understand how the client select between it’s availible certificates when several exists.
If you want more details i can send you an email.
Richard M. Hicks
/ April 18, 2018If that’s the case, I’m not sure how you would resolve this. With EAP you can employ certificate filtering, but there’s no way to do that here unfortunately. :/