Integrate Duo with VMware VCSA 6.5 (VMware vCenter Server Appliance)?

[TheZealous]

Hello guys,

I am in a position where I am unable to find a solution to rollout Duo with VMware VCSA 6.5 (VMware vCenter Server Appliance). I called Duo Support and they provided me the 2 solutions, using Proxy LDAP or Radius authentication. I reviewed the VMware documentation and found out these 2 methods are not supported by VMware. https://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc%2FGUID-ACFFCBEC-6C1C-4BF9-9971-04AEE9362AFE.html

I am writing this post in the hope that anyone out there can share some light into this problem? I am sure someone have already tried to implement DUO with their VMware environment already. What is your solution and how do you please?

Thanks,
T.

[leejohnc]

Do I need to add service account to duo as by pass users?

[DuoKristina]

@leejohnc

The user you specify in exempt_ou_1 does not need to be enrolled in Duo (that’s the purpose of that option, to skip Duo auth).

If the user DN you specified in exempt_ou_1 isn’t getting exempted from MFA, ensure that you’ve configured VMWare to send the username in DN format, and not just the username.

[leejohnc]

When testing via ldp.exe I get this

res = ldap_simple_bind_s(ld, ‘CN=xxxx,OU=Service Accounts,DC=example,DC=com’, ); // v.3
Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: Access Denied. The username you have entered cannot authenticate with Duo Security. Please contact your system administrator.

exempt_ou_1=OU=Service Accounts,DC=example,DC=com

[leejohnc]

Duo doesn’t like the space between “Service Accounts”. Eliminating that, and changing to the DN format seems to have solved that issue.

[DuoKristina]

The Duo proxy accepts spaces in a DN, so I think it’s your other change (to send the DN from the downstream authenticating service) that might have fixed it. I just double-checked with LDP and an account that has multiple spaces in its DN.

Did you set the exempt value to an OU as in your example exempt_ou_1=OU=Service Accounts,DC=example,DC=com? This bypasses Duo for every account in that Service Accounts OU. I’d suggest you set that to the DN of just the one account you’re using for Duo lookup i.e. exempt_ou_1=CN=xxx,OU=Service Accounts,DC=example,DC=com.

[Jacob6]

Out of curiosity, how did you change it to send the DN instead of just the username? We’ve been stuck on this front a bit.

[DuoKristina]

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.

[John110]

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

[adarobin]

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?

[John110]

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.