Veeam Backup & Replication has some nice out-of-the-box features for Veeam Agent management if you’re using Microsoft Windows or Linux Operating Systems. I don’t like talking about a possible solution though until I’ve tried it for myself. This way I can gauge the problems that’ll occur by how I’ve tripped up in testing.
This brings me to the topic of today, Linux + Veeam Backup & Replication Agent Management.
Nowhere within Veeam’s documentation could I find references to what was/wasn’t supported for creating an Agent Protection Group. I see this as a potential risk, without stating which operating systems you can target via the mechanisms such as Computers from CSV file or Microsoft Active Directory Objects etc, how do you know if it will actually work? I could add IBM AIX servers to a CSV file, but that won’t work in reality as I’d need to pre-install the agent.
So, I decided to explore just how far I could go with automatically creating Linux Protection Groups that would scale. My notes are below.
The Test Environment
To test this, I needed a way of integrating Linux into Active Directory (AD), and a Linux distribution. I wanted to test for RHEL integration, but I didn’t have a RHEL instance available, so I deployed the latest version of CentOS 7 instead, and then tested my results again with Ubuntu, this solved my Linux distribution(s), next I needed to handle the integration, to achieve this I used System Security Services Daemon (SSSD).
As for the Windows side, I spun up a quick two server test environment, one being a domain controller, the other being my VBR + Backup Repository server.
I won’t go into the details of how to integrate SSSD and AD as that’s outside the scope of the blog post, there’s plenty of guides online that have specific instructions for whichever version(s) you might find yourself coming across, Ubuntu themselves even maintain integration documentation for SSSD & AD.
The outputs from this though are key. After the integration, I could utilise any AD accounts that I granted permission for, onto the servers, and when these servers became ‘Domain Joined’, they were creating computer objects within AD.
Creating the Protection Group
When my Linux-based servers started appearing with AD, I had pre-defined an organisational unit (OU) that they would reside within, at this point I technically could just target the OU within a VBR Protection Group and leave it as that, however this isn’t suitable for quite a few reasons. Such as:
- What if I had domain joined servers that I was protecting at a hypervisor level?
- What if I had different protection requirements for different servers? How could I differentiate these into different protection groups.
To answer this, I created an AD Security Group for my Linux Agent-based backups that I then placed my relevant servers into. This would allow me to add servers into a security group within AD as such tasks normally happen by relevant teams during server build stages. Veeam would automatically poll the security group and deploy its agent based on my protection group settings, to keep itself up to date on which servers need protecting.
This could be extended further by scripting if you needed to, such as automatic adding/removing servers based off other properties such as OS builds, or attributes, but that’d be organisation specific customization.
Now I have my group created, I can push out the agent at scale, but I still need to ensure the authentication happens at scale.
Authentication at Scale
Odds are, you’ve got a service account that is authenticating to your servers for backup purposes, but it’s also possible you might have different accounts requiring different needs within your Linux servers, so specifying every account explicitly might be an administrative headache. To resolve this, I created another AD Security Group that contained my Veeam service account and specified this within the SSSD configuration as an allowed AD group, I then added this AD group to the sudoers file as well. You might not need this depending on how many different AD authentication driven integrations you might have with your Linux environments, but for me, it was a necessity of the organisation’s security policy to use security groups instead of named accounts for permissions.
Pulling it all Together
With this completed, I created my protection group, targeting an AD security group populated only with Linux servers, and for credentials I added a standard Linux account, with the “AD\User” formatting for the username, and supplied the password for the service account. I then tested the credentials successfully, and attempted to deploy the agents, it worked!
But of course, this isn’t a backup, so I tested a backup using this protection group and everything still worked great!
How does this work?
When configuring SSSD, you’re adding a computer object into your AD, which is how you can then add it to your various security groups and structure this within your OUs. It doesn’t matter that the object is a Linux server, it’s still just an AD object with various attributes. Veeam is querying which computer objects exist within the protection group configuration, and returning them. At this point, Veeam care if it’s a Windows or Linux server.
What matters are the credentials we specify. Within Veeam’s Credentials Manager, amongst the options are ‘Standard Accounts’ and ‘Linux Accounts’, and this is where we can go wrong. You’d think that a ‘Standard Account’ which we use for Windows, and therefore AD, might be the right option, but the documentation states that ‘this ‘Standard Account’ is to be used ‘to connect to a Microsoft Windows server, a VM running Microsoft Windows OS or a storage system.’. Linux Accounts however, are used to ‘connect to a Linux server or VM running Linux OS.’.
Look what happens below when I attempt to connect to my CentOS VM with the same credentials, but one set is added as a ‘Standard Account’ and the other as a ‘Linux Account’.
When using ‘Standard Account’ credentials, Veeam assumes the server is a Windows server, and fails to connect.
However, swapping the credentials to a Linux account makes Veeam assume the server is a Linux server, and successfully connects.
You’ll notice the structure of the account credentials is identical, as is the username itself and the password, it’s the same credentials inserted twice, just once as a ‘Standard Account’ the other as a ‘Linux Account’.
And if you’re wondering how using an AD set of credentials works within Linux this way, SSSD is connecting to the AD environment to retrieve identity & authentication information, and then uses the authentication information to create a local cache of users and credentials. So to Linux, it’s just a normal account you’re authenticating with.
