The objects that grant access

A verb does not grant itself. Something in the estate makes the action succeed, and that something has a name, an owner, and a place you can point at. This chapter asks for the object that makes the verb true. Until you can name it, "excessive access" is a mood. With the object named, you can remove it, shrink it, or leave it in place on purpose.

A product course would hand you a taxonomy of entitlements. You get one here only as far as it changes the Monday table.

The object is whatever would still work if the catalogue vanished

Take a row from the Monday table. A verb, a resource, an identity. Ask a blunt question. If I deleted every role name, campaign, and certification record, and I left the directories, the applications, and the vaults running, what would still let this action succeed tomorrow morning?

That remaining thing is the object.

If you cannot answer the question, you do not yet know what grants the access. You know what the catalogue calls it. Those are different facts. Write the object into the table as its own column, beside the verb. One verb can have more than one object. An administrator who can reset authentication methods might hold a directory role and also sit in a group that a custom role still honours. Both objects are real. Closing one and leaving the other is how reviews produce a green row and an open verb. When you find two, write two. Do not pick the one that is easier to explain.

Six objects, and the lie each one tells

I am going to stay with six. Fewer than six and a reader will map their whole estate onto groups, which is the most common way to be wrong in a large directory.

A group. Groups are the object people trust because they can see them. Membership is a list. Nested membership is still a list, only harder to read. The lie a group tells is that the name describes the verb. The grant is the permission on the group, plus every nest that puts a person or a service principal inside it, plus every sync that recreates the group from somewhere else. Hybrid privilege drift is this object doing what it was built to do. The review that looks only at the new group certifies the new world and leaves the old grant standing. If you cannot name the rule, you have a wish, not a removal plan. The Billing-Readers row in Figure 2, later in this chapter, is this lie with the columns filled.

A role. A directory role, a custom role, an eligible role in PIM, an application role. The lie a role tells is that eligible means safe. Eligible means the action would succeed after an activation. If the activation is available to the owner with no further gate, eligible is standing access with a short delay. If the activation requires another person, the delay is a control, and you should say whose person. Standing and eligible are not the same object. Writing "Global Administrator" on a row without saying whether it is active or eligible briefs a calmer picture than the tenant will allow at two in the morning. A role assigned directly to an account has no nest to inspect. Group-centric exports miss it. Look for the direct assignment on purpose.

An application permission. This is the object that does not look like a user grant, which is why user-shaped reviews miss it. The permission is an app role or a Microsoft Graph application permission on the principal. The lie it tells is that consent was a decision about an app the business wanted. Consent, admin consent especially, is a grant of verbs to an identity that is not a person. A client secret or a certificate is how that identity authenticates. The secret is not the permission. Rotating the secret leaves the permission in place. You can rotate forever and still have Mail.Read, or RoleManagement.ReadWrite.Directory, or whatever was consented, sitting on the principal. The check that names the object is Get-MgServicePrincipalAppRoleAssignment, and the sibling that lists OAuth permission grants. If your review samples group membership and never these, you are reviewing humans and hoping the applications behave.

A credential that is valid on its own. A vaulted password, an unvaulted one, an API key in a pipeline, a break-glass envelope, a certificate in a store. The lie is that vaulting it governed it. Vaulting changes who can see the secret and whether a session was recorded. It does not, by itself, change what the account can do. Classify the secret you found. If what you found is a secret, the object is the account or principal it unlocks, plus the secret's location. A copy in a vault and a copy in a repository are two objects. Closing one ticket and leaving the other copy is a favourite way to finish.

A local account. The application, appliance, database, or SaaS tenant that authenticates against its own store. No federation, or federation for the front door and a local break-glass the vendor insisted on. The lie this object tells is that it is legacy and therefore small. Local accounts are often administrative, because they were created when someone needed to get in and the identity provider was down, or had not been wired, or was never going to be wired. They do not appear in Entra. They do not appear in the governance campaign. They appear when you ask the person who runs the system. Write the store they live in. "Local" is not specific enough to remove. If you will not touch it this month, mark it out of scope and leave the verb visible. An invisible exclusion improves the ratio without touching the estate.

A policy exception. Conditional Access excludes this account. A privileged role can be activated without the usual approval because a group is on an exception list. A firewall rule, a resource lock that is not locked, a grant of "just for the migration". The lie an exception tells is that it is temporary because the ticket said temporary. Temporary is a date. If there is no date, or the date has passed and the exception remains, the exception is the design. Notice when the exception is the thing granting the verb. If deleting it would change nothing, it is a comment, and you are still looking for the object.

Six is enough to sort a neighbourhood. You will meet variants. An access package. A SharePoint group that is not the Entra group of the same name. A Kubernetes role binding. A cloud infrastructure entitlement that no identity governance platform aggregated. Put the variant under the six by asking the same question. What would still work if the catalogue vanished, and which of the six is it closest to? If it is closest to none of them, add a seventh for that neighbourhood and define it in one sentence. Do not add a seventh because a vendor's diagram had seven boxes.

Nested, synced, and inherited

Objects grant access in chains, and reviews like to stop at the first link they understand.

Nesting. A user sits in a group, which sits in a group, which holds the role. The export of the outer group shows the middle group. The export of the user's direct membership shows the inner group, not the role. Walk the chain, including service principals. The mental picture of a group is a list of colleagues, which is why those rows get forgotten.

The cloud group may be a projection. Remove the member in the cloud and the next sync puts them back, if the other directory still owns the membership. Writeback runs the other way, and the cloud review that thinks it has finished will not reopen the attribute. Record the chain in one line: direct, nested through these groups, synced from this directory by this rule, or inherited. "Group" on its own will be argued again next month. "Nested through A and B, synced, rule still enabled" can be acted on.

Inheritance. A permission on a management group, a parent site, a folder, a subscription, granted wide and inherited down. The child resource looks empty of assignments and is not empty of access. Two teams can argue about an identity's role while the resource's own list grants everyone in a legacy group. Look at the resource. The identity-side story is half.

What the three consoles call an object

Entra will show eligible and active assignments if you open the right blade. It does not show a local account in an application it does not govern. A synchronised group does not, by itself, show the stale membership feeding it. Keep the calls that list role assignments, nested membership, and application permissions.

The governance platform shows the model it mapped onto those objects. The model can point at a grant that has already died, or miss a grant that is alive. Reconcile the label to the object. If they disagree, the directory is the grant and the label is the story.

The vault shows accounts and secrets it holds. The object is the account the secret opens, plus any second copy. Onboarded is coverage, not a verb. If you have not looked for the second copy, write unknown.

Managed identities need a separate sentence because they confuse this picture. There is often no password to vault. The object is the role assignment or the access policy on the resource, held by that identity. People go looking for a credential and, finding none, conclude there is nothing to review. The absence of a password is not the absence of a verb.

Conditional Access is not an object that grants. It is an object that can refuse. An exclusion from Conditional Access can be the reason a grant still works from a place you thought was blocked. Treat an exclusion as a policy exception, one of the six. Do not treat a Conditional Access policy as if it were a role. A policy that cannot see the object cannot be the control for the object.

Extending the Monday table

Keep the Monday table. Add columns rather than starting a new workbook nobody will join back up.

Object type, using the six names. If you need a seventh in this neighbourhood, define it at the top of the sheet in a sentence, not in a cell comment.

Object identifier. The group object id, the role assignment id, the service principal and the permission, the local account and the store, the exception and the policy name. Identifiers, not display names alone. Display names collide. Identifiers are what a later change will target.

Chain. Direct, nested, synced, inherited. One line, as above.

Would removing this object stop the verb? Yes, no, or not the only one. "Not the only one" means you have another row for the same verb. This is the column that stops a remediation from closing one door and leaving two.

Fill these columns for the rows that already have a verb. Do not expand the neighbourhood yet. A second neighbourhood with empty object columns is how the method becomes a tour. Depth on the first neighbourhood is what the join needs. It cannot be done from display names.

Inside the month, start with application permissions and direct role assignments, because group-only reviews have already missed them. Then walk nests on the groups you already listed. Then check sync and inheritance on any row where a removal in the cloud might not stick. Then look for a second copy of any secret. Then mark local accounts and exceptions. That order is biased toward the objects user-shaped reviews skip. The bias is intentional.

Do not let an entitlement name be the only entry in the object column. The name can sit in a note. It cannot be the identifier. The drawing of the role model is a target. The table is a description. Overwrite the description with the target and you have lost the delta. Pair a rotation with the permission list, or expect the same principal next month with a new secret and the old verbs.

Application object, service principal, permission, secret

These four get mixed up in every review I have watched, so they get their own pass. They are not four words for one thing.

The application object is the definition. It lives with the registration. It describes the application. It is not, by itself, the identity that calls your tenant at two in the morning.

The service principal is that application as an identity in a tenant. Multi-tenant applications have a principal in each tenant where they are used. The grant you care about is on the principal in your tenant. Reviewing the registration in a home tenant you do not own, and ignoring the principal in the tenant you do, is a common way to look busy in the wrong place.

The permission is the verb list on that principal. Application permissions and delegated permissions are not interchangeable. Delegated means a user is present and the app acts as them, within what the user could already do. Application permission means the app acts as itself, and the user's existence is irrelevant. A review question written for delegated access ("which user approved this?") does not reach an application permission. There is no user in the request. There is a principal and a grant. Admin consent is the moment the grant was created. It is not a recurring check. The grant outlives the meeting in which someone clicked yes.

The secret, or the certificate, is how the principal authenticates. It can expire. It can be rotated. It can leak. A leaked secret on a principal with a narrow permission is a smaller event than a leaked secret on a principal with a directory role. The object that decides the size is the permission, not the leak.

Sponsorship names the who. It does not stand in for the permission list. An agent with a sponsor and a wide app role is a sponsored wide grant. The exit is the empty cell. Record the permission, and record the absence of an end date. The sponsor's name must not collapse those into one reassuring cell.

Eligible, active, and the group that can activate

PIM adds states, and states are objects only in a careful sense. An active role assignment is a grant now. An eligible assignment is a grant available to be activated. The object you would remove to stop both is the assignment. The object you would change to stop a casual activation is the policy on that assignment: approval, authentication context, time limit, who is allowed to activate.

Write the state on the row. Active, or eligible. If the activation rule is doing real work, put it in the chain column. "Eligible" alone will be heard as "not standing" by a sponsor who has not activated anything all year. Some eligible roles are activated by the same person who benefits, with a reason string nobody reads. That is standing access with a form. Say so if that is what the policy allows. If you have not opened the activation policy, the cell is unknown.

Groups that can be activated, and roles assigned to groups that are themselves eligible, stack the problem. You can have an eligible group, a permanent member, and a role on the group. The member is one activation away from the verb, or zero activations away if the group is already active. Walk it.

The Billing-Readers row

The Billing-Readers row is a group in a fictional tenant. It is not a client, not a breach, and not evidence. It is one neighbourhood and one row, so later chapters can talk about the same grant. The blank template underneath is still yours. This row does not fill it.

The neighbourhood is a billing application. The identity, copied as found, is the group Billing-Readers. The owner cell is weak: the only route is a list named billing-platform, and no person answers it. The verb that would succeed this morning is reset credentials on the billing application's user store. The name says readers. The grant does not.

The object is that security group. The chain is nested, and synced from an on-premises group whose rule is still enabled. The permission that makes the verb succeed is an application role on the billing service principal, assigned through the group. Entra knows the group. The governance platform has aggregated an entitlement it calls Billing read, which does not match the verb. There is no credential to vault, because the grant is a permission, not a password. The evidence pointer is the role assignment on the billing enterprise application, together with the sync rule.

Removing the display name would not stop the verb. Removing the application role would, unless a sync or a pipeline puts the role back. That is the whole of the example. When the book says "the Billing-Readers row", it means this one, Figure 2.

Figure 2. The fictional Billing-Readers row, filled only so the columns can be seen. Illustrative. Not a client, not a breach, not evidence.

One row, written as a template

What follows is a blank row in prose, not a tenant, and not the Billing- Readers row above. Fill it with yours. Where a sentence has brackets, the brackets are the work. Leave them empty if you do not yet know.

We found the identity as [the string in the manifest or the local store], not as [the display name the directory prefers]. The verb that would succeed this morning is [verb] on [resource]. The owner we could call is [name], or the who-cell is empty, and we have written which.

The objects that make the verb succeed are these. First, [object type] with identifier [id], chain [direct, nested, synced, or inherited]. Second, if there is a second, the same three facts. We checked whether removing only the first would stop the verb. The answer is [yes, or no, because the second remains].

Entra [knows the identity or does not]. The governance platform calls this [entitlement label], and that label [matches the object or points at something older]. The vault [holds a secret, holds no secret because this is a managed identity, or we have not proved there is no second copy]. Conditional Access [can see this object, or cannot, under the workload limit].

The removal we are not ready to propose would have to cover [every object listed]. A change ticket aimed only at [the friendly name] would leave the verb intact.

Look from the resource as well as from the identity

One last discipline, because identity teams start from identities and the verb lives on the resource. For the handful of resources in the neighbourhood that matter, open the resource's own access list. Not the identity's memberships. The list on the key vault, the subscription, the database, the repository, the SaaS admin console. Write down every principal on that list and match it back to a row you already have.

The principals that match are confirmation. The principals that do not match are rows you missed, and they are often the inherited grant or the local account. This is a second pass, not a new method. It exists because a complete identity-side walk can still miss a grant that was written on the resource and never projected into a group you would have thought to open.

When the resource list and the identity list disagree, believe both until you have walked the chain. Disagreement is not an error in your notes.