Step 2: Defining the search order of the configured authentication providers

The Blue Cedar Connect Gateway uses a chain of authentication providers to validate user requests. When a client makes an authentication request, the gateway looks at the first appropriate auth-group (which is local) and then at the auth-provider with the lowest search-order within that group.

If the gateway receives a "No such user or resource" result from the auth-provider, it continues to the next auth-provider in the sequence until the gateway receives a definitive "success" or "error" and then returns the result.

If you have more than one authentication provider, assign a search-order number to each provider:

BASH

% set aaa auth-group groupname provider name search-order number

Element

Description

provider name

Name assigned to the authentication provider when defining the authentication provider.

Values:

local (the authentication provider on the gateway)
name of an Active Directory auth-provider
name of an LDAP auth-provider
name of an external web auth-provider for authentication
name of a RADIUS auth-provider
name of an OAuth auth-provider

search-order number

A lower number indicates a higher priority. the gateway searches the authentication provider with the lowest number (highest priority) first. If the user is not found in that authentication provider, the gateway searches the provider with the next search-order number, and so on.

Values: 0–1000

For example, a search order of 5 means the gateway uses the specified auth-provider to validate an authentication request after authentication providers with lower search-order numbers have either succeeded or failed:

BASH

% set aaa auth-group groupname provider externalWebAuth search-order 5

To see operational statistics about the success or failure of an auth-provider:

BASH

% run show status operational context default aaa-operational auth-group-oper

The following code example shows the JSON output from the gateway for the previous command:

BASH

auth-group-oper default {
  provider-status local {
  search-order 1;
  auth-success 5;
  err-no-such-user 6;
  err-access-denied 0;
  }
  provider-status web-auth:webauth {
  search-order 2;
  auth-success 5;
  err-no-such-user 0;
  err-access-denied 1;
  }
  provider-status active-directory:newAD {
  search-order 3;
  auth-success 0;
  err-no-such-user 0;
  err-access-denied 0;
  }

Because each authentication involves network traffic, you should configure each auth-provider in the rough order of expected number of authentications. To ensure that the search-order process succeeds, Blue Cedar recommends the following:

Set local as the first auth-provider that the gateway searches for (search-order 0). If you do not set local as the first auth-provider, the search-order process fails because the gateway always searches the local provider first.
Set an Active Directory server as an auth-provider with a higher search-order value (greater than zero).
Set an LDAP server as an auth-provider with a search-order value greater than zero.
Set a RADIUS server as an auth-provider with a search-order value greater than zero.
Set an OAuth server as an auth-provider with a search-order value greater than zero.
Set an external web server as an auth-provider with a search-order value greater than zero and greater than any other authentication providers.

Note: You are not required to configure a local auth-provider if you are using Active Directory. However, Blue Cedar recommends that you configure a local auth-provider as a backup to AD for authentication. The reason is if the user account for configuring the gateway is in the Active Directory and the AD server cannot be contacted for whatever reason, you cannot login to the gateway to configure or manage it. Having a local user for this purpose gives you a backup option for authentication. Likewise, add a web authentication provider at the end of the search list: if the web authentication provider fails, it does not prevent access to other authentication providers.

Example

The following example is based on the above figure (Active Directory forest and its domains) and the following CLI commands set the search order for four auth-providers (sub2, sub1, region, and servers domains):

BASH

% set aaa auth-group groupname provider sub2 search-order 200 
% set aaa auth-group groupname provider sub1 search-order 300 
% set aaa auth-group groupname provider region search-order 400 
% set aaa auth-group groupname provider servers search-order 500 
% commit

To see the current search order of the authentication providers, use this template:

BASH

> show config configuration context default aaa auth-group groupname  
auth-group groupname {
  login-prompt           "Please enter your login credentials."; 
  dormant-session-timeout 30; 
  reconnect-enable        true;
  max-session-duration    0;
  certificate-enrollment { 
    enabled          true; 
    email-pin        true; 
    scep-server-type ms-ndes-2008; 
    scep-url         http://192.168.50.45/certsrv/mscept/mscep.dll; 
    request-template { 
      challenge-password joeblow; 
      key-type           rsa2048; 
    } 
  } 
  provider local {
    search-order 100; 
  }
  provider sub2 {
    search-order 200; 
  } 
  provider sub1 { 
    search-order 300; 
  } 
  provider region { 
    search-order 400; 
  } 
  provider servers { 
    search-order 500; 
  } 
}

As the example shows, when the gateway receives a username/password, it attempts to login the user first with the "local" authentication provider. If the user is not found, the gateway calls the second authentication provider ("sub2"). If the user login fails again, the gateway calls the third authentication provider ("sub1") and so on.

The end result is that you can inform users to "just use your username," and have them automatically authenticate without needing to know to which regional domain they belong.