LDAP authentication policies

As with other types of authentication policies, a Lightweight Directory Access Protocol (LDAP) authentication policy is comprised of an expression and an action. After creating an authentication policy, you bind it to an authentication virtual server and assign a priority to it. When binding it, you also designate it as either a primary or a secondary policy. In addition to standard authentication functions, LDAP can search other active directory (AD) servers for user accounts for users that do not exist locally. This function is called referral support or referral chasing.

Normally you configure the NetScaler appliance to use the IP address of the authentication server during authentication. With LDAP authentication servers, you can also configure the ADC to use the FQDN of the LDAP server instead of its IP address to authenticate users. Using an FQDN can simplify an otherwise much more complex AAA configuration in environments where the authentication server might be at any of several IP addresses, but always uses a single FQDN. To configure authentication by using a server’s FQDN instead of its IP address, you follow the normal configuration process except when creating the authentication action. When creating the action, you use the serverName parameter instead of the serverIP parameter, and substitute the server’s FQDN for its IP address.

Before you decide whether to configure the ADC to use the IP or the FQDN of your LDAP server to authenticate users, consider that configuring AAA to authenticate to an FQDN instead of an IP address adds an extra step to the authentication process. Each time the ADC authenticates a user, it must resolve the FQDN. If a great many users attempt to authenticate simultaneously, the resulting DNS lookups might slow the authentication process.

LDAP referral support is disabled by default and cannot be enabled globally. It must be explicitly enabled for each LDAP action. You must also make sure that the AD server accepts the same binddn credentials that are used with the referring (GC) server. To enable referral support, you configure an LDAP action to follow referrals, and specify the maximum number of referrals to follow.

If referral support is enabled, and the NetScaler appliance receives an LDAP_REFERRAL response to a request, AAA follows the referral to the active directory (AD) server contained in the referral and performs the update on that server. First, AAA looks up the referral server in DNS, and connects to that server. If the referral policy requires SSL/TLS, it connects via SSL/TLS. It then binds to the new server with the binddn credentials that it used with the previous server, and performs the operation which generated the referral. This feature is transparent to the user.

Note

These instructions assume that you are already familiar with the LDAP protocol and have already configured your chosen LDAP authentication server.

For more information about setting up authentication policies in general, see Authentication Policies. For more information about NetScaler appliance expressions, which are used in the policy rule, see Policies and Expressions.

To enable LDAP referral support by using the command line interface

At the command prompt, type the following commands:

  • set authentication ldapAction <name> -followReferrals ON
  • set authentication ldapAction <name> -maxLDAPReferrals <integer>

Example

> set authentication ldapAction ldapAction-1 -followReferrals ON
> set authentication ldapAction ldapAction-1 -maxLDAPReferrals 2

To enable LDAP referral support by using the configuration utility

Note

In the configuration utility, the term server is used instead of action, but refers to the same task.

  1. Navigate to Security > AAA - Application Traffic > Policies > LDAP.
  2. In the details pane, on the Servers tab, select the LDAP server that you want to configure, and then click Edit.
  3. In the Configure Authentication Server dialog, scroll down to the Referrals check box, and select it.
  4. In the Maximum Referral Level text box, type the maximum number of referrals to allow.
  5. Click OK, and then click Close.

Key-based authentication support for LDAP users

With key-based authentication, you can now fetch the list of public keys that are stored on the user object in LDAP server through SSH. The NetScaler appliance during role-based authentication (RBA) process must extract public SSH keys from the LDAP server. The retrieved public key, which is compatible with SSH, must allow you to log in through RBA method.

A new attribute “sshPublicKey” is introduced in the “add authentication ldapAction” and “set authentication ldapAction” commands. By using this attribute, you can obtain the following benefits:

  • Can store the retrieved public key, and the LDAP action uses this attribute to retrieve SSH key information from LDAP server.
  • Can extract attribute names of up to 24 KB.

Note

The external authentication server, such as LDAP is used only to retrieve SSH key information. It is not used for authentication purpose.

Following is an example of the flow of events through SSH:

  • SSH daemon sends an AAA_AUTHENTICATE request with password field empty to AAA daemon port.
  • If LDAP is configured to store the SSH public key, AAA responds with “sshPublicKey” attribute along with other attributes.
  • SSH daemon verifies these keys with the client keys.
  • SSH daemon passes user name in the request payload, and AAA returns the keys specific to this user along with generic keys.

To configure the sshPublicKey attribute, at the command prompt type the following commands:

  • With add operation, you can add “sshPublicKey” attribute while configuring ldapAction command.

    add authentication ldapAction <name> {-serverIP <ip_addr|ipv6_addr|*> | {-serverName <string>}} [-serverPort <port>] … [-Attribute1 <string>] … [-Attribute16 <string>][-sshPublicKey <string>][-authentication off]

  • With set operation, you can configure “sshPublicKey” attribute to an already added ldapAction command.

    set authentication ldapAction <name> [-sshPublicKey <string>][-authentication off]