Overview
Two-factor authentication is standard in most infrastructures where users are prompted for something they have and something they know. Generally, two factor authentication on the Netscaler is integrated with Radius where the Radius server is LDAP integrated however we have seen some scenarios where the Active Directory and RSA infrastructures are not integrated so the usernames are different for both authentication methods.
This case study details a recent engagement with this particular requirement. The access scenario below details the use-case and the use of responder policies along with AAA to satisfy the requirements for this customer.
Access Scenario
- When a user connects initially to the URL https://access.company.com they will be presented with the NetScaler Gateway login screen which prompts for Active Directory username and password only. Provided the authentication is successful AD groups are extracted.
- If a user does not belong to the AD-2Factor-Auth group (the group containing the two-factor users), they are forwarded to a StoreFront LB VIP (load balanced on the NetScaler) and subsequently experience a seamless single sign-on with StoreFront and their desktops.
- If a user does belong to the AD-2Factor-Auth group they are redirected via a NetScaler Responder policy to a separate StoreFront LB VIP (also load balanced on the NetScaler) that requires additional authentication. This storefront LB VIP is front-ended by a AAA-TM VIP that prompts them now for their RSA username and PIN + Token code.
- Provided that authentication is successful they are then forwarded to StoreFront where they login in again with their AD username and password, completing the process. If this authentication is successful they are presented with their desktops.
- When the user selects ‘Logout’ NetScaler Rewrite policies ensure their local authentication cookies are expired so they must authenticate again to resume access. Because this occurs at the StoreFront load balancer requiring authentication user must again provide both RSA and Active Directory credentials maintaining the 2-factor requirement.
Fig 1: User Flow
Note: Due to the Responder redirect policies actually redirecting the endpoint device both StoreFront Load Balancer 2 and the AAA VServer must be accessible by the endpoint in addition to the initial NetScaler Gateway VIP. Depending on the deployment these can be secured with policies crafted to drop traffic that does not meet conditions established using Regular Expressions.
Policies and Actions
The following CLI entry was used to create the NetScaler Gateway VServer
- add vpn vserver nsgateway_vpn_vserver SSL 10.0.0.150 443 -icaOnly ON -Listenpolicy None
The Responder policy checks for a user that is a member of the “AD-2Factor-Auth” Active Directory group. If a user authenticating through the NetScaler Gateway is a member then the Responder action bound to the policy triggers. In this case the Responder action is a redirect to another URL before the session policies are applied.
The following CLI entries were used to create and bind the Responder policies and actions that redirect two-factor users after they have authenticated with LDAP at the NetScaler Gateway VServer
- add responder action RSA_Redirect_Action redirect “\”https://company.com/Citrix/StoreWeb\””
- add responder policy RSA_Redirect_Policy “HTTP.REQ.USER.IS_MEMBER_OF(\”AD-2Factor-Auth\”)” RSA_Redirect_Action
- bind vpn vserver nsgateway_vpn_vserver -policy RSA_Redirect_Policy -priority 100 -gotoPriorityExpression END -type REQUEST
The Load Balancing VServer works in conjunction with the Authentication VServer to provide the second factor of authentication (RADIUS in this case). Authentication is enabled on the Load Balancing VServer and directs the user to the tmindex.html where they perform authentication with the configured service. If successful the user is forwarded through to the back-end servers behind the Load Balancing VServer using the configured LB and persistence methods.
The Load Balancing VServer was configured from the following CLI commands
- add lb vserver twofactorsflb.company.com_vserver SSL 10.0.0.151 443 -persistenceType SOURCEIP -Listenpolicy None -cltTimeout 180 -AuthenticationHost RSAServer.company.com -Authentication ON -authnVsName RSA_Auth_VServer -comment “RSA LB VIP”
The Authentication VServer was creating using the following CLI commands
- add authentication vserver RSA_Auth_VServer SSL 10.0.0.152 443 -AuthenticationDomain company.com
When the user that was a member of the AD-2Factor-Auth group selects “Logoff” from the StoreFront interface a series of Rewrite policies trigger their associated actions. These actions edit the AAA cookies on the users endpoint to set the expiry date into the past. This immediately makes the cookies invalid so that the user must perform the AAA and StoreFront authentication again.
The following CLI entries were used to create and bind the Rewrite policies and actions that expire the AAA cookies on the user endpoint when “Log Off” is selected at StoreFront. They are modified versions of the OWA Logout policies and actions found in the Citrix Blog http://blogs.citrix.com/2011/11/11/ensuring-secure-logout-for-your-application/ by Abhilash Verma.
- add rewrite action RSA_EXPIRE_TMAS_COOKIE_Action insert_http_header Set-Cookie “\”NSC_TMAS=xyz;Domain=.company.com;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure\””
- add rewrite action RSA_EXPIRE_TMAA_COOKIE_Action insert_http_header Set-Cookie “\”NSC_TMAA=xyz;Domain=.company.com;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40 GMT;Secure\””
- add rewrite policy RSA_EXPIRE_TMAS_COOKIE_Policy “HTTP.REQ.URL.CONTAINS(\”/Citrix/StoreWeb/Authentication/Logoff\”)” RSA_EXPIRE_TMAS_COOKIE_Action
- add rewrite policy RSA_EXPIRE_TMAA_COOKIE_Policy “HTTP.REQ.URL.CONTAINS(\”/Citrix/StoreWeb/Authentication/Logoff\”)” RSA_EXPIRE_TMAA_COOKIE_Action
- bind lb vserver SF_RSA_LB_VS -policyName RSA_EXPIRE_TMAS_COOKIE_Policy -priority 90 -gotoPriorityExpression NEXT -type RESPONSE
- bind lb vserver SF_RSA_LB_VS -policyName RSA_EXPIRE_TMAA_COOKIE_Policy -priority 100 -gotoPriorityExpression END -type RESPONSE