I'm trying to connect vCenter to our IdP (Okta) using SAML so that we can also have multifactor auth. However, when I look under the SSO config, I do not see a SAML Providers tab at all (as indicated in this doc - https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.psc.doc/GUID-24FBEF5A-4A93-468B-A039-A52603...)
What am I missing? Do I need to have a specific service running?
You can't in anything before 7.x, and that only works with adfs. Read this part
"You can use the vSphere Web Client to add a SAML service provider to vCenter Single Sign-On, and add vCenter Single Sign-On as the identity provider to that service. When users log in to the service provider, the service provider authenticates those users with vCenter Single Sign-On."
your making the vcenter an idp, not the other way around.. You need to use adfs and then use adf to point to okta I beleive
Thanks for the reply and additional info. We are currently on 6.7 so it appears that our options are limited.
Ugh. So you have to federate vCenter with ADFS and then do SAML from there? That seems pretty convoluted. I can't believe that VMware doesn't support SAML, OpenID or some other external secure authentication method other than just ADFS.
What else are people doing for SSO with their IdP though?
No idea if okta can do this, but duo as a proxy you can setup that acts an ldap proxy. You configure that and then configure vcenter to use that as its identity source. It works quite well, I don't have it in production yet, and may not since we are almost at 7.x but I have it in lab working .
Thanks .. that's the other option I'm looking into as well 😉
Where you able to do this successfully with okta? We dont have an adfs setup but our secTeam has told us OKTA can emulate!? the closest i have found to that is this https://www.okta.com/integrations/okta-mfa-for-microsoft-adfs/ and it clearly shows you need an ADFS server..
Yes and no. It won't work using AD based names with a domain suffix but I did get it working using native Okta accounts without domain using OpenLDAP.
The reason AD-based logins won't work is because VMware truncates the domain suffix during the initial authentication step - in other words, it uses the domain suffix to determine the identity source to use, then discards it. So for example, if you enter email@example.com, VMware will search the domain.com identity source for a corresponding user. If it finds it, it will send the auth request to that identity source for validation. If the name is validated, VMware will receive the response back with the name (ie. user1) WITHOUT the domain suffix attached .. so at that point, VMware will not be able to match the response (user1) with a user in that identity source. I don't know if VMware does this on purpose, but its certainly something they could fix programmatically.
So, to workaround this, you can use a native Okta user which does not have a domain suffix. That way when you add the user into VMware, it will show up as "domain.okta.com/user1" and VMware will have no domain suffix to truncate. MFA will still work though - Okta does provide a KB for accommodating that (you simply append the MFA challenge to the password when you login to vCenter - obviously you need to have the MFA challenge prior to the initial login, so you have to use something like Okta Verify). Unfortunately, this doesn't allow you to use your internal admin accounts from active directory, for example.
I wrote up an explanation of this and sent it to Okta so maybe they will publish an official KB or something, but it is odd that VMware doesn't have better support for MFA or other external IdPs.
Can you share how you accomplished this? I've been trying to get Vcenter hooked to Okta for a couple of days now with no luck.
My previous post basically explains the steps - the big caveat here is that this won't work (at least from what I've found) with internal AD accounts because the VMware auth process doesn't handle the DNS suffix well.
The only way I got this to work was by using a native Okta user with no DNS suffix. In order to do that, you need to create a custom sign-on policy that allows you to create a native Okta user without a suffix. Once you have that, you can create an LDAPS Identity Source in VMware that points to Okta.
The whole key here is the DNS suffix. When VMware evaluates your logon request, it first looks at the user's domain suffix (ie. @Domain.com), determines which identity source to use and then sends the request to that source to be validated. Unfortunately, VMware strips off the dns suffix, so even if the authentication respond from Okta is successful, VMware no longer sees a match within the Identity Source (because the user within the Identity Source has a DNS suffix but the Okta response will not) .. hence why you need to have a user without a suffix. Complicated enough? Yeah.
Maybe a future version of vCenter will accommodate for this DNS suffix issue .. but I wouldn't hold your breath because it will require a code change by VMware on their authentication process.
Hello rossanderson, can you explain in details to share how configure Okta and VMware vCenter for authentication with Okta local user?
Thanks a lot