Screenshot and Teaching-Aid Backlog
These screenshots and sanitized outputs are for instructor explanation and slide clarity. They are not student submission requirements. Students should learn to explain what an observation means, not collect flags or upload artifacts.
Production Rules
- Use training-tenant sample data whenever possible.
- Remove or blur tenant IDs, user names, email addresses, object IDs, IP addresses, tokens, secrets, and reusable credentials unless the value is synthetic.
- Prefer screenshots that make one concept visible.
- Do not include live tokens, refresh tokens, private keys, client secrets, session cookies, or real logs from non-training tenants.
- If a screenshot shows tool output, use sanitized output and explain which fields matter.
- Add each final asset to the relevant slide only after John confirms the lab or demo path exists.
Portal Screenshots
Enterprise Applications: Service Principal View
- Phase: 1 / 4
- Teaching job: show that a service principal is the tenant-local representation students will often inspect.
- Highlight: owners, permissions, assignments, sign-in visibility if present.
- Do not require: students submitting app screenshots.
App Registrations: Application Object View
- Phase: 1 / 4
- Teaching job: contrast application object with enterprise application / service principal.
- Highlight: app ID, redirect URI area, API permissions, certificates/secrets location.
- Sanitization: use synthetic app names and hide object IDs unless needed.
Consent Prompt or Consent Configuration
- Phase: 2
- Teaching job: make user consent vs admin consent understandable.
- Highlight: requested scopes, publisher/app identity, approval boundary.
- Avoid: real phishing language or lure examples.
Admin Consent Workflow
- Phase: 2 / 6
- Teaching job: show the defensive workflow that changes consent risk.
- Highlight: request, reviewer, decision, policy link.
- Sanitization: use training request examples only.
Conditional Access Policy Scope
- Phase: 6
- Teaching job: show that CA effectiveness depends on users, apps, conditions, and grant controls.
- Highlight: included apps/users, exclusions, grant controls.
- Avoid: real production policy screenshots.
Sign-In Log Teaching View
- Phase: 2 / 6
- Teaching job: show what defenders and students can observe after auth and consent activity.
- Highlight: user, app, status, CA result, risk fields if available.
- Sanitization: blur identifiers and IP addresses unless synthetic.
Azure Role Assignment Scope
- Phase: 5
- Teaching job: show subscription/resource group/resource scope differences.
- Highlight: principal, role, scope, inherited vs direct assignment.
- Avoid: real subscription IDs.
Storage Access Control View
- Phase: 5
- Teaching job: contrast management access with Blob data access.
- Highlight: Storage Blob data roles, role scope, container/blob view.
- Sanitization: use sample container names and non-sensitive blobs.
Key Vault Access Boundary
- Phase: 5
- Teaching job: show the access model and why control plane/data plane matters.
- Highlight: RBAC mode or access policy mode, role assignments, secret/certificate area without values.
- Avoid: secret names that imply real operations.
Managed Identity Configuration
- Phase: 5
- Teaching job: show where managed identity exists and which resource it belongs to.
- Highlight: system-assigned vs user-assigned identity, target resource permissions.
- Avoid: token endpoint output in portal screenshots.
Sanitized Tool Output
ROADrecon Tenant Overview
- Phase: 3
- Teaching job: show how raw directory collection becomes questions about relationships.
- Highlight: users/groups/apps/SPs/roles counts, relationship pivots.
- Sanitization: replace tenant and object names with classroom examples.
ROADtools or Graph Query Example
- Phase: 3 / 4
- Teaching job: show the difference between "can query" and "can abuse".
- Highlight: selected fields only, such as displayName, appId, owners, appRoles.
- Avoid: full JSON dumps in slides.
App Role Assignment Snippet
- Phase: 4
- Teaching job: show what an app role assignment looks like and why it matters.
- Highlight: principal, resource, appRoleId or readable mapping.
- Sanitization: synthetic IDs and names.
Defensive Observation Examples
- Phase: 6
- Teaching job: show how a defender would observe consent, sign-in, app change, or resource access.
- Highlight: event type, actor, target, result, next question.
- Avoid: framing this as something students must submit.
Optional Later Assets
- Cross-tenant sync portal view if promoted from parking lot.
- Azure Lighthouse delegated resource view if promoted from parking lot.
- Entra Connect / ADFS topology screenshot or diagram if promoted from parking lot.
- Intune device compliance view if promoted from parking lot.
Original Markdown source
# Screenshot and Teaching-Aid Backlog
These screenshots and sanitized outputs are for instructor explanation and slide clarity. They are not student submission requirements. Students should learn to explain what an observation means, not collect flags or upload artifacts.
## Production Rules
- Use training-tenant sample data whenever possible.
- Remove or blur tenant IDs, user names, email addresses, object IDs, IP addresses, tokens, secrets, and reusable credentials unless the value is synthetic.
- Prefer screenshots that make one concept visible.
- Do not include live tokens, refresh tokens, private keys, client secrets, session cookies, or real logs from non-training tenants.
- If a screenshot shows tool output, use sanitized output and explain which fields matter.
- Add each final asset to the relevant slide only after John confirms the lab or demo path exists.
## Portal Screenshots
### Enterprise Applications: Service Principal View
- Phase: 1 / 4
- Teaching job: show that a service principal is the tenant-local representation students will often inspect.
- Highlight: owners, permissions, assignments, sign-in visibility if present.
- Do not require: students submitting app screenshots.
### App Registrations: Application Object View
- Phase: 1 / 4
- Teaching job: contrast application object with enterprise application / service principal.
- Highlight: app ID, redirect URI area, API permissions, certificates/secrets location.
- Sanitization: use synthetic app names and hide object IDs unless needed.
### Consent Prompt or Consent Configuration
- Phase: 2
- Teaching job: make user consent vs admin consent understandable.
- Highlight: requested scopes, publisher/app identity, approval boundary.
- Avoid: real phishing language or lure examples.
### Admin Consent Workflow
- Phase: 2 / 6
- Teaching job: show the defensive workflow that changes consent risk.
- Highlight: request, reviewer, decision, policy link.
- Sanitization: use training request examples only.
### Conditional Access Policy Scope
- Phase: 6
- Teaching job: show that CA effectiveness depends on users, apps, conditions, and grant controls.
- Highlight: included apps/users, exclusions, grant controls.
- Avoid: real production policy screenshots.
### Sign-In Log Teaching View
- Phase: 2 / 6
- Teaching job: show what defenders and students can observe after auth and consent activity.
- Highlight: user, app, status, CA result, risk fields if available.
- Sanitization: blur identifiers and IP addresses unless synthetic.
### Azure Role Assignment Scope
- Phase: 5
- Teaching job: show subscription/resource group/resource scope differences.
- Highlight: principal, role, scope, inherited vs direct assignment.
- Avoid: real subscription IDs.
### Storage Access Control View
- Phase: 5
- Teaching job: contrast management access with Blob data access.
- Highlight: Storage Blob data roles, role scope, container/blob view.
- Sanitization: use sample container names and non-sensitive blobs.
### Key Vault Access Boundary
- Phase: 5
- Teaching job: show the access model and why control plane/data plane matters.
- Highlight: RBAC mode or access policy mode, role assignments, secret/certificate area without values.
- Avoid: secret names that imply real operations.
### Managed Identity Configuration
- Phase: 5
- Teaching job: show where managed identity exists and which resource it belongs to.
- Highlight: system-assigned vs user-assigned identity, target resource permissions.
- Avoid: token endpoint output in portal screenshots.
## Sanitized Tool Output
### ROADrecon Tenant Overview
- Phase: 3
- Teaching job: show how raw directory collection becomes questions about relationships.
- Highlight: users/groups/apps/SPs/roles counts, relationship pivots.
- Sanitization: replace tenant and object names with classroom examples.
### ROADtools or Graph Query Example
- Phase: 3 / 4
- Teaching job: show the difference between "can query" and "can abuse".
- Highlight: selected fields only, such as displayName, appId, owners, appRoles.
- Avoid: full JSON dumps in slides.
### App Role Assignment Snippet
- Phase: 4
- Teaching job: show what an app role assignment looks like and why it matters.
- Highlight: principal, resource, appRoleId or readable mapping.
- Sanitization: synthetic IDs and names.
### Defensive Observation Examples
- Phase: 6
- Teaching job: show how a defender would observe consent, sign-in, app change, or resource access.
- Highlight: event type, actor, target, result, next question.
- Avoid: framing this as something students must submit.
## Optional Later Assets
- Cross-tenant sync portal view if promoted from parking lot.
- Azure Lighthouse delegated resource view if promoted from parking lot.
- Entra Connect / ADFS topology screenshot or diagram if promoted from parking lot.
- Intune device compliance view if promoted from parking lot.