![]() 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. Unfortunately, this doesn't allow you to use your internal admin accounts from active directory, for example. 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). That way when you add the user into VMware, it will show up as "/user1" and VMware will have no domain suffix to truncate. So, to workaround this, you can use a native Okta user which does not have a domain suffix. I don't know if VMware does this on purpose, but its certainly something they could fix programmatically. so at that point, VMware will not be able to match the response (user1) with a user in that identity source. user1) WITHOUT the domain suffix attached. If the name is validated, VMware will receive the response back with the name (ie. If it finds it, it will send the auth request to that identity source for validation. So for example, if you enter will search the identity source for a corresponding user. 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. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |