faaleoleo · June 2026 · Security
One of the most common questions in Bacula Enterprise projects is whether user accounts can be managed through an existing authentication provider — Active Directory, OpenLDAP, Entra ID, or any of the other centralised identity solutions in widespread use. The answer is yes. But not everything that is technically possible is operationally sound, and with backup infrastructure the cost of a wrong architectural decision only becomes visible when you can least afford it.
Centralised identity management is the right call for most enterprise systems. Managing user accounts in one place, enforcing password policy centrally, deprovisioning access automatically when someone leaves — these are solved problems with well-understood tooling. It is entirely natural to want the same for your backup infrastructure.
Bacula Enterprise supports integration with LDAP-based directories, Active Directory, and external identity providers. The technical plumbing exists. What this article is about is the layer of thinking that needs to happen before you connect them.
This is not a rhetorical point. When an incident occurs — a ransomware attack, a catastrophic hardware failure, a misconfigured change that cascades through your infrastructure — your backup system is what stands between the organisation and unrecoverable data loss. Every design decision about your backup infrastructure must be evaluated through that lens: what happens to this component when everything else has already failed?
Most of your other systems can tolerate dependency on your authentication provider. If your email server authenticates against Active Directory and AD goes down, email is unavailable — inconvenient, but recoverable. If your backup system cannot authenticate because its identity provider is unreachable, you cannot restore. The asymmetry matters.
Consider the most common serious incident affecting enterprise environments today: a ransomware attack. The attack pattern in sophisticated campaigns is not to simply encrypt files — it is to maximise disruption before the encryption payload runs. This routinely includes:
If your Bacula environment authenticates operators against Active Directory and your Active Directory is compromised or offline, you arrive at the recovery phase of the incident and find that the people who need to run restores cannot log in to the system that holds the recoverable data. You have a working backup. You cannot access it.
This is not a theoretical edge case. It is a known failure mode in real ransomware incidents, and it is entirely avoidable with the right architecture.
The scenario described above becomes acute when local accounts have been removed in favour of centralised identity management. Centralised identity is convenient — a single place to manage access, consistent policy enforcement, one offboarding step. Over time, the operational habit of maintaining local accounts atrophies. Local accounts start to feel like a maintenance burden and a security risk, so they are removed.
When the authentication provider is offline, those accounts are gone. There is no fallback. The people with the technical knowledge to run a restore are present and willing, but the system they need to access has no way to verify who they are.
The question to ask before you design this dependency into your backup infrastructure is: under what conditions will we need to restore, and under those same conditions, will our authentication provider be available? In a routine restore — a single file recovery, a test — the answer is almost certainly yes. In the incidents where backup access matters most, the answer is far less certain.
Entra ID (formerly Azure Active Directory) introduces a further dimension that on-premises Active Directory does not: your authentication provider is now a cloud service outside your network perimeter.
In a serious on-premises incident — network segmentation, firewall failure, ISP outage, or a deliberate attacker cutting external connectivity — your Entra ID tenant may be perfectly healthy but completely unreachable. The authentication request leaves your network, hits an external endpoint, and never comes back.
There are also compliance dimensions to consider. Regulated organisations in sectors covered by NIS2, DORA, or national equivalents are required to assess and manage supply chain risk — which includes cloud identity providers. If your backup authentication depends on a cloud service, that dependency needs to appear in your risk assessment, your business continuity plan, and your incident response procedures. An auditor reviewing your BC/DR documentation will look for it.
Backup infrastructure typically involves two distinct categories of user access that are often conflated in early architecture discussions:
The risk profile of these two categories is different, and the authentication and access control approach should reflect that.
OS-level accounts on backup infrastructure should be governed by the same principle that applies to any privileged system: minimum permissions necessary to perform the function, nothing more.
Specifically:
These controls apply regardless of whether OS accounts are managed locally or via a directory. If you are using a directory for OS account management, the controls above are in addition to the directory integration, not a substitute for thinking about the local account question.
BWeb, the Bacula Enterprise web management interface, is the highest-exposure surface on most backup deployments — it is the interface where restores are initiated, job configurations are changed, and the backup catalog is visible. It should be treated accordingly.
Two-factor authentication on BWeb access is not an enhancement or a nice-to-have. It is the baseline. An operator account with only a username and password, regardless of how that password is managed, represents an unacceptable risk on infrastructure that holds your organisation's recovery data.
If you are integrating BWeb with an external identity provider, verify that 2FA enforcement is handled at the identity provider level and cannot be bypassed by a direct authentication path. The 2FA requirement must be architectural, not procedural.
None of this argues against using Active Directory, OpenLDAP, Entra ID, or other identity providers with Bacula. These integrations are legitimate and in many environments they are the right approach for application-level access. The argument is about completeness of thinking.
A sound architecture for Bacula authentication includes:
Local emergency accounts that are always available. At minimum one local account on the OS and one local Bacula operator account, stored with credentials managed outside the primary identity provider (offline, in a physical safe, in a secrets manager that does not share the same dependency chain). These accounts exist for one purpose: access when the primary authentication path is unavailable.
Separation of OS and application access. Directory integration for BWeb and bconsole operator accounts is reasonable. Directory integration for OS-level accounts requires the additional safeguard of local emergency accounts.
Offline credential management. The credentials for emergency access must be recoverable without network access, without authentication against a directory, and without any dependency on the infrastructure that might be offline during an incident. This typically means physical documentation in a physically secured location or a hardware security module.
2FA everywhere. Both OS console access and BWeb access require a second factor. This is non-negotiable regardless of the identity provider in use.
Recovery access tested. The procedure for using emergency access — who holds the credentials, how they are retrieved, how access is verified to be working — must be rehearsed before an incident, not discovered during one.
Central authentication is a convenience that serves you when your infrastructure is healthy. Backup infrastructure exists precisely for when your infrastructure is not healthy. Design the authentication model of your backup system to work in the conditions where you will actually need it, not in the conditions that prevail on a normal working day.
The question is not whether to use Active Directory or Entra ID. The question is: if that system is unavailable tomorrow morning because of an incident, can the right people still access the backup system and run a restore? If you cannot answer yes with confidence, the architecture is incomplete.
Every faaleoleo managed service and Enterprise deployment ships with all of the controls described in this article enabled out of the box. Local emergency accounts are created and credential management is documented as part of the initial deployment. OS-level accounts are configured with restricted shells and minimum permissions. 2FA is enforced on both console access and BWeb from day one. System and application users are separated by design.
Customers who have specific requirements — for example, an integration with an existing directory that requires adjusting the default configuration — can request changes. faaleoleo will implement them. Where a requested change reduces the security posture described here, we will document it clearly and flag it as not recommended. The decision remains with the customer; the risk is recorded.
The default exists because we believe backup infrastructure should be as resilient as possible without requiring customers to make every security decision themselves. Most of what this article describes should not be something you need to configure — it should already be there.
Questions about authentication architecture for your Bacula environment? This is a routine part of what we design and review with customers. Reach us at contact@faaleoleo.io.