RADIUS Authentication – Citrix Gateway

Last Modified: Mar 29, 2021 @ 11:28 am

215 Comments

This article applies to Citrix Gateway 13.0, Citrix Gateway 12.1, and NetScaler Gateway 12.0. Citrix ADC is the new name for NetScaler. Citrix Gateway is the new name for NetScaler Gateway.

Navigation

Change Log

RADIUS Overview

One method of two-factor authentication to Citrix Gateway is the RADIUS protocol with a two-factor authentication product (tokens) that has RADIUS enabled.

  • Another common two-factor authentication method is SAML to an Identity Provider, like Azure Active Directory or Okta. SAML is detailed in the Federated Authentication Service article.

RADIUS Clients and Source IP – On your RADIUS servers, you’ll need to add the ADC appliances as RADIUS Clients. When ADC uses a local (same appliance) load balanced Virtual Server for RADIUS authentication, the traffic is sourced from the ADC SNIP (Subnet IP). When ADC uses a direct connection to a RADIUS Server without going through a load balancing Virtual Server, or uses a remote (different appliance) Load Balancing Virtual Server, the traffic is sourced from the ADC NSIP (ADC Management IP). Use the correct IP(s) when adding the ADC appliances as RADIUS Clients. And adjust firewall rules accordingly.

  • For High Availability pairs, if you locally load balance RADIUS, then you only need to add the SNIP as a RADIUS Client, since the SNIP floats between the two appliances. However, if you are not locally load balancing RADIUS, then you’ll need to add the NSIP of both appliances as RADIUS Clients. Use the same RADIUS Secret for both appliances.

Links:

Some two-factor products (e.g. SMS Passcode) require you to hide the 2nd password field. Receiver 4.4 and newer supports hiding the 2nd field if you configure a Meta tag in index.html.

Two-factor Policies Summary

ADC has two methods of configuring multi-factor authentication:

  • Citrix Gateway Virtual Server has bind points for Primary and Secondary authentication. This functionality is available in all ADC Editions and is detailed in this post.
    • This is the older method of configuring authentication also known as Classic authentication policies. One challenge with Classic policies is that Citrix Workspace app requires the LDAP and RADIUS fields to be swapped.
  • nFactor Authentication supports unlimited factors, but requires ADC Advanced Edition (formerly known as Enterprise Edition) or ADC Platinum Edition.
    • nFactor is the newer authentication configuration method also known as Advanced authentication policies. With nFactor, there’s no need to swap the LDAP and RADIUS fields for Citrix Workspace app.

Workspace app authentication with a Classic Policy configuration looks like a Window that is very difficult to customize.

Workspace app authentication with an nFactor configuration looks like a webpage that is fully customizable.

See the ADC menu page for additional authentication mechanisms supported by Citrix Gateway. Some require nFactor.

When configuring the Citrix Gateway Virtual Server, you can specify both a Primary authentication policy, and a Secondary authentication policy. Users are required to successfully authenticate against both policies before being authorized for Citrix Gateway.

For browser-based StoreFront, you need two authentication policies:

  • Primary = LDAPS authentication policy pointing to Active Directory Domain Controllers.
  • Secondary = RADIUS authentication policy pointing to RSA servers with RADIUS enabled.

For Citrix Workspace app, the classic authentication policies need to be swapped. There’s no need to swap them if doing nFactor (Advanced) policies.

  • Primary = RADIUS authentication policy pointing to RSA servers with RADIUS enabled.
  • Secondary = LDAPS authentication policy pointing to Active Directory Domain Controllers.

With Classic Authentication Policies, if you need to support two-factor authentication from both web browsers and Citrix Workspace app, then you’ll need at least four authentication policies as shown below.

Primary:

  • Priority 90 = RADIUS policy. Expression = REQ.HTTP..HEADER User-Agent CONTAINS CitrixReceiver
  • Priority 100 = LDAP policy. Expression = REQ.HTTP..HEADER User-Agent NOTCONTAINS CitrixReceiver

Secondary:

  • Priority 90 = LDAP policy. Expression = REQ.HTTP..HEADER User-Agent CONTAINS CitrixReceiver
  • Priority 100 = RADIUS policy. Expression = REQ.HTTP..HEADER User-Agent NOTCONTAINS CitrixReceiver

LDAP Server/Action

See the LDAP post for instructions to create an LDAP Server/Action. Only the LDAP server/action is needed. The Policies will be created later.

RADIUS Server/Action

Create a RADIUS Server/Action:

  1. On the left, expand Authentication, and click Dashboard.
  2. On the right, click Add.
  3. Change Choose Server Type to RADIUS.
  4. Give the server a name.
  5. Specify the IP address of the RADIUS load balancing Virtual Server.
  6. Enter the secret key specified when you added the ADCs as RADIUS clients on the RADIUS server. Click Test RADIUS Reachability.
  7. Scroll down, and click More.
  8. Find the Password Encoding drop-down. Change it to mschapv2 if your RADIUS server supports it, c. Microsoft NPS requires mschapv2 to support changing expired Active Directory passwords. 💡
  9. If you want ADC to receive AAA Group information from RADIUS, see CTX222260 Radius Group Extraction from Windows Server 2008/2012 with NetScaler/CloudBridge.
    • RADIUS attribute = 26 (Vendor-Specific)
    • Vendor Code = 3845 (Citrix)
    • Vendor-assigned attribute number = any number (e.g. 1). Configure RADIUS policy on ADC with same attribute number.
    • Attribute value = Group Name
  10. Click Create.

    add authentication radiusAction RSA -serverIP 10.2.2.210 -serverPort 1812 -authTimeout 60 -radKey Passw0rd -passEncoding mschapv2

Advanced Authentication (nFactor) Policies for LDAP and RADIUS

For the older Classic Authentication policies, jump ahead to the Classic Policies section.

Create Advanced Authentication Policies:

  1. In the left menu, go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy.
  2. On the right, click Add.
  3. In the Create Authentication Policy window:
    1. Change the Action Type to RADIUS.
    2. Select your RADIUS Action.
    3. Give the policy a name.
    4. Expression = true.
  4. Click Create.
  5. Create another Authentication Policy.
    1. Set Action Type to LDAP.
    2. Select your LDAP Action/Server.
    3. Give the policy a name.
    4. Expression = true.
  6. Click Create.

Create a Policy Label for the second factor, which is typically the RADIUS policy. The first factor (LDAP) does not need a Policy Label.

  1. In the left menu, click Policy Label.
  2. On the right, click Add.
  3. Give the Policy Label a name.
  4. Leave Login Schema set to LSCHEMA_INT. The Login Schema in the first factor will collect both password and passcode in one form so there’s no need for the second factor to collect it again.
  5. Click Continue.
  6. In the Select Policy field, select your RADIUS policy.
  7. Click Bind at the bottom of the page.
  8. Click Done to finish creating the Policy Label.

Create a Login Schema to collect the password and passcode on the same form.

  1. In the left menu, click Login Schema.
  2. On the right, switch to the tab named Profiles and then click Add.
  3. Give the Login Schema a name (e.g. DualAuth).
  4. Click the pencil icon and then open the LoginSchema folder.
  5. Click the DualAuth.xml file on the left. On the right, make sure you click the blue Select button. It’s too easy to miss this step.
    • See my nFactor article for some info on how to customize the Login Schema.
  6. Then click Create.
  7. On the right, switch to the tab named Policies.
  8. Give the Login Schema Policy a name.
  9. Select the Login Schema Profile you just created.
  10. Set the Rule field to true.
  11. Click Create.

Create an Authentication (AAA) Virtual Server to link the factors together.

  1. In the left menu, under AAA – Application Traffic, click Virtual Servers.
  2. On the right, click Add.
  3. Change the IP Address Type to Non Addressable.
  4. Give the AAA vServer a name and then click OK.
  5. In the Certificate section, you can optionally bind a certificate. It doesn’t matter what certificate you choose (typically the Gateway cert). The only thing this certificate binding does is make the AAA vServer show as UP instead of DOWN. Otherwise it has no effect on functionality. Click Continue.
  6. In the Advanced Authentication Policies section, click where it says No Authentication Policy.
  7. In the Select Policy field at the top of the window, select the LDAP policy.
  8. Near the bottom, in the Select Next Factor field, click where it says Click to select.
  9. Select your RADIUS Policy Label and then click Bind. After LDAP is done, nFactor will then move to your RADIUS Policy Label.
  10. Click Continue.
  11. On the right, in the Advanced Settings column, click Login Schemas.
  12. On the bottom left, click where it says No Login Schema.
  13. Select the DualAuth Login Schema you created earlier and then click Bind.
  14. Click Done at the bottom of the page.

Link the AAA vServer to your Gateway vServer:

  1. In the left menu, expand Citrix Gateway and then click Virtual Servers.
  2. On the right, edit your Gateway vServer.
  3. On the right, in the Advanced Settings column, click Authentication Profile.
  4. On the bottom left, in the Authentication Profile section, click the Add button.
  5. Select the AAA vServer you created earlier.
  6. Give the Profile a name and then click Create.
  7. Back in the Gateway vServer, make sure you click OK in the Authentication Profile section. If you forget to click OK then the Authentication Profile won’t be bound.

If you point your Workspace app to the Gateway that has nFactor configured, the authentication window will look like a web page.

Classic Authentication Policies for LDAP and RADIUS

For Advanced Authentication (nFactor) policies, jump back to the Advanced Policies section.

  1. Go to Citrix Gateway > Policies > Authentication > RADIUS.
  2. On the right, in the Policies tab, click Add.
  3. In the Create Authentication RADIUS Policy page:
    1. Name the policy RSA-ReceiverSelfService or similar.
    2. Select the RADIUS server created earlier.
    3. Enter an expression. You will need two policies with different expressions. The expression for Receiver Self-Service is REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver.
      Note: Citrix Gateway 12.1 does not natively support binding of Advanced Authentication Policies so you’ll have to create them as Basic Policies (classic expressions). You can only bind Advanced Authentication Policies using nFactor.
  4. Click Create.
  5. If you see a warning about deprecation, click OK, and ignore it.
  6. Create another RADIUS policy to match the ones shown below. Both RADIUS policies are configured with the same RADIUS server. The only difference between them is the expression (CONTAINS vs NOTCONTAINS):
    Name Expression Server
    RSA-ReceiverSelfService REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver RSA
    RSA-ReceiverForWeb REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver RSA

  7. Go to the Citrix Gateway\Policies\Authentication\LDAP node.
  8. On the Policies tab, create two policies with the expressions shown below. Both LDAP policies are configured with the same LDAP server. The only difference between them is the expression (CONTAINS vs NOTCONTAINS).
    Name Expression Server
    LDAP-Corp-ReceiverSelfService REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver LDAP-Corp
    LDAP-Corp-ReceiverForWeb REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver LDAP-Corp 

add authentication radiusPolicy RSA-ReceiverForWeb "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" RSA

add authentication radiusPolicy RSA-ReceiverSelfService "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" RSA

add authentication ldapPolicy Corp-Gateway-ReceiverForWeb "REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver" Corp-Gateway

add authentication ldapPolicy Corp-Gateway-ReceiverSelfService "REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver" Corp-Gateway

Bind Two-factor Policies to Gateway

  1. When you create or edit a Citrix Gateway Virtual Server, bind the Basic Authentication Policies as shown in the following table. Priority doesn’t matter because they are mutually exclusive.
    Policy Name Type Bind Point
    LDAP-Corp-ReceiverForWeb LDAP Primary
    RSA-ReceiverSelfService RADIUS Primary
    LDAP-Corp-ReceiverSelfService LDAP Secondary
    RSA-ReceiverForWeb RADIUS Secondary 

    bind vpn vserver gateway.corp.com -policy Corp-Gateway-ReceiverForWeb -priority 100

bind vpn vserver gateway.corp.com -policy RSA-ReceiverSelfService -priority 110

bind vpn vserver gateway.corp.com -policy RSA-ReceiverForWeb -priority 100 -secondary

bind vpn vserver gateway.corp.com -policy Corp-Gateway-ReceiverSelfService -priority 110 -secondary
  2. The Session Policy/Profile for Receiver Self-Service needs to be adjusted to indicate which authentication field contains the Active Directory password. On the Client Experience tab is Credential Index. This needs to be changed to SECONDARY. Leave the session policy for Web Browsers set to Primary.

    set vpn sessionAction "Receiver Self-Service" -ssoCredential SECONDARY
  3. On the StoreFront server, when creating the Citrix Gateway object, on the Authentication Settings page, change the Logon type to Domain and security token. This instructs Receiver / Workspace app to properly handle two-factor authentication. If you change this setting after Receiver / Workspace app has already performed discovery, then users might have to remove the Account from Receiver / Workspace app and re-add it.

215 thoughts on “RADIUS Authentication – Citrix Gateway”

  1. hello , we have rsa am 8.7 , i see your tip on changing password encoding to mschapv2 (we’re currently on pap). How would i know if my current radius server supports it ?

    Reply

  2. Appericiate it carl

    I am facing an error when loggin into sg through GW. ( Cant complete your request)
    Ag Basic login failed, 403 forbidden.

    This particularly happened after enabling nfactor
    (First page AD creds, second page Radius passcode)

    i double checked the STA conf, sso domain, storefront services.
    Anything else i am missing here

    Reply

    1. Check StoreFront Server > Event Viewer > Applications and Services > Citrix Delivery Services.

      Did you create a Login Schema Profile for the first factor? If so, edit it, click More, and there’s a checkbox for Enable Single Sign On Credentials.

      Reply

      1. i did enable the option on the schema,
        still facing same error.

        The logs shows 403 forbidden event

        ist required that i apply a traffic policy aaa.user.attribute expression to deliver the creds to sf ?

        Reply

        1. Maybe. NetScaler might be sending your RADIUS passcode to StoreFront instead of the user’s password.

          StoreFront Event Log should have another event from Authentication Service. There are usually two or three events when authentication does not succeed. Also, are you sending the user’s domain name from NetScaler to StoreFront?

          Reply

          1. Issue resolved,

            Apparently, we had a trigger pushed to the radius server after ldap auth is completed.

            This resulted on wrong creds parsed to the storfront. ( creds+ trigger)’
            however when i removed that and made it as soft token radius it worked

  3. Hi all!
    Could someone tell me how to configure Netscaler to use Message-Authenticator and Reply-Message to communicate with our RADIUS? When I enable this on RADIUS, Netscaler shows a reject message in the aaa.debug log for attribute 80 and 18.
    Thanks,
    Tom

    Reply

    1. I’d like to know this also. We’ve got patches for Fortinet. FreeRADIUS and Windows NPS already support on reasonably recent versions. Can’t find anything in any Netscaler docs about this attribute.

      Reply

      1. Netscaler doosn´t support this. I opened a call and Citrix support took some network dumps. When they realized my requirement, they opened a feature request.

        Reply

  4. Hi,
    We’re having an absolute nightmare implementing Azure MFA (RADIUS) on our Citrix netscalers.
    Windows devices are fine but our Wyse ThisOS 9 thin clients are being problematic. About 20% of our users are getting SSL 9 or 31 or 45 (or a mixture of all 3) errors when connecting via the internet. They can be in a session for 5 minutes or 2 hours when the error appears and they are unceremoniously kicked.
    The CA Root and Inter certs are valid.
    The same pair are being used via RSA (which we are migrating from) and there are no issues at all.
    Anyone experienced this? I can’t find anything related on the interweb.

    Reply

  5. Hello Carl,

    I’m planning on doing an upgrade for an ADC 13.0 going towards 14.1, run the script to check the configuration and I have some basic policies that reads something like:
    add authorization policy vpn-pol ns_true ALLOW

    how can I translate that to advanced, do you have a link that’s easy to understand for someone who english is not first language?

    Thank you in advance,

    Christian

    Reply

    1. Did the script say that the commands will be removed in 13.1? Or did the script say that the commands are deprecated? The deprecated commands still work in 14.1.

      Reply

      1. Carl, thank you for for your quick reply. The script gave this as a complete line “Classic expression in the rule field is deprecated for command [add authorization policy vpn-pol ns_true ALLOW], please use the advanced expression”
        As for your comment, I don’t need to do anything to modify this line?
        thank you again for your help

        Reply

        1. There’s no requirement to convert it. When you do the firmware upgrade from the CLI, the upgrade script will tell you which commands don’t work in 13.1 or 14.1.

          Reply

  6. Hello everyone,

    I have worked through the instructions on our test netscaler with a standard license and am now wondering how to create the 2nd factor.
    The Manageotp page is not available for me either.
    I am grateful for any advice.

    Reply

      1. Thank you for the quick reply,
        Is it not possible to set up a native OTP with a standard license via Classic Authentication?

        Reply

  7. Hi Carl
    Can I use NetScaler Standard Edition to switch authentication process to RSA as primary and LDAP as secondary? However, I want users to see LDAP as primary (first) and RSA as secondary (second). It’s challenging for users to enter RSA first due to the 60-second RSA timeout.

    Thank you
    kish

    Reply

      1. Hi Carl

        We have the same requirement, but we’re using Basic Auth in Standard Edition so there is no nFactor virtual server using a login schema. How can this be done in this case or is the login schema XML still being used under the hood somewhere?

        Thanks!

        Reply

  8. With the latest 13.1 version and advanced policies for LDAP + Radius, there a checkbox called Enable Single Sign On Credentials in the Login schema profile. If you don`t check it, single sign-on will fail on the SF side.

    Reply

  9. Hello
    I need to configure Radius as first factor and Ldap as Second factor using nfactor flow. when i configure the Dualauth.xml Loginschema does not accepts password in 2nd field. it accepts passcode in second field and password in 3rd field. so selected DUALAUTH_Flipped.xml as login schema for first factor, here as well Passcode not accepted in second field. rather it accepts password in second field and passcode in 3rd filed(the way i want) but it doesnt performs sso for storefront and give cannot complete your request.

    Reply

    1. Normally the last password/passcode collected is used for SSON unless you selected the SSON checkbox in the Login Schema. You can override this by configuring the Login Schema to store the password in a AAA Attribute and then configure a Gateway Traffic Policy to send the AAA Attribute as the SSON Password.

      Reply

  10. After upgrading a netscaler to a latest 13.1 firmware SMS passcode authentication is not working.

    It is working fine on the other non upgraded node. I wonder what could be the cause?

    /usr/home/build/adc/usr.src/netscaler/aaad/radius_drv.c[862]: continue_radius_auth 1-62: RADIUS Auth: UDP: attempting to do RADIUS authentication for user [gribskov\****] @ [1.10.1.1]
    Tue May 16 19:00:20 2023
    /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[6403]: register_timer 1-62: setting timer 130
    Tue May 16 19:00:20 2023
    /usr/home/build/adc/usr.src/netscaler/aaad/radius_drv.c[2529]: process_radius 1-62: Got RADIUS event 1
    Tue May 16 19:00:20 2023
    /usr/home/build/adc/usr.src/netscaler/aaad/naaad.c[6480]: unregister_timer 1-62: releasing timer 130
    Tue May 16 19:00:20 2023
    /usr/home/build/adc/usr.src/netscaler/aaad/radius_drv.c[2651]: process_radius 1-62: Received RAD_ACCESS_REJECT for: gribskov\****
    Tue May 16 19:00:20 2023
    /usr/home/build/adc/usr.src/netscaler/aaad/radius_drv.c[2658]: process_radius 1-62: RADIUS auth: Authentication failed for user gribskov\**** from server 1.10.1.1 – Invalid Credentials

    There is an instant error message once entering the username/password field.

    Reply

  11. Thank you! Always got “credentials invalid” via workspaceapp, no issues via webbrowser. Solved my problem, saved my day!

    @Carl: Plz add this nasty little tickbox and THANKS FOR ALL YOUR WORK

    Reply

  12. We’re using Okta to create local users, Citrix ADC authenticates the Okta users via RADIUS. Each Okta groups matches up with a different RADIUS server (same ip address, different port). Is there a way to pass group information from Okta so that based on the Okta groups (or the specific RADIUS server), a user is presented with a specific set of bookmarks?

    Reply

    1. I’m not sure about the Okta configuration but if the SAML Assertion or RADIUS Accept message includes groups then NetScaler can use them.

      Reply

      1. Hi Carl,
        Figured out how to do this – in Okta, there are vendor specific attributes that need to be passed to the Citrix ADC for it to work, those same attributes need to be defined for the RADIUS server settings on the ADC Configuration -> System -> Authentication -> Basic Policies -> RADIUS -> select specific radius server -> More -> match Group Vendor Identifier and Group Attribute Type with what is in Okta

        Reply

  13. Hi Carl,
    I wanted to ask you if it was possible to enable 2FA only to some Domino users ( who are in certain AD groups ) leaving simple authentication without passcode for everyone else.
    I saw that in the Radius server settings there is a field called “Default Authentication Group”…
    We use the FortiAuthenticator ( with Token mobile ) which is connected to the LDAP server of the AD domain; in the FortiAuth we define the groups with the LDAP users and I thought that the group I define in that setting ( “Default Authentication Group” ) can match with the one present in the FortiAuth and therefore do the 2FA only to that group of users and leave the simple one to those who do not fall in that group.
    Do you think that can be done?

    Regards

    Fabio

    Reply

    1. Users are placed in the “Default Authentication Group” after successful authentication. You then create a AAA Group with the same name and bind VPN objects to that group.

      If you want different authentication for different users, then configure nFactor. nFactor first asks for user ID. Next factor is the authentication method based on the user’s group membership. https://www.carlstalhood.com/nfactor-authentication-citrix-gateway-13/#samplegroupextract

      Reply

  14. Is it possible to have one Auth(LDAP) on the first page with username and Radius(MFA) on the next page after the successful attempt of LDAP credentials?

    Reply

    1. Yes. nFactor can do that by configuring each factor with separate Login Schemas. The first factor would be singleAuth instead of dualAuth.

      Reply

      1. Understood, Is there any documentation you can refer to me? I don’t want each page to ask for Username again and again, So on the first page I guess single auth should but on the second page I just need the RSA to be called.

        Reply

          1. greetings carl,
            Am currently having an nfactor flow as Anu requested.

            first page : ldap + second page: radius

            I need a way to send a trigger to the radius server from the NS after user finished LDAP auth.

            Currently users need to fetch token from authentication.
            and our radius server does not send an sms OTP unless it recieve a trigger from the application ( netscaler in this case)

            I tried it multiple ways but i think am missing something.
            Thanks for your continuous help

  16. @Carl : What if we have more than 1 radius server for redundancy ?

    Eg. If radius-server-1 fails and we want radius-server-2 to take effect ?
    We can’t create vserver for radius as the monitor creation for radius vserver maybe not feasible.

    Reply

      1. Hello Carl,

        Thanks for reverting.
        Could we apply 2 secondary radius policy for “non citrixreceiver” so that if 1 radius policy.fails. 2nd can take charge.

        As per classic policy will those 2 radius policy bind at secondary work as “AND” or “OR”

        Reply

        1. If you bind multiple authentication policies to the same bind point, then they will be checked in priority order until one of them works.

          Reply

          1. At secondary authentication on Gateway vserver, we have 2 radius policy with binding as “ns_true” (ideally it should have been based on CitrixReveiver header).

            But in this case, will both the policy would be checked ? (they have different priority)

            It is classic policy on- 12.1.60.19
            The problem is if 1 radius failed the one with higher priority (lower value) the MFA failed.

  17. Hi Carl, is it true you need Enterprise or above license to do NFactor? I tried the setup but got a license error at the Logon Schema step.

    Reply

    1. Advanced Edition, yes.

      In Standard Edition, you can get to it through Gateway > Authentication Profile but only standard Login Schemas allowed.

      Reply

  18. Hi Carl,

    Is it possible to use token from Citrix SSO apps (from playstore/appstore) for MFA?
    If yes, how to do that?

    Thanks

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *