Security continues to be a top priority for organizations, and protecting data is increasingly challenging, with attack methods constantly changing. Having users properly authenticated is a key focus area. After all, users can share passwords with others. Password character type rules, password expiry, and third-party authentication solutions are all methods used to combat this issue.

Another common solution involves enforcing two (or more) factors of authentication, aligning with “something you know and something you have” standards. Some solutions are expensive and depend on several components within an IT infrastructure such as servers. A one-time password (OTP) is a password that is valid for a single login session or transaction on a computer system or other digital devices. Citrix ADC supports OTPs without requiring a separate server.

Traditionally, Citrix ADC supported a maximum of two authentication factors — primary and secondary authentication. But the chosen factors would have to be applied to all users. Citrix ADC nFactor changes all this because now it’s possible to have N number of authentication factors (hence “nFactor).

While some customers are served by the standard OTP configuration, others require a more complex configuration that covers multiple domains, access via Citrix Receiver, and group membership validation. Thanks to the flexibility and adaptability that nFactor offers, it’s possible to meet these and other requirements.

You’ll find information about advanced settings here. We also have a couple of articles that show how to configure Native OTP on Citrix ADC and how to configure AD Domain Group Membership check. In this blog post, I’ll show you how to do both together.

nFactor with Multiple AD Domain and Group Membership Check

The overall process flow for how users will be authenticated in this scenario was:

Step 1: Evaluate UPN and Citrix Receiver

  1. Citrix Receiver detected, trigger the embedded browser, go to Step 2
  2. Citrix Receiver not detected, go to Step 2

Step 2: Evaluate AD Group and URL

  1. User is not a member of CTX_OTP_GROUP, go to Step 4
  2. User is a member of CTX_OTP_GROUP
    1. If, user typed /MANAGEOTP, go to Step 3A
    2. Else, go to Step 3B

Step 3: Ask for

  1. Enroll the device
  2. Or ask for OTP token
  3. Go to Step 4.

Step 4: Finish the authentication flow

First Factor: Check AD Domain using UPN and check for Receiver/Workspace app access

The policies shown in the below diagram were linked to the AAA vServer to obtain the user’s domain and check whether Citrix Receiver/Workspace app was being used:

Figure 1: Policies Bind on AAA VIP (Click image to view larger.)

Filter expressions were used to verify whether users came from one domain or another and thereby direct the LDAP authentication request. The filter expressions used were:

“AAA.LOGIN.USERNAME.CONTAINS(\”domain01.local\“)
“AAA.LOGIN.USERNAME.CONTAINS(\”domain02.corp\“)
“AAA.LOGIN.USERNAME.CONTAINS(\”domain03.net\“)
“AAA.LOGIN.USERNAME.CONTAINS(\”domain04.internal\“)

Notice that this will only work if users use their UPN to authenticate themselves at the Citrix Gateway. Alternatively, the below expressions could have been used:

“HTTP.REQ.BODY(10000).TYPECAST_NVLIST_T(\’=\’,\’&\’).VALUE(\”login\”).CONTAINS(“domain01.local”)
“HTTP.REQ.BODY(10000).TYPECAST_NVLIST_T(\’=\’,\’&\’).VALUE(\”login\”).CONTAINS(“domain02.corp”)
“HTTP.REQ.BODY(10000).TYPECAST_NVLIST_T(\’=\’,\’&\’).VALUE(\”login\”).CONTAINS(“domain03.net”)
“HTTP.REQ.BODY(10000).TYPECAST_NVLIST_T(\’=\’,\’&\’).VALUE(\”login\”).CONTAINS(“domain04.internal”)

Additionally, a NO_AUTHN policy was bound to check whether the Receiver/Workspace app client was used via the filter expression:

“HTTP.REQ.HEADER(\”User-Agent\“).CONTAINS(\”CitrixReceiver\“)”

This is only required to activate the embedded browser. After that, it is linked to a separate login schema that processes the domain to which the user belongs.

Without this configuration the Receiver / Workspace would not be able to activate the embedded browser, nor would it validate the user’s domain. The login schema is shown below.

Figure 2: Receiver Check (Click image to view larger.)

Second Factor: Check “CTX_USER_OTP” group membership to select OTP or single Factor

After ADC matched the first factor, the next step is a group membership validation to check whether the authentication flow continues or ends. That is also required to access the “MANAGEOTP” page.

If the user is not a member of “CTX_USER_OTP” group, the authentication flow will end, and the resource will be allowed for the user. However, if the user is a member of the group, the next factor (OTP) will be invoked.

This chain of policies is shown below as an example for domain01, but each domain would have a parallel configuration.

Figure 3: Check CTX_USER_OTP group membership for domain01 (Click image to view larger.)

Third Factor: Ask for OTP Token or allow “MANAGEOTP” page

If the user is a member of the “CTX_USER_OTP” group, he/she will be presented with a single password field for OTP validation via the policy shown below.

Figure 4: Ask for OTP code (Click image to view larger.)

Alternatively, if the user types /manageotp in URL at the beginning of the access flow, they will be redirected to a page for device enrollment.

Figure 5: Allow access to MANAGEOTP page (Click image to view larger.)

Summary

To summarize, some key items covered in this post were:

  • Citrix ADC nFactor allowa an unlimited number of authentication factors
  • Citrix ADC native OTP does not require a third-party authentication solution
  • For OTP with Multiple Domains and User Group Check:
    • Create 1 Receiver/Workspace App check policy.
    • Create 4 LDAP policies to check the UPN to determine the user’s domain.
    • Create 4 policy label and bind NOAUTH policies to determine if user is member of CTX_USER_GROUP or not. This is also required to access MANAGEOTP page.

You can download the full set of configurations here. I hope this helps guide you on your nFactor journey!