Configuration Parameters

Top  Previous  Next

The component uses configuration parameters which are specified in the [LookupD] section of the integrated configuration file of Dr.Web for UNIX Mail Servers.

The section contains the following parameters:

LogLevel

{logging level}

Logging level of the component.

If the parameter value is not specified, the DefaultLogLevel parameter value from the [Root] section is used.

Default value: Notice

Log

{log type}

Logging method

ExePath

{path to file}

Path to the executable file of the component.

Default value: <opt_dir>/bin/drweb-lookupd

For Linux, Solaris: /opt/drweb.com/bin/drweb-lookupd

For FreeBSD: /usr/local/libexec/drweb.com/bin/drweb-lookupd

RunAsUser

{UID | user name}

The parameter determines under which user name the component should be run. The user name can be specified either as the user’s number UID or as the user’s login. If the user name consists of numbers (i.e. similar to number UID), it is specified with the “name:” prefix, for example: RunAsUser = name:123456.

When a user name is not specified, the component operation terminates with an error after the startup.

Default value: drweb

IdleTimeLimit

{time interval}

Maximum time that the component can remain idle. If the specified value is exceeded, the component shuts down.

Minimum value—10s.

Default value: 30s

DebugLibldap

{Boolean}

Indicates whether debug messages of the libldap library are also included into the log file on the debug level (i.e. when LogLevel = DEBUG).

Default value: No

LdapCheckCertificate

{No | Allow | Try | Yes}

The mode of certificate verification for LDAP connections via SSL/TLS.

Allowed values:

No—do not request the server’s certificate;

Allow—request the server’s certificate. If the certificate is not provided, the session will continue in its normal way. If the server’s certificate is provided but cannot be checked (it is impossible to find the corresponding root certificate), the certificate will be ignored and the session keeps running in its normal way.

Try—request the server’s certificate. If the certificate is not provided, the will continue in its normal way. If the server’s certificate is provided but cannot be checked (it is impossible to find the corresponding root certificate), the session will be terminated.

Yes—request the server’s certificate. If the certificate is not provided or cannot be checked (it is impossible to find the corresponding root certificate), the session is terminated.

For LDAP data sources this certificate verification mode influences the way the URL is processed when the ldaps:// scheme or the StartTLS extension is used; and for AD data sources it will influence connections to the server, if UseSSL=Yes has been specified in the corresponding section (see below).

Default value: Yes

LdapCertificatePath

{path to file}

Path to the SSL certificate used for connection to the LDAP servers (Active Directiory) via a secure SSL/TLS connection.

Please note that the certificate file and the private key file (which is specified by a parameter described below) must form a matching pair.

Default value: (not specified)

LdapKeyPath

{path to file}

Path to the private key used for connection to the LDAP servers (Active Directiory) via a secure SSL/TLS connection.

Please note that the certificate file and the private key file (which is specified by the mentioned parameter) must form a matching pair.

Default value: (not specified)

LdapCaPath

{path}

Path to the directory or file with system list of trusted root certificates which are trusted for sharing data through the LDAP protocol via SSL/TLS.

Path to the list of trusted certificates. The path depends on your GNU/Linux distribution:

For Astra Linux, Debian, Linux Mint, SUSE Linux and Ubuntu, usually it is a path /etc/ssl/certs/;

For CentOS and Fedora—a path /etc/pki/tls/certs/ca-bundle.crt.

For other distributions a path can be defined through results of execution of the command openssl version -d.

If a command is unavailable or an OS distribution could not be identified , the value /etc/ssl/certs/ is used.

Data Source Sections

In addition to the general section [LookupD], the configuration file should also contain individual sections that describe connections to the LDAP and Active Directory servers that you use (one section for each connection). These sections are named using the following scheme: [LookupD.<type>.<name>], where

<type>—is the connection type: LDAP (for LDAP) or AD (for Active Directory).

<name>—is a unique identifier (tag) for the connection, by which the connection can be referred to from the rules.

For example: [LookupD.LDAP.auth1]. The set of parameters that are included inside the section of a data source depends on the type of connection. There is no restriction on the number of data source sections.

1. Parameters used in sections of LDAP type

Url

{string}

URL that defines the used LDAP server and extracted data. According to RFC 4516, URL is built on the basis of the following scheme:

<scheme>://<host>[:<port>]/<dn>[?<attrs>[?<scope>[?<filter>[?<extensions>]]]]

Where:

<scheme>—method of connection to the server (the following schemes are allowed: ldap, ldaps and ldapi);

<host>[:<port>]—LDAP server address that receives a request;

<dn>—distinguished name of an object. Information on this object has been sent;

<attrs>—names of the record attributes, the values of which must be received in the request;

<scope>—search scope (base, one, sub);

<filter>—filtering condition for values of extracted attributes.

<extensions>—list of LDAP extensions used in the request.

Features:

In the list of attributes <attrs>, it is possible to use special characters of choice '*', '+' and '1.1'.

The following automatically resolved placeholders can be used in the <dn> and <filter> parts of the URL:

$u is automatically replaced with the user name, sent by the client component.

$d is automatically replaced with the domain, sent by the client component.

$D—chain <subdomain>.<domain>, modified into dc=<subdomain>,dc=<domain>.

$$—an '$' character.

If the condition <filter> requires usage of special characters (for example: '*', '(', ')', '\', character with code 0) as usual ones, they should be written as \XX. Besides, special characters in URL LDAP are encoded using sequences %XX. For example, when using URL according to the scheme ldapi of the character '/' as a part of the path to the local LDAP server socket, this character is encoded as %2f.

As allowed extensions in <extensions>, only StartTLS and 1.3.6.1.4.1.1466.20037 are supported, they include usage of the TLS mechanism (i.e. establishment of the protected connection with the LDAP server, even if it does not explicitly indicate usage of the protected scheme ldaps) If the name of the used extension is preceded by the character '!', then usage of TLS is required, i.e. in case the establishment of the secure connection is impossible, the request will not be handled. Otherwise, the request will be handled even if the secure connection is not established.

Indicated extensions could not be used with the protected ldaps scheme. For more information refer to RFC 4516 or man ldap_search_ext_s.

Examples:

"ldaps://ds.example.com:990/$D?givenName,sn,cn?sub?(uid=$u)"
"ldap://ldap.local/o=org,dc=nodomain?ipNetworkNumber?sub?(objectClass=ipNetwork)?!StartTLS"

Default value: (not specified)

BindDn

{string}

An object in the LDAP directory to which the user is bound to get authorization.

Example: "cn=admin,dc=nodomain"

Default value: (not specified)

BindPassword

{string}

The user’s password for authentication on the LDAP server

Default value: (not specified)

ChaseReferrals

{Boolean}

Instructs the component to follow references to other LDAP servers, if the current LDAP server returns them as a reply to the request.

Default value: No

2. Parameters used in sections of AD type

Host

{string}

The domain name (FQDN) or the IP address of the host on which the server of the Active Directory service that you would like to connect to is running.

Example: "win2012.win.local"

Default value: (not specified)

Port

{integer}

Port on the host which is listened to by the server of the Active Directory service.

Default value: 389

Dn

{string}

DN of an object in the Active Directory; it is similar to the dn part of an LDAP URL.

Example: "dc=win,dc=local"

Default value: (not specified)

User

{string}

The full identifier of a user on the server, to be used for identification.

Example: "Administrator@WIN.LOCAL"

Default value: (not specified)

Password

{string}

Password of the user for authentication on the Active Directory server.

Default value: (not specified)

ChaseReferrals

{Boolean}

Instructs the component to follow references to other LDAP servers, if the current Active Directory server returns them as a reply to the request.

Default value: No

UseSSL

{Boolean}

Instructs to use SSL/TLS for connecting to the Active Directory.

Default value: No

Adding sections for new data sources

To add a new section for a new data source of a supported type with a <name> tag with the help of the Dr.Web Ctl command-line-based management tool for Dr.Web for UNIX Mail Servers (accessed via the drweb-ctl command), it is necessary to use the following command:

# drweb-ctl cfset LookupD.<type> -a <name>

Example:

# drweb-ctl cfset LookupD.AD -a WinAD1
# drweb-ctl cfset LookupD.AD.WinAD1.Host 192.168.0.20

The first command will add a section named [LookupD.AD.WinAD1] into the configuration file, and the second command will modify the value of the Host parameter within this section.

Alternatively, you can write the new section directly into the configuration file, for example, by adding it to the end of the file.

[LookupD.AD.WinAD1]
Host = 192.168.0.20

Both ways have an equal effect but if you edit the configuration file, you will also need to apply the changed settings by sending a SIGHUP signal to the drweb-configd component (to do that, you can issue the drweb-ctl reload command).