I just discovered that a name change on an AD Security Group (SG) that is used for permissions in vCenter isn't properly updated.
I tried to restart the vCSA and PSC to force a synchronization but it doesn't works. What is weird is that I can find and add the newly named SG side by side with the "old named" one (which shouldn't exist anymore apart for its GUID).
Is there a way to force a full synchronization or maybe prune old metadata ?
PS : vCSA and external PSC v18.104.22.168100 and 6 linked mode appliances.
We're using AD Integrated Windows auth. I've read the recommendation to move to AD o/ LDAP with vSphere 7 but we are not there yet.
What's the difference between vSphere and vCenter forums ?
Then I am not sure. I know that 15 minutes is the time for synchronizing the permissions once some user is deleted from a group. Is this happening to you for all the groups?
And regarding from Windows Intergrated and AD over LDAP, I was asking also because of that. It is getting deprecated in the future and maybe it could be the solution to your issue.
However I am no 100% sure so let's wait maybe for somebody with the same issue as you.
Membership are correctly synchronized as far as I'm concerned.
The issue relies only on the display name of the security group which doesn't update.
For example in the screenshot below, the old name still shows in the Global Permissions whereas in AD, the SG has been renamed 4 days ago.
After further testing, it's even worse than that, the SG isn't functional anymore.
You need to add the renamed SG in the global permissions as the old one doesn't grant permissions anymore.
That's pretty harsh.
Is there anyone in the community which uses AD over LDAP could confirm this behavior ?
It would be nice to know if it has the same issue ? I can't believe this is by design, is it ?
I have seen issues in which it took a full day to (re)sync AD with vCenter. Not sure how long has passed since you changed this though.
13 days have past since the SG name has been updated in AD.
vCenter still has no clue whatsoever about this naming change thus I suppose we're not talking about a synchronization delay here.
Thanks for the try though 👍
Aah ok alright. I didn't know how much time had passed.
I suppose you could create a support ticket for this, or you might be better of just removing the old SG and re-adding the new SG honestly.
Regarding your second statement, it is definitely not a solution.
In a scenario of mass renaming of SGs for whatever reasons, you would temporarily lose all permissions granted to these and would have to manually re-add them with correct roles. I'm aware all of this can be automated and scripted and all but ... GUID exists for a reason 🙂
There must be an official statement on this specific action from VMware IMHO.
Either it is a bug, either it must be clearly specified somewhere in the documentation.
I agree with your statement, a mass rename isn't convenient. As far as I know there is no official statement on this, that's why I mentioned the VMware Support Case as an option.