Console Resource

There are three different kinds of consoles, which the administrator or user can use to interact with the Director. These three kinds of consoles comprise three different security levels.

• The first console type is an anonymous or default console, which has full privileges. There is no console resource necessary for this type since the password is specified in the Director’s resource and consequently such consoles do not have a name as defined on a Name= directive. Typically you would use it only for administrators.

• The second type of console is a “named console” defined within a Console resource in both the Director’s configuration file and in the Console’s configuration file. Both the names and the passwords in these two entries must match much as is the case for Client programs.

  This second type of console has absolutely no privileges except those explicitly specified in the Director’s Console resource. Thus you can have multiple Consoles with different names and passwords, sort of like multiple users, each with different privileges.

  Access privileges to commands and resources are provided by specifying access control lists in the Director’s Console resource. These ACLs are specified by a directive followed by a list of access names. Examples of this are shown below.

• The third type of console is similar to the above mentioned one in that it requires a Console resource definition in both the Director and the Console. In addition, if the console name, provided on the directive, is the same as a Client name, that console is permitted to use the command to change the Address directive in the Director’s client resource to the IP address of the Console. This permits portables or other machines using DHCP (non-fixed IP addresses) to “notify” the Director of their current IP address.

The Console resource is optional and need not be specified.

The following directives are permitted within the Director’s configuration resource:

Name

Name = <name> The name of the console. This name must match the name specified in the Console’s configuration resource (much as is the case with Client definitions).

Password

Password = <password> Specifies the password that must be supplied for a named Bacula Console to be authorized. The same password must appear in the resource of the Console configuration file. For better security, the password is never actually passed across the network but rather is used as a shared secret in a challenge response authentication scheme.

This directive is required.

If you have either /dev/random or bc on your machine, Bacula will generate a random password during the configuration process. When installing from reasonably built packages, the password should be generated during the installation. Otherwise it may be left blank or be set to some static text, in which case you should change it immediately after installation.

The password is plain text. It is not generated through any special process. However, it is preferable for security reasons to choose sufficiently long random text.

Authentication Plugin

AuthenticationPlugin = <plugin-definition> Specifies a plugin to use by the authentication API framework which allows to configure a different set of authentication mechanisms (user credentials verification) using a dedicated Director plugin. This is called BPAM (Bacula Pluggable Authentication Modules). The first plugin available is a LDAP connector that is suitable to work with OpenLDAP or Active Directory. The new framework supports standard user/password and Multi Factor Authentication schemes which are fully driven by external plugins. On the client side, bconsole will perform the needed user interaction to collect required credentials. Bacula will still support all previous authentication schemas including CRAM-MD5 and TLS. It is possible to configure TLS Authentication together with BPAM authentication raising the required security level. BPAM authentication is available for named Console resources only. To use this feature you have to load a dedicated Director plugin from the directory pointed to by the Plugin Directory Director resource configuration. This plugin should be listed in director status command output. Then you should configure the Console resource to use this plugin for authentication with the Authentication Plugin directive together with a named Console configuration in bconsole.conf as described in the Console Configuration chapter.

Console {
    Name = "ldapconsole"
    Password = "xxx"
    Authentication Plugin = "ldap:<parameters>"
}

where parameters are the space separated list of one or more plugin parameters:

• url - LDAP Directory service location, i.e. “url=ldap://10.0.0.1/”

• binddn - DN used to connect to LDAP Directory service to perform required query

• bindpass - DN password used to connect to LDAP Directory service to perform required query

• query - a query performed on LDAP Directory serice to find user for authentication. The query string is composed as <basedn>/<filter>. Where <basedn> is a DN search starting point and <filter> is a standard LDAP search object filter which support dynamic string substitution: %u will be replaced by credential’s username and %p by credential’s password, i.e. query=dc=bacula,dc=com/(cn=%u).

• starttls - instruct BPAM LDAP Plugin to use StartTLS extension if LDAP Directory service will support it and fallback to no TLS if this extension is not available.

• starttlsforce - does the same what starttls but resport error on fallback.

Some actually working configuration examples:

bacula-dir.conf - Console resource configuration for BPAM LDAP Plugin with OpenLDAP authentication example.

Console {
    Name = "bacula_ldap_console"
    Password = "xxx"
    Authentication Plugin = "ldap:url=ldap://ldapsrv/ binddn=cn=root,dc=bacula,dc=com bindpass=secret query=dc=bacula,dc=com/(cn=%u) starttls"
    ...
}

bacula-dir.conf - Console resource configuration for BPAM LDAP Plugin with Active Directory authentication example.

Console {
    Name = "bacula_ad_console"
    Password = "xxx"
    Authentication Plugin = "ldap:url=ldaps://ldapsrv/ binddn=cn=bacula,ou=Users,dc=bacula,dc=com bindpass=secret query=dc=bacula,dc=com/(&(objectCategory=person)(objectClass=user)(sAMAccountName=%u))"
    ...
}

Note

TLS Directives in the Console resource of bacula-dir.conf

Bacula has built-in network encryption code to provide secure network transport. The Bacula TLS encryption applies only to information transmitted across a network, so the data written to Volumes by the Storage daemon is not encrypted by this functionality.

For more information how to enable TLS encryption, click here.

ACLs

The following ACL related directives apply to named consoles as introduced above.

Job Acl

JobACL = <name-list> This directive is used to specify a list of Job resource names that can be accessed by the console. Without this directive, the console cannot access any of the Director’s Job resources. Multiple Job resource names may be specified by separating them with commas, and/or by specifying multiple JobACL directives. For example, the directive may be specified as:

JobACL = kernsave, "Backup client 1", "Backup client 2"
JobACL = "RestoreFiles"

With the above specification, the console can access the Director’s resources for the four jobs named on the JobACL directives, but for no others.

Client ACL

ClientACL = <name-list> This directive is used to specify a list of Client resources that can be accessed by the console.

Restore Client ACL

RestoreClientACL = <name-list> This directive is used to specify a list of Client resource names that can be used by the console to run Restore Jobs on. The ClientACL is not affected by the RestoreClientACL directive.

ClientAcl = bacula-fd # backup and restore
RestoreClientAcl = test-fd # restore only
BackupClientAcl = production-fd # backup only

Backup Client ACL

BackupClientACL = <name-list> This directive is used to specify a list of Client resource names that can be used by the console for backup jobs. The ClientACL is not affected by the BackupClientACL directive.

DirectoryACL

Directory ACL = <name-list> This directive is used to specify a list of directories that can be accessed by a restore session. Without this directive, the console cannot restore any file. Multiple directories names may be specified by separating them with commas, and/or by specifying multiple DirectoryACL directives.

To be able to restore to the source location, the entry “/” should be in the list of allowed directories.

User Id ACL

UserIdACL = <name-list> This directive is used to specify a list of user and group ids that can be accessed from a restore session. Without this directive, the console cannot restore any file. During a restore session, the Director will compute the restore list and will exclude files and directories that cannot be accessed. Bacula uses the LStat catalog field to retrieve mode, uid and gid information for each file and compares them with the UserIdACL elements. If a parent directory doesn’t have a catalog entry, access to this directory will be automatically granted.

UID/GID names are resolved using the Unix function getpwnam() by the Director, whereas the stored values in the catalog will be numerical and unmodified from what is retrieved from the client at backup time. This implies that User UID/GID access control lists are only useful in environments with a common user id assignment.

Windows systems are not compatible with the UserIdACL feature. The use of UserIdACL=*all* is required to restore Windows systems from a restricted Console.

Multiple UID/GID names may be specified by separating them with commas, and/or by specifying multiple UserIdACL directives.

Storage ACL

StorageACL = <name-list> This directive is used to specify a list of Storage resources that can be accessed by the console.

Schedule ACL

ScheduleACL = <name-list> This directive is used to specify a list of Schedule resources that can be accessed by the console.

Pool ACL

PoolACL = <name-list> This directive is used to specify a list of Pool resource names that can be accessed by the console.

FileSet ACL

FileSetACL = <name-list> This directive is used to specify a list of names of FileSet resources that can be accessed by the console.

Catalog ACL

CatalogACL = <name-list> This directive is used to specify a list of Catalog resource names that can be accessed by the console.

Note

Multiple Catalogs are not recommended

Despite this functionality being available, we strongly recommend against using more than one catalog database. Data segregation and access control can be more robustly achieved using pools and possibly devices per separated entity, and setting proper ACLs for access to them.

Command ACL

CommandACL = <name-list> This directive is used to specify a list of console commands that can be executed by the console.

Note

Dot-commands and command completion

Features such as command completion in bconsole or drop-down list population in graphical user interfaces may require more commands to be enabled than expected at first glance. For example, bconsole uses the .help command to find completions for commands, and uses .jobs, .clients and others to provide completions for the respective resource names. Thus, a CommandACL directive with a value list such as CommandAcl = "run","status","restore","list", "estimate",".jobs",".clients",".filesets", ".client", ".help" may be useful.

Where ACL

WhereACL = <string> This directive permits you to specify where a restricted console can restore files to. If this directive is not specified, only the default restore location as defined in the restore job’s configuration is permitted (often /tmp/bacula-restores). If *all* is specified any path the user enters will be accepted (which is not very secure), any other value specified (there may be multiple WhereACL directives) will restrict the user to use that path. For example, on a Unix system, if you specify “/”, restores will be allowed to the original location.

Aside from Director resource names and console command names, the special keyword *all* can be specified in any of the above access control lists. When this keyword is present, any resource or command name (which ever is appropriate) will be accepted. An example configuration file can be found in the Console Configuration section.

Please note the *all* keyword must be used alone in an ACL list. The following definition will be interpreted as a “Glob Pattern” for any FileSet including the “all” string:

FileSetACL = "fs-test*", "*all*"

or

FileSetACL = "fs-test*"
FileSetACL = "*all*"

As of Bacula version 10.2, ACL Resource directives accept wildcard globbing such as *.prod or job.client1.* to ease the configuration.

ClientAcl = "test-*"
JobACL = "job-test-*"
FileSetACL = "fs-test*"

Console Multi-Factor Authentication Plugins

Time-based One-Time Password (TOTP) Authentication Plugin

The TOTP Authentication Plugin is compatible with the RFC 6238. Many smartphone apps are available to store the keys and compute the TOTP code.

Console {
   Name = "totpconsole"
   Password = "xxx"

   Authentication Plugin = "totp:<parameters>"
}

where parameters are the space separated list of one or more plugin parameters:

• keydir The directory where the TOTP keys are stored. /opt/bacula/etc/conf.d/totp by default.

• no_qrcode Do not generate QR code at the first connection. The Bacula administrator must provide the TOTP key to users manually using the btotp command for example.

• sendcommand Use the command specified by sendcommand to send the QRCode as a PNG image to the user.

The working configuration examples:

bacula-dir.conf - Console resource configuration for BPAM TOTP Plugin example.

# In bacula-dir.conf
Console {
  Name = "totpconsole"
  Password = "xxx"

  # New directive
  Authentication Plugin = "totp"
}

# in bconsole.conf
Console {
  Name = totpconsole
  Password = "xxx"              # Same as in bacula-dir.conf/Console
}
Director {
  Name = mydir-dir
  Address = localhost
  Password = notused
}

At the first console connection, if the TLS link is correctly setup (using the shared secret key), the plugin will generate a specific random key for the console and display a QR code in the console output. The user must then scan the QR code with his smartphone using an app such as Google Authenticator or Aegis (Opensource).

Note

The program qrencode (>=4.0) is used to convert the otpauth URL to a QR code. If the program is not installed the QR code can’t be displayed.

The btotp command can be used to manipulate TOTP keys. For example, to generate the QR code in the terminal:

# /opt/bacula/bin/btotp -n totpconsole -q

To generate the otpauth URL in the terminal (can be used to generate a QRcode later) with qrencode:

# /opt/bacula/bin/btotp -n totpconsole -u otpauth://totp/Bacula:totpconsole?secret=OR2TM22...&issuer=Bacula

In this example, the QR code is sent by email to the console owner:

# In bacula-dir.conf
Console {
   Name = "roberto"
   Password = "xxx"

   # New directive
   Authentication Plugin = "totp: sendcommand=\"mpack -s 'Bacula Console Access for %d' -d /opt/bacula/etc/template %a  %c@acme.org\"\""
}

# in bconsole.conf
Console {
  Name = roberto
  Password = "xxx"              # Same as in bacula-dir.conf/Console
}
Director {
  Name = mydir-dir
  Address = localhost
  Password = notused
}

At the first console connection, the plugin will generate a specific random key for the console and send a QR code PNG file via the command configured. In the example, the mail command mpack will send an email with the attachement to the email roberto@acme.org.

Subject: Bacula Console Access for mydirector-dir

Please find the QR Code needed to access the
Bacula director

---image attached---

The following variables can be used in the sendcommand string:

• %a - Path to the QR code png file

• %d - Director name

• %c - Console name

LDAP Authentication Plugin

A LDAP Authentication Plugin that is suitable to connect OpenLDAP or ActiveDirectory connector plugins is available.

Console {
   Name = "ldapconsole"
   Password = "xxx"

   Authentication Plugin = "ldap:<parameters>"
}

where parameters are the space separated list of one or more plugin parameters:

• url - LDAP Directory service location, i.e. “url=ldap://10.0.0.1/”

• binddn - DN used to connect to LDAP Directory service to perform required query

• binidpass - DN password used to connect to LDAP Directory service to perform required query

• query - a query performed on LDAP Directory serice to find user for authentication. The query string is composed as <basedn>/<filter>. Where ‘<basedn> is a DN search starting point and <filter> is a standard LDAP search object filter which support dynamic string substitution: %u will be replaced by credential’s username and %p by credential’s password, i.e. query=dc=bacula,dc=com/(cn=%u).

• starttls - instruct BPAM LDAP Plugin to use StartTLS extension if LDAP Directory service will support it and follback to no TLS if this extension is not available.

• starttlsforce - does the same what ‘starttls‘ but resport error on fallback.

The working configuration examples:

bacula-dir.conf - Console resource configuration for BPAM LDAP Plugin with OpenLDAP authentication example.

Console {
  Name = "bacula_ldap_console"
  Password = "xxx"
  # New directive (on a single line)
  Authentication Plugin = "ldap:url=ldap://ldapsrv/    binddn=cn=root,dc=bacula,dc=com bindpass=secret query=dc=bacula,dc=com(cn=%u) starttls"
  ...
 }

bacula-dir.conf - Console resource configuration for BPAM LDAP Plugin with Active Directory authentication example.

Console {
  Name = "bacula_ad_console"
  Password = "xxx"

  # New directive (on a single line)
  uthentication Plugin = "ldap:url=ldaps://ldapsrv/ binddn=cn=bacula,ou=Users,dc=bacula,dc=com bindpass=secret query=dc=bacula,dc=com/(&(objectCategory=person)(objectClass=user)(sAMAccountName=%u))"
  ...
 }

See also

Go back to:

• Director Resource

• Job Resource

• JobDefs Resource

• Schedule Resource

• FileSet Resource

• Client Resource

• Storage Resource

• Pool Resource

• Catalog Resource

• Messages Resource

Go to:

• Counter Resource

• Statistics Resource

Go back to the Director Resource Types page.

Go back to the Technical Reference for Director.