I’ve been running vCenter SSO 5.5 in mixed mode with vCenter 5.1 for a little while in our lab and production environment and recently had to configure external authentication for access against a subset of VMs we host. I covered how to setup a vCenter 5.1 AD Identity source in a this previous post, and the process hasn’t really changed that much in 5.5.

While there has been a slight tweek in the UI, the setup process is the same except you now have an additional option to utilize AD with Integrated Windows Authentication, which is covered by @chriswahl in this blog post.

After configuring the identity source as shown below.

And after configuring the appropriate permissions in vCenter I was getting the following error while trying to login with a user who was part of a Group with access to the VM location.

There wasn’t a hell of a lot on Google that looked to resolve this issue, and after some investigation I found that the reason for the error was that vCenter SSO will look to interrogate/verify every group of the user attempting to login…even though some may be out of scope and not relevant. The fact the error was returning a GroupSID that couldn’t’ be found told me that during the login process, SSO enumerates all Groups in order to find a match relevant to the vCenter Permission. If that group falls out of the Base DN for Groups, SSO can’t resolve the name to match it.

To resolve the issue I had to modify the Base DN for Group Location to be the domain root…once done the user was able to login without issue. This probably isn’t a bug like previous AD Domain SSO bugs however its still limits security restrictions when designing/allocating a user and group OU structure for AD authentication.