SQL Backup Master

Introduction: Explicit Credentials vs. MSA

When configuring SQL Backup Master to connect to a SQL Server instance using Windows Authentication, you have the option of entering account credentials directly into the application. In such cases, SQL Backup Master stores those credentials (encrypted) and uses them to connect to SQL Server when performing backups or restores. This approach is simple and works well, but it has a drawback: you must manually update those credentials (in SQL Backup Master) if the account password changes.

A Managed Service Account (MSA), on the other hand, is a special type of account in Active Directory that eliminates the need to manually manage and rotate passwords. Windows handles password changes for the MSA automatically on a frequent schedule, and you never actually see or store the MSA password yourself. This yields several important benefits:

• Security: No need to store encrypted passwords to support SQL connections.
• Simplicity: Windows automatically updates the MSA account’s password.
• Reliability: The MSA is tied to your domain and can be restricted to specific servers/services.

SQL Backup Master supports either approach: specify the Windows account credentials in the application or run the service under an MSA that has the necessary permissions to back up your databases.

Preparing for an MSA

Using an MSA requires the following prerequisites:

• Your environment must be Active Directory-based (no local MSA support on standalone machines).
• You must have Windows Server 2008 R2 or later (for standard MSAs) or Windows Server 2012 or later (for Group MSAs).
• You need Domain Administrator privileges (or assistance) to create and configure the MSA in Active Directory.

Creating and Installing a Managed Service Account

Typically, a domain administrator handles creating the MSA. Specific steps will vary depending on your environment, but here's an overview of the general process:

• On a domain controller, open PowerShell and run a command such as:
  New-ADServiceAccount -Name SqlBackupMasterSvc -DNSHostName SqlBackupMasterSvc.domain.local
• Install the MSA on the target server where SQL Backup Master runs:
  Install-ADServiceAccount SqlBackupMasterSvc
• Validate that the MSA can run on that server:
  Test-ADServiceAccount SqlBackupMasterSvc

If it returns True, you’re all set to proceed.

For more information on creating and managing MSAs, see Microsoft’s documentation on Managed Service Accounts.

Granting the MSA Permissions on SQL Server

Because you’ll be using Windows Authentication (Integrated Security) with SQL Backup Master, SQL Server needs to recognize the MSA and assign it the correct permissions. Again, the specific steps will depend on your environment and the commands below are just examples.

• Add the MSA as a login in SQL Server:
  CREATE LOGIN [DOMAIN\SqlBackupMasterSvc$] FROM WINDOWS;
• Create a user mapped to that login in each database you plan to back up:
  USE [YourDatabaseName];
  CREATE USER [DOMAIN\SqlBackupMasterSvc$] FOR LOGIN [DOMAIN\SqlBackupMasterSvc$];
• Assign backup permissions, for example by adding the MSA to the db_backupoperator role:
  EXEC sp_addrolemember 'db_backupoperator', 'DOMAIN\SqlBackupMasterSvc$';

Configuring SQL Backup Master to Use an MSA

By default, SQL Backup Master installs its system service with the local system account. Here’s how to switch to your MSA:

Good news: the installer provisions the protected MachineKeys registry value (used to encrypt stored credentials) automatically during install and upgrade, and a bundled helper applies the permissions an MSA needs in one step. You no longer have to start the service under Local System first, or run any icacls/PowerShell commands by hand.

• Open Windows Services (services.msc).
• Stop the "SQL Backup Master" service if it’s running.
• Right-click the "SQL Backup Master" service and select "Properties."
• On the "Log On" tab, choose "This account" and enter your MSA in the format DOMAIN\SqlBackupMasterSvc$ (leave the password fields blank).
• Click OK to save the service logon changes.
• With the service now set to run as your MSA, apply the permissions it needs by running the bundled helper: from the SQL Backup Master program folder (typically C:\Program Files\Key Metric Software\SQL Backup Master), right-click SQLBackupMaster.InstallHelper.exe and choose Run as administrator. It detects the MSA and grants it the required data-folder and machine-key permissions automatically. (It writes a short log to %WINDIR%\Temp\sbm-install-helper.log if you want to confirm what it did.)
• Restart the "SQL Backup Master" service and then open SQL Backup Master.
• Edit a backup job and click the Choose SQL Server button. Select the Advanced tab and enable the Use Managed Service Account option. Save your changes.

Now, your backup job will run under the MSA identity. Because no credentials are stored, it automatically uses Windows Authentication for connecting to SQL Server under the MSA context.

What the helper does, and why it's needed (v8.5 and later): SQL Backup Master v8.5 hardened the NTFS permissions on its data folder and the ACL on its machine-key registry value, restricting both to SYSTEM and Administrators. Under the default LocalSystem identity this needs no action, but an MSA, gMSA, or any other non-administrator service identity must be granted access explicitly. The helper, running elevated, applies both grants in one step: Full Control on the data folder (so the service can manage its working and log folders, including on an impersonation account's behalf) and Read on the machine-key registry value (so the service can decrypt stored credentials).

Manual alternative. If you prefer to apply the permissions by hand, grant them from an elevated prompt – replace DOMAIN\SqlBackupMasterSvc$ with your account:

• Data folder, from an elevated command prompt:
  icacls "C:\ProgramData\Key Metric Software\SQL Backup Master" /grant:r "DOMAIN\SqlBackupMasterSvc$:(OI)(CI)F" /T
• Machine-key registry value, from an elevated 64-bit PowerShell prompt:
  $key = "HKLM:\SOFTWARE\Key Metric Software\SQL Backup Master\MachineKeys"
  $rule = New-Object System.Security.AccessControl.RegistryAccessRule("DOMAIN\SqlBackupMasterSvc$", "ReadKey", "Allow")
  $acl = Get-Acl $key; $acl.AddAccessRule($rule); Set-Acl $key $acl

You only need to do this once. The same helper runs automatically during every install, upgrade, and repair, so it re-provisions the machine key and re-applies both grants for your service identity each time – you don't have to re-run anything after an upgrade. The one exception is a domain account or (g)MSA whose domain controller is unreachable at the moment the upgrade runs: the account can't be resolved to re-apply the grant, so re-run the helper (or the manual commands) once the domain controller is reachable.

On startup the service writes a brief probe file to its data folder; if that write fails it logs an actionable Error to the Windows Event Log (under Applications and Services Logs → SQL Backup Master, and a fatal entry under Application) naming the current service identity and the exact icacls command to run. See also the Backup Temp Folder Permissions article for the full v8.5 permission model.

Recovering a missing MachineKeys key

Current installers provision the machine key automatically, so this is rare – but if you took over a server that was switched to an MSA before the key was ever created, you may see "Access to the registry key … MachineKeys is denied" or "the registry key … MachineKeys doesn't exist". The fix is simply to run the helper:

• With the service already set to run as your MSA, run SQLBackupMaster.InstallHelper.exe from the program folder as an administrator. Running elevated, it creates the machine key (which the MSA itself cannot do) and applies the MSA's grants in one step. Then restart the service.

The service also degrades gracefully in the meantime: if the machine key is missing or unreadable, it logs an actionable warning at startup and keeps running, saving its configuration without at-rest machine-binding (the data folder's permissions still protect it) until the helper is run.

Verification and Testing

Run each of your backup jobs to ensure they complete successfully, reviewing the job logs for any errors or warnings. If you see authentication or permission errors, verify:

• The MSA is properly installed on the server.
• The MSA has appropriate SQL Server permissions.
• You used the correct DOMAIN\AccountName$ format for the service Log On.

Important: Test all backup jobs thoroughly after making any changes to the service account.

Conclusion: Which Approach Should You Choose?

Specifying account credentials explicitly can work for smaller or non-domain environments but involves manual password management. A Managed Service Account is typically more secure and requires less upkeep because Windows rotates passwords automatically.

For most Active Directory environments, running SQL Backup Master under an MSA is the recommended best practice, providing added security, simplicity, and reliability.