Citrix Blogs

ADFS v3 on Windows Server 2012 R2 with NetScaler

Tijl Van den Broeck

As I’ve had a lot of conversations and questions around ADFSv3 and NetScaler, this post will cover–in greater detail–the steps to configure NetScaler with ADFS v3 in the following scenarios:

NetScaler as SAML-SP for ADFSv3

There is an excellent KB article on NetScaler integration with ADFS v2.0 at CTX133919. Please use this existing CTX133919 article of as baseline for configuration.

When configuring NetScaler for ADFSv3 there are a couple of side notes to keep in mind. First of all, I’ve used following versions in this configuration: NetScaler 10.5 build 57.7 and Windows Server 2012 R2.

Prerequisites to keep in mind before configuration,

Just in case you’ve never configured ADFS before, this guide from Jay Simcox is a good starting point.

Watch out, before you start configuring ADFS:

When configuring ADFS on the Windows Server with “Configure the federation service on this server”, make sure the Federation Service Name is NOT set to the server name of the Windows server (if you do; you’ll get an SPN error). But you do need to create a DNS record pointing the Federation Service Name to your adfs server. In my setup the Windows server name is fs.citrix.local; whilst the ADFS service (and matching certificate for SSL Communications) is on adfs.citrix.local.

Configure the relying party trust (as mentioned in CTX133919) with all its steps;

Please note, that as specified in CTX133919, for ADFSv3 there is no need to change the Advanced tab to “SHA-1”, it can be left at the default SHA-256.

If you’re using an internal Certificate Authority, or if you are not exposing your internal CA’s CRL’s, then you need to explicitly disable the Certificate Revocation List checking of your Relying Party. Launch up a PowerShell console (Administrative Privileges are required; don’t forget “Run as Administrator”) and issue the following command:

PS C:\Windows\system32> Set-AdfsRelyingPartyTrust -TargetName “sp-adfs.rocks.local” -SigningCertificateRevocationCheck”None” -EncryptionCertificateRevocationCheck “None”

Additionally, make sure that the Federation Service is not encrypting claims:

PS C:\Windows\system32> Set-AdfsRelyingPartyTrust -TargetName “sp-adfs.rocks.local” -EncryptClaims $false

Note that this is explicitly different from ADFSv2, and SAML will fail with a “Malformed Assertion” error if your certificate revocation checking is enabled.

Configuration on NetScaler is then as following:

add authentication vserver vs_samlsp-adfs SSL 172.16.17.113 443 -AuthenticationDomain rocks.local

add lb vserver vs_https_sp-adfs SSL 172.16.17.112 443 -AuthenticationHost sp-adfs.rocks.local -Authentication ON -authnVsName vs_samlsp-adfs

bind ssl vserver vs_https_sp-adfs -certkeyName sp-adfs-rocks-local

add authentication samlAction srv_samlsp-adfs -samlIdPCertName adfs-citrix-local-ADFS-Signing -samlSigningCertName sp-adfs-rocks-local -samlRedirectUrl “https://adfs.citrix.local/adfs/ls/wia” -samlUserField NameID -samlIssuerName sp-adfs.rocks.local -signatureAlg RSA-SHA256 -digestMethod SHA256 -requestedAuthnContext minimum -authnCtxClassRef PasswordProtectedTransport -attributeConsumingServiceIndex 1
add authentication samlPolicy pol_samlsp-adfs ns_true srv_samlsp-adfs
bind authentication vserver vs_samlsp-adfs -policy pol_samlsp-adfs -priority 100

Notice in the samlAction the samlRedirectUrl is set to “https://adfs.citrix.local/adfs/ls/wia“, this is a different URL than ADFSv2. Also make sure the signature algorithm is set to RSA-SHA256 and digest method to SHA256 (Note that this requires Netscaler version 10.5 build 56.15 or higher).

Again make sure your DNS entries are also correctly set and I can now access https://sp-adfs.rocks.local. My browser will be automatically redirected to https://adfs.citrix.local and prompt for authentication. After successful authentication the browser is redirected again to https://sp-adfs.rocks.local and it succesfully authenticates.
(Tip: For easy reviewing of saml assertions; and tracing in browser use Google Chrome and enable the “Preserve Log” option in Developer Mode).

NetScaler as ADFS Proxy (or WAP) replacement

This is documented in the Guide to Succesfully Deploying Netscaler as an Active Directory Federation Services Proxy, so there is no need for a pair of Microsoft WAP Servers in the DMZ.

Again as baseline article the deployment guide can be followed, but when configuring a NetScaler LB or CS virtual server with SSL certificate to front your internal Federation Server you will need to explicitly disable SNI-binding.

Configuration of NetScaler (as per deployment guide, but do notice the URL’s for ADFSv3 are slightly different):

add authentication vserver vs_aaa_adfsproxy SSL 172.16.17.115 443 -AuthenticationDomain citrix.local

add service svc_https_adfs 172.16.17.198 SSL 443

add lb vserver vs_https_adfsproxy SSL 0.0.0.0 0 -authn401 ON -authnVsName vs_aaa_adfsproxy
bind lb vserver vs_https_adfsproxy svc_https_adfs

add lb vserver vs_https_adfsproxy_noauth SSL 0.0.0.0 0
bind lb vserver vs_https_adfsproxy_noauth svc_https_adfs

add cs vserver vs_https_adfs SSL 172.16.17.114 443

add cs action act_lb_adfs_proxypassive -targetLBVserver vs_https_adfsproxy
add cs action act_lb_adfs_proxynoauth -targetLBVserver vs_https_adfsproxy_noauth
add cs policy pol_adfs_proxypassive -rule “http.REQ.URL.CONTAINS(\”/adfs/ls/wia\”)” -action act_lb_adfs_proxypassive
add cs policy pol_adfs_proxynoauth -rule “http.REQ.URL.CONTAINS(\”/adfs/services/trust\”) || http.REQ.URL.CONTAINS(\”/federationmetadata/2007-06/federationmetadata.xml\”)” -action act_lb_adfs_proxynoauth
bind cs vserver vs_https_adfs -policyName pol_adfs_proxynoauth -priority 90
bind cs vserver vs_https_adfs -policyName pol_adfs_proxypassive -priority 100
bind cs vserver vs_https_adfs -lbvserver vs_https_adfsproxy

add rewrite action act_rw_adfs_mexrequest replace http.REQ.URL “\”/adfs/services/trust/proxymex\””
add rewrite policy pol_rw_adfs_mexrequest “http.REQ.URL.CONTAINS(\”/adfs/services/trust/mex\”) act_rw_adfs_mexrequest
bind lb vserver vs_https_adfsproxy_noauth -policyName pol_rw_adfs_mexrequest -priority 100 -gotoPriorityExpression END -type REQUEST

add authentication radiusAction srv_radius -serverIP 172.16.17.101 -serverPort 1812 -radKey ca2a03547ec92572a3c9 -encrypted
add authentication radiusPolicy pol_radius ns_true srv_radius
bind authentication vserver vs_aaa_adfsproxy -policy pol_radius -priority 100

add tm trafficAction prf_sso_to_401-adfs -SSO ON -persistentCookie OFF -InitiateLogout OFF -kcdAccount NONE
add tm trafficPolicy pol_sso_to_401-adfs “http.REQ.URL.PATH.EQ(\”/adfs/ls/wia\”)” prf_sso_to_401-adfs
bind lb vserver vs_https_adfsproxy -policyName pol_sso_to_401-adfs -priority 100 -gotoPriorityExpression END -type REQUEST

Configuration of your Windows Server 2012R2 Federation Server concerning SNI-binding:

PS C:\Windows\system32> netsh

netsh> http show sslcert
Hostname:port : adfs.citrix.local:443
Certificate Hash : 96cd248c99bbefee52572f69383043149a8f99ae
Application ID : {5d89a20c-beab-4389-9447-324788eb944a}
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)

netsh> http add sslcert ipport=0.0.0.0:443 certhash=96cd248c99bbefee52572f69383043149a8f99ae appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY

Some background on SNI. SNI or Subject Name Indicator is a solution for a problem that has long been around; when using SSL a fully qualified domain name should only match a single public IP address. When the client is doing the SSL Handshake (See link here), the server will handover its configured certificate. Only after SSL connection establishment will the client start asking the correct website in HTTP format. If the certificate does not match the requested FQDN or website an error is thrown. This makes SSL websites very hungry for the scarce IPv4 addresses, hence SNI was introduced with RFC4366.

There needs to be a way to indicate to the server to which FQDN a client is connecting during the SSL Handshake, so that the server can look at it’s repository of SSL Certificates and return the correct certificate; this extension on SSL is called Subject Name Indicator. NetScaler fully supports SNI on the front-end and can use SNI to select correct certificates. Backend support is currently not available, but in this case of SNI for ADFS this is not a real problem and you can safely disable the SNI-binding to ADFSv3 on Windows 2012R2 server and revert back to IP-binding. Remember SNI is mainly for managing IPv4 scarcity on the internet, there is little need for SNI in the internal LAN.

Updates (last: 2017-12-7)

Many thanks to Morten Kallesoe (Citrix), Valerie Bonchev (Citrix), Simon Gottschlag (Xenit) and Greg Boch (Citrix) for their much appreciated additional tips, guidelines and feedback.

Disclaimer:

The sample code mentioned above is provided to you as is with no representations, warranties or conditions of any kind. You may use, modify and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the sample code may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the sample code fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the sample code. In no event should the code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SAMPLE CODE, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Although the copyright in the code belongs to Citrix, any distribution of the code should include only your own standard copyright attribution, and not that of Citrix. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.

Exit mobile version