NetScaler – An Identity Provider (IdP) Solution with MFA for OnPrem-Services and Citrix DaaS

Reading Time: 7 minutes

Overview

Recently I had the pleasure of being invited to the SwissCUGC Event in Zurich about the benefits for using Citrix ADC as an overall Identity Provider (IdP). It was really great fun and I met some cool community people.

This post will give you an introduction and some technical insights why I’m using Citrix ADC as IdP as a preferred solution at my customers. I love doing configurations with Azure Active Directory as centralized IdP – but there are several customers which aren’t allowed to use AAD / M365 at this time, yet.

This bought me to the idea to create a strong alternative solution, which is flexible enough in technical and sales perspective. With nFactor and Group Extraction you get the maximum flexibility for smooth MFA adoption and also an emergency fallback to single factor. So this post includes some details about Native OTP / Push OTP, Certbased Authentication (CBA) and also SAML / OAuth in nFactor flows. Costs is also a perspective which I wrote about.

Configuration

Native OTP

Citrix ADC Native OTP is included starting with advanced edition. As I’ve done a bunch of deployments in different scenarios, here are some of my personal points to consider when choosing Native OTP as a second factor.

• The OTP store location is Active Directory
• Enable OTP encryption as default
• Think about the location of the private key of the encryption certificate
• Create a dedicated AD-Attribute, never use “UserParameters” (as they can include legacy paths to Roaming Profiles)
• Stop using LDAP, use LDAPS instead
• As mostly there is more than one Domain Controller (and more than one ADC) it’s a High Available MFA solution
• In most deployments with RADIUS Boxes (like LinOTP, RSA, SafeNet,…) I’ve seen only one standalone virtual Appliance, that’s the single point of failure in the logon-scenario
• The Sub-URL /manageotp is accessing the Inbuilt LoginSchema SingleAuthManageOTP.xml
• This is happening as there a some hidden fields which create the NSC_TASS Cookie and enables the OTP-Registration page
• If you want to know more about how this is functioning and how you are able to secure the /manageotp with MFA, too, checkout here
• Use a dedicated Token-Selfservice URL, the User isn’t able to differ between the Gateway Loginpage and the Sub-URL /manageotp

Push OTP

Citrix ADC Push OTP is included only in premium edition. As I’ve done a bunch of deployments in different scenarios, here are some of my personal points to consider when choosing Push OTP as a second factor.

• The Push-Notification is coming from the Push-Service of Citrix Cloud. You have to create at least a Citrix Cloud Tenant (choose your preferred Region) and register your ADC as a Secure Client. There is no need for any additional chargeable Cloud Service

• At least one SNIP must be able to access mfa.cloud.com and trust.citrixworkspacesapi.net via https
• Think about a combination of Push OTP and Native OTP
• To register for Push OTP, you have to use the Citrix SSO App, which isn’t available for all Smartphone Operating System
• When trying to scan the QR-Code with other OTP Apps, the registration of the OTP fails, as the Push Service cannot connect
• There is also the need for working with service accounts on shared desks, which brings the idea for using WinAuth as an open-source portable Windows Authenticator
• Create a separate Token-Selfservice-Legacy URL (which is basically the configuration of Native OTP) and use both in a row via nFactor flow
• The Token-Selfservice URL has to be published to the Internet
• When Scanning the QR-Code with the Citrix SSO App (this is the only supported app which is supporting the Push-Notification) the Citrix Cloud Push-Service is registering and accessing the Token-Selfservice URL
• For hardening (so Users are only able to register and manage their Token from internal) use a dedicated Gateway vServer with an AAA profile and some SRC IP filters set into the authentication LoginSchema policy (via Pattern Sets)
• Use the Inbuilt “DualAuthPushOrOTP” LoginSchema as your template, if there’s no internet-connection for receiving the Push-Notification, Users are able to insert the OTP by manual as there is the option to enable a third loginbox – example:

Certificate-Based Authentication (CBA)

CBA is truly a wide common MFA-Solution, most because it’s free to use with Windows PKI Services and it’s often used to make a difference between services, accessed by Corporate-Owned vs. Private-Owned (BYOD) device.

It’s possible to enable CBA as a first check in a ADC MFA nFactor flow. Just care about some limitations when using different native clients other than only browsers. You definitely have to set an expression for example only offering a certificate during login mechanism when using Google Chrome, Microsoft Edge or Citrix Workspace App (starting with Build 1809, the browser engine’s header is called CWAWEBVIEW)

HTTP.REQ.HEADER("User-Agent").CONTAINS("Chrome")||HTTP.REQ.HEADER("User-Agent").CONTAINS("Edg")||HTTP.REQ.HEADER("User-Agent").CONTAINS("CWAWEBVIEW")

See more details about CBA in my other post.

Citrix DaaS with OAuth

You are able to use your OnPrem ADC for doing authentication on your cutomer.cloud.com Cloud Workspace, too. When accessing customer.cloud.com, you get redirected to your OnPrem aaa.customer.com, doing your preferred Auth-Flow and kicked back with SSO to your customer.cloud.com Cloud Workspace. Some insights about connecting Citrix Gateway as IdP:

• The DaaS Wizard is saying you should connect with your Citrix Gateway FQDN – don’t use a Gateway vServer, use your AAA nFactor vServer instead
• Save the generated clientID, clientSecret and put these into the script below
• OAuth policies are independent bound policies on your AAA, these don’t correlate with other LDAPS / SAML / … policies
• As it’s using the OAuth protocol – not SAML – the no need for certificates for signing or encryption is the most benefit
• It’s no rocket science, the configuration on ADC is done with these simple commands – I’ve added an extension for filtering internal / external – as the redirection takes also place when accessing your Cloud Workspace from internal:

#Adding OAuth Profile
add authentication OAuthIDPProfile CitrixCloudGatewayIDP -clientID 12345 -clientSecret 12345 -redirectURL "https://accounts.cloud.com/core/login-cip" -issuer "https://aaa.customer.com" -audience (clientid) -skewTime 10 -encryptToken ON -sendPassword ON
add authentication OAuthIdPPolicy OAuth_CitrixCloudGatewayIDP -rule true -action CitrixCloudGatewayIDP

bind authentication vserver AAA_vServer_nFactor_NA -policy OAuth_CitrixCloudGatewayIDP -priority 100 -gotoPriorityExpression END


#Binding your cert to vpnglobal is a requirement
bind vpn global -certkeyName wildcard.customer.com


#Creating a Pattern Set for Filtering internal Subnets, presenting just Username + Password when access to customer.cloud.com is happening from internal
add policy patset PatSetCloud_InternalSubnets
bind policy patset PatSetCloud_InternalSubnets "192.168.1.0/24" -index 1

#Creating sepearte LoginSchema for Single-Auth
add authentication loginSchema InternalSingleAuth -authenticationSchema "/nsconfig/loginschema/custom/InternalPasswordOnly.xml"
add policy expression PolExpr_Cloud_InternalSubnets "(CLIENT.IP.SRC + \"/32\").EQUALS_ANY(\"PatSetCloud_InternalSubnets\") || (CLIENT.IP.SRC.SUBNET(22) + \"/22\").EQUALS_ANY(\"PatSetCloud_InternalSubnets\") || (CLIENT.IP.SRC.SUBNET(24) + \"/24\").EQUALS_ANY(\"PatSetCloud_InternalSubnets\")"
add authentication loginSchemaPolicy InternalSingleAuth -rule PolExpr_Cloud_InternalSubnets -action InternalSingleAuth
add authentication Policy Adv_Pol_LDAPS_PatSetFilter -rule PolExpr_Cloud_InternalSubnets -action Auth_LDAPS_No_Filter
bind authentication vserver AAA_vServer_nFactor_NA -policy InternalSingleAuth -priority 95 -gotoPriorityExpression END

• Checkout your Active Directory User Properties. The following properties must be set – if these are empty, Users can’t sign in to their workspace. If there are Users without an Email account, you have to insert a fake-mail / place holder into the Email address property

Citrix ADC as SAML IdP with Cisco AnyConnect as SAML SP

There isn’t much documentation on how to use Citrix ADC as a SAML IdP with other SAML-compliant products for doing authentication on the ADC-side. Most helping hands I was getting from Johannes Norz in his Post about SAML with ADC. Here is an example by connecting your ADC as SAML IdP to a Cisco Firepower Appliance as SAML SP for redirecting the Auth-Flow to ADC AAA when using the Cisco AnyConnect Client (it also includes a browser-engine like Citrix Workspace App) for doing Client-VPN.

• Create your ADC SAML IdP configuration and remember the different AAA URLs for putting it into the Cisco Firepower Auth-Configuration
• It’s recommended to configure the “Assertion Consumer Service URL Rule” to only include the FQDN of the corresponding SAML SP, see CTX316577 – in my deployment the Auth-Flow was never successful with this setting, tried different Firepower SAML SP URLs, that’s why it’s empty in my script
• For doing group extraction / client-IP filtering, the Firepower needs the User-Attribute in sAMAccountName@contoso.com format, that’s why I’m using the NameIDExpression “AAA.USER.NAME + \”@\” + \”contoso.com\”” in my script below

#################################################
#Using Citrix ADC as SAML IdP, creating Selfsinged Cert via Key on ADC and Certcreation via OpenSSL and Importing on ADC as PFX
#Example with Cisco FirePower for AnyConnect Client-VPN

#IDP Entity ID:
#https://aaa.customer.com/saml/login

#SSO URL:
#https://aaa.customer.com/saml/login

#Logout URL:
#https://aaa.customer.com/cgi/tmlogout


add authentication samlIdPProfile AuthProf_AnyConnect_SP -samlSPCertName wildcard.customer.com -samlIdPCertName ADC-IDP -assertionConsumerServiceURL "https://vpn.customer.com/+CSCOE+/saml/sp/acs?tgname=CVPN_AnyConnect" -samlIssuerName "https://aaa.customer.com/saml/login" -audience "https://vpn.customer.com/saml/sp/metadata/CVPN_AnyConnect" -NameIDFormat Unspecified -NameIDExpr "AAA.USER.NAME + \"@\" + \"contoso.com\"" -SPLogoutUrl "https://vpn.customer.com/+CSCOE+/saml/sp/logout"
add authentication samlIdPPolicy Auth_Pol_CustomerAD_SAML_AnyConnect -rule true -action AuthProf_AnyConnect_SP

bind authentication vserver AAA_vServer_NA -policy Auth_Pol_CustomerAD_SAML_AnyConnect -priority 90 -nextFactor lschema_EnterUsername -gotoPriorityExpression NEXT

• This is the configuration of the Single Sing-on Server on Cisco Firepower as SAML SP:

Cost Recommendation

Long story short – Citrix Service Provider (CSP) for the Win!

Here’s why I highly recommend using the CSP licensing-model for your ADC setup:

• Pay per Instance per Month (and terminable per Month)
• Upgrade or Downgrade the license edition or Throughput per Month
• Pooled vCPU capacity possibilities with ADM
• Availability for full-featured VPX 50-Series (not that restricted VPX Gateway Enterprise one)
• In a HA-Setup you only have to pay for the Primary Node

Which I came to my personal conclusion Purchasing ADC perpetual licenses is a waste of money these days, mostly because of no flexibility.

Migrating MFA to a new Phone

Dennis Span recently blogged about how to migrate OTP tokens / accounts from the most common authenticator apps. Checkout here.

Summary

I hope I was able to give you some insights about the functionality of Citrix ADC as an Identity Provider. Please feel free to give me some feedback or asking questions.