Hello again
Today I’m going to highlight some of the bugs/problems we have run into with vSphere Single Sign On (SSO), introduced in vSphere 5.1.
Using Active Directory groups from a Multi-Domain Forest with Parent-Child trust:
We are using a Active Directory (AD) forest that consists of a single root domain around 20 sub domains, a single level down. That is we have a root AD domain like example.com and below a single level we have all the domains, mostly on the form department.example.com. All users exist in one of the sub domains, none are placed in the root domain. It contains only service accounts, groups and servers.
The SSO as of version 5.1 U1b only supports External Two-way trusts (See: KB:2037410) so at first you think it won’t work. So you try adding a group from AD and you are able to do so. But trying to authenticate with a user of that group doesn’t work. Adding the user itself instead of the group works. VMware have stated to us that this is a problem with the transitivity of the trust in Parent-Child trusts which does not exist in the External Two-way trust. I suspect that this is also caused by another “bug” that we have noticed that I will explain below.
Workaround: use local SSO groups with AD users. This works just fine.
Users with same sAMAccountName in different domains in same forest cannot be used:
We discovered last week that we were unable to add users to permissions or SSO groups if the SSO already new a user with the same sAMAccountName but in a different domain. VMware confirmed this as a bug which will be fixed in an upcomming release. The bug only occurs in child domains in an AD forest.
Users are presented in the SSO with wrong domain when added:
This is small bug but when adding a user (or group) the first time the user is added with username@example.com rather than the correct username@department.example.com which is shown when adding and despite selecting the correct domain in the “Add user” dialog. The result is that the first time the user logs in nothing is shown despite the user having permissions. Have the user log out and then remove and add the user solves the problem, as if the SSO figures out that the user is in the sub domain on first login. I suspect that this has something to do with the first problem as well.
Cannot remove user from SSO group:
Despite KB:2037102 stating that the bug was solved in vSphere 5.1 U1a we are experiencing it on this version aswell. We have not reported this yet but am doing so tomorrow morning. For some users no errors are shown but the user is not removed, for others an error is shown that the principal could not be removed. In the imsTrace log a Java exception shows that the principal cannot be removed because it does not exist on the group, even though the web client shows the user.
This post may be updated in the future:)