VMware VCSA 6.5 Permissions and Active Directory Groups Not Working

I recently deployed VCSA 6.5U2 with embedded PSC and selected Active Directory (Windows Integrated Authentication) as the identity source.

All the required steps were carried out, joining the VCSA to Active Directory, rebooting the VCSA then adding the AD identity source with using the machine SPN.

I could successfully query and add users and group from Active Directory and added the security group used for VCSA administration and granted the Administrator role in Global Permissions section. The mentioned security group is a standard AD Global Security group with users in that group. I then logged into VCSA with an account from that group. Everything was working fine. I could login and had full administrative rights in VCSA.

I then started populating the roles and permissions from the various user AD security groups granting the different teams in the organisation the appropriate permissions in VCSA.

However, the users reported the following error when trying to login.

Tried multiple things to troubleshoot including rebooting the VCSA, granting Administrator rights, adding the group to Global Permissions, creating a new group in AD, but none of those fixed the issue.

I checked the vCenter vpxd logs as well as the PSC logs and found that the user was being authenticated correctly and found in Active Directory but it seems that the user’s group membership could not be enumerated to link the user to the group which was granted permissions.

Finally, I changed the identity source from Active Directory (Windows Integrated Authentication) to Active Directory over LDAP which fixed the issue.

The only reason that I could think of was maybe the Active Directory I was using was still on Windows 2003 functional level and VCSA was making a query that AD could not support.

Let me know in the comments if you had similar issues and your experiences.

10 Responsesso far.

  1. Penney Gheewala says:

    I went over this web site and I believe you have a lot of great info , saved to my bookmarks (:.

  2. Russell Lafuze says:

    I think you have noted some very interesting details , appreciate it for the post.

  3. bullet force hack mod apk - bullet force hack latest says:

    Hello There. I found your blog using msn. This is a very well written article. I’ll be sure to bookmark it and come back to read more of your useful info. Thanks for the post. I will definitely return.

  4. minecraft says:

    I could not refrain from commenting. Very well written!

  5. Jeremy Prestage says:

    I believe that is among the so much significant information for me. And i am satisfied studying your article. However want to observation on some common issues, The website style is perfect, the articles is in point of fact nice : D. Just right task, cheers

  6. mywebsite says:

    Hmm it appears like your site ate my first comment (it was
    extremely long) so I guess I’ll just sum it up what I had written and say, I’m thoroughly enjoying your blog.
    I as well am an aspiring blog blogger but I’m still new to the whole
    thing. Do you have any suggestions for newbie blog writers?
    I’d certainly appreciate it.

  7. Aaron says:

    Administration>Sessions – make sure you remove any idle sessions when updating membership of groups in AD

  8. Michael Gorton says:

    Funny, this is the exact problem I’m having at the moment. I’ve been pulling my hair out. Thanks, I’ll try just using LDAP instead.

  9. Michael Gorton says:

    Also, our domain’s functional level is 2012, so unlikely it was the functional level.

  10. Richard Parker says:

    I had the same problem, tried adding LDAP (its more complicated than its worth). I added the authentication and didn’t remove the original.

    LDAP requires a bunch of settings and it never works the first few times, I know the AD values for GROUPS and USERs blah blah blah, I do this everyday but vCenter ALWAYS needs something to be different.

    So I reverted to integrated windows and all I did was changed default to use System Domain then default to the domain method. Maybe something behind the scenes caused the method to ‘refresh’ or maybe my attempts setting up LDAP did something I don’t know just know it’s now working.

    Groups are working again. No reboot of the VCSA, no logging off users or idle sessions, just set as default to System Domain and set as default to the domain. (which is 2 steps)

    It seems very odd that users function while groups do not, they are using the SAME exact AD even the EXACT method to authentication why would being a member of a GROUP affect how a user logs in? It’s just a connection to AD objects that makes no sense to me.

    Anyway that’s my 2 cents.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.