Hemang Raval

August 16, 2022 Author: Matt Brooks Special thanks: Dan Feller Introduction Large Enterprise environments require flexible authentication options to meet the needs of a variety of user personas. With Group Extraction user AD group membership determines the number, and type of nFactor authentication methods users are required to complete to verify their identity and access their applications and data. Examples of user groups include: normal-security-group for individuals that may have lower security requirements by the nature of their job or limited data access and are located within the bounds of the corporate security perimeter. This group may only require 1 factor. elevated-security-group for third party workers or contractors who may not have had background checks done and have higher security requirements. This group may require 2 or more factors. high-security-group for employees that perform critical jobs, and require special government clearance, or industry approval. This group may require 2 or more factors and contextual verifications such as source IP address. Overview This guide demonstrates how to implement a Proof of Concept environment using two factor authentication with Citrix Gateway. It uses LDAP only to validate Active Directory credentials if the user’s endpoint is on a private subnet, indicating they are on the corporate intranet, or if they are a member of a “VIP” AD group such as a CXO. Otherwise, it is assumed they are located external to the perimeter of the Enterprise network and not a member of a group with lower security requirements, and are required to complete a second factor in the form of entering an email One Time Password (OTP). It uses a Citrix Virtual Apps and Desktops published virtual desktop to validate connectivity. It makes assumptions about the completed installation and configuration of the following components: Citrix ADC installed, and licensed Citrix Gateway configured with an externally reachable virtual server bound to a wildcard certificate Citrix Gateway integrated with a Citrix Virtual Apps and Desktops environment which uses LDAP for authentication Endpoint with Citrix Workspace app installed Active Directory (AD) is available in the environment Access to an SMTP server to originate email Refer to Citrix Documentation for the latest product version, and license requirements: nFactor Group Extraction nFactor First, we log in to the CLI on our Citrix ADC and enter the authentication actions and associated policies for LDAP and Email respectively. Then we log in to our GUI to build our nFactor flow in the visualizer tool and complete the multifactor authentication configuration. LDAP Authentication policies We create the LDAP actions, and the policies that reference them. We also create the Email action, and the policy that references it, which is the multifactor authentication method for users that are not members of the VIP group or on a local subnet. For LDAP Actions populate the required fields to create the LDAP action in a string and paste it into the CLI: ldapAction - enter the action name. serverIP - enter the domain server/s FQDN or IP address. serverPort - enter the LDAP port. ldapBase - enter the string of domain objects and containers where pertinent users are stored in your directory. ldapBindDn - enter the service account used to query domain users. ldapBindDnPassword - enter your service account password. ldapLoginName - enter the user object type. groupAttrName - enter the group attribute name. subAttributeName - enter the sub attribute name. secType - enter the security type. ssoNameAttribute - enter the single sign-on name attribute. defaultAuthenticationGroup - enter the default authentication group. alternateEmailAttr - enter the user domain object attribute where their email address can be retrieved. For LDAP Policies populate the required fields to reference the LDAP Action in a string and paste it into the CLI: Policy - enter the policy name. action - enter the name of the Email action we created above. For more information see LDAP authentication policies First connect to the CLI by opening an SSH session to the NSIP address of the Citrix ADC and log in as the nsroot administrator or equivalent admin user. LDAP action 1 - authAct_GroupExtract_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication ldapAction authAct_GroupExtract_genf -serverIP 192.0.2.50 -ldapBase "OU=Team M,OU=Team Accounts,OU=Demo Accounts,OU=Workspaces Users,DC=workspaces,DC=wwco,DC=net" -ldapBindDn workspacessrv@workspaces.wwco.net -ldapBindDnPassword 123xyz -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName cn -secType SSL -authentication DISABLED LDAP policy 1 - authPol_GroupExtract_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication Policy authPol_GroupExtract_genf -rule true -action authAct_GroupExtract_genf LDAP policy 2A - authPol_LdapOnly_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication Policy authPol_LdapOnly_genf -rule "AAA.USER.IS_MEMBER_OF(\"VIP\") || client.IP.SRC.IN_SUBNET(10.0.0.0/8)" -action NO_AUTHN LDAP policy 2B - authPol_TwoFactor_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication Policy authPol_TwoFactor_genf -rule "client.IP.SRC.IN_SUBNET(10.0.0.0/8).NOT" -action NO_AUTHN LDAP action 3A - authAct_Ldap_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication ldapAction authAct_Ldap_genf -serverIP 192.0.2.50 -ldapBase "OU=Team M,OU=Team Accounts,OU=Demo Accounts,OU=Workspaces Users,DC=workspaces,DC=wwco,DC=net" -ldapBindDn workspacessrv@workspaces.wwco.net -ldapBindDnPassword 123xyz -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName cn -secType SSL -passwdChange ENABLED LDAP policy 3A - authPol_Ldap_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication Policy authPol_Ldap_genf -rule true -action authAct_Ldap_genf LDAP action 3B - authAct_LDAP_eotp_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication ldapAction authAct_LDAP_eotp_genf -serverIP 192.0.2.50 -serverPort 636 -ldapBase "DC=workspaces,DC=wwco,DC=net" -ldapBindDn workspacessrv@workspaces.wwco.net -ldapBindDnPassword 123xyz -encrypted -encryptmethod ENCMTHD_3 -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName cn -secType SSL -ssoNameAttribute userPrincipalName -defaultAuthenticationGroup Email-OTP -alternateEmailAttr otherMailbox LDAP policy 3B - authPol_LDAP_eotp_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication Policy authPol_LdapEtop_genf -rule true -action authAct_LDAP_eotp_genf Email Authentication policy Populate the following fields to create the Email action and paste the completed string into the CLI: emailAction - enter the action name. userName - enter the user, or service account, that log in to the mail server. password - enter your service account password to log in to the mail server. (The password is encrypted by the Citrix ADC by default) serverURL - enter the FQDN or IP address of the mail server. content - enter the user message next to the field to enter the email code. time out - enter the number of seconds the email code is valid. emailAddress - enter the LDAP object to query for the user email address. For the Email policy populate the required fields to reference the Email Action in a string and paste it into the CLI: Policy - enter the policy name. action - enter the name of the Email action For more information see Email OTP authentication policy Email action 4B - authAct_Email_eotp_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication emailAction authAct_Email_eotp_genf -userName workspacessrv@workspaces.wwco.net -password 123xyz -encrypted -encryptmethod ENCMTHD_3 -serverURL "smtps://192.0.2.40:587" -content "Your OTP is $code" -timeout 60 -emailAddress "aaa.user.attribute(\"alternate_mail\")" Email policy 4B - authPol_Email_eotp_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication Policy authPol_Email_eotp_genf -rule true -action authAct_Email_eotp Login Schema lSchema 1 - lSchema_GroupExtract_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication loginSchema lSchema_GroupExtract_genf -authenticationSchema "/nsconfig/loginschema/LoginSchema/OnlyUsername.xml" lSchema 2 - CheckAuthType_genf The second factor does not require a Login Schema. It just has policies with expressions to check which factor to do next. lSchema 3A - lSchema_LDAPPasswordOnly_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication loginSchema lSchema_LDAPPasswordOnly_genf -authenticationSchema "/nsconfig/loginschema/LoginSchema/PrefilUserFromExpr.xml" Here you may receive a warning that http.req.user has been replaced with aaa.user. You must edit the xml file from the cli. To edit the xml file from CLI, do the following: Log in to the Citrix ADC CLI Enter shell Now you have two options: Automated: Enter sed -i '' 's/http.req/aaa/' /nsconfig/loginschema/LoginSchema/PrefilUserFromExpr.xml Enter cat /nsconfig/loginschema/LoginSchema/PrefilUserFromExpr.xml to review the change Manual: Enter cd /nsconfig/loginschema/LoginSchema Enter vi PrefilUserFromExpr.xml Enter /http.req Press x 8 times to delete the http.req string Press the escape key Press i and enter aaa, press the escape key again Press the colon key ‘:’, enter wq and press enter. NOTE that you can use this method to modify other aspects of the login schema such as the field prompts lSchema 3B - lSchema_EOTPPasswordOnly_genf Update the following fields for your environment and copy and paste the string into the CLI: add authentication loginSchema lSchema_EOTPPasswordOnly_genf -authenticationSchema "/nsconfig/loginschema/LoginSchema/PrefilUserFromExpr.xml" NOTE: The 3B factor also uses the PrefilUserFromExpr.xml schema, but we label the policy differently for the EOTP path. lSchema 4B - EOTP_genf The fourth factor does not require a Login Schema. It generates the email with the One Time Passcode. nFactor Log in to the Citrix ADC GUI Navigate to Traffic Management > SSL> Certificates > All Certificates to verify you have your domain certificate installed. In this POC example we used a wildcard certificate corresponding to our Active Directory domain. See Citrix ADC SSL certificates for more information. Next navigate to Security > AAA - Application Traffic > nFactor Visualizer > nFactor Flows Select Add and select the plus sign in the Factor box Visualizer Factor1_GroupExtract_genf Enter Factor1_GroupExtract_genf and select create Select Add Schema Select the Login Schema lSchema_GroupExtract_genf Select OK In the same box select Add Policy Select the LDAP policy authPol_GroupExtract_genf Select Add Select the green plus sign next to the authPol_GroupExtract_genf policy to create another factor Factor2_CheckAuthType_genf Enter Factor2_CheckAuthType_genf This Factor is used to verify the authentication requirements Select Create In the same box select Add Policy Select authPol_LdapOnly_genf Under Goto Expression select END Select Add Select the blue plus sign under the authPol_LdapOnly_genf policy to add a second policy Select the policy authPol_TwoFactor_genf Enter 90 for the Priority Here we make the Two Factor policy occur prior to the LDAP only policy by lowering the priority to 90 which is less than the default of 100. This ensures that remote users in the VIP group are identified for LDAP only authentication. Select Add Factor3A_LDAPPasswordAuth_genf Back next to the authPol_GroupExtract_genf policy select the green plus sign to create another factor Enter Factor3A_LDAPPasswordAuth_genf Select Create In the same box select Add Policy Select authPol_Ldap_genf Under Goto Expression select END Select Add Select Add Schema Select the Login Schema lSchema_LDAPPasswordOnly_genf Select OK Factor3B_EOTPPasswordAuth_genf Back next to the authPol_TwoFactor_genf policy select the green plus sign to create another factor Enter Factor3B_EOTPPasswordAuth_genf Select Create In the same box select Add Policy Select authPol_LdapEtop_genf Select Add Select Add Schema Select the Login Schema lSchema_EOTPPasswordOnly_genf Select OK Factor4B_EOTP_genf Next to the authPol_LdapEtop_genf policy select the green plus sign to create another factor Enter Factor4B_EOTP_genf Select Create In the same box select Add Policy Select authPol_Email_eotp_genf Select Add Select Done and the nFactor flow is complete Citrix ADC authentication, authorization, and auditing (Citrix ADC AAA) virtual server Next navigate to Security > AAA - Application Traffic > Virtual Servers and select Add Enter the following fields and click OK: Name - a unique value. We enter GroupExtraction_AuthVserver IP Address Type - Non Addressable Select No Server Certificate, select the domain certificate, click Select, Bind, and Continue Select No nFactor Flow Under Select nFactor Flow click the right arrow, select the Factor1_GroupExtract_genf flow created earlier Click Select, followed by Bind, followed by Continue Citrix Gateway - virtual server Next navigate to Citrix Gateway > Virtual Servers Select your existing virtual server that provides proxy access to your Citrix Virtual Apps and Desktops environment Select Edit If you currently have an LDAP policy bound navigate under Basic Authentication - Primary Authentication select LDAP Policy. Then check the policy, select Unbind, select Yes to confirm, and select Close Under the Advanced Settings menu on the right select Authentication Profile Select Add Enter a name. We enter GroupExtract_AuthProfile Under Authentication virtual server click the right arrow, and select the Citrix ADC AAA virtual server we created GroupExtraction_AuthVserver Click Select, and Create Click OK and verify the virtual server now has an authentication profile selected while the basic authentication policy has been removed Click Done User Endpoint First we test whether One Factor authentication is applied to VIP users by authenticating into our Citrix Virtual Apps and Desktops environment. Open a browser, and navigate to the domain FQDN managed by the Citrix Gateway. We use https://gateway.workspaces.wwco.net After your browser is redirected to a login screen. First enter a user name. We use wsvipuser@workspaces.wwco.net This user must be a member of the AD group VIP nFactor determines that the user is a member of the VIP group and you are prompted to submit the user password. Now the user is logged into their Workspace page. Select a virtual desktop and verify launch. Now we test Two Factor authentication with Email OTP by authenticating into our Citrix Virtual Apps and Desktops environment again. Open a browser, and navigate to the domain FQDN managed by the Citrix Gateway. We use https://gateway.workspaces.wwco.net After your browser is redirected to a login screen. First enter a user name. We use wsuser@workspaces.wwco.net nFactor determines that the user is not local, nor a member of the VIP group, you are be prompted to submit the user password. The nFactor then presents a form requesting the OTP passcode. We copy and paste the passcode from the wsuser email account. Now the user is logged into their Workspace page. Select a virtual desktop and verify launch. Summary With Citrix Workspace and Citrix Gateway Enterprises can improve their security posture by implementing multifactor authentication without making the user experience complex. Group Extraction allows Enterprises to customize the depth of their multifactor use, along with contextual authentication, according to user group persona requirements. References For more information refer to: Citrix ADC Commands to Find the Policy Hits for Citrix Gateway Session Policies - learn more about CLI commands like nsconmsg -d current -g _hits to track policy hits to help troubleshoot. nFactor for Citrix Gateway Authentication with Email OTP - learn how to implement an extensible and flexible approach to configuring multifactor authentication with nFactor for Citrix Gateway authentication with email one-time password.

Introduction Implementing multifactor authentication is one of the best ways to verify identity and improve security posture. Email OTP is a convenient way to implement another factor using the readily available email system. It allows users to receive, copy, and paste authentication validation codes, into their gateway authentication form, from their email client on any device. Citrix Gateway supports Email OTP authentication, and can provide authentication for various services including web services, VPN, and Citrix Virtual Apps and Desktops. In this POC Guide we demonstrate using it for authentication in a Citrix Virtual Apps and Desktops environment. Overview This guide demonstrates how to implement a Proof of Concept environment using two factor authentication with Citrix Gateway. The guide uses LDAP to validate Active Directory credentials as the first factor and use Email OTP as the second factor. It uses a Citrix Virtual Apps and Desktops published virtual desktop to validate connectivity. It makes assumptions about the completed installation and configuration of the following components: Citrix Gateway installed, licensed, and configure with an externally reachable virtual server bound to a wildcard certificate Citrix Gateway integrated with a Citrix Virtual Apps and Desktops environment which uses LDAP for authentication SMTP server access with the ability to log in with user name and password to originate emails Endpoint with Citrix Workspace app installed Active Directory (AD) is available in the environment Refer to Citrix Documentation for the latest product version and license requirements: Email OTP Authentication Citrix Gateway First, we will log in to the CLI on our gateway and enter the authentication actions and associated policies for LDAP and email respectively. Then we will log in to our GUI to build our nFactor flow in the visualizer tool and complete the multifactor authentication configuration. Authentication policies We create the LDAP action, and the policy that references it, which is the first authentication factor. Then we create the Email action, and the policy that references it, which is the second authentication factor. First connect to the CLI by opening an SSH session the NSIP address of the Citrix ADC and log in as the nsroot administrator. LDAP action Populate the following fields to create the LDAP action and paste the completed string into the CLI: ldapAction - enter the action name. We enter authAct_LDAP_eotp serverIP - enter the domain server/s FQDN or IP address. We enter 192.0.2.50 for the private IP address of the domain server in our environment serverPort - enter the LDAP port. We enter 636 for the secure LDAP port ldapBase - enter the string of domain objects and containers where pertinent users are stored in your directory. We enter "OU=Team M,OU=Team Accounts,OU=Demo Accounts,OU=Workspaces Users,DC=workspaces,DC=wwco,DC=net" ldapBindDn - enter the service account used to query domain users. We enter workspacessrv@workspaces.wwco.net ldapBindDnPassword - enter your service account password. The password is encrypted by the Citrix ADC by default ldapLoginName - enter the user object type. We enter userPrincipalName groupAttrName - enter the group attribute name. We enter memberOf subAttributeName - enter the sub attribute name. We enter cn secType - enter the security type. We enter SSL ssoNameAttribute - enter the single sign-on name attribute. We enter userPrincipalName defaultAuthenticationGroup - enter the default authentication group. We enter Email-OTP alternateEmailAttr - enter the user domain object attribute where their email address can be retrieved. We enter otherMailbox Once you have constructed the full string for your environment copy and paste it into the CLI: add authentication ldapAction authAct_LDAP_eotp -serverIP 192.0.2.50 -serverPort 636 -ldapBase "OU=Team M,OU=Team Accounts,OU=Demo Accounts,OU=Workspaces Users,DC=workspaces,DC=wwco,DC=net" -ldapBindDn workspacessrv@workspaces.wwco.net -ldapBindDnPassword your_service_account_password -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName cn -secType SSL -ssoNameAttribute userPrincipalName -defaultAuthenticationGroup Email-OTP -alternateEmailAttr otherMailbox A variety of tools exist that may be used to populate Active Directory user object attributes. For the POC we use ADSI edit, from ‘Server Manager > Tools’, to manually add an email address for user1 to it’s ‘otherMailbox’ attribute. LDAP policy Populate the following fields to create the LDAP action and paste the completed string into the CLI: Policy - enter the policy name. We enter authPol_LDAP_eotp action - enter the name of the Email action we created above. We enter authAct_LDAP_eotp Once you have constructed the full string for your environment copy and paste it into the CLI: add authentication Policy authPol_LDAP_eotp -rule true -action authAct_LDAP_eotp For more information see LDAP authentication policies Email action Populate the following fields to create the Email action and paste the completed string into the CLI: emailAction - enter the action name. We enter authAct_Email_eotp userName - enter the user, or service account, that will log in to the mail server. We enter workspacessrv@workspaces.wwco.net password - enter your service account password to log in to the mail server. The password will be encrypted by the Citrix ADC by default serverURL - enter the FQDN or IP address of the mail server. We enter "smtps://192.0.2.40:587" content - enter the user message next to the field to enter the email code. We enter "Your OTP is $code" time out - enter the number of seconds the email code is valid. We enter 60 emailAddress - enter the LDAP object to query for the user email address. We enter "aaa.user.attribute(\"alternate_mail\")" Once you have constructed the full string for your environment copy and paste it into the CLI: add authentication emailAction authAct_Email_eotp -userName workspacessrv@workspaces.wwco.net -password your_service_account_password -serverURL "smtps://192.0.2.40:587" -content "Your OTP is $code" -timeout 60 -emailAddress "aaa.user.attribute(\"alternate_mail\")" Email policy Populate the following fields to create the Email policy and paste the completed string into the CLI: Policy - enter the policy name. We enter authPol_Email_eotp action - enter the name of the Email action we created above. We enter authAct_Email_eotp Once you have constructed the full string for your environment copy and paste it into the CLI: add authentication Policy authPol_Email_eotp -rule true -action authAct_Email_eotp For more information see Email authentication policies nFactor Log in to the Citrix ADC UI Navigate to Traffic Management > SSL> Certificates > All Certificates to verify you have your domain certificate installed. In this POC example we used a wildcard certificate corresponding to our Active Directory domain. See Citrix ADC SSL certificates for more information. Next navigate to Security > AAA - Application Traffic > nFactor Visualizer > nFactor Flows Select Add and select the plus sign in the Factor box Enter nFactor_EmailOTP and select create Select Add Schema and select Add again next to Select Policy Enter lschema_SingleAuth Under Authentication Schema select the pencil icon to edit the schema selection Under Schema Files, select LoginSchema, and navigate to LoginSchema, and select SingleAuth.xml Select the blue select button, followed by Create, followed by OK In the same box select Add Policy Select the LDAP policy we created. We use authPol_LDAP_eotp Select Add Select the green plus sign next to the authPol_LDAP_eotp policy to create a factor Enter factor_Email This Factor will use the Email code to perform the 2nd factor authentication Select Create In the same box select Add Policy Select the Email policy we created. We use authPol_Email_eotp Under Goto Expression select END Select Add Now we`ve completed the nFactor flow setup and can click Done Citrix ADC authentication, authorization, and auditing (Citrix ADC AAA) virtual server Next navigate to Security > AAA - Application Traffic > Virtual Servers and select Add Enter the following fields and click OK: Name - a unique value. We enter ‘EMAILOTP_AuthVserver’ IP Address Type - Non Addressable Select No Server Certificate, select the domain certificate, click Select, Bind, and Continue Select No nFactor Flow Under Select nFactor Flow click the right arrow, select the nFactor_EmailOTP flow created earlier Click Select, followed by Bind Click Continue, followed by Done Citrix Gateway - virtual server Next navigate to Citrix Gateway > Virtual Servers Select your existing virtual server that provides proxy access to your Citrix Virtual Apps and Desktops environment Select Edit If you currently have an LDAP policy bound navigate under Basic Authentication - Primary Authentication select LDAP Policy. Then check the policy, select Unbind, select Yes to confirm, and select Close Under the Advanced Settings menu on the right select Authentication Profile Select Add Enter a name. We enter EmailOTP_auth_profile Under Authentication virtual server click the right arrow, and select the Citrix ADC AAA virtual server we created EmailOTP_Auth_Vserver Click Select, and Create Click OK and verify the virtual server now has an authentication profile selected while the basic authentication policy has been removed Click Done User Endpoint Now we test Email OTP by authenticating into our Citrix Virtual Apps and Desktops environment. Open a browser, and navigate to the domain FQDN managed by the Citrix Gateway. We use https://gateway.workspaces.wwco.net After your browser is redirected to a login screen enter user userPrincipalName and password Open the user email client and copy the OTP code Return to your browser where the user name is populated, paste the code, and click OK Verify the users virtual apps, and desktops are enumerated, and launch once logged in Troubleshooting SMTP server The Citrix Gateway must be able to authenticate to a mail server with a user name and password in order to originate the client email with the OTP code. If the Citrix Gateway cannot send the email, completion of the first factor will time out after the user submits their user name and password. If your exchange server is configured for NTLM only, by default, the Citrix Gateway will not be able to authenticate. The Citrix Gateway must be able to login with a username and password to compose and send an email with the OTP code. To verify, SSH to the Citrix Gateway, or access the console. Enter the shell and telnet to the mail server TCP port 25. For example telnet ipoct1.ipoct2.ipoct3.ipoct4 25 Then enter ehlo. The result should show AUTH LOGIN or AUTH NTLM LOGIN. If it does not show LOGIN for more information see enable login based authentication on the SMTP server. You can also use public email servers such as Gmail. When configuring the Email OTP policy enter smtps://smtp.gmail.com:587 in the email server field. However, you must configure your firewalls to allow outbound SMTPS on TCP port 587. Summary With Citrix Workspace and Citrix Gateway, Enterprises can improve their security posture by implementing multifactor authentication without making the user experience complex. Users can get access to all of their Workspaces resources by entering their standard domain user and password and simply confirming their identity with Email OTP sent to their email client. References For more information refer to other nFactor authentication options: Email OTP – Email OTP is introduced with Citrix ADC 12.1 build 51.x

Introduction Large Enterprise environments require flexible authentication options to meet the needs of various user personas. With Device Certificate, coupled with LDAP credentials, Enterprises get “something you have” and “something you know” multifactor authentication. This allows users to seamlessly verify their identity and securely access their applications and data. Overview This guide demonstrates how to implement a Proof of Concept environment using two factor authentication with Citrix Gateway. It validates a Device Certificate as the first factor using Endpoint Analysis (EPA). Then it uses the user’s domain credentials as the second factor. It uses a Citrix Virtual Apps and Desktops published virtual desktop to validate connectivity. It makes assumptions about the completed installation and configuration of the following components: Citrix ADC installed, and licensed Citrix Gateway configured with an externally reachable virtual server bound to a wildcard Certificate Citrix Gateway integrated with a Citrix Virtual Apps and Desktops environment which uses LDAP for authentication Active Directory (AD) is available in the environment with Microsoft Certificate Authority installed A Windows 10 endpoint is domain joined, and has Citrix Workspace app installed The endpoint user must have local admin rights or have the Citrix Gateway Plug-in installed Refer to Citrix Documentation for the latest product version, licensing, and requirement details: Device certificate in nFactor as an EPA component Configuration First, we log in to the CLI on our Citrix ADC and enter the authentication actions and associated policies for EPA and LDAP respectively along with the login schema. Then we log in to our GUI to build our nFactor flow in the visualizer tool and complete the multifactor authentication configuration. EPA Authentication policies Next we create the EPA action to check the device certificate, and the policy that references it. EPA action 1 - authAct_EPA_dcnf Update the following fields for your environment and copy and paste the string into the CLI: add authentication epaAction authAct_EPA_dcnf -csecexpr "sys.client_expr(\"device-cert_0_0\")" EPA policy 1 - authPol_EPA_dcnf Update the following fields for your environment and copy and paste the string into the CLI: add authentication Policy authPol_EPA_dcnf -rule true -action authAct_EPA_dcnf LDAP Authentication policies We create the LDAP actions, and the policies that reference them. For LDAP Actions populate the required fields to create the LDAP action in a string and paste it into the CLI: ldapAction - enter the action name. serverIP - enter the domain server/s FQDN or IP address. serverPort - enter the LDAP port. ldapBase - enter the string of domain objects and containers where pertinent users are stored in your directory. ldapBindDn - enter the service account used to query domain users. ldapBindDnPassword - enter your service account password. ldapLoginName - enter the user object type. groupAttrName - enter the group attribute name. subAttributeName - enter the sub attribute name. secType - enter the security type. ssoNameAttribute - enter the single sign-on name attribute. For LDAP Policies populate the required fields to reference the LDAP Action in a string and paste it into the CLI: Policy - enter the policy name. action - enter the name of the Email action we created above. For more information see LDAP authentication policies First connect to the CLI by opening an SSH session to the NSIP address of the Citrix ADC and log in as the nsroot administrator or equivalent admin user. LDAP action 1 - authAct_LDAP_dcnf Update the following fields for your environment and copy and paste the string into the CLI: add authentication ldapAction authAct_Ldap_dcnf -serverIP 192.0.2.50 -serverPort 636 -ldapBase "DC=workspaces,DC=wwco,DC=net" -ldapBindDn wsadmin@workspaces.wwco.net -ldapBindDnPassword xyz123 -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2021_03_23_19_58 -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName cn -secType SSL -passwdChange ENABLED LDAP policy 1 - authPol_LDAP_dcnf Update the following fields for your environment and copy and paste the string into the CLI: add authentication Policy authPol_LDAP_dcnf -rule true -action authAct_Ldap_dcnf Login Schema Next we create Login Schemas used with each factor. lSchema 1 - lSchema_EPA_dcnf The EPA factor does not require a Login Schema. lSchema 2 - lSchema_LDAP_dcnf Update the following fields for your environment and copy and paste the string into the CLI: add authentication loginSchema ls_ldap_dcnf -authenticationSchema "/nsconfig/loginschema/LoginSchema/SingleAuth.xml" Certificates Domain Certificate In this POC we used a wildcard certificate corresponding to our Active Directory domain and it also corresponds to the fully qualified domain name we use to access to the Gateway virtual server (gateway.workspaces.wwco.net) Log in to the Citrix ADC GUI Navigate to Traffic Management > SSL> Certificates > All Certificates to verify you have your domain certificate and CAs installed and linked. See Citrix ADC SSL certificates for more information. Device Certificate There are many systems and options for user and device certificate management. In this POC we use the Microsoft Certificate Authority installed on our Active Directory server. We also have our Windows 10 endpoint joined to the domain. From the start menu on our domain joined Windows 10 endpoint we enter mmc, right-click and run as administrator Select File > Add/Remove, select Certificates, select the arrow to move it to the Selected snap-in pane, select Computer account, Next, Local computer, Finish and, click OK Open the Personal folder, right-click the Certificates folder > All Tasks > Request New Certificate Click next until you are offered certificate types, select Computer, and click Enroll, followed by Finish Double-click the certificate it installed, select the Certification Path tab, select the root CA on the top, and click View Certificate. (Note: We can export the CA from the Active Directory server, yet for the POC we can eliminate steps by doing it here) In the popup select the Details tab, select Copy to File, click Next, click Next (to accept DER encoding) Select browse, and enter a file name, select save, select next, and select finish to store the CA certificate file. Now we will import it into the ADC by navigating to **Traffic Management > SSL> Certificates > CA Certificates Click Install, we enter the name DeviceCertificateCA, select Chose File, Local, and select the file, Open and click Install nFactor Visualizer Next navigate to Security > AAA - Application Traffic > nFactor Visualizer > nFactor Flows Select Add and select the plus sign in the Factor box Factor1_Epa_dcnf Enter Factor1_Epa_dcnf and select create In the same box select Add Policy Select the EPA policy authPol_EPA_dcnf Select Add Select the green plus sign next to the authPol_EPA_dcnf policy to create another factor Factor2_Ldap_dcnf Enter Factor2_Ldap_dcnf Select Create In the same box select Add Schema Select ls_ldap_dcnf In the same box select Add Policy Select authPol_LDAP_dcnf Under Goto Expression select END Citrix ADC authentication, authorization, and auditing (Citrix ADC AAA) virtual server Next navigate to Security > AAA - Application Traffic > Virtual Servers and select Add Enter the following fields and click OK: Name - a unique value. We enter DC_AuthVserver IP Address Type - Non Addressable Select No Server Certificate, select the domain certificate, click Select, Bind, and Continue Select No nFactor Flow Under Select nFactor Flow click the right arrow, select the Factor1_Epa_dcnf flow created earlier Click Select, followed by Bind, followed by Continue Citrix Gateway - virtual server Next navigate to Citrix Gateway > Virtual Servers Select your existing virtual server that provides proxy access to your Citrix Virtual Apps and Desktops environment Select Edit Under Basic Settings select the pencil icon to edit, then select more at the bottom At the bottom right, under Device Cert CA select Add, and click the plus (+) sign next to the DeviceCertificateCA followed by OK Now under Certificate, select CA Certificate, Add Binding, select the right arrow under Select CA Cert and select DeviceCertificateCA followed by Bind and Close If you currently have an LDAP policy bound navigate under Basic Authentication - Primary Authentication select LDAP Policy. Then check the policy, select Unbind, select Yes to confirm, and select Close Under the Advanced Settings menu on the right select Authentication Profile Select Add Enter a name. We enter DC_AuthProfile Under Authentication virtual server click the right arrow, and select the Citrix ADC AAA virtual server we created DC_AuthVserver Click Select, and Create Click OK and verify the virtual server now has an authentication profile selected while the basic authentication policy has been removed Click Done User Endpoint Verification We test authentication by authenticating into our Citrix Virtual Apps and Desktops environment. Open a browser, and navigate to the domain FQDN managed by the Citrix Gateway. We use https://gateway.workspaces.wwco.net Select download if the EPA plug-in has not been installed. Otherwise select Yes when the EPA plug-in prompts you to scan (you can also select Always to automatically scan). Thereafter it scans for device certificates. If you have multiple device certificates it prompts you to select the appropriate one to authenticate with otherwise it presents a logon prompt. Enter the domain user name and password. Select the virtual desktop from the available resources in their workspace and verify a successful launch. Summary With Citrix Workspace and Citrix Gateway Enterprises can improve their security posture by implementing multifactor authentication without making the user experience complex. Device Certificates allow Enterprises to seamlessly add a 2nd authentication factor to user credentials, maintaining a good user experience while improving security posture. References For more information refer to: How to Configure Device Certificate on Citrix Gateway for Authentication - learn how to implement an OSCP responder to verify certificate revocation status. Understanding and Configuring EPA Verbose Logging on NetScaler Gateway - verify the nsepa.txt on the endpoint logs the correct CA in the list that is downloaded. “Netscaler has sent list of allowed CA for device certificate.” If not verify you imported and bound the correct one, that issued the device certificate, to the Gateway vServer. Citrix ADC Commands to Find the Policy Hits for Citrix Gateway Session Policies - learn more about CLI commands like nsconmsg -d current -g _hits to track policy hits to help troubleshoot.

Introduction Weak or stolen passwords are a leading cause of breaches in Enterprise networks. They can lead to loss of Intellectual Property, loss of Personally identifiable information (PII) and result in a significant impact on the business. Multifactor Authentication (MFA) is one of the best security measures to guard against identity vulnerabilities. Typically there are three types of authentication used to identify users: 1) Something you know (for example, password) - this type is historically the most common type used. Users enter a user name and a password that only they know. Passwords can be strengthened against attacks from bad actors, with greater amounts of characters and with more types of characters. However, users are only human and may keep them simple or avoid changing them regularly. Then if the endpoint is infected with malware, it is only a matter of time until unrelenting algorithms figure out the password and compromise systems and data that the user has access to. 2) Something you have (for example, a digital key, physical, or virtual smartcard) - this type is a common second factor, particularly with the US government. Users are issued a smartcard, and after entering their user name and password, a private certificate and key are extracted and validated. Physical cards are inserted into readers attached to endpoints, or virtual cards are installed on the endpoint for the user to copy and pasted into the authentication form. 3) Something you are (for example, fingerprint scanner) - this type is a third method that focuses on using biometrics to uniquely identify a user. Historically biometrics have seen slower mainstream adoption due to expense to implement and complexity, yet they are a powerful option for high-security environments. Multifactor authentication pertains to using two or more of these types of authentication to verify user identity and mitigate the risk of bad actors obtaining access to Enterprise environments. Overview The Citrix ADC supports various multifactor authentication methods. It provides an extensible and flexible approach to configuring them with nFactor authentication. It also supports various application delivery technologies that can utilize multifactor authentication, including Content Switching, Traffic Management Load Balancing, Full VPN, and Gateway proxy. It can be employed in on-premises, Cloud, and Hybrid environments. This brief describes multifactor authentication using five pairs of methods with Citrix Gateway. It focuses on using the methods with Citrix Virtual Apps and Desktops on-premises environments and with Citrix Workspace. nFactor nFactor uses Citrix ADC AAA Virtual Servers to deploy multifactor authentication. They bind to advanced policies and actions, grouped in factors, to implement authentication methods. The interface to users requesting authentication credentials, and the variables that store their input, are defined in a login schema. nFactor can be configured through the CLI, through the GUI manually, or through the visualizer tool in the GUI. Pertinent configuration elements include: Visualizer - a tool available in the Citrix ADC GUI to aid with the configuration of nFactor to implement MFA flows for a multitude of authentication requirements. Citrix ADC AAA Virtual Server - “Factor 0” is the starting point for MFA, which is referenced by Gateway, LB, or Content Switch Virtual Servers that rely on it for authentication. Factor - factors, which are bound to the Citrix ADC AAA Virtual Server, act as a “bucket” to contain a set of policies and pertinent schema. (Also known as Policy Labels when the Visualizer is not used) Login Schema - the “landing page” for each authentication factor includes field types and variables referenced throughout the flow. Policy - an object that maps to authentication actions and includes an expression to determine when it’s a match. Action - Defines the various authentication methods. SAML, OAuth, Certificate, LDAP, and so on. Methods Citrix ADC supports many authentication methods. For more information, see Citrix ADC Authentication Methods. In this brief, we focus on using domain credentials, representing something the user knows, with five variations of something the user has. Native OTP Push Token Email OTP Group Extraction Device Certificate Native OTP Native OTP or “One Time Pin” works by the Citrix ADC, having users register with an app that supports OTP and sharing a key with it. Then it uses the current time along with that key to generate a string of numbers, at regular intervals, that only the user’s OTP app has (for example Microsoft Authenticator, or Citrix SSO app). By default, it uses a six-digit OTP code that is valid for 30 seconds. In our scenario, in order to successfully authenticate, the user enters their domain credentials followed by the OTP code. After successful validation by the Citrix ADC, the user’s credentials are relayed to the target delivery systems, and their apps sessions can be established with single sign-on. For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway with Native OTP Authentication Push Token With Push Token, the user also does an initial registration with the Citrix ADC. Yet, with this method, the user is not required to copy and paste a code. Instead, the ADC sends a PUSH notification over mobile delivery networks (APNS for Apple devices or GCM for Android devices). Then the user simply has to accept a popup from the Citrix SSO app to complete the second factor. Again, once the user’s credentials are relayed to the target delivery systems and their apps, sessions can be established with single sign-on. For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway Authentication with Push Token Email OTP Email OTP works like Native OTP, yet the OTP code is sent as an email rather than to an app. This method is valuable for user groups that do not have mobile devices. It works in a similar fashion in that the code generated expires at regular intervals, and the user must copy and paste it into a field along with their credentials. For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway Authentication with Email OTP Group Extraction Group Extraction is the same type of authentication as entering domain credentials, yet it is able to route to other types by extracting the user’s group membership. Then, using the earlier example, admins can designate a group as mobile users or non-mobile users to determine whether their second factor is Push Token and Email OTP. Alternatively, they can designate groups of users according to their security persona and match the number and type of authentication methods according to the groups’ risk profile. Examples of user groups include: Normal-security-group for individuals that have lower security requirements by the nature of their job or limited data access and are located within the bounds of the corporate security perimeter. This group may only require 1 factor. Elevated-security-group for third-party workers or contractors who do not have had background checks done and have higher security requirements. This group may require two or more factors. High-security-group for employees that perform critical jobs and require special government clearance or industry approval. This group may require two or more factors and contextual verifications such as source IP address. For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway Authentication with Group Extraction Device Certificate Device Certificate relies on the availability of a unique certificate on the endpoint. The Citrix ADC validates that the certificate was issued by a designated Certificate Authority. There are various methods to manage issuing and revoking the certificates. Once in place, it can provide a seamless second authentication factor that requires little or no input from the user. For more information regarding how to try it out in your environment, see: Proof of Concept Guide: nFactor for Citrix Gateway Authentication with Device Certificate Workspace service Once you have a nFactor flow setup, you can integrate with Workspace service. Within Workspace service under Identity and Access Management, the Citrix Gateway service provides settings required to integrate with the Citrix ADC using OAuth. 1.) Citrix Workspace - configure the Citrix Gateway service to point to the Citrix ADC Virtual Server. Change the Workspace authentication method to Citrix Gateway For more information regarding how to try it out in your environment, see: Tech Insight video: Authentication - On-Premises Citrix Gateway 2.) Citrix ADC nFactor - create an Oauth policy using tenant information obtained from Workspace service. Bind it to the pertinent AAA Virtual Server with a higher priority than the nFactor flow. Update the “Logon Point” landing page theme with the Citrix Workspace look and feel. For more information regarding how to try it out in your environment, see: Customizing the on-premises Citrix Gateway authentication page to look identical to Citrix Cloud logon page Once configured, users continue to access their Workspace service domain (for example, https://<customerdomain>.cloud.com) and are automatically redirected to the Citrix ADC FQDN. Upon successful authentication, Citrix ADC relays the status for the user name back to the Workspace, and the user is presented with their resources. Summary With Citrix nFactor, Enterprises can implement reliable multifactor authentication and fortify the primary entrance to their environments. They can implement this security improvement all while maintaining a good user experience.

Submitted on: May 10, 2021 Author: Dharanikanth Dugginni APIs are a critical infrastructure component and help to drive the modern digital economy. If your organization is using APIs, you can’t afford for them to go down. If your APIs are attacked successfully, it can lead to data loss, frustrated customers, and hits on your revenue and reputation. Strong authentication (Who is the client or user?) and authorization (What can the client or user do?) practices are essential to ensuring your APIs are secure. In this blog post, I’ll cover oAuth2.0, which has become the de facto standard for authenticating APIs and users in modern hybrid multi-cloud architectures (single-page apps, progressive web apps, mobile clients, and microservices). We’ll also look at how you can leverage the NetScaler API authentication and authorization solution to protect your APIs and simplify your app deployment. What Is oAuth2.0? oAuth2.0 provides an interoperable framework to convey authorization information. It uses short-lived tokens — JSON Web Tokens (JWT) or opaque tokens — with limited rights as a means to provide delegated access control. A valid token indicates that the client (user) has been authenticated and any requested permissions (claims) are present in the token, the permissions may be used for authorization policy decisions. Clients include the token in the requests using the Authorization header with “Bearer” type, like this: "Authorization: Bearer &lt;token&gt;" Other commonly used authentication methods like basic authentication and API keys are less secure because of the risk of exposure of credentials (username, password or API keys); mutual TLS, often used in service-to-service scenarios, is more complex to deploy. oAuth2.0 provides a more robust and scalable solution by decoupling authentication and authorization. It eliminates issues around credential sharing by giving users more control over their data; supports a variety of devices; and is extensible and can be developed upon. Citrix API Gateway: Authentication and Authorization NetScaler ADC is the foundation of the NetScaler API gateway solution and serves as the data plane (run-time proxy), with NetScaler Application Delivery Management (ADM) serving as the management plane. (You can use Kubernetes as the controller in a cloud-native environment.) NetScaler ADC provides comprehensive authentication and authorization features and supports various authentication protocols, including oAuth2.0. You can create authentication and authorization policies for fine-grain access control to your apps’ web and API resources. With the NetScaler API gateway solution, you don’t have to deal with implementing different authentication protocols for your app. It’s deployed in front of your app and handles authentication and authorization. A Traditional HMC Deployment NetScaler ADM service provides the control/management plane for the API gateway solution in on-prem and cloud deployments. You can carry out your configuration workflows using the intuitive UI or with APIs. To configure an oAuth policy to validate JWT tokens using the Citrix ADM UI, first navigate to Applications → API Gateway → Policy. Create a policy by selecting a deployment and upstream. Choose the ‘oAuth’ policy type and enter your details, as shown below. The JWKS URI is the URL where you’ll find the signature “keys” for the token issuer; these are fetched and used to validate tokens. The Issuer and Audience should match the values present in the token. NetScaler ADC can enhance your security posture because it supports the best practices for JWT validation outlined in RFC8725, including validation of issuer and audience. You can also limit the signature algorithms to asymmetric variants. If your use case requires you to validate “opaque” tokens, the introspection URL needs to be configured along the with client ID and secret. The URL is used to reach out to the authorization server for token validation. The API gateway uses the client ID and secret to identify itself with the authorization server. Please note, Citrix ADC uses a positive security model, so when you configure an auth policy for some API resources, you’ll configure the “No Auth” policy for the remaining API resources to skip authentication. Otherwise, access will be denied with a 401 error message. NetScaler ADC supports authorization policies, too. If you want to verify access privileges to a resource, you generally check the claims associated with the token using authorization policies. The policies can verify whether the required claims are present in the token received with an API request. In the NetScaler ADM service, navigate to Applications → API Gateway → Policy. Create the policy by selecting a deployment and upstream. Choose the “Authorization” policy type and enter the required claims and values expected for the selected resource endpoints. You should save any claims that you want to use here as part of your authentication configuration. Please note, if the API resources have authentication policies, you’ll need to create authorization policies also for those API resources. Otherwise, you’ll get a 403 error message. If you do not need authorization checks, you can create an authorization policy with empty claims. Deploying in Kubernetes Environment Apps are usually deployed as microservices in a Kubernetes environment. The configuration is applied using the Kubernetes APIs or a command line utility like ‘kubectl’ and config files. NetScaler ADC provides custom resource definitions (CRDs) for an app-specific configuration. Authentication and authorization policies are configured using the Auth CRD, which comes with the Citrix Ingress Controller. Typically, users apply the CRD spec, create one or more instances with values required to configure the desired authentication and authorization policies, then apply those. The following yaml file shows the use of the oAuth JWT token validation setup: If you save the config as auth-example.yaml file and you already have a Citrix Ingress Controller running in your cluster, you can take these steps to create the auth policies: # kubectl create -f auth-crd.yaml customresourcedefinition.apiextensions.k8s.io/authpolicies.citrix.com created # kubectl create -f auth-example.yaml Analytics and Observability NetScaler ADM has a breadth of analytics features to support observability, performance, and security monitoring. For authentication, it provides the number of authentication requests, successes, and failures, as well as the reason for failures both at the API level and for each resource individually. NetScaler ADC is also integrated with open-source tools like elastic search, Kibana, Prometheus, and Grafana, and you can use these to build custom reports. Conclusion There are several methods for API authentication and authorization, but oAuth2.0 is the most popular, scalable and secure. NetScaler's API gateway supports oAuth2.0 in traditional on-prem and cloud deployments, as well as in Kubernetes deployments. Learn more about API gateway policy creation using NetScaler ADM service and the Citrix Ingress Controller Auth CRD. Click Down