Using Netscaler as ADFS proxy - Exported configuration

After my last blog article on how to replace the Microsoft ADFS Proxy, I've been asked to provide the configuration of my Netscaler for the ADFS proxy replacement so I've exported the part that are needed to achieve this, please comment with a little thanks if it was helpful to you. Note that I'm using Netscaler 10.1 with ADFS 2.0 on windows 2008r2.

I found a Citrix article about ADFS 3.0 that refer to the fact that Netscaler doesn't support the sni feature for the backend server that is used in ADFS 3.0 which is most likely causing headache to ADFS 3.0 users.
http://support.citrix.com/article/CTX125798
The citrix article refer you to this microsoft article that talk about a way to partially disable the SNI feature for ADFS 3.0... 
http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx


Here's the code and some comments :

********* Begin Starting Notes *******
This config is for Netscaler 10.1 (Currently at Build 129.11 but it's been working with previous 10.1. build)
Your Netscaler must be licensed for "AAA - Traffic management" and it must be enable under settings -> "Configure Basic Features" (Authentication, Authorization and Auditing)
Your ADFS URL must be reachable by DNS externally (you can't authenticate using IP address, it has to be a DNS name, worst case scenario you can edit your host file temporarily for testing)
you need to have an external IP address available to Setup the Reverse Proxy

If you have multiple domain, you can easily repeat the config for the second domain and add the 2nd LDAP policy to the authentication Vserver with a different priority

Example: bind authentication Vserver vs_Auth.Company.com -policy Subdomain2.Company.com -priority 110
The domain settings in the Netscaler is not related to the AD domain but to the domain in the FQDN url (i.e.: email domain, If your internal domain is company.local and your website is company.com then the domain you set in the Netscaler is company.com)


********* End Starting Notes *******

********* Begin configuration code *******

enable ns feature AAA LB CS SSL SSLVPN REWRITE RESPONDER

add serviceGroup SG_LDAP_CORP_389 TCP -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -cltTimeout 9000 -svrTimeout 9000 -CKA NO -TCPB NO -CMP NO -appflowLog DISABLED
bind serviceGroup SG_LDAP_CORP_389 DomainControllerCorp1 389 -CustomServerID "\"None\""
bind serviceGroup SG_LDAP_CORP_389 DomainControllerCorp2 389 -CustomServerID "\"None\""

add lb vserver LB_LDAP_CORP TCP 192.168.1.79 389 -persistenceType NONE -cltTimeout 9000
bind lb vserver LB_LDAP_CORP SG_LDAP_CORP_389

add authentication ldapAction LDAP-LB_LDAP_corp -serverIP 192.168.1.79 -authTimeout 5 -ldapBase "DC=corp,DC=Company,DC=com" -ldapBindDn netscaler@corp.Company.com -ldapBindDnPassword TypeThePasswordForTheAccountHere -encrypted -ldapLoginName samAccountName -groupAttrName memberOf -subAttributeName CN -nestedGroupExtraction ON -maxNestingLevel 4 -groupNameIdentifier samAccountName -groupSearchAttribute memberOf -groupSearchSubAttribute CN
add authentication ldapPolicy corp.Company.com ns_true LDAP-LB_LDAP_corp

add authentication vserver vs_Auth.Company.com SSL 192.167.233.32 443 -AuthenticationDomain Company.com
bind authentication vserver vs_Auth.Company.com -policy corp.Company.com -priority 100

set tm sessionParameter -SSO ON

add serviceGroup SG_ADFS_HTTPS SSL -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -cltTimeout 180 -svrTimeout 360 -CKA NO -TCPB NO -CMP NO -appflowLog DISABLED
bind serviceGroup SG_ADFS_HTTPS ADFS_Server1 443 -CustomServerID "\"None\""
bind serviceGroup SG_ADFS_HTTPS ADFS_Server2 443 -CustomServerID "\"None\""
bind serviceGroup SG_ADFS_HTTPS -monitorName https-ecv

add lb vserver LB_ADFS_Proxy_Replacement_FullAuth_Forest SSL 192.167.233.30 443 -persistenceType COOKIEINSERT -timeout 0 -cltTimeout 180 -AuthenticationHost auth.Company.com -Authentication ON
bind lb vserver LB_ADFS_Proxy_Replacement_FullAuth_Forest SG_ADFS_HTTPS
bind ssl vserver LB_ADFS_Proxy_Replacement_FullAuth_Forest -certkeyName Company-wildcard


*************** This part is related to RSA and is optional but we require that user authenticate using their AD password AND RSA token, make sure the LDAP part works fine before adding secondary authentication ***************


add serviceGroup SG_RSA_1645 RADIUS -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport NO -cltTimeout 120 -svrTimeout 120 -CKA NO -TCPB NO -CMP NO -appflowLog DISABLED

bind serviceGroup SG_RSA_1645 RSA-AM-Server1 1645 -CustomServerID "\"None\""
bind serviceGroup SG_RSA_1645 RSA-AM-Server2 1645 -CustomServerID "\"None\""
bind serviceGroup SG_RSA_1645 -monitorName ping

add lb vserver LB_RSA-AM RADIUS 192.168.1.14 1645 -persistenceType SOURCEIP -timeout 700 -cltTimeout 120
bind lb vserver LB_RSA-AM SG_RSA_1645

add authentication radiusAction LB_RSA-AM_srv -serverIP 192.168.1.14 -serverPort 1645 -radKey YourRadiusSharedSecretHere -encrypted
add authentication radiusPolicy Radius-Company ns_true LB_RSA-AM_srv

bind authentication vserver vs_Auth.Company.com -policy Radius-Company -priority 100 -secondary


********* End configuration code *******


*************** Begin Ending Notes ***************


For LDAP authentication action, you have to create a standard user (no special right required except "password never expire") for the netscaler to use this account to log in to the LDAP server and check for the user credential. The GUI offer an option to test the LDAP credential to make sure the connection works.

The Domain you set on your ADFS_Proxy_replacement and on your Auth.company.com MUST MATCH with the domain in the URL your users are sent for the ADFS authentication. My ADFS is setup as fs.company.com, this is the name clients will connect to, and so it must be resolvable via DNS externally.

Fs.company.com must resolve to your LB_ADFS_Proxy_Replacement_FullAuth_Forest


*************** Finish Ending Notes ***************

Use Citrix Netscaler as a replacement for ADFS Proxy

I did a setup last year to replace the Microsoft ADFS Proxy by using the Netscaler 10.1 as the reverse proxy for ADFS 2.0 on Windows 2008r2 (I found a Citrix article about ADFS 3.0 that refer to the fact that Netscaler doesn't support the sni feature for the backend server that is used in ADFS 3.0 which is most likely causing headache to ADFS 3.0 users. http://support.citrix.com/article/CTX125798
The citrix article refer you to this microsoft article that talk about a way to partially disable the SNI feature for ADFS 3.0... http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx

Citrix recently published a document to accomplish this but after looking at it I realized that my setup was looking much simpler so I will publish it in this article. This blog article assume you already have your Netscaler deployed in the DMZ ready to accept external connection (we use "2 arm mode" as we do some Load balancing internally and also some reverse proxy externally)

To use the Netscaler as a reverse proxy for ADFS you need to have your Netscaler licensed for "AAA - Traffic Management" (AAA-TM) so that you can authenticate directly on the Netscaler using LDAP.

This step is optional but I strongly suggest that you Load Balance (LB) your Domain Controller (DC) to have LDAP redundancy in your Netscaler as you can't configure it to authenticate to more than 1 source so if that source is a LB then you have redundancy. 

Go into Traffic management, Load Balancing, Servers -> Add, enter the name of your domain controller (DC1.domain), the IP address and then click create. Repeat for the rest of your DC. 

Next, you need to create a service group for LDAP, go into Traffic management, Load Balancing, Service Groups-> Add, name: SG_LDAP_Domain_389 -> Protocol: TCP -> under members, click on server based, under port, type: 389, then choose the DC you created previously DC1.domain and click add, repeat for every DC in that domain, go into the monitors tab and choose TCP (note: this will only monitor if port 389 is open and listening on the DC (Citrix has some documentation on how to create a complete LDAP monitor if you really want to be bullet proof but I didn't do it so I can't comment on this part, for us, monitoring TCP port 389 was considered reliable enough to confirm if the DC is up or not). Note: Citrix documentation configure things using "Services" but I prefer to do the configuration using "Service Groups" as to me it's always simpler and safer to create a Group and put member in it instead of configuring multiple service for the same need with multiple server. 

Next we create the LB Vserver for LDAP, go into Traffic management, Load Balancing, Virtual Servers -> Add, name: LB_LDAP_Domain, IP address: x.x.x.x, Port: 389, Services Group: SG_LDAP_Domain_389, in the Method and Persistence Tab, LB Method: Least connection, Persistence: None.

Now we will create the LDAP authentication, go into Security, AAA - Application Traffic, Policies, Authentication, LDAP, in the Servers tab, click on add, Name: LDAP-LB_LDAP_Domain, Authentication type: LDAP, IP address: x.x.x.x (you need provide the IP address of the LB Vserver you created earlier) Type: AD, Port: 389, Timeout: 5, Base DN: DC=corp,DC=company,DC=com (I input the root of the domain as the search point but you can "OU=users," in front of it to restrict the search) "Administrator Bind DN" is the user you define to authenticate in AD, this user doesn't need any special permission as everyone that is authenticated has read access in AD, password and confirm password are self-explaining. Server logon Name: SamAccountName, Group Attribute: memberOf, Sub Attribute name: CN, Security: PLAINTEXT (we used port 389 above which is unencrypted). Put a check mark into "Authentication" and "User Required", under nested group extraction, I choose enable, Maximum Nesting Level: 4, GroupName: SamAccountName, Group Search: memberof, Group Search Sub-attribute: CN. Click create.

Next, still under LDAP go into the Policies tab, click Add -> Name: domain.company.com, Authentication Type: LDAP, Server: LDAP-LB_LDAP_Domain, Expression: ns_true, click create.

Next, under Security, AAA-TM, Virtual Servers, click Add, Name: vs_Auth.domain.com IP: x.x.x.x. Protocol: SSL, Port: 443 Domain: company.com (This field is very important see AuthDomainNote for more detail) Certificates: choose a valid certificate for the URL your user will be redirected to for login (Ex: auth.company.com), under authentication tab, click on "Insert Policy" in the bottom of the page and choose the policy we created earlier: domain.company.com and click on create. Note, you can configure multiple authentication profile if you want to use the dual factor authentication you can create an RSA authentication policy and insert it in the "Second..." and you will have dual authentication. http://support.citrix.com/article/CTX113640/ explain how to setup RSA with Netscaler, just do the setup under security, AAA-TM, Policies, Authentication, Radius instead of under Netscaler Gateway.

Next we need to make sure SSO is enable in AAA-TM -> go into Security, click on AAA - Application Traffic and choose "Change global settings" and put a check mark into "Single Sign-on to Web Applications" then click OK.

Finally we create the ADFS LB_Vserver and his component, go to traffic management, Load Balancing, Servers to add your ADFS servers the same way we created the DC earlier, then go into "Service Groups", create a new service group for your ADFS servers, Name: SG_ADFS_HTTPS Protocol: SSL, choose "server based", port: 443 click "add" on your ADFS server, in the monitor tab: choose: httpS-ecv

Go to Load Balancing, Virtual Servers, click Add

Name: LB_ADFS_ExternalUrl, Protocol: SSL, IP: x.x.x.x (This need to be resolvable externally as your ADFS URL, it's the IP address that was pointing to your ADFS Proxy before), Port: 443, Service Groups Tab: SG_ADFS_HTTPS, Method and Persistence tab: Least connection, Persistence: COOKIEINSERT, time-out: 0, SSL settings: Choose the certificate that match your ADFS URL. The important part is under advanced tab, scroll down to the bottom and expend "Authentication settings", check the "Authentication" box and then enter the FQDN of the url your user will be redirected to for authentication (EX: auth.company.com) See AuthDomainNote2 below.

 AuthDomainNote: The domain here is critical if you want to have everything working, it must match with the domain name that your user will be coming from to this Vserver, if user want to authenticate to application.testcompany.com and your domain name is company.com then the authentication will not work, it will only authenticate user coming from the domain company.com, this is not related to the domain name you put in AD, it can be anything as long as your domain match the domain of the url it's coming from.

AuthDomainNote2: This URL must be reachable externally and it must point to the Authentication Vserver IP address.

Now if everything works fine when you try and reach your ADFS URL you will land on the Black Netscaler login page. Type your LDAP credential and the Netscaler will then request an ADFS token on your behalf from the ADFS server and you will then be granted access to Office365 portal. This also works with any other ADFS provider that you may have configured.

Next step you will most likely want is to customize the Netscaler login page to fit your company need. I published an article in December 2014 that explain how to achieve this: http://cividan.blogspot.ca/2014/12/customize-netscaler-101-aaa-tm-login.html

renouvellement des certificats de token signing/decrypting ADFS

Pour augmenter la duré des certificats de token:

http://social.technet.microsoft.com/wiki/contents/articles/4588.ad-fs-2-0-how-to-modify-the-duration-of-autocertificaterollover-certificates.aspx

Steps

1. Launch an administrative Powershell console window
2. Add the AD FS 2.0 Powershell snap-in:

        Add-PsSnapin Microsoft.Adfs.Powershell

3. Set the CertificateDuration property in the Federation Service Properties:

        Set-AdfsProperties -CertificateDuration integer-number-in-days

        Example for a 5-year certificate duration
        Set-AdfsProperties -CertificateDuration 1825

Note: la switch -urgent mentionner dans l'article technet vous empêche de pouvoir faire un rollback en cas de problème car elle supprime l'ancien certificat et le remplace par un nouveau donc je ne recommande pas de mettre cette switch mais plutôt de temporairement désactiver le AutoCertificateRollover et de modifier manuellement le primary certificate.

Pour renouveller les certificats de token ADFS, il faut utiliser les commandes powershell suivante:

Add-PsSnapin Microsoft.Adfs.Powershell

Set-AdfsProperties -CertificateDuration 1825

Update-AdfsCertificate

Lorsque vous aurez fait le Update-AdfsCertificate, dans la console ADFS, vous allez voir 2 certificats pour les token signing et token decrypting, dont un qui est disponible à partir de la date que vous venez de généré (date du jour).

Ensuite, il faut désactiver le auto-rollover des certificats pour pouvoir gérer manuellement quel certificat est le primary en utilisant la commande powershell suivante:

Set-ADFSProperties -AutoCertificateRollover $false

Maintenant vous pouvez aller dans la console ADFS et modifier le « Token-Signing certificate » avec un clic droit « Set as primary » sur le certificat secondaire. Répétez l’opération avec le « Token-Decrypting certificate ».

NOTE : Si jamais un problème insurmontable survient vous pouvez faire un retour en arrière en faisant un clic droit sur l’ancien certificat qui est maintenant secondaire et choisir « Set as primary ».

Ensuite il faut renouvelé les relaying party trust: Pour office 365 il faut utilisé l'outil "windows azure active directory module for powershell"

ATTENTION : si vous faites un RollBack et que vous aviez déjà remplacé le certificat avec certains trusts vous devrez les mettre à jour à nouveau si vous changez le primary certificate.

 
Rebooter les serveurs ADFS est une suggestion optionnelle mais recommandé par Microsoft. Je recommande donc de rebooter les serveurs ADFS à tour de rôle en débutant par le principal. Si vous avez des serveurs ADFS proxy, il faut allez dessus et re-faire le "AD FS 2.0 Federation Server Proxy Configuration Wizard."

Renouvelez les certificats sur les « relaying party trust », pour voir les trusts présents il faut ouvrir « AD FS 2.0 Management », naviguez jusqu’à Trust Relationships --> Relaying Party Trusts, regardez dans la fenêtre du milieu les trusts présents qui ont le statut « Enable » à « Yes »

Après avoir changé les certificats, il faut aller changer le token-signing dans les applications externe qu’on à configurer avec ce certificat :

     

Office 365:

Pour Office365, allez sur le serveur adfs, lancez le « Windows Azure Active Directory Module for Windows PowerShell »

Connect-MSOLService  (vous allez avoir un pop-up qui demande les credentiels {utliser votre compte admin office 365 ex: admin@companyOnMicrosoft.com})

Pour voir quel domaines sont synchronisé avec Office 365 et savoir quel domaine est le principal, utiliser la commande suivante:

Get-MsolDomain | fl name, rootdomain  (si plusieurs domaine s'affiche vous allez les voir avec le nom du domaine qui est le principal (RootDomain) pour faire la commande suivante utiliser celui de vos domaines qu n'a pas de RootDomain et qui n'est pas *.OnMicrosoft.com pour la commande suivante, si un seul domaine apparaît autre que celui *.OnMicrosoft.com alors vous n'avez pas besoin de la switch -SupportMultipleDomain dans la commande suivante.
 

Update-MsolFederatedDomain -DomainName compagnie.ca -SupportMultipleDomain

Ensuite il faut edité le "claim rule #3" et remplacer le contenu par le texte suivant sans les guillemets:
" c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
 => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, "^((.*)([.|@]))?(?<domain>[^.]*[.].*)$", "http://${domain}/adfs/services/trust/")); "

Pour confirmer que le certificat dans le cloud est le même que celui sur le serveur ADFS utiliser la commande suivante:

Get-MsolFederationProperty -DomainName compagnie.ca
Comparez les valeurs des Serial number et Thumbprint des certificats dans les sources ADFS server et Microsoft Office 365

Autre référence pour le -SupportmultipleDomain

http://blogs.technet.com/b/abizerh/archive/2013/02/06/supportmultipledomain-switch-when-managing-sso-to-office-365.aspx

Sharefile:

Pour Sharefile, il faut exporté le "token signing certificate" en base64 x.509 et l'ouvrir avec notepad, copié/collé le contenu du certificat dans la page d'administration de sharefile dans la section SSO.

Assurez-vous de vider la cache et les cookies de votre navigateur lors de vos tests pour ne pas avoir de faut résultat

N.B. Si vous avez des problème n'oubliez pas que vous pouvez toujours remettre l'ancien certificat temporairement en allant dans la console ADFS et choisir "Set as primary".

Lorsque vous avez testé tous vos trust et que tout fonctionne bien, remettez le rollover automatique des certificats à $True avec les commande Poweshell suivantes:

Add-PsSnapin Microsoft.Adfs.Powershell

Set-ADFSProperties -AutoCertificateRollover $True

Lorsque vous retournez dans la console ADFS dans la section certificat faire un refresh et vous faites un clic droit sur le certificat, l'option "Set as primary" sera grisé. Si ce n'est pas le cas vos certificats ne feront pas de Rollover automatiquement.

Voilà !