NetScaler Gateway 11.1 – LDAP Authentication

Last Modified: Nov 7, 2020 @ 6:34 am


💡 = Recently Updated

LDAP Load Balancing

Before you create an LDAP authentication policy, load balance the Domain Controllers. If you don’t load balance your Domain Controllers, then when users enter an incorrect password, the user account will be prematurely locked out.

If you have multiple domains, create different Load Balancing Virtual Servers for each domain. These multiple Load Balancing Virtual Servers can share the same VIP if their port numbers are different. Or you can use a different VIP for each domain.

LDAP Authentication Server

To create the LDAP Authentication Server, do the following:

  1. On the left, expand Authentication and click Dashboard.
  2. On the right, click Add.
  3. In the Choose Server Type drop-down, select LDAP.
  4. Enter LDAP-Corp as the name. If you have multiple domains, you’ll need a separate LDAP Server per domain so make sure you include the domain name.
  5. Change the selection to Server IP. Enter the VIP of the load balancing vServer for LDAP.
  6. Change the Security Type to SSL.
  7. Enter 636 as the Port. Scroll down.
  8. Note: it’s also possible to point the LDAP Server IP to a Global Catalog. See Citrix CTX200506 How to Change Password through NetScaler in a Multi-Domain Active Directory Forest Using LDAP Referral for configuration details.  💡
  9. In the Connection Settings section, in the Base DN field, enter your Active Directory DNS domain name in LDAP format.
  10. In the Administrator Bind DN field, enter the credentials of the LDAP bind account in userPrincipalName format. Domain\Username also works.
  11. Enter the Administrator password.
  12. Click Test Connection. NetScaler will attempt to login to the LDAP IP. Scroll down.
  13. In the Other Settings section, use the drop-down next to Server Logon Name Attribute, Group Attribute, and Sub Attribute Name to select the default fields for Active Directory.
  14. On the right, check the box next to Allow Password Change.
  15. Note: there is a checkbox for Validate LDAP Server Certificate. If you want to do this, see Citrix Discussions for instructions for loading the root certificate to /nsconfig/truststore.
  16. If you want to restrict access to only members of a specific group, in the Search Filter field, enter memberOf=<GroupDN>. See the example below:
    You can add :1.2.840.113556.1.4.1941: to the query so it searches through nested groups. Without this users will need to be direct members of the filtered group.

    1. An easy way to get the full distinguished name of the group is through Active Directory Administrative Center. Double-click the group object and switch to the Extensions page. On the right, switch to the Attribute Editor tab.
    2. Or in Active Directory Users & Computers, enable Advanced view, browse to the object (don’t use Find), double-click the object, and switch to the Attribute Editor tab.
    3. Scroll down to distinguishedName, double-click it and then copy it to the clipboard.

    4. Back on the NetScaler, in the Search Filter field, type in memberOf= and then paste the Distinguished Name right after the equals sign. Don’t worry about spaces.
  17. Scroll down and click More.
  18. For Nested Group Extraction, if desired, change the selection to Enabled.
  19. Set Group Name Identifier to samAccountName.
  20. Set Group Search Attribute to memberOf. Select << New >> first.
  21. Set Group Search Sub-Attribute to CN. Select << New >> first.
  22. For the Group Search Filter field, see CTX123795 Example of LDAP Nested Group Search Filter Syntax.
  23. Scroll down and click Create.

    add authentication ldapAction Corp-Gateway -serverIP -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn "corp\\ctxsvc" -ldapBindDnPassword Passw0rd -ldapLoginName samaccountname -searchFilter "memberOf=CN=Citrix Remote,CN=Users,DC=corp,DC=local" -groupAttrName memberOf -subAttributeName CN -secType SSL -passwdChange ENABLED
  24. The status of the LDAP Server should be Up.

LDAP Policy Expression

The Authentication Dashboard doesn’t allow you to create the LDAP Policy so you must create it elsewhere.

You can create the LDAP policy now. Or you can wait and create it later when you bind the LDAP Server to the NetScaler Gateway vServer.

To create it now:

  1. Go to NetScaler Gateway > Policies > Authentication > LDAP.
  2. On the right, in the Policies tab, click Add.
  3. Change the Server drop-down to the LDAP Server you created earlier.
  4. Give the LDAP Policy a name (one for each domain).
  5. In the Expression box, enter ns_true.
  6. Click Create.

     add authentication ldapPolicy LDAP-Corp ns_true LDAP-Corp

Gateway Authentication Feedback and Licenses

  1. On the left, under NetScaler Gateway, click Global Settings.
  2. On the right, in the right column, click Change authentication AAA settings.
  3. If you are using Gateway features that require Gateway Universal licenses, then change the Maximum Number of Users to the number of Gateway Universal licenses you have installed on this appliance. This field has a default value of 5, and administrators frequently forget to change it, thus only allowing 5 users to connect.
  4. If desired, check the box for Enable Enhanced Authentication Feedback. This feature provides a message to users if authentication fails. The message users receive include password errors, account disabled or locked, or the user is not found, to name a few. Click OK.

    set aaa parameter -enableEnhancedAuthFeedback YES -maxAAAUsers 200

Next Step

Multiple Domains – UPN Method

To support multiple Active Directory domains on a NetScaler Gateway, you create multiple LDAP authentication policies, one for each Active Directory domain, and bind all of the LDAP policies to the NetScaler Gateway Virtual Server. When the user logs into NetScaler Gateway, only the username and password are entered. The NetScaler will then loop through each of the LDAP policies in priority order until it finds one that contains the entered username/password.

What if the same username is present in multiple domains? As NetScaler loops through the LDAP policies, as soon as it finds one with the specified username, it will try to authenticate with that particular LDAP policy. If the password doesn’t match the user account for the attempted domain then a failed logon attempt will be logged in that domain and NetScaler will try the next domain.

Unfortunately, the only way to enter a realm/domain name during user authentication is to require users to login using userPrincipalNames. To use userPrincipalName, set the LDAP Policy/Server with the Server Logon Name Attribute set to userPrincipalName.

You can even do a combination of policies: some with samAccountName and some with userPrincipalName. The samAccountName policies would be searched in priority order and the userPrincipalName policies can be used to override the search order. Bind the userPrincipalName policies higher (lower priority number) than the samAccountName policies.

NetScaler 11.1 supports adding a domain name drop-down list to the logon page. Then use Cookie expressions in the auth policies and session policies. However, this probably doesn’t work for Receivers. See CTX203873 How to Add Drop-Down Menu with Domain Names on Logon Page for NetScaler Gateway 11.0 64.x and later releases for details.
User-added image

Another option for a domain drop-down is nFactor Authentication for Gateway. This also doesn’t work with Receiver Self-service.

After authentication is complete, a Session Policy will be applied that has the StoreFront URL. The NetScaler Gateway will attempt to log into StoreFront using Single Sign-on so the user doesn’t have to login again. When logging into NetScaler Gateway, only two fields are required: username and password. However, when logging in to StoreFront, a third field is required: domain name. So how does NetScaler specify the domain name while logging in to StoreFront?

There are two methods of specifying the domain:

  • AAA Group – Configure multiple session policies with unique Single Sign-on Domains.  Inside the Session Policy is a field called Single Sign-on Domain for specifying the domain name. If there is only one Active Directory domain, then you can use the same Session Policy for all users. However, if there are multiple domains, then you would need multiple Session Policies, one for each Active Directory domain. But as the NetScaler loops through the LDAP policies during authentication, once a successful LDAP policy is found, you need a method of linking an LDAP policy with a Session Policy that has the corresponding SSO Domain. This is typically done using AAA groups. To use this method, see Multiple Domains – AAA Group Method.
  • userPrincipalName – Alternatively, configure the LDAP policy/server to extract the user’s UPN, and then authenticate to StoreFront using UPN. This is the easiest method but some domains don’t have userPrincipalNames configured correctly.

The userPrincipalName method is detailed below:

  1. In each of your NetScaler LDAP policies/servers, in the Other Settings section, in the SSO Name Attribute field, enter userPrincipalName (select –<< New >>– first). Make sure there are no spaces after this attribute name. NetScaler will use this pull this attribute from AD, and use it to Single Sign-on the user to StoreFront.
  2. In StoreFront Console, right-click  the Store, and click Manage Authentication Methods.
  3. On the right, click the gear icon, and then click Configure Trusted Domains.
  4. In the Trusted domains box, select Any domain.
  5. Or add your domains in DNS format. The advantage of entering domain names is that you can select a default domain if internal users forget to enter a domain name during login. The DNS format is required for UPN logins (e.g. SSO from NetScaler Gateway).
  6. On the NetScaler Gateway Virtual Server, bind LDAP authentication polices in priority order. It will search them in order until it finds a match.
  7. In your Session Policies/Profiles, in the Published Applications tab, make sure Single Sign-on Domain is not configured. Since NetScaler is using the userPrincipalName there’s no need to specify a domain. If Single Sign-on Domain is configured then Single Sign-on authentication will fail.

Multiple Domains – AAA Groups Method

Another method of specifying the domain name when performing Single Sign-on to StoreFront is to use a unique session policy/profile for each domain. Use AAA Groups to distinguish one domain from another.

  1. Go to NetScaler Gateway > Policies > Authentication > LDAP.
  2. On the right, switch to the Servers tab. Make sure all domains are in the list. Edit one of the domains.
  3. Scroll down to the Other Settings section,
  4. In the Default Authentication Group field, enter a new, unique group name. Each domain has a different group name. Click OK.
  5. Edit another domain and specify a new unique group name. Each domain has a different group name.
  6. Go to NetScaler Gateway > User Administration > AAA Groups.
  7. On the right, click Add.
  8. Name the group so it exactly matches the group name you specified in the LDAP server. Click OK.
  9. On the right, in the Advanced Policies section, add the Policies section.
  10. On the left, in the Policies section, click the Plus icon.
  11. Select Session, and click Continue.
  12. Click the plus icon to create a new policy.
  13. Give it a name that indicates the domain. You will have a separate policy for each domain.
  14. Click the plus icon to create a new profile.
  15. Give the Profile a name that indicates the domain. You will have a separate profile for each domain.
  16. Switch to the Published Applications tab.
  17. Check the Override Global box next to Single Sign-on Domain. Enter the domain name that StoreFront is expecting. Click Create.
  18. Give the policy a ns_true expression, and click Create.
  19. In the Priority field, give it a number that is lower than any other Session Policy that has Single Sign-on Domain configured. Click OK.
  20. Click Done.
  21. Create another AAA Group.
  22. Give it a name for the next domain.
  23. Create another Session Policy for the next domain.
  24. Create another profile for the next domain. On the Published Applications tab, specify the domain name of the next domain.
  25. Bind the new policy with a low Priority number.
  26. When a user logs in, NetScaler loops through LDAP policies until one of them works. NetScaler adds the user to the Default Authentication Group specified in the LDAP Server. NetScaler finds a matching AAA Group and applies the Session Policy that has SSON Domain configured. Since the policy is bound with a low priority number, it overrides any other policy that also has SSON Domain configured.

27 thoughts on “NetScaler Gateway 11.1 – LDAP Authentication”

  1. On a VPX without the AAA feature, would you expect the AAA-linked session policies to always hit (regardless of user’s AD group membership)?

    Interestingly, although you can’t enable the AAA feature, the AAA Group and associating session policy menu items do not show as unlicensed.

    Thanks! This site is an amazing resource, I appreciate your efforts.

    1. Citrix Gateway has some AAA functionality built in, but not all of it. AAA Groups are one of the Gateway features.

      There are two different Session Policy/Profiles – one for AAA TM (Traffic Management), and one for Gateway.

  2. Hi Carl, I have a RADIUS Authentication Policy configured in Netscaler with Azure MFA, how can I authenticate users from two different domains?

  3. Hi Carl,

    I want to configure multiple SAMl Authentication for multiple customers , can i configure that in the way for a specific customer to use a specific SAML authontication server ?

    Thank you in advance


    1. I’m not aware of any instructions to configure NetScaler to use the user’s email address to find the iDP. I suspect you can do something in nFactor, where the first factor asks for user name, then the second SAML factor is based on the user’s email suffix.

  4. I worked with several Citrix engineers to solve a problem that this article solved for me. My users were getting presented with a server login screen when they launched apps. I could only get one domain to work at time no matter what I put in the policies. In the end, it was just as simple as creating a AAA group for each of my domains and then setting a corresponding LDAP policy. Thanks Carl this was a great help to me and my organization.

  5. Hi Carl,

    great new Article regarding AAA Groups for multiple Domain Authentication.

    will this be a good way to realize Netscaler Gateway Authentication with multiple Domain Controllers in the Backend where all Domains have there own XenApp Farm with Storefronts in it?

    means, each of the Domains are isolated in there own Subnet from each other.

    the netscaler will have one virtual gateway with all three LDAP Servers as Authentication Servers.

    we create one Session Policies for each Domain where the Published App Tab will have the internal Storefront IP in Place…

    thanks for your help

    1. So you would bind three different LDAP policies to the vServer? Each of these policies would be checked in turn until one of them works.

      Default Authorization group would distinguish one from another when processing session policies.

      1. Good Morning to Kansas!

        “So you would bind three different LDAP policies to the vServer? Each of these policies would be checked in turn until one of them works.”


        “Default Authorization group would distinguish one from another when processing session policies.”

        Yes we have tried this with your new posted Article as Reference and generally the Authentication is working like described.

        The Question is, is that a good working way to bring all the components together,
        means for each Domain / XenApp Farm with there own SF inside (“keep it simple Deployment” will be failed at this moment xD)

        or do you have another way to get that goal?

        1. With a single FQDN, I believe this is the only option. Another method is different Gateway FQDNs for each Domain/farm.

          1. yes with single FQDN, …i think the same. Like i wrote generally the authentication over three LDAP Auth Points and the single Netscaler Gateway (FQDN) works fine,

            but ive the effect that after authentication at the Netscaler Gateway, the user from Domain 3 will be forwarded to the Storefront URL from SF in Domain 1.

            To avoid sources of error if used the Storefront IP Address in the published App Tab from the Session Policy

            for Domain 1 its like “”.

            for Domain 3 its like “”

            there is no LB on the NS configured at this Point to load balance SF.

            i cannot find the entry where NS uses the “/Citrix/Customer1Web” für User from Domain 3.

            do you have an idea?

  6. Hi Carl , I am having difficulties with the Multiple domain setup.I tried using the UPN method with the Domain drop down on the NetScaler but it seems to default on the Storefront to the first domain on the list when passing the authentication from the NetScaler to the Receiver for web .Any recommendations on changing this as the first domain on the list works but as soon as you try the 2nd and 3rd it fails in passing the credentials.

  7. First of all, thanks for all the usefull articles. Has helped me a lot.

    Question about LDAP non-authentication queries.
    On our AAA-Auth Vserver, the primairy authentication is SAML.
    To get the user groups, I have added a secondary authentication containing 2 LDAP non-authentication policies. Using UPN it needs to query 2 different domain LDAP servers for the usergroups.

    I only get this to work for the top policy. The second is never used. No option for expressions to test en point to correct policy.

    Any idea how to solve this ?

    1. I think that once there’s a successful query, then it stops checking the cascade.

      Maybe you can do multiple LDAP group extractions using nFactor.

      1. The strange part is, that when the UPN doesn’t exist on the first domain, then second LDAP server isn’t tried.
        Even a sniffertrace shows LDAP answer saying no match.
        Could this be normal for non-authentication queries ?

  8. Hi Carl,

    Quick question, do we need to bind the AAA Group into the NetScaler Gateway VIP? or does NS automatically goes and checks the AAA Group?
    Also, if we configure the AA Group, do we need to take out the Authentication policies and session policies from the NS GW VIP?

    Thank you!

    1. NetScaler uses LDAP auth policy/server to extract a user’s AD groups. NetScaler then does a case sensitive comparison of the AD group name with the AAA Group name. If match, apply the AAA Group configuration (e.g. Session Policies) combined with vServer configuration based on priority number.

      You definitely need LDAP Auth policies bound to the Gateway vServer.

  9. Great article Carl!

    I am trying to wrap my head around what the “best” method would be for these scenarios. I recently inherited an environment that uses the REQ.HTTP.HEADER Cookie CONTAINS “Domain” method for LDAP and Session Policies.

    It essentially has a single AAA group with 7 session policies to support 7 AD domains. There are 7 LDAP and Radius policies bound to the NS Gateway vServer, but instead of using the Default Authorization Group the LDAP policies use the Cookie Contains “domain” that gets passed when a user selects a domain from the drop-down. This was originally done on NetScaler 10.1 and we have been tasked to redesign it for 11.1.

    Is it worth going through all that just for the drop-down box in your opinion? With the AAA method you describe above would users even need to specify their domain at login? (assume their user name is unique to their domain)

    1. UPN for SSON Attribute is probably the easiest method, assuming UPNs are configured correctly on all user accounts. Then you only need one session policy for all domains since UPN contains the domain name.

      If you can guarantee uniqueness of sAMAccountNames across all domains, then I’m not sure the drop-down is needed. But if you have duplicate sAMAccountNames in multiple domains, and if you need users to be able to specify a domain name, then you can either provide a domain selection mechanism on the logon page (drop-down, domain\) with corresponding cookie, or you can ask users to enter UPN for username. Note: nFactor has an easy method of configuring a domain drop-down.

      If UPN for username, then you don’t need the multiple session policies for each domain since UPN contains the domain name.

      But if SAMAccountName is used for both username and SSON Attribute, then you need some method of informing StoreFront of the user’s domain name, which means a separate session policy for each domain. Citrix used to have a blog post doing something similar and it required a ridiculous number of commands.

      Can a single RADIUS policy handle users from all 7 domains? If not, any problem with NetScaler trying each RADIUS policy until it works?

      1. Thanks Carl. Yes, a single RADIUS policy should be able to handle users from all domains. I just wish there was more clear guidance on how to support these more complex scenarios that are likely very common. This article is a good starting point so Ill try to test different options.

  10. Hi Carl, we try to setup a Double-Hop DMZ scenario but we cant use ldap from the first HOP. Is there a way to authenticate at the second hop? Or if we use Storefront auth (from CTX200066) is there a way to auto discover the domain? Thanks

    1. On fist hop, you can point the LDAP server to a LDAP load balancing VIP on the second NetScaler.

      Not sure what you mean by “auto discover” the domain. Are you thinking of disabling auth on Gateway and making StoreFront do it? If so, you can leave the “Manage Trusted Domains” set to Any and users can enter any domain (trusted).

  11. Is it possible to use Storefront for authentication Netscaler only as ICA proxy? With multiple Active Directories this would be my preferred method. Storefront and Netscaler are placed in the DMZ.

Leave a Reply

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