-
- Lurker
- Posts: 2
- Liked: never
- Joined: Nov 21, 2022 1:49 pm
- Full Name: thomas
- Contact:
OKTA SSO On Veeam Backup & Replication Console
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
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
-
- Chief Product Officer
- Posts: 31806
- Liked: 7300 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: OKTA SSO On Veeam Backup & Replication Console
Hello!
We do support SSO for the web UI (Veeam Backup Enterprise Manager) but not for the Windows console.
Thanks!
We do support SSO for the web UI (Veeam Backup Enterprise Manager) but not for the Windows console.
Thanks!
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Nov 21, 2022 1:49 pm
- Full Name: thomas
- Contact:
Re: OKTA SSO On Veeam Backup & Replication Console
Hello Gostev,
Thank you for the reply, did you plan to integrate it on your roadmap ?
Best regards
Thank you for the reply, did you plan to integrate it on your roadmap ?
Best regards
-
- Chief Product Officer
- Posts: 31806
- Liked: 7300 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: OKTA SSO On Veeam Backup & Replication Console
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.
-
- Service Provider
- Posts: 176
- Liked: 53 times
- Joined: Mar 11, 2016 7:41 pm
- Full Name: Cory Wallace
- Contact:
Re: OKTA SSO On Veeam Backup & Replication Console
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.
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.
Who is online
Users browsing this forum: Bing [Bot], Ivan239 and 256 guests