Troubleshooting
Find answers to common questions and solutions to frequently encountered issues when using Access Optimization.
Common Issues Covered
- Unused findings: Why active roles show as unused
- Dynamic counts: Why optimization counts change between scans
- Group details: Missing group member information
- Over-privileged: Legitimate critical role assignments flagged
- Missing principals: Why healthy access isn't displayed
- Over-scoped: Unexpected scope efficiency results
- Export: How to export filtered subsets
Why am I seeing "unused" findings for a role I know is actively used?
Answer
Activity logs only capture write operations (create, update, delete, RBAC changes), not read operations. If a user has a role primarily for viewing data, monitoring dashboards, or reading logs, their read activity is not captured in Azure Activity Logs.
Resolution Steps
Step 1: Review role permissions
Is it read-only (Reader, Monitoring Reader, Log Analytics Reader)?
Step 2: If read-only role
Unused detection is not applicable (Azure limitation)
Consider filtering out read-only roles from reports
Step 3: If not read-only
Navigate to Azure Portal → Activity Log → Filter by user's UPN
Check if operations appear in portal but not in StratoLens (may indicate correlation issue)
Step 4: Documentation
For read-only roles, document in your audit process that "unused" findings don't apply due to Azure logging limitations
Consider excluding Role Type: Read from optimization type filters when reviewing unused access
Real-World Scenario
User has "Log Analytics Reader" role flagged as unused. This is expected - they read dashboards daily but activity logs don't capture read operations. Document as "Appropriate - read-only role for dashboard access" and keep assignment.
Why does the optimization count change between scans even though I haven't made changes?
Answer
Optimization detection is dynamic and based on rolling time windows and current activity data. As time passes, the same assignment's status can change:
- Access that was "active" 10 days ago may become "stale" today if no new activity occurs (crosses stale threshold)
- Access that was "stale" yesterday may become "active" today if new operations are performed
- Activity log data is continuously aggregated - new activity from the last 5-15 minutes appears in subsequent scans
Management Strategies
Focus on Persistent Findings
Track findings that persist across multiple scans (e.g., access unused for weeks or months)
Use Longer Windows
180-365 days for more stable optimization detection
Higher Stale Threshold
Set to 70% to focus on clearly abandoned access rather than recent inactivity
Track Trends
Monitor trends over time rather than absolute counts (improving vs. worsening)
Dynamic Behavior Example
User's Contributor assignment shows "stale" on Monday (last activity 16 days ago, 50% threshold in 30-day window). User performs operations on Tuesday. Wednesday's scan shows assignment as "active" again (recent activity). This is correct dynamic behavior.
Why don't I see group member details for some assignments?
Answer
Group member resolution requires Microsoft Graph API permissions (Group.Read.All, User.Read.All, Application.Read.All). If the StratoLens managed identity lacks these permissions, Access Optimization can detect that access is granted via a group but cannot list the individual members.
Resolution Steps
1. Verify Permissions
Check StratoLens has required Microsoft Graph API permissions:
- Azure Portal → Azure Active Directory → Enterprise Applications
- Find StratoLens application registration
- Check API Permissions → Microsoft Graph
- Confirm Group.Read.All, User.Read.All, Application.Read.All are present and admin-consented
2. If Permissions Missing
- Contact your Azure AD administrator to grant permissions
- Permissions require admin consent (cannot be user-consented)
3. After Permissions Granted
- Wait for next scan (5 minutes) or trigger manual scan
- Group member details should appear in subsequent scans
4. Temporary Workaround
- Manually look up group members in Azure Portal → Azure Active Directory → Groups
- Document group-based access in audit reports as "Access via Group [Name] - see Azure AD for members"
Before and After
Assignment shows "via Engineering Team" but no nested group chain or member list. Check permissions → Missing Group.Read.All. After admin grants permission and consent, next scan shows "via Engineering Team → All Employees" with member details.
Why is a user shown as "over-privileged" when they legitimately need Owner role?
Answer
Over-privileged detection is based on observed usage in activity logs, not business requirements. If a user has Owner role but hasn't performed any RBAC operations (role assignments, permission grants) in the selected time window, they're flagged as over-privileged. This is a detection to prompt review, not a definitive declaration that access is wrong.
Common Scenarios and Actions
Disaster Recovery / Emergency Access
User needs Owner for emergency scenarios but hasn't used it yet
Action: Document business justification "Owner role for disaster recovery - break-glass access"
Keep assignment, add to exception list for quarterly reviews
Seasonal / Quarterly Usage
User manages access during specific periods (quarterly audits, seasonal onboarding)
Action: Expand time window to 365 days to capture infrequent but legitimate usage
If still flagged, document "Quarterly access review responsibilities - October usage not captured in current window"
Actually Over-Privileged
User only creates/manages resources, never assigns roles or manages permissions
Action: Downgrade to Contributor (resource management without RBAC management)
User can still perform all their regular work
Pending Responsibilities
User was granted Owner for upcoming project but hasn't started RBAC management yet
Action: Document "Owner granted for Project Phoenix - RBAC management starts Q2"
Set reminder to verify usage after project start
Verification Method
Click "View in Activity Explorer" → Filter by Operation Type: RBAC to see if any permission management operations exist outside the current time window.
Investigation Result
User has Owner role flagged as over-privileged in 30-day window. Check 365-day window → Still no RBAC operations. Check with user → They only manage VMs and storage. Conclusion: Downgrade to Contributor is appropriate.
Why don't I see all principals with access in Access Optimization?
Answer
Access Optimization only shows principals with at least one optimization finding (unused, stale, over-privileged, over-scoped, excessive sprawl, or redundant). Principals with "healthy" access (active recent usage, appropriately scoped, no redundancy) are not displayed. This is by design - the feature focuses on problematic access requiring attention, not comprehensive access inventory.
How to View All Assignments
- Complete Inventory
- Navigate to Access Control → Role Assignments
- Shows
- All assignments, all principals (no filtering by optimization findings)
- Use Case
- Comprehensive access audits and complete RBAC inventory
- Access Optimization Use Case
- Targeted remediation of problematic access only
Comparison
Scenario: Organization has 200 principals with RBAC assignments
Access Optimization
Shows 35 principals (those with optimization findings)
Role Assignments
Shows all 200 principals (complete inventory)
Note: Both views serve different purposes
Why does "over-scoped" detection show different results than I expected?
Answer
Over-scoped detection uses real entity counts from the most recent scan data, not estimates. The calculation is precise:
- Count total entities in the assignment's scope (all resources in subscription, all resource groups in management group, etc.)
- Count unique entities the principal has performed operations on (from activity logs)
- Calculate scope efficiency: (active entities / total entities) × 100
- Flag if scope efficiency < over-scoped threshold percentage
Verification Checklist
Check Assignment Scope
- Is it actually subscription-wide or just a resource group?
- Detail panel shows scope type (management group/subscription/resource group/resource)
Verify Entity Counts
- Detail panel shows "X of Y scopes" (e.g., "3 of 20 scopes")
- Check if total count matches your expectation
- If counts seem wrong, scan may be outdated (check scan timestamp)
Review Scan Freshness
- Check scan timestamp in header (e.g., "2 hours ago")
- Recent resource changes may not be reflected in older scans
- Trigger new scan or wait for next automatic scan (5 minutes)
Adjust Threshold If Needed
- Default 30% threshold may not match your organization's definition of "over-scoped"
- Some organizations use 20% (more aggressive), others use 50% (more conservative)
- Configure threshold to match your policies
Investigation Walkthrough
User flagged as over-scoped with "5% scope efficiency (3 of 60 scopes)". You expect only 20 total resources. Investigation: Scan is 6 hours old, 40 resources were created this morning and aren't in scan yet. Wait for next scan → Shows "3 of 63 scopes" but still <30% threshold, correctly flagged.
Why do some redundant assignments show as both hierarchy and supersession?
Answer
A single role assignment can exhibit multiple types of redundancy simultaneously. This is correct behavior - the assignment is redundant in multiple ways.
Example Scenario
Parent Scope: Owner on subscription "Production"
Hierarchy parent scope
Child Scope: Owner on resource group "Production-Apps"
Hierarchy child scope (redundant with parent)
Same Scope: Contributor on "Production-Apps"
Supersession (Owner includes all Contributor permissions)
Result: Resource group Owner assignment shows:
- Redundancy: "Hierarchy Inheritance" (covered by subscription Owner)
- Redundancy: "Role Supersession" (also has Contributor on same scope)
Remediation Priority
Priority 1
Remove subscription-level Owner if resource group Owner is sufficient (reduce blast radius)
Priority 2
Remove resource group Contributor (superseded by Owner on same scope)
Final State
User has Owner on resource group only (minimum necessary access)
Common Pattern
Multi-redundant assignments often result from:
- Manual access grants without review of existing permissions
- Multiple administrators independently granting access
- Copy-paste role assignments without deduplication
- Automated provisioning without conflict detection
Can I export only specific optimization types or principals?
Answer
The export function (if available) exports all visible findings based on active filters. You control what's exported by applying filters before exporting.
Export Workflow
1. Apply Filters Before Export
- Optimization Type filter: Select only types you want (e.g., only "Unused" and "Over-Privileged")
- Principal Type filter: Limit to Users, Service Principals, or Groups
- Role Type filter: Focus on critical/management roles
- Search: Filter by specific principal names (partial match supported)
2. Verify Filtered Results
Confirm the principal list shows only the subset you want
3. Export
Click Export button (top-right, if available) → Download as CSV or JSON
4. Further Analysis
Open in Excel/spreadsheet tool for further analysis or formatting
Example Export Scenarios
Quarterly Audit of Critical Roles
Filter: Role Type: Critical, Optimization Type: Over-Privileged, Unused
Export: CSV with only Owner/UAA assignments that are problematic
Service Principal Cleanup
Filter: Principal Type: Service Principal, Optimization Type: Unused, Stale
Export: JSON for automation scripts to process removals
User Offboarding Verification
Search: "alice@contoso.com"
Filter: Optimization Type: Unused
Export: CSV showing all Alice's unused assignments for offboarding checklist
Export Functionality Not Available?
If export functionality is not yet available in the UI, you can:
- Take screenshots of detail panels for documentation
- Copy principal names and optimization details to spreadsheet manually
- Request export feature enhancement from StratoLens team
Why does Access Optimization show findings for service principals and managed identities?
Answer
Service principals and managed identities (application identities) can also have over-privileged, over-scoped, or unused access. They follow the same optimization logic as user principals. This is by design - all identity types should follow least-privilege principles.
Review Guidelines
Service Principals (applications, automation accounts)
- Common issue: Owner when only Contributor needed (resource creation/management without RBAC)
- Over-scoped: Subscription access when only one resource group used
- Unused: Decommissioned applications with lingering access
Example: Service principal for CI/CD pipeline has Owner but only deploys resources → Downgrade to Contributor
Managed Identities (VM-attached, function app identities)
- Common issue: Broad subscription access when only specific resources needed
- Over-scoped: Full subscription when identity only accesses Key Vault and Storage Account
- Redundant: Same managed identity assigned multiple times at different scopes
Example: Function app managed identity has Contributor on subscription but only reads from one Key Vault → Rescope to Key Vault Secrets User on that specific Key Vault
Investigation Process
- Click service principal/managed identity in principal list
- Review operations performed in Activity Explorer
- Identify minimum permissions required
- Downgrade or rescope accordingly
Best Practices
Service principals and managed identities should have even more restrictive access than users (automated = predictable usage patterns)
Use custom roles for service principals with exact permissions needed
Regularly audit application identities - decommissioned apps often leave orphaned service principals
Filter by Principal Type: Service Principal to focus reviews on application access
Real-World Remediation
Managed identity for VM "backup-processor" has Contributor on subscription with 200 resources. Activity shows it only writes to one storage account. Remediation: Create custom role "Backup Writer" with Storage Blob Data Contributor, rescope to storage account only.