Admin user has lost permissions and cluster visibility in TMC following an AD modification

Products

• VMware Tanzu Mission Control

Issue/Introduction

• Following an Active Directory (AD) configuration change, administrator users logging into Tanzu Mission Control (TMC) Self-Managed are incorrectly assigned default Read-Only (RO) permissions.
  
  
• Authentication succeeds, but role-based access control (RBAC) authorization fails to grant admin access.
  
  
• Validating the values.yaml file confirms the Identity Provider (IdP) group roles are correctly mapped:
  
  ###TCAD NO
idpGroupRoles:
  admin: ADGroup_TMC_ADMIN
  member: ADGroup01_All_Users
  
  
• Verifying the secret group confirms that the login process is creating a new secret. 
  
  kubectl -n tmc-local get secret --no-headers -o custom-columns=":metadata.name"  | grep pinniped-storage-access-token  | xargs -i kubectl -n tmc-local get secret {} -ojsonpath='{.data.pinniped-storage-data}' | base64 -d | jq .

"ext": {
  "azp": "client.oauth.pinniped.dev-auth-manager-pinniped-oidc-client",
  "groups": [
    "ADGroup01_All_Users",
    "ADGroup_TMC_ADMIN"
  ],
  "username": "user"
}
  
  
• Any user which is a member of "ADGroup01_All_Users" has no admin permissions, only RO permissions.

Cause

• Changing the name of admin or member group for TMC-SM it is not supported.
• TMC-SM automatically creates organization access policies based on the admin and member group names provided during initial setup. These access policies do not automatically update when TMC-SM is reconfigured with a new Active Directory server, causing an RBAC mismatch that prevents administrative access.

Resolution

Workaround:

1. Add the same groups on the new AD.
   OR
2. Manually change the groups in all access policies

1. 1. Revert Identity Provider Settings: Temporarily reconfigure TMC-SM to use the previous AD settings. This ensures the admin can authenticate with full administrative privileges to perform the necessary policy modifications.
   2. Log into the TMC-SM UI as an admin. Navigate to the left-hand sidebar and select Access Policies.
   3. Select Organization to view the current organizational access policies.
      
      
      
      
   4. Update Administrator Group Identity:
      1. Locate the policy that grants the organization.admin permission to members of the legacy AD admin group.
      2. Select Edit. In the Identities drop-down menu, select Groups.
      3. Enter the name of the new AD administrator group in the Group Identity text field and select Add.
      4. Confirm that both the legacy and new AD administrator groups are listed as identities, then select Save.
         
         
         
         
   5. Update Member Group Identity:
      
      1. Locate the policy that grants organization.credential.view permissions to members of the legacy AD member group.
      2. Repeat the edit process from step 4 to add the new AD member group identity.
      3. Select Save to ensure members of either group are recognized as organizational members.
   6. Review the organizational access policies within the UI to verify that both organization.admin and organization.credential.view have been updated with the additional group identities.
   7. Reconfigure TMC-SM with the settings for the new AD server.
   8. Authenticate as an admin using the new AD credentials. Confirm the UI grants full administrative access and no longer defaults to a Read-Only view.
   9. Authenticate as a non-admin member user to confirm the UI reflects the correct permissions and visibility for that role.
   10. Once the new AD group permissions are verified, log in as an administrator to remove the legacy AD group names from the policies edited in steps 4 and 5. The organization.admin and organization.credential.view policies should eventually contain only the new AD group identities.
   11. Inspect any other direct access policies within the UI. If additional policies were manually created using legacy AD group names, update them to reflect the new group identities. Note that inherited access policies do not require manual intervention, as they update automatically based on changes to the direct policies.