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.
LDAP authentication parameters such as LDAP server address, search scope etc.
Certificate authentication parameters such as trusted CA certificate and certificate to admin account mappings.
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:
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.
The account is identified by the account name entered in the login screen. If the given account name is not valid, access is denied.
The account's authentication settings are applied as follows:
If the account has password authentication configured, then the password is verified. If verification fails, access is denied.
If the account has certificate authentication configured, then the TLS client certificate is verified using the certificate parameters. If verification fails, access is denied.
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.
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.
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:
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.
This field contains the FQDN of the LDAP server you wish to connect to for authentication purposes.
This is the port on which the LDAP server is listening.
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.
The password for the username specified in the LDAP username field.
This field sets where in the schema the query should start searching.
The scope of the search - either sub or one. The default is sub.
If you wish to use TLS to protect the communications between the Management Server and LDAP server, upload a certificate for that purpose here.
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.
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:
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.
This field contains the FQDN of the LDAP server you wish to connect to for authentication purposes.
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.
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.
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.
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.
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:
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.
This is the trusted CA certificate. You can either upload a certificate (if none is defined yet), or delete an existing CA certificate.
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.
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.
New authentication settings can be created by selecting Authentication settings and clicking the Add new configuration button.
Each authentication setting has three editable parameters:
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.
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.
This field allows you to select the currently defined certificate authentication parameters or None.