Principals

principals

principals is the identity inventory command for AzureFox.

Use it when you need to understand which users, groups, service principals, and managed identities are visible in the current tenant context before you decide which identity path deserves deeper review.

What This Command Answers

• Which identities are visible here?
• What kinds of principals dominate this environment?
• Which identities look unusual, central, or worth investigating first?

Run It

azurefox principals --output table

For saved structured output:

azurefox principals --output json

Example Table Output

principal	type	roles	assignments	identity context	current
azurefox-lab-sp	ServicePrincipal	Owner	1	identities=ua-app; attached=1	yes
operator@lab.local	User	Reader	1	-	no

When To Use It

• after Whoami confirms your session is correct
• when you need a first pass over the visible identity landscape
• before deciding whether to focus on privilege, trust, or workload-linked identity review

What To Look For

• service principals and managed identities with obvious workload relevance
• identity types that appear repeatedly across the visible environment
• unusual naming patterns, incomplete records, or identities that look more central than the rest
• identity classes that tell you which follow-on command is likely to matter most

Why It Matters

Identity review starts with understanding what is actually present.

If you do not know whether the tenant is dominated by user accounts, service principals, managed identities, or groups, it is easy to waste time on the wrong follow-up. principals gives you a usable inventory so later privilege and trust analysis starts from the right place.

What Should Stand Out First

• service principals and managed identities with strong workload relevance
• unusual or incomplete identity records
• identity classes labeled clearly enough to guide the next follow-up
• repeated or central-looking identities that deserve a second look

If You See..., Go Next To...

• If you see role_names already include a high-impact role such as Owner, go next to Permissions because it confirms whether that identity is one of the strongest Azure control paths in the tenant.
• If you see attached_to point at a VM, App Service, or Function App, go next to Managed-Identities because it shows the workload-to-identity path you can actually follow.
• If the interesting row is an application-linked or service-principal identity, go next to Role-Trusts because it explains who can modify it or trust into it.

What To Do Next

• Use Permissions to find the most powerful visible principals.
• Use Role Trusts when ownership or federation matters more than direct role assignment.
• Use Managed Identities when workload-linked identities are likely to be the real pivot path.

Boundary

principals is an inventory and first-pass triage command.

It should make the identity landscape understandable. It is not a full Entra graph explorer or a complete privilege model.