Add multiple Basic Authentication LDAP policies/servers to Gateway or LB VIP

The best way to add additional LDAP servers for authentication is to add another LDAP Authentication Policy which is associated with another LDAP server and then bind that new policy to your Gateway or LB VIP.

This article only works with Basic Authentication with LDAP but if you have an Authentication Profile on Gateway the process below will not work.

For Basic Authentication Policies with LDAP:

Log into the Netscaler GUI.

Click on “Citrix Gateway” (or Traffic Management -> Load Balancing) -> Virtual Server -> select your virtual server where you wish to add more LDAP servers.

Under “Basic Authentication” click on the LDAP Policy (If no policy exists you will create one here). Select the policy and click “Edit Server”. Make sure to copy the settings so that they are the same on the second LDAP server/policy you are about to create. Click Close.

For the existing Policy, write down the Priority value. You will want this to be the same for the new LDAP servers unless you specifically want a lower priority.

Select “Add Binding”. Change the Priority to match the one you just wrote down. Then click “Add” next to “Select Policy”

Create a Name for the policy. Make the Expression in the lower box: NS_TRUE

Click on “Add” next to Server selection box. Add all the server details for the second LDAP server. They should all be the same except for the IP address of the new server. Click on “Create”.

Click “Create” on the LDAP Policy page to create the policy with the new server.

Click on “Bind” to bind the policy with the set priority.

Now you should see two LDAP policies with the same priority and different policy names.

Next to Select Policy press the “Add” button and on the next screen click “Add’ to create a new LDAP policy.

PLEASE NOTE: These LDAP policies will NOT Round Robin. The first LDAP server will always be used unless it cannot authenticate, it goes down, or is otherwise unavailable. Only then will the second LDAP server be used.


  • No Related Posts

How to Configure NetScaler Gateway to use RADIUS and LDAP Authentication with Mobile/Tablet Devices

  • On the Secondary Authentication Policies, add the LDAP_Mobile policy as top priority, followed by the RSA_NonMobile policy as secondary priority:

    User-added image

    Important! The session policy must have the correct Single Sign-on Credential Index, that is, it must be the LDAP credentials. For mobile devices, Credential Index under Session Profile > Client Experience should be set to Secondary which is LDAP.

    Therefore you need two session policies, one for mobile devices and the other for non-mobile devices.

    For mobile devices session policy and session profile will look as shown in the following screenshot.

    To create session policy, navigate to required virtual server and, click Edit, go to policy section and click + sign:

    User-added image

    User-added image

    Choose Session option from the drop-down.

    User-added image

    Enter the desired Session Policy name and click + to create a new profile. For mobile devices, Credential Index under Session Profile > Client Experience should be set to Secondary which is LDAP.

    User-added image

    User-added image

    User-added image

    For non-mobile device follow the same steps. Credential Index under Session Profile > Client Experience should be set to Primary which is LDAP.

    The expression should be changed to:

    REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver

    User-added image

    To create new profile for non-mobile user,click + sign.

    User-added image

    User-added image

  • Related:

    NOC Engineer

    I need a solution

    Hi everyone

    I’m beginning to discover the benefits of using Symantec VIP in our infrastructure and I’m very please until now.
    We have a AD groups and a user store LDAP that authenticate the users by username – password + TOKEN ( VIP access )
    Everything works very well.
    But now the Client send me a new goal
    We have some users that does not belong to the company and sometimes we need to create an AD user with username and password to these users.
    If I create a user in VIP Gateway – public service – and configure a PIN, can I use these users in the VPN authentication, without a username AD?
    We have the Firewall point to our VIP server in the local network, that is also connected to one DC by LDAP.
    The issue is how can I create a new user store that only check the local users I create in the Cloud VIP Gateway, wend i try to create a new, only LDAP is permitted.

    Is this possible – create users in VIP with pin and credential and make the VIP server authenticate these users?

    Thanks in advance!



    • No Related Posts

    How to Use sAMAccountName and userPrincipalName at Same Time for User Logon with Active Directory

    Make two LDAP server profiles pointing to the same LDAP server IP. All the values should be same in the configuration except one. The Server logon name attribute is different for both the profiles. One has ‘sAMAccountName’ and the other one will be ‘userPrincipalName’.

    Now when the user tries to login with ‘domainusername’, they will be authenticated by the LDAP profile using ‘sAMAccountName’. And when they uses their email id, they will be allowed by the other LDAP profile.

    To know how to create and bind LDAP authentication profiles please follow the instructions of this article:


    How to Enable the Change Password Option For NetScaler Gateway Users

    Changing a NetScaler Gateway user’s password can be either forced or user initiated. To force a change, use the procedure for changing the password of an AAA-TM user, as described in the article at CTX201133 – How to Change Password for LDAP Authentication for NetScaler Gateway and AAA-TM Users.

    If you enable user-initiated password change, the Change Password option appears in the top-right corner of the portal page after a user logs on.

    Use case

    NetScaler Gateway users would like to the option to change their own passwords, without any dependency on the admins.


    Before giving users the option to change their passwords, make sure that:

    Before giving users the option to change their passwords, make sure that:

    • The basic Active Directory authentication is configured. See CTX108876 – How to Configure LDAP Authentication on a NetScaler Appliance.

      User-added image

    • Access to LDAP and Active Directory uses SSL (port 636).

      User-added image

    • A NetScaler Gateway virtual server is configured and bound to the LDAP policy.

      User-added image

    • You understand the Active Directory and LDAP protocols.

      User-added image


    RecoverPoint: LDAP group user cannot login to RP GUI

    Article Number: 491768 Article Version: 3 Article Type: Break Fix


    Impact on customer:

    when LDAP server is configured and used with groups, user may not be able to login the classic GUI and RP plugin if the LDAP server has high latency >30s.

    Impacted configuration:

    all configurations when using slow LDAP server.

    Impact on RP:

    LDAP group authentication queries the LDAP server too often. If the LDAP server is slow enough login may fail.

    management LDAP cache is not being used for groups, causing each authentication request to be authenticated against the LDAP server and take about 2 minutes.

    In addition, the classic GUI sends requests for authentication every 7 seconds, causing FAPI queue to be full with authentication requests that takes 2 minutes to complete.

    Workaround: this workaround may not help if the LDAP is too slow:

    1. Configure LDAP users instead of groups

    2. Change the LDAP cache reset interval to 10 minutes:t_resetLdapCacheInterval = 600000000

    Fixed at: HF based on, 5.0 ,( is a candidate)

    Affected versions: 4.0.x, 4.1.x, 4.2.x, 4.3.x, 4.4.x


    7018092: Active Directory Password Checkout – LDAP modify failed, error 53 (Server is unwilling to perform)

    This document (7018092) is provided subject to the disclaimer at the end of this document.


    NetIQ Privileged Account Manager

    Microsoft Active Directory LDAP


    Unable to check-in password with Microsoft Active Directory (AD) LDAP

    Password Checkout for Active Directory Application over LDAP is not working

    Using the checked-out password reports invalid credentials, account name / password

    MyAccess reports Failed Check-in to user

    The following appears in the Debug unifid.log when attempting check-in:

    Warning, LDAP modify failed, error 53 (Server is unwilling to perform)

    Error, LDAP modify failed – 182553


    Microsoft Active Directory (AD) may have requirements that are preventing the password change from taking place. This error means the destination LDAP server is not allowing this password change to go through. While there might several reasons for this error to be returned from the LDAP server, here are some common Microsoft Active Directory explanations / requirements:

    1. Microsoft AD may impose some strength requirements on the password. In order to conform to these requirements, a password policy must be created and assigned to the application account domain in the Enterprise Credential Vault. For more details about this process, please refer to documentation:
  • Microsoft AD may only accept password changes over secure connections (SSL, ldap port 636). Verify the Active Directory Application Account Domain in the Enterprise Credential Vault has been configured to have SSL enabled and to use the correct port.

    Note: By default, LDAPS://connections use port 636 for SSL.

  • Microsoft AD requires that the client must bind as a user with sufficient permissions to modify another user’s password. In this case, the proxy credential provided to PAM in the AD LDAP Account Domain of the Enterprise Credential Vault must have sufficient permissions to modify another user’s password. According to Microsoft, “the password is stored in the AD and LDS database on a user object in the unicodePwd attribute.”

  • Cause

    Microsoft Active Directory (AD) is denying the LDAP modify request because the request violates certain requirements / criteria determined by the Microsoft AD Domain Controller.

    Additional Information

    For more information from Microsoft on these certain restrictions, please refer to How to change a Windows Active Directory and LDS user password through LDAP.


    This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.


    7017729: SSPR Error 5081 – No profile is assigned for this operation

    First, make sureyour configuration is unlocked. To do this, go to your SSPRConfiguration.xmland set configIsEditable to True. See TID 7014954 – SSPR Configuration Manager is not available for details on this.

    Once you’ve donethis, go into the Configuration Editor. Use the following steps to”refresh” the policies you’ve set.

    • Go to Policies > Challenge Policies > Select your Policy profile (“default” is the default policy, if that is what you are using).
    • Take note of your current LDAP filter settings. You’ll need to put them back in later.
    • Click the red “x” to remove the LDAP filter.
    • Repeat steps 2 & 3 for Policies > Password Policies > Your Policy Profile.
    • Save your configuration. This will restart the SSPR service.
    • Logout of SSPR – You should still see the “Warning” on the right, showing you don’t have a profile set.
    • Go back into the Configuration Editor.
    • For the Challenge Policy, add the LDAP filter back in.
    • Do the same for the Password Policy.
    • Save your settings again.

    At this point, theerror should be corrected. The policies are now being correctly recognized. Ifthey are not, then make sure you entered your LDAP Filter search parameterscorrectly. Click “View Matches” (back on the Policy profile’ssettings) to make sure that it’s finding users as it should.

    Remember to lockyour configuration again, and switch configIsEditable to False instead of True.

    Other Possible Resolutions.

    I. This error has been seen when the user does have a matching password policy, or if there is not a default password policy for SSPR. If the above suggestions do not work and you do not have a default password policy in SSPR, try configuring a new password policy called default with all default settings and see if the error goes away then.

    II. The error has been seen if you have an invalid search filter specified in the Password Policy Profile Match.

    1. To fix the issue, you need to unlock the configuration through the appliance admin console (https://serveripaddress:9443), under Administrative commands, Unlock Configuration.
    2. Then go into configuration Editor and change the Password Policy Profile Match to objectclass=* (default) https://IPAddressOfServer/sspr/private/config/ConfigEditor
    3. Under Policies ⇨ Password Policies ⇨ default -> Password Policy Profile Match, under the LDAP Search Filter change objectclass=cn to objectclass=*, then save the configuration and test.
    4. Once it is verified working go back into the Appliance admin console or Configuration Manager and lock the configuration.


    • No Related Posts

    Re: Networker 9.1 AuthC error

    I am trying to configure the new Authc authentication for a Networker 9.1 env. The AD (LDAP) configuration part succeeds ,whereas the nsrlogin test fails every time, I try authenticating with an appropriate user ID and password of the configured LDAP domain. It says..

    130136:nsrlogin: Please enter password:

    117849:nsrlogin: Authentication library error: Unauthorized access: The username or password is incorrect

    All necessary supporting packages were installed prior to the config. both the user name and the password combination is also correct.

    nsr auth c version

    Any help in this is much appreciated.