Workload License Overage and an AD Group That Cannot Log In

Start from the Licensing page rather than the total. It breaks consumption down by target and entity type, which lets you attribute the 1,690 instead of guessing. Workloads are counted as managed VMs and containers; hosts, datastores and cloud services are not the licensed unit.

Two consequences follow:

• Reorganizing VMs into groups, scoping them to a business unit, or setting automation to Disabled does not change the count. Only ceasing to manage the entity does.
• The lowest-friction remediation inside the freeze is removing the QA vCenter target, which frees 410 workloads. Before deleting it, export the sizing and plan outputs the performance team still needs, because removing a target removes its entities and their history from the supply chain.
• Removing the AWS account (190) is the alternative if cloud optimization is out of scope, but that alone lands you exactly at 1,500 with zero headroom - not a fix.

Confirm the entitlement figure against the license key or entitlement record before acting. Then revalidate consumption after removal, and open the renewal conversation with at least a month of buffer rather than letting the instance run into expiry while the overage is unresolved. If provisioning plans must be re-run during the nine months, that is a business decision to document, not an admin workaround.

The fact that TURBO-APPOWNERS works proves the LDAP connection, bind credentials and base DN are correct, so do not re-enter the server settings. Test in this order:

1. Reproduce with one affected user. Determine whether authentication succeeds but authorization leaves an empty scope - users report that as a login failure. The audit log distinguishes the two.
2. Check whether the platform sees the group's members. Open TURBO-NETOPS in Users and Groups. Zero members usually means the group is populated only by nesting another group; directory nesting is not resolved the way users expect, so a group whose members are all inherited authenticates nobody. The documented fix is to flatten the group in AD or map the inner group explicitly.
3. Check the membership attribute configured for the connection (memberOf versus member) and whether the user objects actually carry it on the relevant domain controller.
4. Verify the mapped Turbonomic group still exists and still contains its 120 VMs. A scope pointing at a deleted group or a renamed tag leaves users with no visible entities.
5. Only then examine role assignment, and whether a second mapping at a higher precedence removes access.

Change one variable at a time and re-test with the same user so you can attribute the result.

The four approvers need a permission set, not a scope. Create a custom role containing view permissions plus the action-approval permission, and nothing that lets them modify targets, policies or credentials. Map it to an AD group (for example TURBO-APPROVERS) with exactly those four members, scoped to the whole estate, because approval attaches to a specific action rather than to a subtree. Everyone else stays Observer, or a deploy role without approval rights.

Separate the two mechanisms, because they are constantly confused:

• The automation level (Manual) determines that an action requires approval.
• The role determines who is allowed to give it.

If anyone sets the automation level to Automatic in those scopes, approval is bypassed no matter which roles exist. Verify by generating a test action in a lab scope and confirming it appears in the queue for the four and is read-only for everyone else.

For AD-only authentication: configure the directory as the authentication provider, keep one local break-glass administrator whose credentials sit in the password vault with a documented rotation and a tested retrieval path, disable or delete every other local account, and audit the user list quarterly. Confirm the break-glass account is not mapped to any AD group, or a directory outage combined with a group change can lock you out entirely.