Jump to content
Welcome to our new Citrix community!
  • 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 organization 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.

    Jacob Rutski 2
    May 27, 2021 Author:  Jacob Rutski Special thanks:  Dileep Reddem, Michael Shuster, Matt Brooks, Martin Zugec, Anthony Raymer Overview
    Many Citrix ADC appliances host VPN and Citrix Gateway deployments that also provide security protections to other web applications. This PoC guide is designed to help protect VPN and Gateway virtual servers using tools already available on the Citrix ADC appliance. This guide covers protecting the portal login page with Bot security and protecting the credential form submission with WAF capabilities. Also, advanced authentication policies add context to user logons and enable multifactor authentication.
    The flow of this configuration diagrammed as follows:

    Configuration Options
    This guide doesn’t provide an exclusive list of protections, nor is it the only way to configure them. For example, deploying both IP Reputation and rate limiting using a responder policy on a Gateway virtual server is common. This configuration is a supported method of deployment. It has a different outcome of dropping or resetting connections before the gateway login page is rendered.
    Also, the WAF profile doesn’t have every protection enabled to prevent complex configuration, custom tuning, and potential issues. Further configuration to the WAF profile is possible, see the links in the references section for guidance.
    Prerequisites
    This guide assumes a working knowledge of Citrix WAF deployment, Bot Security deployment, and Advanced Authentication Policies (nFactor). It makes assumptions that a gateway or authentication virtual server is already installed and configured. The following are requirements for the configuration:
    Advanced Authentication Policies require release 12.1 build 57.18 or later Web Application Firewall protections require release 12.1 build 57.18 or later Bot Security protections require release 13.0 build 71.40 or later Most of the features in this guide require a premium license An existing server or service listening on port 80 An existing Gateway or authentication virtual server, with an existing advanced authentication configuration (advanced authentication or nFactor flow) Enable the following features: Citrix Web App Firewall, Citrix Bot Management, and Reputation Bot Protection
    Bot Signatures
    From Security > Citrix Bot Management > Signatures, select the Default Bot Signatures and click the Clone button. Apply a descriptive name, then click create.

    Create a Bot Management Profile and Policy
    From Security > Citrix Bot Management > Profiles, select Add to create a new Bot Management Profile. Give the profile a descriptive name and select the previously created signature set.

    Select the profile to edit the advanced settings.
    Add IP Reputation from the right column and check the box to enable it.

    Next, choose ‘Add’ under categories, select IP for the Type, check the box for Enabled and set the action to Drop. Last, check the box for ‘Log’ and set the log message to something descriptive.


    Select Device Fingerprint from the right column, ensure that the ‘Enabled’ check box is NOT checked and click Update.

    The last setting for the Bot Profile is to enable rate limiting, select Rate Limit from the right column and check the box for enabled. Click ‘Add’ under Configure Resources, and add three URL type rate limit bindings for the following URLs:
    /logon/LogonPoint/index.html /logon/LogonPoint/tmindex.html /vpn/index.html Configure the rate limits as follows:
    Enabled Rate of 5 Period of 1000 Action of Drop Log set to enabled Log Message with a descriptive message title.
    The Bot Profile is now configured as follows:

    Create a Bot Management Policy by going to Security > Citrix Bot Management > Bot Policies and choosing Add. Select the previously created Bot Profile, with an expression as follows:
        HTTP.REQ.URL.CONTAINS("/vpn")||HTTP.REQ.URL.CONTAINS("/logon") Finally, the bot policy is bound by selecting ‘Policy Manager’. Select a Bind Point of ‘Default Global’, select ‘Click to select’ to select the policy. Highlight the previously created policy, and choose ‘Select’. Select ‘Bind’ then ‘Done’.

    WAF Protection
    It isn’t possible to bind a WAF policy directly to a Gateway or authentication virtual server. Also, binding a WAF policy globally with an expression that targets Gateway or authentication virtual servers won’t function as expected. The policy processing order causes this malfunction - WAF policies are processed after Gateway and authentication policies. See the image below for a traffic flow clarification.

    The WAF protection policy uses an HTTP Callout to protect the logon page and invalidate the authentication flow if a WAF exception is caught. This configuration requires a pattern set (Patset) that includes the login URLs, a dummy service and load balancing virtual server, an HTTP callout, and the WAF policy and configuration.
    Pattern Set
    Navigate to AppExpert > Pattern Sets and select ‘Add’. Give the new Pattern Set a name, then select ‘Insert’ and add the following patterns:
    /cgi/login (index 1) /nf/auth/doAuthentication.do (index 2)
    Alternatively, create the pattern set from the CLI:
        add policy patset GW_VPN_Patset bind policy patset GW_VPN_Patset "/cgi/login" -index 1 bind policy patset GW_VPN_Patset "/nf/auth/doAuthentication.do" -index 2 Dummy Virtual Server and Service
    The HTTP Callout uses a dummy virtual server. This virtual server doesn’t need to be publicly available, so it can be non-addressable. The virtual server DOES need to be up, so the back end server needs to be up and responding on port 80. A new service and virtual server are created in this guide, but a pre-existing virtual server can be used.
    Go to Traffic Management > Load Balancing > Services and select ‘Add’. Give the service a descriptive name, set the protocol to HTTP and port to 80. Enter the IP address of the server and choose OK. Alternatively, create the service with an existing server. Use all default settings, including monitors bound to the service.

    Next create the load balancing virtual server by going to Traffic Management > Load Balancing > Virtual Servers and select ‘Add’. Give the server a descriptive name, set the protocol to HTTP, and set the IP address type to Non Addressable. Bind the previously created service to this virtual server by selecting ‘No Load Balancing Virtual Server Service Binding’ then ‘Click to select’ and selecting the service. There is now 1 service bound to the virtual server and the state is ‘UP’.

    HTTP Callout
    Navigate to AppExpert > HTTP Callouts and select ‘Add’. Give the HTTP Callout a descriptive name, select ‘Virtual Server’ to receive the callout request, and select the dummy virtual server. In the Request to send to the server, select the type as Expression-Based, set the scheme to ‘HTTP’ and set the Full Expression to the following:
        HTTP.REQ.FULL_HEADER.BEFORE_STR("\r\n\r\n")+"\r\nGW_VPN-WAF_Callout:abc\r\n\r\n"+HTTP.REQ.BODY(2048) In the Server Response section, set the return type to BOOL and set the expression to ‘true’.

    Alternatively, create the HTTP Callout from the CLI:
        add policy httpCallout GW_VPN_WAF_Callout -vServer dummy-vserver-here -returnType BOOL -fullReqExpr HTTP.REQ.FULL_HEADER.BEFORE_STR("\r\n\r\n")+"\r\nGW_VPN-WAF_Callout:abc\r\n\r\n"+HTTP.REQ.BODY(2048) -scheme http -resultExpr true Authentication Policy
    Modify an existing LDAP authentication policy to use the HTTP Callout. Open the existing authentication policy by going to Security > AAA Application Traffic > Policies > Authentication > Advanced Policies > Policy, select the existing policy and choose ‘Edit’. Modify the existing expression to the following:
        HTTP.REQ.URL.CONTAINS_ANY("GW_VPN_Patset") && SYS.HTTP_CALLOUT(GW_VPN_WAF_Callout)
    WAF Profile and Policy
    To build the WAF profile go to Security > Citrix Web Application Firewall > Profiles and choose ‘Add’. Give the profile a descriptive name and select Web Application (HTML) and Basic Defaults. Open the newly created profile by choosing ‘Edit’ then select ‘Security Checks’ from the right hand column.
    Enable the following security checks (disable all other settings):
    Buffer Overflow - Log, Stats Post Body Limit - Block, Log, Stats HTML Cross-Site Scripting - Block, Log, Stats HTML SQL Injection - Block, Log, Stats
    Next select ‘Profile Settings’ from the right hand column and set the Default Response to:
        application/octet-stream Then check the box for Log Every Policy Hit.

    Next, configure the WAF policy by going to Security > Citrix Web Application Firewall > Policies > Firewall and choose ‘Add’. Give the policy a descriptive name and select the profile created in the previous step. For the expression, enter the following:
        HTTP.REQ.HEADER("GW_VPN-WAF_Callout").EXISTS Last, bind the WAF policy to the dummy load balancing virtual server created earlier by going to Traffic Management > Load Balancing > Virtual Servers. Select the virtual server then choose ‘Edit’.
    From the right hand column, select ‘Policies’ then click the ‘+’ plus to add a policy. Select policy App Firewall and type Request. Select the policy created previously then select ‘Bind’ and ‘Done’.

    Alternatively, create the WAF configuration using the CLI as follows:
        add appfw profile demo_appfw_profile -startURLAction none -denyURLAction none -fieldFormatAction none -bufferOverflowAction log stats -responseContentType "application/octet-stream" -logEveryPolicyHit ON -fileUploadTypesAction none add appfw policy demo_appfw_policy "HTTP.REQ.HEADER(\"GW_VPN-WAF_Callout\").EXISTS" demo_appfw_profile bind lb vserver dummy-vserver-here -policyName gw_appfw_policy -priority 100 -gotoPriorityExpression END -type REQUEST Advanced Authentication Settings
    There are two configurations related to authentication - encrypting user credentials from the client to the ADC within nFactor and IP reputation based MFA.
    Encrypting User Credentials
    The following setting enables the ADC to encrypt the credential set when the user submits the form data using ECDHE algorithms. To enable this setting, navigate to Citrix Gateway > Global Settings > Authentication Settings > Change Authentication AAA settings and set Login Encryption to ENABLED.

    Alternatively, change this setting from the CLI as follows:
        set aaa parameter -loginEncryption ENABLED IP Reputation Based MFA
    Use IP Reputation with advanced authentication to prompt the user for an extra factor if the database includes the source address. Also, creatte a manually maintained dataset of addresses.
    Create a data set by going to AppExpert > Data Sets and selecting ‘Add’. Create a data set with a descriptive name, a type of ‘ipv4’ and click ‘Create’.

    Next, two advanced authentication policies need to be created by going to Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Policy and select ‘Add’.
    Create the first policy with a descriptive name, an action type of NO_AUTHN, and the expression set to ‘true’.

    Create the second policy with a descriptive name, action type of NO_AUTHN, and an expression as follows:
        CLIENT.IP.SRC.IPREP_IS_MALICIOUS || CLIENT.IP.SRC.TYPECAST_TEXT_T.CONTAINS_ANY("suspicious_ips") Next, a CAPTCHA login schema profile is created by going to Security > AAA - Application Traffic > Login Schema > Profiles Tab and selecting ‘Add’. Give the profile a descriptive name then edit the Authentication Schema by selecting the ‘pencil’ edit icon. Browse to the LoginSchema directory, highlight SingleAuthCaptcha.xml, and choose Select.

    Next, create an authentication policy label for the Captcha schema by going to Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Policy Label and selecting ‘Add’. Give the PL a descriptive name and select the previously created captcha login schema. Bind the required LDAP action policy.

    Create another policy label by selecting ‘Add’. Give this PL a descriptive name, and set the login schema to LSCHEMA_INT. Next, bind the two previously created NO_AUTHN authentication policies.

    Last, set the next factor of the previously created authentication policy as this IP Reputation check policy label. It’s already bound to an authentication or Gateway virtual server. Highlight the authentication policy, select ‘edit binding’ then set the new policy label as the ‘Select Next Factor’ field.

    Summary
    Citrix ADC provides many built-in security protections that protect Gateway or Authentication virtual servers running on the same appliance. These protections have no impact on typical users as they try to log in to Citrix Gateway.
    References
    For additional information and configuration options, see the following articles:
    Introduction to Citrix Web Application Firewall - Citrix Product Docs: Introduction to Citrix Web Application Firewall
    Citrix Web Application Firewall PoC Guide - proof of concept deployment guide for Citrix Web Application Firewall
    Citrix Training for Application Delivery and Security - Citrix Education Training for Application Delivery and Security
    Getting started with Citrix ADC - Citrix Product Docs: Getting started with Citrix ADC - Packet Flow
    IP Reputation - Citrix Product Docs: IP Reputation
    Bot Management - Citrix Product Docs: Bot Management
    Bot Detection - Citrix Product Docs: Bot Detection
    nFactor Authentication - Citrix Product Docs: nFactor Authentication
    Citrix ADC - nFactor Basics Cheat Sheet - Citrix Tech Zone: Diagrams and Posters Citrix ADC - nFactor Basics Cheat Sheet
    CTX216091 - supporting re-Captcha with nFactor
    nFactor for Citrix Gateway with Push Token - proof of concept deployment guide for TOTP push tokens for Citrix Gateway

    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.

    Konstantinos Kaltsas
    Agile, flexible DevOps practices are crucial to successful application modernization initiatives, which often involve migrating applications from on-premises to public cloud using containers. At the same time, many organizations must continue hosting applications on-premises due to regulatory and compliance requirements, cost concerns, or other business needs. NetScaler, an application delivery and security platform, and Google Anthos, a cloud-centric container platform, work together to provide consistent and reliable application delivery and security for any application on any infrastructure.
    NetScaler for hybrid cloud application delivery
    NetScaler provides powerful and flexible topologies that complement organizational boundaries. Dual-tier deployments employ high-capacity hardware or virtualized NetScaler ADCs in the first tier to segment control between network operators and Kubernetes operators, while the second tier employs containerized NetScaler ADCs within the Kubernetes cluster.
    With its flexible topologies, NetScaler makes it as easier to migrate applications between on-premises and cloud. Because all NetScaler form factors share the same code base, NetScaler works the same regardless of the environment in which it is deployed. So you gain operational consistency along with greater agility regardless of the type of application (monolith or microservices) and infrastructure. Key NetScaler features include auto-scaling, global server load-balancing (GSLB), multi-cluster ingress, and a web application firewall.
    Google Anthos for hybrid cloud infrastructure management
    Google Anthos unifies the management of compute infrastructure and applications across on-premises, at the edge, and in multiple public clouds with a Google Cloud-backed control plane for consistent operation at scale. Key features like an enterprise-grade container orchestration and management service; policy and configuration management; and a service mesh help you to accelerate the adoption of Day 2 operations and make your DevOps pipeline more efficient.
    Key capabilities of NetScaler with Google Anthos
    Key capabilities you gain from using NetScaler with Google Anthos include:
    Auto-scale ADCs from within a Google Kubernetes Engine (GKE) cluster based on user demand Automate ADC Day 2 operations using Anthos Config Management Implement advanced security controls and enforce security policies with NetScaler Web App Firewall and Anthos Policy Controller Automate multi-cluster/multi-regional deployments and load balancing configurations from within GKE using NetScaler GSLB and Anthos Config Management Export metrics and transaction data from NetScaler using the containerized NetScaler Observability Exporter and export them to such popular endpoints as Zipkin, Kafka, Elasticsearch, Prometheus, and Splunk Enterprise Automate canary deployments using NetScaler Ingress Controller and Anthos Config Management We provide fully functional labs for you to test. The labs’ source code is publicly available on GitHub. Note that our GitHub account refers to Citrix ADC, which is the former name of NetScaler.
    Request a free consultation with the NetScaler product team
    If you’re looking to get started with application modernization, request a free consultation with the NetScaler product team: appmodernization@citrix.com.
    To participate in the discussion about application modernization, join the NetScaler cloud-native Slack channel.
     
     

    Konstantinos Kaltsas
    This is the third post in our series on Citrix ADC with Google Anthos. In our first post, we talked about the importance of modern app deliver and security for hybrid multi-cloud, and in our second post, we focused on achieving consistent and reliable app delivery for Kubernetes apps and shared a lab on GitHub for readers to test.
    In this post, we’ll focus on security and demonstrate how:
    Citrix ADC can strengthen your security posture across hybrid and multi-cloud. Citrix Web App Firewall (WAF) works seamlessly with Google Anthos Policy Controller to provide protection for Kubernetes apps and APIs. Citrix Web App Firewall with Google Anthos Policy Controller enforce app protection using configuration as code GitOps enhances continuous configuration along with Google Anthos Config Management for automating security configuration. Protecting Web Apps and APIs
    When it comes to application delivery, security is a top priority. Web apps and APIs are often an organization’s most valuable but vulnerable assets, and to reach production and go live, there are several requirements that need to be met. From governance and compliance requirements to organization-specific requirements, the task is not an easy one.
    Citrix Web App Firewall has proven and robust security controls to protect apps against known and unknown application attacks. It defends apps and APIs against OWASP top 10 threats and zero-day attacks and provides security insights for faster remediation. To learn how Citrix Web App Firewall is designed to provide security, check out our product documentation. Our introduction to Citrix Web App Firewall, overview of security checks, and FAQs and deployment guide are great resources to help you get started.
    Citrix Web App Firewall is designed to be easily enabled and configured as code following the infrastructure and configuration as code paradigms. By providing WAF, bot management, CORS CRD for Kubernetes, security configurations are now possible from within a GKE cluster. You can now automate the configuration of both Tier-1 and Tier-2 Citrix Web App Firewalls easily.
    Common protections such as buffer overflow, cross site request forgery (CSRF), cross site scripting (XSS), SQL injection, URL allow lists and block lists, or more advanced ones can be easily enabled as policies using simple YAML files. Combining these capabilities with policy agents (as we’ll see in our lab) introduces an enterprise-grade practice of configuring and automating security.
    The key advantage of using Citrix WAF is that it uses a single code base across all Citrix ADC form factors (MPX and SDX, as well as VPX and CPX) so you can consistently apply and enforce security policies across any application environment. That gives you ease of deployment and simplicity in configurations which saves time and reduces configuration errors.
    Citrix Web App Firewall follows well-established principles that provide DevOps, CloudOps and SecOps teams with the tools they need to effectively do their job. By supporting both positive and negative security models Citrix Web App Firewall provides the widest protection possible. In addition to that, common event format (CEF) logging enables customers to easily collect and aggregate WAF data for analysis by an enterprise management system. Configuring and integrating a WAF has never been easier.
    Because security configurations can be part of the source code and stored in Git, different configurations can be created and maintained per environment. “Shifting Security Left” in the early stages of testing can become easier and Dev(Sec)Ops practices can be applied. Configurations are now closer to meeting the actual need, closer to the apps that need protection, and can eliminate false positives. And with a single point of truth, full visibility is achieved for both Operations and Audit teams, making it even easier to perform required audits.
    Deploying a Modern Application Architecture
    Here, we’ll focus on deploying a Tier-1 Citrix ADC (VPX) in front of a Google Anthos GKE cluster within GCP. We will leverage Google Anthos Configuration Management for consistent deployment of Citrix components into the Anthos GKE cluster. Additionally, we’ll leverage Google Anthos Policy Controller to ensure that Citrix Web App Firewall configurations exist to protect ingress objects within a cluster.
    ACM (Anthos Configuration Management) is a GitOps-centric tool that synchronizes configuration into a Anthos Kubernetes cluster from a Git repository. Policy Controller is a component of ACM that can audit or enforce configurations across the cluster. This lab automation has been written with GitHub as the git repository tool of choice.
    The following diagram illustrates the infrastructure used by our lab that will be deployed. (Click the image to view larger.)

    Citrix ADC VPX
    A single Citrix ADC VPX instance is deployed with two network interfaces:
    nic0 provides access for management (NSIP) and access to back-end servers (SNIP). nic1 provides access for deployed applications (VIPs). Each interface is assigned an internal private IP address and an external public IP address. The instance is deployed as a pre-emptible node to reduce lab costs. The instance automatically configures the password with Terraform. The instance is then automatically configured by the Citrix Ingress Controller and Citrix Node Controller deployed in the GKE cluster. VPCs and Firewall Rules
    Two VPCs are used in this deployment:
    The default VPC and subnets are used for instance and GKE cluster deployment. The vip-vpc is used only to host VIP addresses, which routes the traffic back to the services in the default VPC. Default firewall rules apply to the default VPC. Ports 80/443 are permitted into the vip-vpc. GKE Cluster with Anthos Configuration Management
    A single GKE cluster is deployed as a zonal cluster:
    Autoscaling is enabled with a minimum of one node and a configurable maximum. The Google Anthos Config Management (ACM) operator is deployed into the GKE cluster and configured to sync the cluster configuration from a GitHub repository. Citrix Ingress Controller and Citrix Node Controller components are automatically installed via ACM into the ctx-ingress namespace. Citrix Web App Firewall Custom Resource Definition (CRD) is installed via ACM to enable developers to create WAF configurations. Worker nodes are deployed as pre-emptible nodes to reduce lab costs. Policy Controller is installed to demonstrate constraints that enforce the presence of a WAF object in a namespace prior to accepting an Ingress resource. GitHub Repository
    A dedicated GitHub repository is created and loaded with a basic cluster configuration:
    A basic hierarchical format is used for ease of navigation through namespaces and manifests. Citrix Ingress Controller and Citrix Node Controller deployment manifests are built from templates and added to this repository, along with their other required roles / rolebindings / services / etc. This repository is created and destroyed by Terraform. Online Boutique Demo Application
    The online boutique demo application provides a microservices-based application for our lab. It has been modified slightly for this environment:
    An ingress resource has been added to receive all traffic through the Citrix VPX. Application components are controlled through Anthos Config Management and the source git repo. To learn more about how to deploy this lab and see autoscaling in action, please visit Citrix ADC with Google Anthos – WAF with Policy Controller Lab on our Citrix Cloud Native Networking (CNN) hands-on guides.
    Additional Information
    Read more about how Citrix can help you on your application modernization journey in our Microservices App Delivery Best Practices library.
    Interested in learning more about Citrix application and API security? Check our Citrix Web App Firewall data sheet.
    Find out how a Citrix ADC solution helps manage, monitor, and secure your entire infrastructure and ensure application security efficacy on our e-book on the Top 6 WAF Essentials to Achieve Application Security Efficacy.
    In our app delivery and security developer docs, you’ll find guidance on configuring Citrix components to meet your specific requirements.
    Our e-book on six must-haves for app delivery in hybrid- and multi-cloud environments has details on why you need an application delivery controller along with a management and orchestration platform.
    You can learn more about the role of application delivery in the cloud-native journey in our white paper on seven key considerations for microservices-based application delivery.
    Finally, the ADC Guide to Managing Hybrid (IT and DevOps) Application Delivery covers how Citrix ADC bridges the gap between traditional and DevOps app delivery.
    What’s Next?
    Watch out for the next blog post in our series, where we will discuss how you can use Citrix ADC, with its extensive set of policies, as an API gateway for Kubernetes apps.
    Looking to get started or take the next step in your app modernization? Our team is now offering free consultations! Send an email to appmodernization@citrix.com to schedule your session or request a call and a specialist will promptly reply with options to connect.
    Want to join our Citrix cloud-native Slack channel? Sign up now to receive an invitation.

×
×
  • Create New...