AS instances using specific database backends can be configured in the section of the MC component. The existing instances and the type of database they use are displayed in a list; instances can be created, deleted, and modified using the control buttons below the list.
| Note |
|---|
Only unused instances can be deleted; if an instance is used in a router, the router has to be modified or deleted first. |
To create a new instance, complete the following procedure:
The AS_db backend authenticates users against an LDAP database using the Microsoft Active Directory, the POSIX, or the Novell eDirectory/NDS scheme.
The backend has the following settings:
: Enable authentication faking. This requires a valid user account in the LDAP database that is exclusively used for this purpose. The user name of this account has to be set in the corresponding textbox.
Note All backends are capable of authentication faking. This is a method to hide the valid usernames, so that they cannot be guessed (for example using brute-force methods). If somebody tries to authenticate with a non-existing username, the attempt is not immediately rejected: the full authentication process is simulated (for example, password is requested, and so on), and rejected only at the end of the process. That way it is not possible to determine if the username itself was valid or not. It is highly recommended to enable this option.
: It is the IP address of the LDAP server.
: It is the port number of the LDAP server.
: Enable SSL encryption to secure the communication between AS and the backend.
: Bind to this DN before accessing the database.
: It shall be the password to use when binding to LDAP.
:
: Perform queries using this DN as base.
: Search for accounts using this filter expression.
: It specifies the scope of the search.
base,sub, andoneare acceptable values, specifyingLDAP_SCOPE_BASE,LDAP_SCOPE_SUB, andLDAP_SCOPE_ONE, respectively.: it Indicate that the incoming username is a fully qualified DN.
: If this option is set, AS will respect the referral response from the LDAP server when looking up a user.
: Specify LDAP scheme to use:
Active Directory,POSIX, orNDSstyle directory layout.Note Make sure to set
SchemetoActive Directorywhen using a Microsoft Active Directory server as a database backend.
: Select and configure the allowed authentication methods.
: It implements password authentication. Allow password authentication only if the connection between PNS and AS is secured (see Section 15.3.2, Authentication of PNS services with AS for details).
: It is the S/Key-based authentication.
: It defines cryptoCard RB1 hardware token based authentication.
: It is authentication against the target LDAP server. Only password authentication is supported by this method, therefore it is only available if the connection between AS and PNS is secured with SSL.
: It defines GSSAPI-based authentication. The representing this authentication service also has to be set.
: It is authentication based on x.509 certificates. To use this method, a number of further options have to be specified:
It is the CA issuing the client certificates. This can be an internal CA group (managed by the PNS PKI, see Chapter 11, Key and certificate management in PNS for details), or an external one. In the latter case the locations of the trusted CA certificates and the corresponding CRLs have to be set as space-separated lists of
file://orldap://URLs.: Compare the stored certificate bit-by-bit to the certificate supplied by the client. The authentication will fail when the certificates do not match, even if the new certificate is trusted by the CA.
: Verify the validity of the certificate (that is, the certificate has to be issued by one of the trusted CAs and must not be revoked). This verification is independent from the , so if both parameters are set, both conditions must be fulfilled to accept the certificate.
: The maximum length of the verification chain.
: Send a list of trusted certificates to the client to choose from to narrow the list of available certificates.
: By default, AS accepts connections only from Authentication Agents (AA). Disable this option if you are using a different client to authenticate on AS, for example, if a web-browser authenticates using a client-side certificate.
Disabling this option works only with proxies that support inband authentication, for example, HTTP.
The backend authenticates users against an Apache htpasswd style password file. The name (including the path) of the file to be used has to be specified in the textbox. Authentication faking can be enabled by selecting the checkbox.
The PAM backend implements authentication based on the local authentication settings of the host running AS. It basically authenticates the users against the local PAM installation and/or using GSSAPI/Kerberos5.
The PAM backend has the following parameters:
: Enable PAM authentication. For PAM authentication the PAM service used for authentication has to be specified.
: Enable GSSAPI based authentication. The representing this authentication service also has to be set.
: Use the local passwd/group database to query group membership of a given account.
Authentication faking can be enabled by selecting the checkbox.
The RADIUS backend has the following parameters:
: It is the hostname of the RADIUS server.
: It is the port of the RADIUS server.
: It is the shared secret between the authentication server and AS.
Authentication faking can be enabled by selecting the checkbox.
© 2021 BalaSys IT Security.
Send your comments to support@balasys.hu
