It’s been a while but I think I chose the generic LDAP option and when entering the username I just entered it in as the full DN instead of just the username.
We just recently finished integrating Duo with vCenter and I had to chase down information from a bunch of different sources. Here are the steps that we used to get things to work with vCenter 6.5 on a VCSA appliance with a separate PSC. We have verified that it allows you to select your Duo authentication type by adding a comma and push, phone, SMS, or a passcode to you password. It also works with a second device (i.e ,push2). This isn’t officially supported by VMWare, but we did work with VMWare support on some of the steps.
- Setup LDAP proxy. We created two Linux VMs with similar configurations because the vCenter LDAP config will allow two servers. We have tested that rollover happens correctly if the primary proxy is down. The [ad_client] section should point to your active directory. You might need to import root, intermediate and AD certs into the operating system to get a secure connection to AD. We tested both self-signed certs and commercial certs to secure the proxy. The Duo authproxy_connectivity_tool is a big help in tracking down cert and connectivity problems. In the [ldap_server_auto] section you should include exempt_primary_bind=false and exempt_ou_1 with the full DN of the user name used in step 4.
- Remove the PSC (VMWare Platform Services Controller) from Active Directory. This is done in the PSC web interface (https://psc_ip_or_hostname/psc and login as SSO admin). This will break the “Use Windows session authentication” check box. You can still check the box, but authentication won’t work. Make sure that an nslookup of your Active Directory comes back with the IP addresses of all of your domain controllers. If not, you might have to add the domain controllers to the hosts files of the PSC and the proxy machines.
- Remove the Active Directory identity source from the VCSA. This is done in vCenter under administration, but it usually needs to be done as the SSO admin in the VSPHERE.Local domain.
- Add an identity source of “Active Directory as an LDAP Server”. The username, base DN for users, and base DN for groups must be active directory objects in DN format. Remember to set this as the default identity provider.
- Remove the Active Directory computer object for the vCenter from the Active Directory. This will disable pass-through credentials from scripting environments. Connecting to a vCenter from PowerShell (Connect-VIServer) will now always prompt for a username and password. It will also do a Duo prompt if there isn’t an exception in the proxy setup.
- Permissions will need to be reapplied to the objects in vCenter to the use the new identity source. A little searching in Google should come up with PowerShell scripts that will change the permissions.
I just finished a similar setup in my environment. One thing I noticed is that with PowerShell logins, I get two Duo pushes when I log in. Do you see similar behavior in your environment?
We are seeing the same thing, but we haven’t dug into it too hard. We are currently going with the philosophy that two Duo pushes is better than no Duo pushes.
The users that we use for automated scripting have persistent PINs and sending them with the password seems to bypass the problem of a double push.