Your browser does not support HTML5 local storage or you have disabled it. Some functionality on this site, including saving your privacy settings and offering you special discounts, uses local storage and may not work with local storage disabled. We recommend allowing the use of local storage in your browser. In some browsers, it is the same setting used for disabling cookies.

SSH Tectia

Configuring Extended Admin Authentication

By default the admin users are authenticated using passwords stored internally by the Management Server. To modify the admininistrator authentication settings, select Settings → Admin Authentication. On this page you will see three types of configurable categories as in Figure 3.12.

Administrator authentication settings

Figure 3.12. Administrator authentication settings

LDAP authentication parameters

LDAP authentication parameters such as LDAP server address, search scope etc.

Certificate authentication parameters

Certificate authentication parameters such as trusted CA certificate and certificate to admin account mappings.

Authentication settings

Authentication settings are assigned to users. Each authentication setting specifies what password and certificate authentication parameters to use (or none).

There are two different default authentication settings called Default superuser authentication settings and Default user authentication settings.

When an administrator is logging in, the authentication process will go through the following steps:

  1. If certificate authentication is configured, any TLS client certificate is verified using the certificate parameters. If verification succeeds, the TLS client certificate is displayed in the login screen.

  2. The account is identified by the account name entered in the login screen. If the given account name is not valid, access is denied.

  3. The account's authentication settings are applied as follows:

    1. If the account has password authentication configured, then the password is verified. If verification fails, access is denied.

    2. If the account has certificate authentication configured, then the TLS client certificate is verified using the certificate parameters. If verification fails, access is denied.

    3. If neither password nor certificate authentication is defined, access is denied (for example using None for both password and certificate parameters will deny access).

It is possible to create and edit sets of password and certificate authentication parameters which can in turn be assigned to authentication sets. The management system itself also defines one password authentication source (Internal password database), which cannot be edited or removed by a superuser.

Configuring LDAP Authentication Parameters

SSH Tectia Manager includes a feature allowing an external LDAP server to be used to store and verify admin user passwords. This section details how to set up and use this feature.

There are two separate LDAP authentication modes available: the LDAP search authentication and the LDAP bind authentication.

LDAP Search Authentication Parameters

The authentication module, once configured, can search an LDAP server for password hashes belonging to users whose login name on the Management Server is identical to an entry in the LDAP database. The uid field in the LDAP database is the field that is searched to determine if the account exists. The module can handle the following types of password hashes:

  • Password hashes stored in the authPassword field as specified in RFC 3112. The SHA1 and MD5 schemes are supported.

  • Password hashes stored in the userPassword field as specified in RFC 2307. The SHA, MD5, SSHA, and SMD5 schemes are supported.

Note that plaintext passwords are not supported for security reasons.

As an example, if the fields in the settings section are filled out as follows:

LDAP server hostname: ldap.ssh.fi LDAP server port: 389
Base search dn: cn=tectia,dc=ssh,dc=fi
Scope: sub

When an admin user called admin is authenticating using LDAP, the following URL would be used for the search:

ldap://ldap.ssh.fi:389/cn=tectia,dc=ssh,dc=fi??sub?(uid=admin)

If either a userPassword or authPassword field is found during this search, the password hash from that record is compared against a similarly created hash from the user's password input in the administration interface.

To add a new set of LDAP settings, select Settings → Admin Authentication. Select LDAP authentication parameters and click Add new configuration. Fill out the fields accordingly:

Name (required)

This field allows you to give the configuration set a descriptive name. This is the name seen in the Authentication group drop-down menu when you edit an admin's account.

LDAP server hostname (required)

This field contains the FQDN of the LDAP server you wish to connect to for authentication purposes.

LDAP server port (required)

This is the port on which the LDAP server is listening.

LDAP username (optional)

If your LDAP server requires that you bind as a certain privileged user to be able to query the userPassword or authPassword field, this would be the bind name of that user, for example cn=Manager,dc=domain,dc=com.

LDAP password (optional)

The password for the username specified in the LDAP username field.

Base search DN (required)

This field sets where in the schema the query should start searching.

Scope (required)

The scope of the search - either sub or one. The default is sub.

TLS certificate (optional)

If you wish to use TLS to protect the communications between the Management Server and LDAP server, upload a certificate for that purpose here.

TLS mode (required)

There are three TLS modes - Disable, Try and Require. The default mode is Disable, but it is recommended to use TLS protection for security reasons.

  • Disable causes communications between the Management Server and LDAP server to happen in plaintext.

  • Try will try TLS, but if it is unavailable, will fall back to plaintext.

  • Require will only attempt to use TLS and fail if it is unavailable.

LDAP Bind Authentication Parameters

The LDAP bind authentication module verifies the admin user password by logging in (or binding) to an LDAP directory using the user account itself. The actual password checking is done by the LDAP directory. This has an advantage of account disable and expiration restrictions being checked by the directory.

In the LDAP bind operation the user password will be transmitted to an LDAP directory. It is therefore of utmost importance that the connection to LDAP is properly secured. TLS is recommended for this purpose, but if it cannot be used, other means of lower-level protection must be deployed (such as SecSh tunneling or IPSec).

As in LDAP search authentication, a user account must be created into both SSH Tectia Manager and the LDAP directory. Additionally, in LDAP bind authentication the user has to have an LDAP path that can be constructed using admin user parameters in the Management Database. For example, if SSH Tectia Manager is configured in the following manner:

Bind DN format: CN=${name}, CN=Users, DC=ad-server, DC=ssh, DC=com

and if an admin user account with the real name CSM Test User has been created, SSH Tectia Manager will attempt to bind to the directory using the following username path:

CN=CSM Test User, CN=Users, DC=ad-server, DC=ssh, DC=com

and the user-supplied password. The user object in LDAP has to have enough access rights to perform the bind operation using a password and to read (at least partially) the user object itself.

To add a new set of LDAP bind settings, select Settings → Admin Authentication. Select LDAP bind authentication parameters and click Add new configuration. Fill in the fields accordingly:

Name (required)

This field allows you to give the configuration set a descriptive name. This is the name seen in the Authentication group drop-down list when you edit an admin account.

LDAP server hostname (required)

This field contains the FQDN of the LDAP server you wish to connect to for authentication purposes.

LDAP server port (required)

This is the port on which the LDAP server is listening. Using TLS with LDAPv2 directory probably requires the port to be set to 636 instead of 389.

Base DN format (required)

Format string for admin user object path construction. Can contain variable fields for user information which are substituted when binding to the directory. Supported fields are:

  • ${name}

    Real name of the admin user.

  • ${account}

    Admin user account name.

  • ${email}

    Admin user email address.

For example the following DN format field

CN=${name}, OU=Tectia Manager Administration, O=SSH, C=FI

will result in the bind DN

CN=John Doe, OU=Tectia Manager Administration, O=SSH, C=FI

if the user real name field in the Management Database contains the name John Doe.

Require TLS (required)

If TLS is not required, clear the check box here. Please note that in this case the admin user password will be transmitted to the LDAP server in plaintext. Disable TLS only if another form of authentication and encryption will be used between SSH Tectia Manager and the LDAP directory.

TLS certificate (optional)

If you wish to use TLS to protect the communications between the Management Server and LDAP server, upload a certificate to be used as a trust anchor in LDAP server authentication.

Configuring Certificate Authentication Parameters

New sets of certificate authentication parameters can be created by selecting Certificate authentication parameters and clicking the Add new configuration button.

Certificate authentication parameters consist of the following editable fields:

Name

This field allows you to give certificate authentication parameters a descriptive name. This is the name seen in the Certificate parameters drop-down menu when you edit the Authentication settings.

CA certificate

This is the trusted CA certificate. You can either upload a certificate (if none is defined yet), or delete an existing CA certificate.

Disable CRL checking

This field defines whether CRL checking is disabled when using these parameters. Note that this affects all certificates. For example, if the CA certificate is a top-level certificate, then CRL checking is disabled also from all intermediate CAs.

Mappings

A mapping is required to map a TLS client certificate to an admin account. Certificates themselves provide only authentication, you still have to configure the authorization part which these mappings provide.

Each mapping is of a specific type (see the list below) and matches certain fields in a certificate to map it to an admin account name. The Match field determines the values or patterns to check for. The User field can either be a real admin account name or a substring of the matched certificate field value (for E-mail address match and Subject name match mapping types).

The mappings are ordered, and are evaluated from top to down. The first mapping which matches the certificate determines the admin account name that will be used with the certificate.

There are six possible mapping types, which identify the admin account from the certificate in different ways:

  • E-mail address: Matches the certificate E-mail field to the given e-mail address.

  • Subject name: Matches the certificate Subject name to the given subject name. Note that the subject name has to be given in the X.509 order, for example, "C=FI, O=SSH, CN="Admin", instead of the LDAP order, which is the reverse of the X.509 order.

  • Serial number: Matches the certificate serial number to the given number. Important: This will match the serial number of the certificate without tying it to a particular CA. If you use intermediate CAs, do not use this method.

  • Serial number with given issuer: Matches the certificate serial number and issuer to the given values.

  • E-mail address match: Matches the certificate e-mail address with a given regular expression. The admin account may contain references to the regular expression's sub-matches. For example, the regular expression could be (.*)@some\.company$ and the account name \1 in which case a certificate with the e-mail address joe@some.company would map to admin account joe.

  • Subject name match: Matches the certificate subject name with a given regular expression. The admin account may contain references to the regular expression's sub-matches. For example, the regular expression could be CN=([a-z]+) and the account name \1 in which case a certificate with e-mail address OU=Testing, CN=joe would map to admin account joe.

To add a new mapping, select its type from the drop-down list and click Add. You can edit a mapping by clicking on its Edit button. If you have clicked Edit on a mapping line, you can then also move the line in the list with the Up and Down buttons. To delete a mapping, click Delete.

Configuring Authentication Settings

New authentication settings can be created by selecting Authentication settings and clicking the Add new configuration button.

Each authentication setting has three editable parameters:

Name

This field allows you to give authentication settings a descriptive name. This is the name seen in the Authentication group drop-down menu when you edit an admin account.

Password authentication parameters

This field allows you to select the currently defined password authentication parameters. There are always at least two possible options, None and Internal password database. LDAP authentication parameters can be also selected, if any are defined. See Configuring LDAP Authentication Parameters.

Certificate authentication parameters

This field allows you to select the currently defined certificate authentication parameters or None.

===AUTO_SCHEMA_MARKUP===