15.3.1.1. Configuring backends

AS instances using specific database backends can be configured in the Instances section of the Authentication Server 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

The AS_db backend authenticates users against an LDAP database using the Microsoft Active Directory, the POSIX, or the Novell eDirectory/NDS scheme.

The AS_db backend

Figure 15.7. The AS_db backend

The backend has the following settings:

  • Fake user: 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.

  • LDAP connection settings

    • Host: It is the IP address of the LDAP server.

    • Port: It is the port number of the LDAP server.

    • Use SSL: Enable SSL encryption to secure the communication between AS and the backend.

    • Bind DN: Bind to this DN before accessing the database.

    • Set Bind password: It shall be the password to use when binding to LDAP.

  • LDAP search settings:

    • Base DN: Perform queries using this DN as base.

    • Filter: Search for accounts using this filter expression.

    • Scope: It specifies the scope of the search. base, sub, and one are acceptable values, specifying LDAP_SCOPE_BASE, LDAP_SCOPE_SUB, and LDAP_SCOPE_ONE, respectively.

    • Username is a DN: it Indicate that the incoming username is a fully qualified DN.

    • Follow referrals: If this option is set, AS will respect the referral response from the LDAP server when looking up a user.

    • Scheme: Specify LDAP scheme to use: Active Directory, POSIX, or NDS style directory layout.

      Note

      Make sure to set Scheme to Active Directory when using a Microsoft Active Directory server as a database backend.

  • Authentication methods: Select and configure the allowed authentication methods.

    • Password: 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).

    • S/Key: It is the S/Key-based authentication.

    • CryptoCard RB1: It defines cryptoCard RB1 hardware token based authentication.

    • LDAP Bind: 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.

    • GSSAPI/Kerberos5: It defines GSSAPI-based authentication. The Principal name representing this authentication service also has to be set.

    • x.509: 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:// or ldap:// URLs.

      • Compare to stored certificate: 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 trust: 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 Compare to stored certificate, so if both parameters are set, both conditions must be fulfilled to accept the certificate.

      • Verify depth: The maximum length of the verification chain.

      • Offer trusted CA list: Send a list of trusted certificates to the client to choose from to narrow the list of available certificates.

      • Accept only AA connections: 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 htpass backend

The htpass 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 Filename textbox. Authentication faking can be enabled by selecting the Fake user checkbox.

The htpass backend

Figure 15.8. The htpass backend

The Pluggable authentication module (PAM) backend

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

Figure 15.9. The PAM backend

The PAM backend has the following parameters:

  • Enable PAM authentication: Enable PAM authentication. For PAM authentication the PAM service used for authentication has to be specified.

  • GSSAPI/Kerberos5: Enable GSSAPI based authentication. The Principal name representing this authentication service also has to be set.

  • Use local accounts: Use the local passwd/group database to query group membership of a given account.

Authentication faking can be enabled by selecting the Fake user checkbox.

The RADIUS backend

The RADIUS backend has the following parameters:

  • Host: It is the hostname of the RADIUS server.

  • Port: It is the port of the RADIUS server.

  • Secret: It is the shared secret between the authentication server and AS.

Authentication faking can be enabled by selecting the Fake user checkbox.

The RADIUS backend

Figure 15.10. The RADIUS backend