Jump to content
  • Aman Sood
    Using NetScaler HTTP Callout and Policies to Implement Dynamic Login
     
    It is not uncommon to witness the coexistence of both legacy and modern applications within today's business environment. As most modern applications adopt Single Sign-On (SSO) based login authentication, it becomes increasingly crucial for legacy applications, predominantly reliant on form-based login authentication, to also upgrade to more simpler and secure authentication methods. It is also not advisable to rewrite the application to implement a SAML based SSO solution.  
     
    This article focuses on a use case of how to simulate SSO type login authentication using NetScaler HTTP callout without having to rewrite the application.
     
    Challenge:
    Assume you are the owner of a legacy web application that is accessed via NetScaler. The web application uses form based login to authenticate the users against credentials stored in a database. Customer wants to migrate to an SAML based SSO solution, however it's not possible to add SAML support to this application.
     
    Old login flow:

    Figure1: Old login flow
     
    User issues a GET request to access the web application. NetScaler Proxies the request. Since the user is not authenticated, the user is presented with a login page. User sends its credentials in the POST request. NetScaler proxies the request. Application validates the client credentials and allows access.  
    Solution:
    You can create a new flow using NetScaler rewrite policies, variables and HTTP callout, to allow users to access the web application without providing their credentials thus simulating an SSO type experience. Customer has created a new web service “credential management service” which takes the username of the user and sets a random password for that user in the database.
     
    The new authentication flow using a rewrite policy on NetScaler that simulates an SSO login is shown below.
     
    Figure2: New login flow 
     
    New login flow:
    Prerequisite: 
    User is already authenticated via SAML SSO. The application is always accessed using the same NetScaler ADC/HA-Pair.  Login Flow:
    User issues a GET request to access the web application and passes its username in the request NetScaler issues an HTTP callout to the credential management service and passes the username of the SAML authenticated user in the callout request The credential management service generates a random password for this user and sets this password in the database The credential management service returns the username and password to NetScaler in the callout response NetScaler does the below processing:  Modifies the GET request to a POST Adds the response received from the credential service in the body Add “content-length” header set to the length of response received from the credential service Add “content-type” header to indicate that the content is a simple form using the default application/x-www-form-urlencoded content type NetScaler sends the request out to the web server Application validates the credentials and permits the user. NetScaler Configuration:
    The new authentication login flow can be achieved by using HTTP callout, variables and rewrite features available in NetScaler
    Create a HTTP callout “permit_user” to call the credential management service and pass the username of the user to this service /permituser URI. In our example the customer is passing the username as a query string in the GET request.  add policy httpCallout permit_user -IPAddress 10.105.158.236 -port 8081 -returnType TEXT -urlStemExpr "\"/permituser\?\"+HTTP.REQ.URL.QUERY" -scheme http -resultExpr "HTTP.RES.BODY(64000)"
    Create a variable “var_callout_response” in NetScaler. The type of this variable is “text”, max length is 64000 and scope is “transaction”.  Transaction scope ensures that this variable is available only during the time of this transaction and is destroyed at the end of this transaction. add ns variable var_callout_response -type "text(64000)" -scope transaction
    Create an assignment for the “store_callout_response” and set it to the response of the HTTP callout. add ns assignment store_callout_action -variable "$var_callout_response" -set "sys.http_callout(permit_user)"
    Create rewrite actions Change the http method from GET to POST add rewrite action act_change_http_method_to_post replace HTTP.REQ.METHOD "\"POST\""
    Insert the response of the HTTP callout in the body add rewrite action act_add_callout_response_in_body insert_after "HTTP.REQ.BODY(0)" "$var_callout_response"
    Add the “content-length” header add rewrite action act_add_content_length insert_http_header content-length "$var_callout_response.LENGTH"
    Add the “content-type” header to indicate form data add rewrite action act_add_content_type insert_http_header content-type "\"application/x-www-form-urlencoded\""
    Create a rewrite policy  Assign the value to the “var_callout_response” variable by calling the HTTP callout add rewrite policy pol_store_callout_action True store_callout_action
    Policy with action for changing the GET method to POST add rewrite policy pol_change_req_method TRUE act_change_http_method_to_post
    Policy with action for setting the the callout response in the body  add rewrite policy pol_set_callout_body TRUE act_add_callout_response_in_body
    Policy with action for setting the content-length add rewrite policy pol_set_content_length TRUE act_add_content_length
    Policy with action for setting the content-type add rewrite policy pol_set_content_type TRUE act_add_content_type
    Attach the policies to the load balancing virtual server for this application. bind lb vserver "WebApp-VirtSvr" -policyName pol_store_callout_action -priority 100 -gotoPriorityExpression NEXT -type REQUEST
    bind lb vserver "WebApp-VirtSvr" -policyName pol_change_req_method -priority 110 -gotoPriorityExpression NEXT -type REQUEST
    bind lb vserver "WebApp-VirtSvr" -policyName pol_set_callout_body -priority 120 -gotoPriorityExpression NEXT -type REQUEST
    bind lb vserver "WebApp-VirtSvr" -policyName pol_set_content_length -priority 130 -gotoPriorityExpression NEXT -type REQUEST
    bind lb vserver "WebApp-VirtSvr" -policyName  pol_set_content_type -priority 140 -gotoPriorityExpression END -type REQUEST
     
     
     

    NetScaler Cyber Threat Intelligence
    NetScaler WAF Signatures Update v128
     
    NetScaler has released a new version of its integrated Web App Firewall signatures to help customers mitigate several CVEs with variable CVSS. 
    A notable CVE with 10.0 score is CVE-2024-4040 which is a server-side template injection vulnerability in CrushFTP, a popular file transfer server software. This vulnerability affects all versions of CrushFTP before 10.7.1 and 11.1.0 on all platforms. The flaw allows unauthenticated remote attackers to exploit the Virtual File System (VFS) sandbox, enabling them to read files from the filesystem outside of the sandbox. By bypassing authentication, attackers gain unauthorized access to sensitive files and can potentially execute code on the server. To mitigate this risk, it’s crucial to promptly update CrushFTP to the patched versions, restrict access to the server, monitor logs for suspicious activity, enforce strong authentication mechanisms, and follow general security best practices.
     Signatures included in v128:
    Signature rule
    CVE ID
    Description
    998498
    CVE-2024-4040
    WEB-MISC CrushFTP Prior to 10.7.1 and 11.1.0 - Server Side Template Injection Vulnerability (CVE-2024-4040)
    998499
    CVE-2024-30162
    WEB-MISC Invision Community - Arbitrary File Upload Vulnerability (CVE-2024-30162)
    998500
    CVE-2024-23538, CVE-2024-23539
    WEB-MISC Apache Fineract Prior to 1.9 - SQL Injection Vulnerabilities (CVE-2024-23538,CVE-2024-23539)
    998501
    CVE-2024-23538, CVE-2024-23539
    WEB-MISC Apache Fineract Prior to 1.9 - SQL Injection Vulnerabilities (CVE-2024-23538,CVE-2024-23539)
    998502
    CVE-2024-20767
    WEB-MISC Adobe ColdFusion Multiple Versions - Improper Access Control Vulnerability (CVE-2024-20767)
    998503
    CVE-2024-1981
    WEB-WORDPRESS WordPress Plugin WPVivid Backup & Migration - SQLi Vulnerability (CVE-2024-1981)
    998504
    CVE-2023-6019
    WEB-MISC Anyscale Ray - OS Command Injection Vulnerability (CVE-2023-6019)
    998505
    CVE-2023-44092
    WEB-MISC Pandora FMS Prior to 776 - Remote Code Execution Vulnerability (CVE-2023-44092)
    998506
    CVE-2023-40000
    WEB-WORDPRESS LiteSpeed Cache Prior To 5.7.0.1 - Stored Cross Site Scripting Vulnerability (CVE-2023-40000)
    998507
    CVE-2023-40000
    WEB-WORDPRESS LiteSpeed Cache Prior To 5.7.0.1 - Stored Cross Site Scripting Vulnerability (CVE-2023-40000)
    998508
    CVE-2023-37679, CVE-2023-43208
    WEB-MISC NextGen Mirth Connect < 4.4.1 - Unauthenticated RCE Vulnerability Via /server (CVE-2023-37679, CVE-2023-43208)
    998509
    CVE-2023-37679, CVE-2023-43208
    WEB-MISC NextGen Mirth Connect < 4.4.1 - Unauthenticated RCE Vulnerability Via /users (CVE-2023-37679, CVE-2023-43208)
    998510
    CVE-2023-25196
    WEB-MISC Apache Fineract Prior to 1.8.4 - SQL Injection Vulnerabilities (CVE-2023-25196)
    998511
    CVE-2023-25195
    WEB-MISC Apache Fineract Prior to 1.8.4 - Server-Side Request Forgery Vulnerability (CVE-2023-25195)
    NetScaler customers can quickly import the above signatures to help reduce risk and lower exposure associated with these vulnerabilities. Signatures are compatible with NetScaler (formerly Citrix ADC) software version 11.1, 12.0, 12.1, 13.0 and 13.1. NOTE: Software versions 11.1 and 12.0 are end of life, and you should consider upgrading for continued support. Learn more about the NetScaler software release lifecycle.
     
    If you are already using NetScaler Web App Firewall with the signature auto-update feature enabled, verify that your signature file version is 128 or later and then follow these steps.
    Search your signatures for <number> Select the results with ID  Choose “Enable Rules” and click OK  
    NetScaler WAF Best Practices
    NetScaler recommends that WAF users always download the latest signature version, enable signature auto-update, and subscribe to receive signature alert notifications. NetScaler will continue to monitor this dynamic situation and provide updates as new mitigations become available.
     
    Handling false positives
    If app availability is affected by false positives that result from the above mitigation policies, relaxations can be applied. NetScaler recommends the following modifications to the policy.
     
    Modifications to NetScaler Web App Firewall Policy:
    add policy patset exception_list
    # (Example: bind policy patset exception_list “/exception_url”) 
    Prepend the existing WAF policy with:
    HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT
    # (Example :  set appfw policy my_WAF_policy q^HTTP.REQ.URL.CONTAINS_ANY(“exception_list”).NOT && <existing rule>^
    NOTE: Any endpoint covered by the exception_list may expose those assets to risks 
    Additional Information
    NetScaler Web App Firewall benefits from a single code base across all its form-factors (physical, virtual, bare-metal, and containers). This signature update applies to all form factors and deployment models of NetScaler Web App Firewall.
    Learn more about NetScaler Web app Firewall, read our alert articles and bot signature articles to learn more about NetScaler WAF signatures, and find out how you can receive signature alert notifications.
    Please join the NetScaler Community today and engage with your peers to learn more about how they are protecting their businesses with NetScaler WAF. 




     

    Subhojit Goswami
    Author: Subhojit Goswami, Satyam Mehrotra and Lahari Panga
     
    Introduction to Profiles
    SSL/TLS is a core tenet of NetScaler which caters to the ever-changing security landscape of application delivery for any organization. NetScaler has a robust SSL/TLS feature stack with some of the core features such as TLS Offload, etc.
     
    To leverage the feature stack, one needs to configure the Netscaler. Configuring the NetScaler can be a tedious and time-consuming process, as to cater to any enterprise organization, one needs to configure innumerable entities such as ‘n’ number of virtual servers, services, internal services, etc. Most of the time, the vast majority of these entities will have identical settings configured and if any kind of change is required then one needs to go to each of those entities and make the necessary changes in the configured setting. Hence, it creates a lot of repetitive processes which is not good for user experience.
     
    To simplify the above issue, Netscaler introduced an entity known as ‘Profile’. With the ‘Profile’ entity, one can simply edit the settings on the Profile itself and then bind the Profile to all the other entities that have identical settings, thus mitigating the repetitive and time–consuming processes. Now, this Profile entity is extended to many other feature stacks such as TCP, SSL, HTTP, etc.
     
    In this article, we will focus solely on the SSL Profile. Currently, there are two types of SSL Profile:
    Legacy SSL Profile Enhanced/Default SSL Profile Both these Profiles solve the inherent issue of making identical SSL setting changes via the entity-specific SSL parameter setting, where one has to go and make the necessary changes on every entity like virtual servers, services, etc.
     
    Deep dive into Legacy and Enhanced/Default SSL Profile
    Let's take a closer look at the Legacy SSL Profile. The Legacy SSL Profile inherits all the parameters of the SSL context entities (virtual servers/ services/ service groups/internal services of type SSL) into the profile. Bindings such as ECC curves and Ciphers are left out of the profile and are still part of the original SSL contexts. Users can set the SSL profile on the SSL context entities by using a set command. For example:
     
    set ssl vserver <name> -sslprofile <name of ssl profile>
     
    If this command is successful, then the parameter values are taken from the SSL Profile instead of the SSL vserver. As pointed out earlier, ECC curves and ciphers are still kept with vserver (in this example). This is how a show command output will look like:
     
    sh ssl vserver v1
     
         Advanced SSL configuration for VServer v1:
         Profile Name :ns_default_ssl_profile_frontend
     
         ECC Curve: P_256, P_384, P_224, P_521

     
    1)  Cipher Name: DEFAULT
         Description: Default cipher list with encryption strength >= 128 bit
     
    To mitigate the above-mentioned limitations of Legacy SSL Profile, Enhanced/Default SSL Profile can be leveraged. A Enhanced/Default SSL Profile contains all the necessary settings an SSL context can have, and it also includes ECC curve and cipher bindings.
    To enable enhanced SSL Profile, one can run the following command:
     
    set ssl parameter -defaultProfile ENABLED
     
    When the user runs this command, all the profiles present in the system get converted to Enhanced SSL profile. The command for setting profile on vserver remains the same as before:
     
    set ssl vserver <name> -sslprofile <name of ssl profile>
     
    Show output will look like this:
     
    > sh ssl vserver v1
     
         Advanced SSL configuration for VServer v1:
         Profile Name :ns_default_ssl_profile_frontend
     Done
     
    As seen here, since the ECC and cipher bindings are also a part of the profile, we do not see them as a part of sh ssl vserver output. To see the details of a profile, we can run 
    show ssl profile <name> command.
     
    Enhanced SSL profile is a powerful concept, and it takes all the advantages of profile infrastructure. NetScaler also provides a few default ssl profiles for use. Here is a list of default ssl profiles:
    ns_default_ssl_profile_backend
    ns_default_ssl_profile_frontend               
    ns_default_ssl_profile_internal_frontend_service
    ns_default_ssl_profile_secure_frontend           
    ns_default_ssl_profile_quic_frontend         
    ns_default_ssl_profile_secure_frontend_cloud
     
    The ns_default_ssl_profile_frontend and ns_default_ssl_profile_backend are the most important SSL profiles. When a user enables default SSL profile, all the front-end entities like virtual servers get attached to ns_default_ssl_profile_frontend profile and the backend entities like service and service group get attached to ns_default_ssl_profile_backend profile. These two profiles are editable, and the user is allowed to make modifications.
     
    One significant thing that a user needs to make a note of is that once the Enhanced Profile is enabled (set ssl parameter -defaultProfile ENABLED) it cannot be undone. The only way to revert is to do a clear configuration on NetScaler.
     
    Need for the migration from Legacy to Enhanced/Default SSL Profile
    Along with overcoming the limitations posed by the Legacy SSL Profile with the inception of Enhanced/Default SSL Profile, there is another major factor that makes Enhanced/Default SSL Profile the latest and the greatest of the SSL Profile infrastructure, i.e., all the new features are/will only be available on Enhanced/Default SSL Profile. So, for one to leverage the SSL/TLS stack to its fullest and utilize the latest features, it is the hour of need for one to migrate from the Legacy SSL Profile to the Enhanced/Default SSL Profile.
    The following are some of the TLS features that are available only in an Enhanced/Default SSL Profile:
    TLSv1.3 SSL Interception Session Ticket Allow Extended Master Secret ALPN Protocol Use only bound CA certificates allowUnknownSNI  
    Migrating from the Legacy SSL Profile to the Enhanced/Default SSL Profile can be a very tedious and time-consuming process, as there can be n number of Legacy SSL Profiles applied to n number of entities. So, to ease the pain of the user, NetScaler came up with an SSL Profile Converter Tool for seamless migration,  taking the overarching process pain from the user’s hands. We are also pleased to state that this tool has now been integrated with the NetScaler GUI which makes it even simpler for a user to convert, just with a click of a button.
    But first, let’s see how the tool works under the hood:

     
    The tool takes a given NetScaler configuration file and scans it. Post scanning it intelligently segregates entities with identical settings like ‘n’ number of vservers having Legacy Profiles with identical settings, etc., it also takes care of entity-specific settings, i.e., entities having no Profile. Once the segregation has been done, the tool generates the corresponding Enhanced/Default SSL Profile for each cohort and finally writes the changes into an output batch file. Thus, completely automating the migration process and improving the user experience.
     
    Now let’s take a look at the steps needed to be adhered to by a user from the NetScaler ADC GUI perspective to use this particular tool:


     
    The tool resides in: Traffic Management > SSL > Tools > SSL Profile Converter.
     
    First and foremost, the user has to save the NetScaler configuration. After that one needs to click on the checkbox indicating that the configuration has been saved, then click on the “Run SSL Profile Conversion” button which converts and produces a batch file with all the Enhanced SSL Profiles in it. Output file location when using admin partitions and running the script from CLI: /nsconfig/partitions/<partition_name>/sslprofile_cmds.txt.
    Output file location when using the default partition and running the script from CLI or GUI: /nsconfig/sslprofile_cmds.txt.
    Once the conversion has been successful, the user needs to review the output file, which can be done instantaneously by clicking on the “View” button, or by clicking on the “ Download” button to download and review it  later. Once the reviewing is done, one can simply enable the Default SSL Profile first with the following command: set ssl parameter -defaultProfile ENABLED And then batch the output file. Thus, having a seamless transition.  
    In this way, a user can seamlessly transition from SSL Legacy Profile/No Profile to Enhanced/Default SSL Profile with just the click of a button.
     
    THANK YOU!

     

    Subhojit Goswami
    Author: Shruti Vijay Dhamale
     
    Smartcard authentication or client certificate authentication with NetScaler Gateway is a common deployment scenario that we come across-especially with government entities. 
    While this method of authentication enhances security, we do see users being prompted multiple times to choose a certificate or enter pin when trying to establish an ICA connection. 
    This article provides an overview of one of the methods to reduce multiple certificate or pin prompts.
    Before reviewing the method let's understand what generates the multiple cert prompts. 
    Consider a NetScaler Gateway vServer configured to perform certificate authentication followed by LDAP authentication using n-factor as mentioned below:
    Authentication Policy
    add authentication certAction certauth_act -twoFactor ON -userNameField Subject:CN
    add authentication Policy Certauth_pol -rule true -action certauth_act
    add authentication ldapAction AD1_SAM -serverIP 172.30.200.20 -ldapBase "dc=citrix,dc=lab" -ldapBindDn citrixservices@citrix.lab -ldapBindDnPassword XXXX -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2021_11_05_17_13_55 -ldapLoginName sAMAccountName
    add authentication Policy adv_ldap_sam -rule true -action AD1_SAM
     
    LoginSchema
    add authentication loginSchema ldap1 -authenticationSchema "/nsconfig/loginschema/LoginSchema/PrefilUserFromExpr.xml" -userCredentialIndex 11 -passwordCredentialIndex 12
    Policy Label
    add authentication policylabel ldapauth1 -loginSchema ldap1
    bind authentication policylabel ldapauth1 -policyName adv_ldap_sam -priority 100 -gotoPriorityExpression NEXT
     
    Authentication vServer
    add authentication vserver AAA_EPA_GW SSL 0.0.0.0
    bind authentication vserver AAA_EPA_GW -portaltheme RfWebUI
    bind ssl vserver AAA_EPA_GW -certkeyName CitrixDemoCenter-cert
    bind ssl vserver AAA_EPA_GW -certkeyName Defaultroot -CA -ocspCheck Optional
    bind authentication vserver AAA_EPA_GW -policy Certauth_pol -priority 100 -nextFactor ldapauth1 -gotoPriorityExpression NEXT
    set ssl vserver AAA_EPA_GW -clientAuth ENABLED -clientCert Mandatory 
     
    Authentication Profile
    add authentication authnProfile EPA_GW -authnVsName AAA_EPA_GW
    Traffic Policy
    add vpn trafficAction sso http -SSO ON -userExpression "AAA.USER.ATTRIBUTE(11)" -passwdExpression "AAA.USER.ATTRIBUTE(12)"
    add vpn trafficPolicy sso true sso
     
    Session Policy
    add vpn sessionAction AC_WB_172.30.200.112 -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -ssoCredential PRIMARY -icaProxy ON -wihome "https://xd1.citrix.lab/Citrix/StoreWeb" -ClientChoices OFF -ntDomain Citrix -clientlessVpnMode OFF -sfGatewayAuthType domain
    add vpn sessionPolicy PL_WB_172.30.200.112 "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"CitrixReceiver\").NOT" 
     
    VPN vServer
    add vpn vserver EPA_Gateway SSL 172.30.200.112 443 -downStateFlush DISABLED -Listenpolicy NONE -authnProfile EPA_GW
    bind vpn vserver EPA_Gateway -staServer https://xd1.citrix.lab
    bind vpn vserver EPA_Gateway -portaltheme RfWebUI
    bind vpn vserver EPA_Gateway -policy PL_WB_172.30.200.112 -priority 100 -gotoPriorityExpression NEXT -type REQUEST
    bind vpn vserver EPA_Gateway -policy sso -priority 100 -gotoPriorityExpression END -type REQUEST
    bind ssl vserver EPA_Gateway -certkeyName CitrixDemoCenter-cert
    bind ssl vserver EPA_Gateway -certkeyName Defaultroot -CA -ocspCheck Optional
    set ssl vserver EPA_Gateway -clientAuth ENABLED -clientCert  mandatory 
     
    The traffic flow at high-level would be as follows:
    Client performs an SSL handshake and is presented with a Citrix NetScaler login page.  Client provides credentials, and NetScaler connects to an external authentication server for validation. These credentials are presented to the Citrix StoreFront server to perform SSO. Citrix StoreFront after verifying with Citrix DDC enumerates appropriate applications to the user. Client clicks on the application and receives the ICA file.  When client launches the ICA file received, a new non-browser session is initiated with NetScaler Gateway vServer. Due to this user receives a new prompt to provide a certificate or enter a pin.  After validation is successful, client is connected to the application/desktop.
    As we can see browser/workspace app caches the information about client certificate/pin and uses it for subsequent SSL handshakes that are done with NetScaler Gateway’s AAA vServer. However, when the session switches from the web to ICA, client gets prompted again to select a certificate/pin to complete the connection.
    To avoid these multiple prompts, we can use the below-mentioned solution using SAML authentication.
    Consider a NetScaler Gateway vServer configured with SAML policy configured to redirect the client to another AAA vServer hosted on the same NetScaler instance using SAML IdP that performs certificate authentication followed by LDAP authentication configured as below:
    Authentication Policy 
    add authentication certAction certauth_act -twoFactor ON -userNameField Subject:CN
    add authentication Policy Certauth_pol -rule true -action certauth_act
    add authentication ldapAction AD1_SAM -serverIP 172.30.200.20 -ldapBase "dc=citrix,dc=lab" -ldapBindDn citrixservices@citrix.lab -ldapBindDnPassword XXXX -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2021_11_05_17_13_55 -ldapLoginName sAMAccountName
    add authentication Policy adv_ldap_sam -rule true -action AD1_SAM 
    add authentication samlAction saml_sp -samlIdPCertName CitrixDemoCenter-cert -samlSigningCertName CitrixDemoCenter-cert -samlRedirectUrl "https://108-168-156-36.mycitrixdemo.net/saml/login" -samlUserField UserID -samlRejectUnsignedAssertion OFF -samlIssuerName "https://108-168-156-37.mycitrixdemo.net"
    add authentication Policy saml_sp -rule TRUE -action saml_sp
    add authentication samlIdPProfile saml_idp -samlSPCertName mylabcert -samlIdPCertName mylabcert -assertionConsumerServiceURL "https://108-168-156-37.mycitrixdemo.net/cgi/samlauth" -samlIssuerName "https://108-168-156-36.mycitrixdemo.net" -signatureAlg RSA-SHA1 -digestMethod SHA1 -Attribute1 Userid -Attribute1Expr "AAA.USER.ATTRIBUTE(11)" -Attribute2 Password -Attribute2Expr "AAA.USER.ATTRIBUTE(12).B64ENCODE" -serviceProviderID "https://108-168-156-37.mycitrixdemo.net"
    add authentication samlIdPPolicy saml_idp -rule TRUE -action saml_idp
     
    LoginSchema
    add authentication loginSchema ldap1 -authenticationSchema "/nsconfig/loginschema/LoginSchema/PrefilUserFromExpr.xml" -userCredentialIndex 11 -passwordCredentialIndex 12
    Policy Label
    add authentication policylabel ldapauth1 -loginSchema ldap1
    bind authentication policylabel ldapauth1 -policyName adv_ldap_sam -priority 100 -gotoPriorityExpression NEXT
     
    Authentication vServer (SAML IdP)
    add authentication vserver SAML_IDP SSL 172.30.200.111 443
    bind authentication vserver AAA_EPA_GW -portaltheme RfWebUI
    bind ssl vserver SAML_IDP -certkeyName CitrixDemoCenter-cert
    bind ssl vserver SAML_IDP -certkeyName Defaultroot -CA -ocspCheck Optional
    bind authentication vserver SAML_IDP -policy saml_idp -priority 100 -gotoPriorityExpression NEXT
    bind authentication vserver SAML_IDP -policy Certauth_pol -priority 100 -nextFactor ldapauth1 -gotoPriorityExpression NEXT
    set ssl vserver SAML_IDP -clientAuth ENABLED -clientCert Mandatory 
     
    Authentication vServer (SAML SP)
    add authentication vserver AAA_EPA_GW SSL 0.0.0.0
    bind authentication vserver AAA_EPA_GW -portaltheme RfWebUI
    bind ssl vserver AAA_EPA_GW -certkeyName CitrixDemoCenter-cert
    bind authentication vserver AAA_EPA_GW -policy saml_sp -priority 100 -gotoPriorityExpression NEXT
     
    Authentication Profile
    add authentication authnProfile EPA_GW -authnVsName AAA_EPA_GW
    Traffic Policy
    add vpn trafficAction sso http -SSO ON -userExpression "AAA.USER.ATTRIBUTE(1)" -passwdExpression "AAA.USER.ATTRIBUTE(2)"
    add vpn trafficPolicy sso true sso
     
    Session Policy
    add vpn sessionAction AC_WB_172.30.200.112 -transparentInterception OFF -defaultAuthorizationAction ALLOW -SSO ON -ssoCredential PRIMARY -icaProxy ON -wihome "https://xd1.citrix.lab/Citrix/StoreWeb" -ClientChoices OFF -ntDomain Citrix -clientlessVpnMode OFF -sfGatewayAuthType domain
    add vpn sessionPolicy PL_WB_172.30.200.112 "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"CitrixReceiver\").NOT" 
     
    VPN vServer
    add vpn vserver EPA_Gateway SSL 172.30.200.112 443 -downStateFlush DISABLED -Listenpolicy NONE -authnProfile EPA_GW
    bind vpn vserver EPA_Gateway -staServer https://xd1.citrix.lab
    bind vpn vserver EPA_Gateway -portaltheme RfWebUIbind vpn vserver EPA_Gateway -policy PL_WB_172.30.200.112 -priority 100 -gotoPriorityExpression NEXT -type REQUEST
    bind vpn vserver EPA_Gateway -policy sso -priority 100 -gotoPriorityExpression END -type REQUEST
    bind ssl vserver EPA_Gateway -certkeyName CitrixDemoCenter-cert
    bind ssl vserver EPA_Gateway -certkeyName Defaultroot -CA -ocspCheck Optional
     
    In this method, the certificate or smart card check is offloaded to AAA vServer acting as an Idp server. So once client is authenticated, their credentials are returned using the SAML attribute to the AAA vServer bound to NetScaler Gateway vServer, which can be then used for SSO with CVAD infrastructure. Notice the difference in authentication policy bindings, client cert setting in SSL parameters for AAA vServer, and SSO credential index used in traffic profile in both scenarios. 
    The traffic flow at high-level would be as follows:
    The Client performs an SSL handshake with NetScaler Gateway vServer and is redirected to a SAML IdP vServer configured on the same NetScaler.  Client performs SSL handshake with AAA vServer that acts as IdP vServer and presents Client certificate. Upon certificate validation, client is presented with the Citrix NetScaler login page. Client provides credentials, and NetScaler connects to an external authentication server to validate the user. Once authenticated, client connects back to NetScaler Gateway vServer, with credentials returned as a part of SAML attributes. These credentials are presented to the Citrix StoreFront server to perform SSO. Citrix StoreFront after verifying with Citrix DDC enumerates appropriate applications to the user. Client clicks on the application and receives the ICA file.  NetScaler requests the IP address from the STA server for the resource requested, post that the ICA connection is established.  

    To obscure the credentials further, you can also base64 encode the credentials when configuring the SAML attribute.
    For an alternative method to reduce multiple prompts, a separate NetScaler Gateway vServer for call-back can also be used as described in this blog. 
    The trace files from the demo environment are available here.

    Akhil Nair
    Proactive actions are crucial in today's digital landscape to successfully combat evolving cyber threats. One such threat, CVE-2024-1709, has recently surfaced, targeting ConnectWise ScreenConnect versions 23.9.7 and earlier. This vulnerability poses a significant risk, potentially allowing attackers to bypass authentication using an alternate path or channel vulnerability.
    The Exploit
    Due to a particular .NET feature that processes additional URL path components beyond the legitimate one, attackers are able to bypass access restrictions and manipulate the setup wizard file on ScreenConnect instances that are already configured. This allowed them to grant elevated privileges or full administrator controls thus rewriting the existing user access database. Once they gain admin rights, attackers can upload malicious files or execute arbitrary codes on the system.
    In this blog post, we'll focus on how organizations can utilize NetScaler Web Application Firewall (WAF) signatures to effectively mitigate the risks associated with CVE-2024-1709.
    Leveraging Signature-based Protections
    NetScaler WAF provides a robust defense mechanism against CVE-2024-1709 and similar vulnerabilities through its extensive database of signatures. These signatures are meticulously crafted to identify and block known attack patterns associated with CVE-2024-1709, enabling organizations to fortify their defenses against emerging threats.
    Comprehensive Threat Intelligence: 
    NetScaler WAF continuously updates its signature database with the latest threat intelligence feeds, ensuring organizations stay ahead of evolving cyber threats, including CVE-2024-1709. By leveraging up-to-date threat intelligence, NetScaler WAF can effectively detect and mitigate emerging vulnerabilities, enhancing overall security posture.
    From Unified Security Console:
    Navigate to the Unified security flow - From your NetScaler Console Service, navigate to Security > Security Dashboard Select your application from the ‘Unsecured Applications’ tab. If you’ve previously configured using the Unified Security flow, you’ll find your application under the ‘Secured Application’ tab and click on the edit icon. Select the ‘CVE Protections’ tile - 
    Search for the CVE from the list of signatures and enable the same - 
    From NetScaler ADC, ensure you’re running signature version 125 and -
    Search your signatures for ‘CVE-2024-1709’ LogString. Select the results. Choose “Enable Rules” and click OK.
    Real-time Detection and Mitigation: 
    NetScaler WAF's signature-based protections operate in real-time, enabling organizations to swiftly detect and mitigate unauthorized access attempts associated with CVE-2024-1709. By analyzing web traffic against its signature database, NetScaler WAF can identify and block malicious activities before they compromise sensitive information or critical systems.
    Customization and Flexibility:
    NetScaler WAF allows organizations to customize signature-based protections based on their specific security requirements and risk profile. By tailoring signature-based rules and policies to their environment, organizations can effectively mitigate CVE-2024-1709 and other vulnerabilities while minimizing false positives and disruptions to legitimate traffic.
    CVE-2024-1709 highlights the importance of proactive cybersecurity measures in safeguarding organizational assets against emerging cyber threats. By leveraging NetScaler WAF signatures, organizations can effectively mitigate the risks associated with CVE-2024-1709 and enhance their overall security posture. With comprehensive threat intelligence, real-time detection, and customization capabilities, NetScaler WAF empowers organizations to defend against evolving cyber threats and protect their critical assets with confidence.
     

    Juliano Reckziegel
    [UPDATE February 23, 2024] It has come to our attention that leveraging client IP information in DUO allows for the application of distinct policies, a feature previously overlooked in our integration. Specifically, we had failed to transmit this information to the DUO proxy server, thereby preventing the implementation of such policies. By default, DUO utilizes the RADIUS calling-station-id attribute as the client IP. In response, I have updated the NetScaler RADIUS action to include this attribute, ensuring that the client IP information is now accurately passed to the DUO proxy server. This enhancement enables the effective utilization of client IP data for policy application within DUO.
    As Cisco DUO's iframe integration reaches its end of support on September 30, 2024, organizations must transition to DUO Universal Prompt or adopt a RADIUS configuration without the iframe for continued support.
    In this article, we explore how to utilize the NetScaler nFactor framework to replicate the iframe functionality while leveraging the non-iframe RADIUS integration, ensuring a smooth transition for users and administrators alike.
    User Experience Overview:
    The integration facilitates a seamless user experience, ensuring secure authentication while maintaining convenience. Users are presented with a familiar interface where they can select authentication methods such as DUO Push, SMS, phone call, or passcode entry, ensuring flexibility and accessibility.
    The following image, depict the user experience using this integration method:

    How this works
    In addition to passcodes, DUO has special words that can be sent via RADIUS to the DUO proxy server that will trigger actions as followed:
    push: Sends a push notification to the user's device. sms: Sends an SMS with passcodes to the user's device. phone: Initiates a phone call to the user's device for confirmation. push#: Sends a push notification to the specified device (e.g., push2 for the second device). sms#: Sends an SMS with passcodes to the specified device (e.g., sms3 for the third device). phone#: Initiates a phone call to the specified device for confirmation (e.g., phone2 for the second device). NetScaler communicates with the DUO proxy server by sending the appropriate keyword based on the user's selection:
    push: When the DUO Push option is selected. passcode: When the user enters a passcode. sms: When the Send SMS option is chosen. phone: When the Call Phone option is selected. Users can manually select the passcode option and input special keywords (e.g., push2, phone3, sms4) to authenticate with alternative devices.
    Authentication Flow
    The authentication flow is configured with two factors:
    DUO MFA via RADIUS: The first factor verifies the user's MFA against DUO via RADIUS. LDAP Password: The second factor authenticates the user's password via LDAP. This sequential configuration helps to prevent that Active Directory (AD) accounts are locked due to excessive authentication attempts.
    DUO Configuration
    On the DUO proxy configuration file (authproxy.cfg), make sure you have a client session with [duo_only_client]  defined and create a new radius_server_duo_only entry on a port that is available, make sure to add the NSIP of both HA pair nodes and SNIP as RADIUS clients as needed.
    [duo_only_client] [radius_server_duo_only99] api_host=api-XXXXXXXX.duosecurity.com ikey=XXXXXXXXXXXXXXXXXXXX skey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX failmode=safe radius_ip_1=192.168.0.100 radius_secret_1=RADIUS_SECRET_123 radius_ip_2=192.168.0.151 radius_secret_2=RADIUS_SECRET_123 radius_ip_3=192.168.0.152 radius_secret_3=RADIUS_SECRET_123 port=18128 Use this configuration as a reference for setting up the DUO proxy server in your environment. Make sure to adapt the settings to match your specific setup, including any changes in IP addresses, shared secrets, or port numbers. If further assistance is required, consult the DUO support documentation or reach out to their support team for guidance on configuring a new radius_server_duo_only session on the authproxy.cfg file.
    NetScaler Configuration
    Assuming that the Citrix Gateway virtual server is already provisioned with necessary configurations such as certificates, Secure Ticket Authority (STA) servers, and session policies/profiles, follow these additional steps to integrate Cisco DUO using the nFactor extensibility features:
    Disable Single Sign-on Domain: Ensure that the "Single Sign-on Domain" is disabled on the session profile. This step is crucial for passing the UserPrincipalName to StoreFront. nFactor Extensibility Features: Utilize the nFactor extensibility features to customize the authentication process and integrate Cisco DUO options seamlessly. This involves creating a new XML Schema and adding jQuery code to the portal theme scripts.js file. XML schema
    Create a new xml file called duo.xml located at /nsconfig/loginschema with the following content:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <AuthenticateResponse xmlns="http://citrix.com/authentication/response/1"> <Status>success</Status> <Result>more-info</Result> <StateContext/> <AuthenticationRequirements> <PostBack>/nf/auth/doAuthentication.do</PostBack> <CancelPostBack>/nf/auth/doLogoff.do</CancelPostBack> <CancelButtonText>Cancel</CancelButtonText> <Requirements> <Requirement> <Credential><Type>none</Type></Credential> <Label><Text>dualauth_please_log_on</Text><Type>nsg-login-label</Type></Label> <Input/> </Requirement> <Requirement> <Credential><ID>login</ID><SaveID>login</SaveID><Type>username</Type></Credential> <Label><Text>dualauth_user_name</Text><Type>nsg-login-label</Type></Label> <Input><Text><ReadOnly>false</ReadOnly><InitialValue/><Constraint>.+</Constraint></Text></Input> </Requirement> <Requirement> <Credential><ID>passwd1</ID><SaveID>passwd1</SaveID><Type>password</Type></Credential> <Label><Text>dualauth_password</Text><Type>nsg-login-label</Type></Label> <Input><Text><Secret>true</Secret><Constraint>.+</Constraint></Text></Input> </Requirement> <Requirement> <Credential><ID>passwd2</ID><Type>duopasscode</Type></Credential> <Label><Text>dualauth_passcode</Text><Type>nsg-login-label</Type></Label> <Input/><!-- input field generated by custom handler --> </Requirement> <Requirement> <Credential><ID>passwd</ID><SaveID>passwd</SaveID><Type>duoselector</Type></Credential> <Label><Type>none</Type></Label> <Input/><!-- radio buttons created by custom handler --> </Requirement> <Requirement> <Credential><Type>duoinfotext</Type></Credential> <Label><Type>none</Type></Label> <Input/><!-- information message from custom handler --> </Requirement> <Requirement> <Credential><ID>Logon</ID><Type>none</Type></Credential> <Label><Type>none</Type></Label> <Input><Button>dualauth_submit</Button></Input> </Requirement> </Requirements> </AuthenticationRequirements> </AuthenticateResponse> Portal Theme
    Create a new portal theme called RfWebUI_DUO with the following NetScaler command:
    add vpn portaltheme RfWebUI_DUO -basetheme RfWebUI Add the following content to /var/netscaler/logon/themes/RfWebUI_DUO/script.js file:
    // This function creates the passcode field for Duo CTXS.ExtensionAPI.addCustomCredentialHandler({ // Credential type defined in login schema getCredentialTypeName: function() { return "duopasscode"; }, // Generate HTML for the custom credential getCredentialTypeMarkup: function(requirements) { var input = $("<input>"); input.attr("id","passwd2"); input.attr("name","passwd2"); //input.attr("type","password"); input.attr("type","text"); input.attr("autocomplete","off"); input.attr("spellcheck","false"); input.prop("disabled",true); input.on("change",function(){$("#duocode").attr("value",$("#passwd2").val());}); return input; } }); // This function creates the radio buttons for Duo CTXS.ExtensionAPI.addCustomCredentialHandler({ // Credential type defined in login schema getCredentialTypeName: function() { return "duoselector"; }, // Generate HTML for the custom credential getCredentialTypeMarkup: function(requirements) { var table = $("<table></table>"); table.addClass("radioButtons"); table.css("border-spacing",0); table.css("height",44); var tr = $("<tr></tr>"); tr.appendTo(table); var tdbase = $("<td></td>"); tdbase.css("width","25%"); var btbase = $("<input>"); btbase.attr("type","radio"); btbase.attr("name","passwd"); var lbbase = $("<label></label>"); lbbase.css("font-size","12px"); lbbase.css("color","#999999"); var button = btbase.clone(); button.attr("value","push"); button.attr("id","duopush"); var label = lbbase.clone(); label.attr("for","duopush"); label.text(" Duo Push"); var td = tdbase.clone(); td.append(button,label); td.appendTo(tr); button.on("change",function(){$("#passwd2").prop("disabled",true)}); button.prop("checked","checked"); button = btbase.clone(); button.attr("value","code"); button.attr("id","duocode"); label = lbbase.clone(); label.attr("for","duocode"); label.text(" Passcode"); td = tdbase.clone(); td.append(button,label); td.appendTo(tr); button.on("change",function(){$("#passwd2").prop("disabled",false)}); button = btbase.clone(); button.attr("value","sms"); button.attr("id","duotext"); label = lbbase.clone(); label.attr("for","duotext"); label.text(" Send SMS"); td = tdbase.clone(); td.append(button,label); td.appendTo(tr); button.on("change",function(){$("#passwd2").prop("disabled",true)}); button = btbase.clone(); button.attr("value","phone"); button.attr("id","duocall"); label = lbbase.clone(); label.attr("for","duocall"); label.text(" Call Phone"); td = tdbase.clone(); td.append(button,label); td.appendTo(tr); button.on("change",function(){$("#passwd2").prop("disabled",true)}); return table; } }); // This function creates the information text for Duo CTXS.ExtensionAPI.addCustomCredentialHandler({ // Credential type defined in login schema getCredentialTypeName: function() { return "duoinfotext"; }, // Generate HTML for the custom credential getCredentialTypeMarkup: function(requirements) { var link = $("<a>here</a>"); link.attr("href","https://support.fqdn.com.lab"); link.attr("target","_blank"); link.css("color","#02a1c1"); var div = $("<div></div>"); div.css("width",385); div.css("font-size","12px"); div.css("color","#999999"); div.css("text-align","center"); div.append("Click ",link," if you are not enrolled in Duo."); div.append("<br>","For assistance call the Help Desk, (XXX) XXX-XXXX."); return div; } }); NetScaler commands
    To the nFactor flow on NetScaler, you would use a series of CLI commands. Below are the commands to put together the configuration for integrating Cisco DUO using nFactor extensibility features and enabling/disabling the passcode field:
    Login Schema
    add authentication loginSchema DUO_LS -authenticationSchema "/nsconfig/loginschema/duo.xml" add authentication loginSchemaPolicy DUO_LSPOL -rule TRUE -action DUO_LS RADIUS policy/action
    In this particular step, the authTimeout is set to 60 seconds. This duration allows users a window of up to one minute to respond to authentication prompts such as push notifications or phone calls. Adjusting the authTimeout value provides flexibility in accommodating user response times within the nFactor authentication flow. The callingstationid parameter is used to pass the user source IP to the DUO proxy server.
    add authentication radiusAction DUO_SRV -serverIP 192.168.0.51 -serverPort 18128 -authTimeout 60 -radKey RADIUS_SECRET_123 -callingstationid ENABLED add authentication Policy DUO_POL -rule TRUE -action DUO_SRV LDAP policy/action
    In this step, the ssoNameAttribute parameter is configured to specify the userPrincipalName. As a result, there's no need to explicitly specify the Single Sign-on Domain on the session policy. This configuration streamlines the authentication process by automatically utilizing the userPrincipalName attribute for Single Sign-on purposes without additional policy settings.
    add authentication ldapAction LDAP_SRV -serverIP 192.168.0.5 -serverPort 636 -ldapBase "dc=company,dc=lab" -ldapBindDn serviceaccount@company.lab -ldapBindDnPassword SERVICE_ACCOUNT_PASSWORD -ldapLoginName sAMAccountName -groupAttrName memberOf -subAttributeName cn -secType SSL -ssoNameAttribute userprincipalname -passwdChange ENABLED add authentication Policy LDAP_POL -rule TRUE -action LDAP_SRV Policy Label
    This policy label represents the second factor of the authentication flow.
    add authentication policylabel LDAP_PL_noschema -loginSchema LSCHEMA_INT bind authentication policylabel LDAP_PL_noschema -policyName LDAP_POL -priority 100 -gotoPriorityExpression NEXT Authentication logic
    This authentication logic is implemented on an authentication virtual server.
    add authentication vserver DUO_AAA SSL 0.0.0.0 bind authentication vserver DUO_AAA -policy DUO_LSPOL -priority 100 -gotoPriorityExpression END bind authentication vserver DUO_AAA -policy DUO_POL -priority 100 -nextFactor LDAP_PL_noschema -gotoPriorityExpression NEXT bind ssl vserver DUO_AAA -certkeyName Sample01_SAN The last command in this block binds a certificate to the authentication virtual server. This step is optional and primarily serves to display the virtual server in an UP (operational) state.
    Authentication Profile
    The authentication profile is used to link the authentication virtual server with a Citrix Gateway virtual server.
    add authentication authnProfile DUO_AuthProf -authnVsName DUO_AAA Citrix Gateway configuration
    As mentioned previously, we are considering and pre-existing Citrix Gateway virtual server, in this case it is called "gw214.company.lab DUO".
    The following command will link it to the authentication logic:
    set vpn vserver "gw214.company.lab DUO" -authnProfile DUO_AuthProf The following command binds the new RfWebUI theme to the Citrix Gateway virtual server.
    bind vpn vserver "gw214.company.lab DUO" -portaltheme RfWebUI_DUO No SMS option
    If your organisation deems SMS as an unsuitable MFA method, you have the option to disable it within the authentication interface. This can be accomplished by adjusting the script.js file.

    To implement this change, follow these steps:
    Modify the width of the table cell (td) to 33% to accommodate the remaining authentication options effectively. Comment out the section of the code responsible for generating the SMS option. By making these adjustments, the SMS option will no longer be displayed within the authentication interface, ensuring that only the preferred MFA methods are presented to users during authentication.
    // This function creates the passcode field for Duo CTXS.ExtensionAPI.addCustomCredentialHandler({ // Credential type defined in login schema getCredentialTypeName: function() { return "duopasscode"; }, // Generate HTML for the custom credential getCredentialTypeMarkup: function(requirements) { var input = $("<input>"); input.attr("id","passwd2"); input.attr("name","passwd2"); //input.attr("type","password"); input.attr("type","text"); input.attr("autocomplete","off"); input.attr("spellcheck","false"); input.prop("disabled",true); input.on("change",function(){$("#duocode").attr("value",$("#passwd2").val());}); return input; } }); // This function creates the radio buttons for Duo CTXS.ExtensionAPI.addCustomCredentialHandler({ // Credential type defined in login schema getCredentialTypeName: function() { return "duoselector"; }, // Generate HTML for the custom credential getCredentialTypeMarkup: function(requirements) { var table = $("<table></table>"); table.addClass("radioButtons"); table.css("border-spacing",0); table.css("height",44); var tr = $("<tr></tr>"); tr.appendTo(table); var tdbase = $("<td></td>"); // tdbase.css("width","25%"); tdbase.css("width","33%"); var btbase = $("<input>"); btbase.attr("type","radio"); btbase.attr("name","passwd"); var lbbase = $("<label></label>"); lbbase.css("font-size","12px"); lbbase.css("color","#999999"); var button = btbase.clone(); button.attr("value","push"); button.attr("id","duopush"); var label = lbbase.clone(); label.attr("for","duopush"); label.text(" Duo Push"); var td = tdbase.clone(); td.append(button,label); td.appendTo(tr); button.on("change",function(){$("#passwd2").prop("disabled",true)}); button.prop("checked","checked"); button = btbase.clone(); button.attr("value","code"); button.attr("id","duocode"); label = lbbase.clone(); label.attr("for","duocode"); label.text(" Passcode"); td = tdbase.clone(); td.append(button,label); td.appendTo(tr); button.on("change",function(){$("#passwd2").prop("disabled",false)}); // button = btbase.clone(); // button.attr("value","sms"); // button.attr("id","duotext"); // label = lbbase.clone(); // label.attr("for","duotext"); // label.text(" Send SMS"); // td = tdbase.clone(); // td.append(button,label); // td.appendTo(tr); // button.on("change",function(){$("#passwd2").prop("disabled",true)}); button = btbase.clone(); button.attr("value","phone"); button.attr("id","duocall"); label = lbbase.clone(); label.attr("for","duocall"); label.text(" Call Phone"); td = tdbase.clone(); td.append(button,label); td.appendTo(tr); button.on("change",function(){$("#passwd2").prop("disabled",true)}); return table; } }); // This function creates the information text for Duo CTXS.ExtensionAPI.addCustomCredentialHandler({ // Credential type defined in login schema getCredentialTypeName: function() { return "duoinfotext"; }, // Generate HTML for the custom credential getCredentialTypeMarkup: function(requirements) { var link = $("<a>here</a>"); link.attr("href","https://support.fqdn.com.lab"); link.attr("target","_blank"); link.css("color","#02a1c1"); var div = $("<div></div>"); div.css("width",385); div.css("font-size","12px"); div.css("color","#999999"); div.css("text-align","center"); div.append("Click ",link," if you are not enrolled in Duo."); div.append("<br>","For assistance call the Help Desk, (XXX) XXX-XXXX."); return div; } }); Conclusion
    In conclusion, this article highlights the versatility of NetScaler nFactor in addressing the imminent discontinuation of the DUO iframe integration. By leveraging nFactor's capabilities, organizations can seamlessly transition to alternative authentication methods while maintaining security and a similar user experience.
    In this article, I've demonstrated a direct connection to the DUO RADIUS proxy and LDAP servers for simplicity. However, as a best practice, it's recommended to implement a load balancing virtual server for these components. This approach enhances the reliability and availability of the authentication infrastructure, ensuring seamless operation even in the event of server failures or high traffic loads.
    It's worth noting that users with multiple devices can conveniently authenticate by selecting the passcode option and inputting special keywords such as push#, sms#, phone# followed by the device number. For example, entering push2 will trigger a push notification to the user's second registered device.
    Credit for the original engineering of this solution goes to my former colleague, Edson da Luz, in 2021. I've made minor updates to present it here. Kudos to Edson for his creativity and skill in implementing this logic.
    This article serves as a testament to the adaptability and innovation within the cybersecurity landscape, offering practical solutions to evolving challenges in authentication and access management.

    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.

    Hemang Raval
    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

    Hemang Raval
    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.

    Hemang Raval
    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.

×
×
  • Create New...