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 .
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.