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 explanation on how to read the directive format:
Name: Contains the linked name of the directive.
Description: Explains what the directive does.
Value: Indicates what type of value to provide (e.g., <type-specification>).
Data Type: Specifies the type of data expected.
Values: Lists specific acceptable values.
Required: If present, indicates that the directive must be set by the user, there is no default value.
Default: If present, indicates that the directive has a predefined value that does not need to be set by the user, cannot be removed.
Comment: Additional important notes.
Example: Shows a usage example.
Console Start of the Console resource. The following directives are permitted within the Director’s configuration resource:
Description: The name of the console.
Value(s):
<name>Data Type: string
Required: Yes
Comment: This name must match the name specified in the Console’s configuration resource (much as is the case with Client definitions).
Description: Specifies the password that must be supplied for a named Bacula Console to be authorized.
Value(s):
<password>Data Type: password
Required: Yes
Comment: 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. If you have either
/dev/randomorbcon 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.
Description: 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.
Value(s):
<plugin-definition>Data Type: string
Comment: 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
statuscommand 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.Example: See the following example:
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))" ... }
Description: This directive is used to specify a list of Job resource names that can be accessed by the console.
Value(s):
<job-list>Data Type: string list
Comment: 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.
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
JobACLdirectives, but for no others.
Description: This directive is used to specify a list of Client resources that can be accessed by the console.
Value(s):
<client-list>Data Type: string list
Description: This directive is used to specify a list of Client resource names that can be used by the console to run Restore Jobs on.
Value(s):
<client-list>Data Type: string list
Comment: The
ClientACLis not affected by theRestoreClientACLdirective.Example: See the following example:
ClientAcl = bacula-fd # backup and restore RestoreClientAcl = test-fd # restore only BackupClientAcl = production-fd # backup only
Description: This directive is used to specify a list of Client resource names that can be used by the console for backup jobs.
Value(s):
<client-list>Data Type: string list
Comment: The
ClientACLis not affected by theBackupClientACLdirective.
Description: This directive is used to specify a list of directories that can be accessed by a restore session.
Value(s):
<directory-list>Data Type: string list
Comment: 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
DirectoryACLdirectives. To be able to restore to the source location, the entry “/” should be in the list of allowed directories.
Description: This directive is used to specify a list of user and group ids that can be accessed from a restore session.
Value(s):
<id-list>Data Type: string list
Comment: 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
UserIdACLfeature. The use ofUserIdACL=*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
UserIdACLdirectives.
Description: This directive is used to specify a list of Storage resources that can be accessed by the console.
Value(s):
<storage-list>Data Type: string list
Description: This directive is used to specify a list of Schedule resources that can be accessed by the console.
Value(s):
<schedule-list>Data Type: string list
Description: This directive is used to specify a list of Pool resource names that can be accessed by the console.
Value(s):
<pool-list>Data Type: string list
Description: This directive is used to specify a list of Pool resource names that can be accessed by the console.
Value(s):
<fileset-list>Data Type: string list
Description: This directive is used to specify a list of Catalog resource names that can be accessed by the console.
Value(s):
<catalog-list>Data Type: string list
Comment: 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.
Description: This directive is used to specify a list of console commands that can be executed by the console.
Value(s):
<command-list>Data Type: string list
Comment: 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
.helpcommand to find completions for commands, and uses.jobs,.clientsand others to provide completions for the respective resource names. Thus, a CommandACL directive with a value list such asCommandAcl = "run","status","restore","list", "estimate",".jobs",".clients",".filesets", ".client", ".help"may be useful.
Description: This directive permits you to specify where a restricted console can restore files to.
Value(s):
<restore-location>Data Type: string list
Comment: 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). Ifallis specified, any path the user enters will be accepted (which is not very secure), any other value specified (there may be multipleWhereACLdirectives) 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
allcan 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.Note the
allkeyword must be used alone in an ACL list.Example: 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
.prodorjob.client1.to ease the configuration.ClientAcl = "test-*" JobACL = "job-test-*" FilesetACL = "fs-test*"
Description: Enable or Disable automatic TLS PSK support.
Value(s):
<yes|no>Data Type: boolean
Default: yes
Comment: TLS PSK is enabled by default between all Bacula components. The Pre-Shared Key used between the programs is the Bacula password. If both TLS Enable and TLS PSK Enable are enabled, the system will use TLS certificates.
Description: Path to PEM encoded Diffie-Hellman parameter file.
Value(s):
<directory>Data Type: string
Comment: If this directive is specified, DH key exchange will be used for the ephemeral keying, allowing for forward secrecy of communications. DH key exchange adds an additional level of security because the key used for encryption/decryption by the server and the client is computed on each end and thus is never passed over the network if Diffie-Hellman key exchange is used. Even if DH key exchange is not used, the encryption/decryption key is always passed encrypted. This directive is only valid within a server context.
To generate the parameter file, you may use openssl:
openssl dhparam -out dh4096.pem -5 4096
Description: When TLS Authenticate is enabled, after doing the CRAM-MD5 authentication, Bacula will also do TLS authentication, then TLS encryption will be turned off, and the rest of the communication between the two Bacula components will be done without encryption. If TLS-PSK is used instead of the regular TLS, the encryption is turned off after the TLS-PSK authentication step.
Value(s):
<yes|no>Data Type: boolean
Comment: If you want to encrypt communications data, use the normal TLS directives but do not turn on TLS Authenticate.
Description: Verify peer certificate. Instructs server to request and verify the client’s X.509 certificate.
Value(s):
<yes|no>Data Type: boolean
Default: yes
Comment: Any client certificate signed by a known-CA will be accepted. Additionally, the client’s X509 certificate Common Name must meet the value of the Address directive. If the TLSAllowedCN configuration option is used, the client’s x509 certificate Common Name must also correspond to one of the CN specified in the TLS Allowed CN directive. This directive is valid only for a server and not in client context. The default is yes.
Description: The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.
Value(s):
<filename>Data Type: string
Description: Enable TLS support.
Value(s):
<yes|no>Data Type: boolean
Comment: If TLS is not enabled, none of the other TLS directives have any effect. In other words, even if you set TLS Require = yes you need to have TLS enabled or TLS will not be used.
Description: Common name attribute of allowed peer certificates.
Value(s):
<certificate-list>Data Type: string list
Comment: This directive is valid for a server and in a client context. If this directive is specified, the peer certificate will be verified against this list. In the case this directive is configured on a server side, the allowed CN list will not be checked if TLS Verify Peer is set to no (TLS Verify Peer is yes by default). This can be used to ensure that only the CN-approved component may connect. This directive may be specified more than once.
Example: In the case this directive is configured in a server side, the allowed CN list will only be checked if TLS Verify Peer = yes (default).
Director { Name = bacula-dir Password = "password" Address = director.example.com # TLS configuration directives TLS Enable = yes TLS Require = yes # if TLS Verify Peer = no, then TLS Allowed CN will not be checked. TLS Verify Peer = yes TLS Allowed CN = director.example.com TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem TLS Key = /opt/bacula/ssl/keys/client1_key.pem }In the case this directive is configured in a client side, the allowed CN list will always be checked.
Client { Name = client1-fd Address = client1.example.com FDPort = 9102 Catalog = MyCatalog Password = "password" ... # TLS configuration directives TLS Enable = yes TLS Require = yes # the Allowed CN will be checked for this client by director # the client's certificate Common Name must match any of # the values of the Allowed CN list TLS Allowed CN = client1.example.com TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem TLS Certificate = /opt/bacula/ssl/certs/director_cert.pem TLS Key = /opt/bacula/ssl/keys/director_key.pem }If the client doesn’t provide a certificate with a Common Name that meets any value in the TLS Allowed CN list, an error message will be issued:
16-Nov 17:30 bacula-dir JobId 0: Fatal error: bnet.c:273 TLS certificate verification failed. Peer certificate did not match a required commonName 16-Nov 17:30 bacula-dir JobId 0: Fatal error: TLS negotiation failed with FD at "192.168.100.2:9102".
Description: Full path to TLS CA certificate directory. In the current implementation, certificates must be stored PEM encoded with OpenSSL-compatible hashes, which is the subject name’s hash and an extension of .0. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer is set to no, and are always required in a client context.
Value(s):
<directory>Data Type: string
Description: Require TLS or TLS-PSK encryption.
Value(s):
<yes|no>Data Type: boolean
Comment: This directive is ignored unless one of TLS Enable or TLS PSK Enable is set to yes. If TLS is not required while TLS or TLS-PSK are enabled, then the Bacula component will connect with other components either with or without TLS or TLS-PSK. If TLS or TLS-PSK is enabled and TLS is required, then the Bacula component will refuse any connection request that does not use TLS.
Description: The full path and filename of a PEM encoded TLS certificate.
Value(s):
<filename>Data Type: string
Comment: It will be used as either a client or server certificate, depending on the connection direction. PEM stands for Privacy Enhanced Mail, but in this context refers to how the certificates are encoded. This format is used because PEM files are base64 encoded and hence ASCII text based rather than binary. They may also contain encrypted information.
Example: This directive is required in a server context, but it may not be specified in a client context if TLS Verify Peer is set to no in the corresponding server context.
Example:
File Daemon configuration file (bacula-fd.conf), resource configuration has TLS Verify Peer=no:
Director { Name = bacula-dir Password = "password" Address = director.example.com # TLS configuration directives TLS Enable = yes TLS Require = yes TLS Verify Peer = no TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem TLS Key = /opt/bacula/ssl/keys/client1_key.pem }
Description: The full path and filename specifying a PEM encoded TLS CA certificate(s).
Value(s):
<filename>Data Type: string
Comment: Multiple certificates are permitted in the file. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer (see above) is set to no, and are always required in a client context.
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.
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/totpby 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
btotpcommand for example.sendcommand Use the command specified by
sendcommandto send the QRCode as a PNG image to the user.
The working configuration examples:
# 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
querybinidpass - DN password used to connect to LDAP Directory service to perform required
queryquery - a query performed on LDAP Directory serice to find user for authentication. The
querystring 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:%uwill be replaced by credential’s username and%pby 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:
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"
...
}
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:
Go to:
Go back to the Director Resource Types page.
Go back to the Technical Reference for Director.