Skip to main content

I tested the new VSA 13 with SAML implementation and thought I'd share the process in the form of this little step by step guide.  

This guide provides instructions to configure Entra ID SAML integration for SSO access to VBR with version 13 

 

As requirements, you need an Entra ID account with one of the following permissions: "Cloud Application Administrator" or "Global Administrator" for creating a new enterprise application.  

You also need a working Veeam version 13 installation.  

 

First, configure the Entra ID application:  

Access Entra ID (https://entra.microsoft.com) and navigate to Enterprise apps and create a new application. 

 

 

Search in the gallery for "Microsoft Entra SAML Toolkit" and select the app 

 

You can specify a name, I choose "Veeam 13 SAML" and then click on create 

 

In the newly created application, navigate to Single sign-on and select SAML.  

 

We now need some information from our VBR.  

Open "Users and Roles" settings 

 

Navigate to "Identity Provider" and enable SAML authentication 

 

First, you have to install a certificate, you can either create a new one or select an existing certificate.  

I selected an existing certificate.  

 

I did some testings with different certificates but could not see any difference, maybe this is related to "Verification certificate" on Entra.  

But for this to get it to work, we can leave this disabled.  

 

Now we do have the certificate selected and can download the metadata to configure the IDP.  

 

Store this xml file somewhere and then upload it to entra id enterprise application.  

 

Leve all settings and just add a "Sign on URL" which is just the FQDN of your VBR. Lets say https://vsa.domain.com 

 

Now we can download the metadata xml from entra id and import it into Veeam.  

 

It should look something like this 

 

Now we need to add the external user to Veeam.  

 

 

 

Enter Username or Group name and click OK.  

 

On the login screen on your VBR, you can see a new button "Sign in with SSO" 

 

 

This will now redirect you to Entra ID login screen. Log in with your user credentials and it will redirect you back to VBR.  

 

If something does not work, here are some troubleshooting steps.  

 

First, Sign-in logs in entra id. You can check if the authentication on Entra ID is successful or not 

 

In Veeam there is this logfile /var/log/VeeamBackup/Svc.Identity.log which can be accessed by enabling ssh to VSA and then reading the file with a command like " tail -f /var/log/VeeamBackup/Svc.Identity.log" 

 

Some thoughts 

  • In VBR, this is only possible for the web management as well as the fat client (VBR console). The "host management" login is not (yet?) possible to integrate with SAML.  

  • While testing I found that the error messages in the web gui are not really useful, in the mentioned logfile I found all the relevant information but that is something veeam could improve in a future update  

Nice step by step ! 
From a security standpoint, however, I have some concerns. If the Microsoft tenant were to be compromised, it could potentially allow access to the Veeam server. To me, this feels quite similar to adding Veeam to a production domain.


Nice step by step ! 
From a security standpoint, however, I have some concerns. If the Microsoft tenant were to be compromised, it could potentially allow access to the Veeam server. To me, this feels quite similar to adding Veeam to a production domain.

Hi, I totally agree, I never join any of my backup servers into a domain. In my opinion, it is not recommended to set “backup administrator” permissions via SAML (or any 3rd party auth)

But for example, some restore operators should be fine. Because they cannot run administrative tasks. 

You can, for example, configure an Entra ID group “veeam restore operators” and add this as an external group to VBR. And keep local administrators in VBR.

So no administrator privileges will work over an Entra ID login.


Indeed..nice writeup ​@tm67 . As one who doesn’t use Entra, it’s good to see the process to get it configured in various ways. Appreciate the share!


Great write-up ​@tm67 always wanted to configure this and now I can test with your guide.  Thanks for sharing with the community.


Well best practices says not to join a backup server to a domain. That is what I always recommend to customers. That is on of my first rules.


great step by step article. thank you share it.


Fantastic write up!

 

To those talking about not joining Veeam to a production domain, aside from only assigning lesser admin roles, you could also leverage a “management” entra ID tenant here like you would a management AD domain, the benefits to an internet based identity mean you can cut off the internet if you have concerns and it cuts off that entire authentication provider. Leveraging modern authentication is also of a net benefit here!

 

As there is no such thing as as 100% secure, anything that pushes the needle towards more secure whilst remaining straight forward is good in my eyes!


Thanks for the writeup, I already have multiple scenarios in my mind that could be applicable:

  • having an offsite VBR (branch or external office / production) that has to be managed both from a HQ and the site itself - could make life easier with SSO
  • having enterprise scenarios where you have to deal with dedicated mgmt domains and many users on VBR servers (similar to self-service with VBEM)
  • setups similar to AD tiering for some upscaling environments

 

I certainly agree with everybody that you should be careful with this and not assign administrative right via SSO and AD.