As a Citrix consultant, I recently addressed a customer request that would be useful to share. The customer wanted to restrict the visibility of a subset of applications and desktops to users with a valid second authentication factor (user certificate). At the same time, they wanted to continue to allow access to a less-sensitive subset of applications and desktops to users authenticating with just a username and password .
Thanks to Citrix ADC N-factor and Smart Access features, Citrix ADC (formerly NetScaler ADC) and Citrix Virtual Apps and Desktops (formerly XenDesktop) can work together to deliver this user experience.
The flow graph below describes this use case, detailing the desired behavior.
What Are the Prerequisites and Constraints?
- Configure callback URL field in the StoreFront Store configuration. (Setting the callback to use Smart Access is mandatory.)
- Enable Trust XML.
- If present, remove ICA-only flag from NS GW VIP (enabling Smart Access).
- Citrix ADC universal licenses are used in this scenario. Starting with build 11.1.49.xx, the following licenses are included: NS Standard includes 500 licenses; NS Enterprise includes 1,000 licenses; and NS Platinum has no CCU requirement. Additional details are available here.
- N-Factor and AAA VServer are used for this configuration, so a Netscaler Enterprise license (at least) is a prerequisite.
- Applications and desktops are filtered on a delivery-group basis. It is the delivery group, configured as sensitive, to be hidden from those users without a valid user certificate.
- This guide assumes that a valid Citrix Gateway VServer is already configured.
- Test the configuration in a proper test environment
First, we are going to configure certificate authentication with a fallback to LDAP as described at https://support.citrix.com/article/CTX201730.
The only differences from the CTX201730 are that we will add a second factor for users with a valid user certificate and set a default user group for users with a valid user certificate.
#Create a not addressable authentication Vserver add authentication vserver AuthVserverTest SSL -state ENABLED -authentication ON #bind the certificate to the auth Vserver (it is not addressable the name can not match) bind ssl vserver AuthVserverTest -priority 0 -certkeyName -crlCheck optional #Add an authentication profile and bind it to the Citrix Gateway Vserver add authentication authnProfile AuthProfile -authnVsName set vpn vserver -authnProfile AuthProfile #Create two Advanced policies and actions for Cert And LDAP authentication and bind them to the auth-Vserver #note that a default Authentication Group is set for Certificate Users add authentication certAction CertificateAuth -twoFactor ON -userNameField Subject:CN -defaultAuthenticationGroup CertUsers add authentication Policy CerificateAuth_Pol -rule true -action CertificateAuth add authentication ldapAction Server_LDAP -serverIP -ldapBase "dc=citrix,dc=lab" -ldapBindDn citrixservices -ldapBindDnPassword -ldapLoginName sAMAccountName add authentication ldapPolicy Server_LDAP_pol NS_TRUE Server_LDAP #Create the CitrixADC Local Group "CertUsers" add aaa group CertUsers
Users with a valid user certificate will be prompted for password. The username will be extracted from the certificate.
Then, add the following login schema and policy label.
add authentication loginSchema SecondFactorSchema -authenticationSchema "/nsconfig/loginschema/LoginSchema/OnlyPassword.xml" add authentication policylabel PLabel_SecondF -loginSchema SecondFactorSchema
Now we bind the authentication policies to the authentication VServer.
bind authentication vserver AuthVserverTest -policy CerificateAuth_Pol -priority 100 -nextFactor PLabel_SecondF -gotoPriorityExpression NEXT bind authentication vserver AuthVserverTest -policy Server_LDAP_pol -priority 110 -gotoPriorityExpression NEXT
We now have a Citrix Gateway Vserver that allows access to users with a valid certificate and password or with a username and password.
To get the configuration we want, we have to filter sensitive desktops and applications to users authenticating with two factors. We will duplicate the session policies to identify these two different scenarios.
So if you have, as I expect, the session policies bound to the Citrix Gateway VServer, you should duplicate them, with the second policy (with a different name) pointing to the same action
The new policy is going to be bound to the CertUsers AAA user group, with the right priority, so that it takes precedent over the policy bound to the Citrix Gateway Vserver.
This is necessary because the policy name is going to be used in the XenDesktop Smart Access Filter to identify the users with a valid certificate.
For instance, in my lab environment, I have the following session policy bound to the VServer.
add vpn sessionPolicy PL_WB_172.30.200.118 "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" AC_WB_172.30.200.118
We are going to create a second policy pointing to the same action, and we will bind it to the user group.
add vpn sessionPolicy PL_WB_CertUsers "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" AC_WB_172.30.200.118 bind aaa group CertUsers -policy PL_WB_CertUsers -priority 100
Now we can set the Smart Access filter on the deliver groups where we want to restrict visibility.
Edit the delivery group and set the filter so that:
- “Site or Farm names” matches the Citrix Gateway’s virtual server name
- “Filter” matches the Citrix Gateway session policy name bound to the group
Set the same filter for all the sensitive resources you want to hide.
Thanks to this configuration, it is possible to identify which virtual applications and desktops require a valid second authentication factor while continuing to permit access to less-sensitive contexts with a simpler authentication.
Check out the Citrix Product Documentation site for more information about N-Factor and Smart Access.