Comprehensive data protection for all workloads
Post Reply
tomslns
Lurker
Posts: 2
Liked: never
Joined: Nov 21, 2022 1:49 pm
Full Name: thomas
Contact:

OKTA SSO On Veeam Backup & Replication Console

Post by tomslns »

Hello,

I would like to know if there is any possibility to use OKTA as SSO Provider (OIDC, SAML, etc.) to login to the VBR console ?

If not possible, did you plan to integrate in on your roadmap ?


Best regards
Gostev
Chief Product Officer
Posts: 31561
Liked: 6725 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: OKTA SSO On Veeam Backup & Replication Console

Post by Gostev » 1 person likes this post

Hello!

We do support SSO for the web UI (Veeam Backup Enterprise Manager) but not for the Windows console.

Thanks!
tomslns
Lurker
Posts: 2
Liked: never
Joined: Nov 21, 2022 1:49 pm
Full Name: thomas
Contact:

Re: OKTA SSO On Veeam Backup & Replication Console

Post by tomslns »

Hello Gostev,

Thank you for the reply, did you plan to integrate it on your roadmap ?

Best regards
Gostev
Chief Product Officer
Posts: 31561
Liked: 6725 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: OKTA SSO On Veeam Backup & Replication Console

Post by Gostev »

As always, it will depend on the number of requests for this functionality vs. other features. So far, it hasn't been a popular request, unlike for example MFA for the backup console.
YouGotServered
Service Provider
Posts: 171
Liked: 51 times
Joined: Mar 11, 2016 7:41 pm
Full Name: Cory Wallace
Contact:

Re: OKTA SSO On Veeam Backup & Replication Console

Post by YouGotServered » 4 people like this post

I'm not sure exactly your implementation of Okta (and I'm not saying that you are doing this), but I would strongly suggest for people to have independent backup infrastructure accounts used for administration. If you do have a separate account that goes through SSO just for your single point of MFA solution, fine, but for the love of god please don't use your general admin account for your backup infrastructure through SSO.

We had a client that was recently targeted by Russian state-sponsored cyber terrorists. They got in and nuked the infrastructure with ransomware at the VMware level. Thankfully the backup infrastructure was left untouched because we didn't use the same credentials (off domain), and our physical backup host was NOT joined to vCenter. The issue was that vCenter was joined to the domain and domain admin credentials got compromised, so the attackers instantly had access to the whole hypervisor environment (except the backup server, thank god) once the domain credentials were in their hand.

It would have been way worse if we had any on-prem accounts that were also global admins in Microsoft 365, because all they would have had to do was reset the password, run an Azure AD sync to Microsoft 365, and boom, they would have been into our email, Azure, and SharePoint data as well. Thankfully, we do NOT sync admin accounts from on-prem to cloud and remake them with separate credentials in the cloud to avoid this exact issue.

Sorry for the small word-vomit - I just say all this to say SSO is GREAT, as long as we heavily regulate / avoid using SSO for administrative accounts. If you get breached in one place, you are now breached everywhere where that account may be an admin. SSO for admin accounts should hopefully be used only for streamlining MFA with individual accounts for each service (user-app1, user-app2, user-appN, etc).

P.S - we have systematically disjoined all vCenters from the domain across our client base. If the client disagrees, they sign a liability waiver.
Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 125 guests