15.3.1.1. Configuring backends

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

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

The zas_db backend

Figure 15.7. The zas_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: By clicking on ... next to the Hosts entry host related information can be specified.

    The host configuration window

    Figure 15.8. The host configuration window

    • LDAP connections: It is the list of LDAP servers. To set the order of servers, use the arrow buttons below the list.

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

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

      • Use TLS: Enable TLS encryption to secure the communication between ZAS and the backend.

    • Algorithm: ZAS attempts to connect to the next host in the ordered LDAP connections list based on the selected algorithm.

    • Connection timeout is: Specifies connection timeout to be used when connecting to the target server.

    • Keep availability state for: ZAS does not try to connect to an unreachable server until the time set in milliseconds in the Keep availability state for option expires.

    • 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 indicates that the incoming username is a fully qualified DN.

    • Follow referrals: If this option is set, ZAS 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 Zorp and ZAS is secured (see Section 15.3.2, Authentication of Zorp services with ZAS 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 ZAS and Zorp 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:

      • The CA issuing the client certificates. This can be an internal CA group (managed by the Zorp PKI, see Chapter 11, Key and certificate management in Zorp 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 ZAA connections: This option is available only in Zorp 3.4 or later. By default, ZAS accepts connections only from Zorp Authentication Agents (ZAA). Disable this option if a different client is used to authenticate on ZAS, 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.9. The htpass backend

The Pluggable authentication module (PAM) backend

The PAM backend implements authentication based on the local authentication settings of the host running ZAS. It basically authenticates the users against the local PAM installation and/or using GSSAPI/Kerberos5.

The PAM backend

Figure 15.10. 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 ZAS.

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

The RADIUS backend

Figure 15.11. The RADIUS backend