Lab 04 – Identity Security Hardening & Best Practices

Real-Life Scenario

Company: Acme Corporation

Acme Corp is a mid-sized SaaS company with 500+ employees and Azure infrastructure managing critical customer data. Last month, their annual security audit revealed serious identity and access control gaps:

Audit Findings:

1. 47 users with Owner role who only need Reader/Contributor
2. 23 inactive employee accounts still have active access
3. Zero MFA protection on administrative accounts
4. No alerting for suspicious sign-in patterns
5. 180+ individual role assignments (should be group-based)
6. No formal approval process for privilege elevation
7. 8 departing employees with lingering access credentials
8. 12 apps using hardcoded passwords instead of managed identities

Your Role: Identity Security Engineer

Mission: Implement all 8 best practices to remediate these findings and pass a follow-up audit.

Success Criteria: Complete all parts, implement all best practices, document findings.

Prerequisites

Required Knowledge:

1. Lab 01: Entra ID - Users & Groups
2. Lab 02: RBAC & Azure Policy
3. Lab 03: Management Groups & Subscriptions

Required Permissions:

1. Global Administrator or User Administrator role in Entra ID
2. Owner role on test subscription
3. Access to Azure Portal

Estimated Time

Total: 250 minutes (~4+ hours)

1. Part 1: 30 minutes
2. Part 2: 30 minutes
3. Part 3: 40 minutes
4. Part 4: 30 minutes
5. Part 5: 30 minutes
6. Part 6: 40 minutes
7. Part 7: 20 minutes
8. Part 8: 30 minutes

Difficulty: Advanced

Part 1 – Least Privilege Assessment & Remediation

The Challenge

Acme Corp has a "just give them Owner role" culture. Your first task: identify over-privileged users and reduce their access to minimum required.

What You'll Learn

1. How to audit current RBAC assignments
2. How to identify over-privileged roles
3. How to create custom roles for specific needs
4. How to reduce attack surface

Step-by-Step Tasks

Step 1: Audit Current Role Assignments

1. Navigate to Azure Portal > Subscriptions > Access control (IAM)
2. Review all role assignments at subscription level
3. Document users with each role:

- Owner roles (should be <5 people)

- Contributor roles (should be business-justified)

- Reader roles (should be majority)

1. Identify candidates for privilege reduction

Example Documentation Format:

Current State Analysis:
├─ Owner (10 users - reduce to 3)
│  ├─ Alice Smith (CTO) - KEEP
│  ├─ Bob Johnson (DevOps Lead) - REDUCE to Contributor
│  └─ Charlie Lee (Developer) - REDUCE to specific contributor role
├─ Contributor (35 users - acceptable)
├─ Reader (80 users - acceptable)
└─ Custom Roles (0 - NEED TO CREATE)

Step 2: Identify Principle of Least Privilege Violations

Create a table with each user and recommended action:

| User | Current Role | Job Function | Recommended Role | Justification |


------
-------------
--------------
------------------
---------------



| Charlie Lee | Owner | Debug issues | Reader + VM Contributor (staging only) | Should not have production access |

Step 3: Create Custom Roles (If Needed)

For users needing specific permissions that don't fit built-in roles:

1. Navigate to Azure Portal > Subscriptions > Access control (IAM) > Roles
2. Click Create a custom role
3. Example: "Blob Storage Operator" role

- Permissions: Read blobs, Upload blobs, Delete own blobs

- Exclude: Delete storage account, Change access policies

1. Name: Storage Blob Operator - Development
2. Assign to specific user/group

Step 4: Remove Over-Privileged Access

For each user identified in Step 1:

1. Go to Access control (IAM)
2. Click the user's current role (e.g., Owner)
3. Select Remove
4. Confirm removal
5. Add appropriate lower-privilege role

Example actions:

Alice Smith: Owner (KEEP) - CEO needs full access
Bob Johnson: Owner → Contributor (reduce from Owner, keep deployment capability)
Charlie Lee: Owner → Container Registry Acrpush role (only push images)
Diana Park: Contributor → Reader + Virtual Machine Contributor (read-only, can only manage VMs)

Validation Checklist

1. [ ] Documented all current role assignments
2. [ ] Identified at least 3 users with excessive privileges
3. [ ] Created at least 1 custom role for specific needs
4. [ ] Reduced privilege for 2+ over-privileged users
5. [ ] Verified reduced users can still perform their jobs
6. [ ] No Owner roles remain except for essential administrators

Success Criteria

✅ Complete: Privilege surface reduced by minimum 40%

✅ All Owner roles are business-justified

✅ Custom roles created for specific job functions

✅ Access changes documented with justification

Part 2 – Quarterly Access Review & Orphaned Account Cleanup

The Challenge

Acme has 23 inactive employee accounts with active access. Find and clean up orphaned accounts and permission creep.

What You'll Learn

1. How to identify inactive users
2. How to review access by user
3. How to disable and remove access safely
4. How to clean up permission creep

Step-by-Step Tasks

Step 1: Identify Inactive Accounts

1. Go to Azure Portal > Entra ID > Users
2. Create a list of users with:

- Last sign-in date > 90 days ago (or never signed in)

- Still assigned to groups/roles

- Status: Active (should be Disabled if not needed)

1. For each inactive user, document:

- Name

- Department

- Last sign-in date

- Current groups

- Current role assignments

Example Inactive Accounts Found:

Michael Brown
├─ Department: Engineering (transferred to DevOps)
├─ Last Sign-in: 180 days ago
├─ Groups: grp-engineers-deploy, grp-production-access
├─ Roles: Contributor (test subscription)
└─ Status: INACTIVE - should be disabled

Sarah Davis
├─ Department: Marketing (left company 6 months ago)
├─ Last Sign-in: 200 days ago
├─ Groups: grp-all-users, grp-marketing
├─ Roles: Reader (production)
└─ Status: ORPHANED - should be deleted

Step 2: Conduct Quarterly Access Review

For each user with access, ask:

Access Review Questionnaire:
Is this user still employed? → If NO, disable/delete
Are they in the correct role for their current job? → If NO, update
When was their access last used? → If >90 days, question necessity
Do they still need each group membership? → If NO, remove
Any suspicious activity on this account? → If YES, investigate

Step 3: Remediate Findings

For each finding:

If User is Inactive (>90 days, employed):

1. Contact manager: "Does [user] need [role] for [resource]?"
2. If NO: Remove from groups and role assignments
3. If MAYBE: Add calendar reminder for follow-up in 30 days
4. Document decision

If User Has Left Company:

1. Go to Entra ID > Users
2. Find user
3. Click Delete user
4. Confirm deletion (this removes all group memberships and roles)

If Permission Creep (user has many roles they don't need):

1. Review each role assignment
2. Ask: "Is this still needed?"
3. Remove unnecessary assignments

Step 4: Document Access Review

Create a summary:

Q2 2024 Access Review Summary
────────────────────────────

Actions Taken:
├─ 6 inactive users: Removed from groups and roles
├─ 4 departed employees: Accounts deleted
├─ 12 users: Updated roles to match current job
├─ 8 users: Removed from unnecessary groups

Permission Creep Eliminated:
├─ 23 unnecessary role assignments removed
├─ 15 obsolete group memberships cleaned

Next Steps:
└─ Schedule Q3 review for [date]

Validation Checklist

1. [ ] Identified all inactive accounts (>90 days)
2. [ ] Reviewed access for minimum 15 users
3. [ ] Documented access review findings
4. [ ] Removed access for at least 2 inactive users
5. [ ] Deleted at least 1 orphaned account
6. [ ] Created remediation summary with dates

Success Criteria

✅ Complete: Removed access for all orphaned accounts

✅ Cleaned up minimum 20 unnecessary role assignments

✅ Documented quarterly review process

✅ Established future review schedule

Part 3 – Enable MFA & Conditional Access Policies

The Challenge

Zero MFA protection on 12 administrative accounts. Implement MFA and configure conditional access for risk-based authentication.

What You'll Learn

1. How to enforce MFA for admin roles
2. How to configure Conditional Access policies
3. How to set up risk-based authentication
4. How to balance security with usability

Step-by-Step Tasks

Step 1: Configure MFA for Global Admin Roles

1. Navigate to Azure Portal > Entra ID > Security > Conditional Access
2. Click + New policy
3. Name: "Require MFA for Global Admins"
4. Configure:

- Users: Select role: Global Administrator

- Cloud apps or actions: All cloud apps

- Conditions: None required (applies to all sign-ins)

- Grant: Require multi-factor authentication

1. Enable: On
2. Click Create

Step 2: Test MFA Enforcement

1. Sign out of Azure Portal
2. Sign in with a Global Admin account
3. Verify MFA prompt appears
4. Complete MFA challenge (use Authenticator app, Windows Hello, or FIDO2)
5. Verify successful sign-in

Step 3: Configure Risk-Based Conditional Access

Create a policy that requires MFA only for risky sign-ins:

1. New policy: "Risk-Based MFA for All Users"
2. Configure:

- Users: All users

- Cloud apps: All cloud apps

- Conditions:

- Sign-in risk: High, Medium

- Grant: Require multi-factor authentication

1. Enable and Create

Step 4: Set Up Unusual Location Detection

1. New policy: "Block or Require MFA for Unusual Locations"
2. Configure:

- Users: All users (except emergency access accounts)

- Cloud apps: All cloud apps

- Conditions:

- Locations: Exclude Trusted locations, Include All other locations

- New/Unfamiliar locations: Yes

- Grant: Require multi-factor authentication

1. Enable and Create

Step 5: Test Conditional Access Policies

Test scenarios:

1. [ ] Sign in from normal location → No MFA required
2. [ ] Sign in from new/unusual location → MFA required
3. [ ] Admin sign-in → MFA always required
4. [ ] Risky sign-in (multiple failed attempts) → MFA required

Step 6: Register MFA Methods for All Users

For successful MFA, users need registered devices:

1. Entra ID > Users > Per-user MFA
2. For each admin user:

- Send them: "Please register MFA: https://aka.ms/setupsecurityinfo"

- Ask them to register:

- Primary: Authenticator app (Microsoft Authenticator)

- Backup: Windows Hello or FIDO2 key

Validation Checklist

1. [ ] MFA required policy created for Global Admins
2. [ ] Tested MFA prompt on admin sign-in
3. [ ] Risk-based MFA policy configured
4. [ ] Unusual location policy configured
5. [ ] All admin users have registered MFA method
6. [ ] Conditional Access policies enabled and tested

Success Criteria

✅ Complete: All admins require MFA on every sign-in

✅ Risk-based MFA configured for all users

✅ Unusual location detection active

✅ MFA methods registered and tested

Part 4 – Sign-in Monitoring & Security Alerts

The Challenge

No alerting for suspicious sign-ins. Configure monitoring to detect breach patterns and create alerts.

What You'll Learn

1. How to review sign-in logs
2. How to identify suspicious patterns
3. How to set up Azure Monitor alerts
4. How to create action plans for incidents

Step-by-Step Tasks

Step 1: Review Sign-in Logs

1. Navigate to Azure Portal > Entra ID > Sign-in logs
2. Review last 7 days of sign-ins
3. Look for:

- Failed sign-in attempts (>5 from same user)

- Sign-ins from unusual locations

- Sign-ins outside business hours

- Bulk changes by unusual users

- Access to sensitive resources

1. Document suspicious patterns:

Sign-In Analysis (Last 7 Days)
────────────────────────────

High Risk Findings:
├─ User: john.smith@acme.com
│  ├─ Failed attempts: 12 in 1 hour (password guessing attempt?)
│  ├─ Location: Unknown (VPN detected)
│  ├─ Time: 2:00 AM (unusual)
│  └─ Action: INVESTIGATE - potential compromise
│
├─ User: admin@acme.com
│  ├─ Bulk access changes: Added to 5 sensitive groups
│  ├─ Location: Malaysia (company is US-based)
│  ├─ Time: Outside business hours
│  └─ Action: VERIFY - possible unauthorized access

Step 2: Create Azure Monitor Alerts

1. Go to Azure Portal > Monitor > Alerts > Create > Alert Rule
2. Alert 1: Failed Sign-in Attempts

- Resource: Entra ID

- Signal: Sign-in activity (Entra ID logs)

- Condition:

- > 5 failed sign-in attempts

- Within 5 minutes

- Action: Email to security team

1. Alert 2: Sign-in from Unusual Location

- Condition:

- Sign-in risk level = High

- Unfamiliar location detected

- Action: Email admin, create ticket

1. Alert 3: Bulk Changes by One User

- Condition:

- Multiple role assignments by single user

- Multiple group membership changes by single user

- Action: Require manual review before completion

1. Test alerts:

Incident Response Playbook
═══════════════════════════

Alert: Multiple Failed Sign-in Attempts
──────────────────────────────
Check alert: How many failed attempts?
Contact user: "Is this you? Any account issues?"
If user: "Use password reset or MFA recovery"
If compromised: Lock account immediately
Document: When, who, what actions taken

Alert: Sign-in from Unusual Location
──────────────────────────────
Check alert: Where is the location?
Contact user: "Did you sign in from [location]?"
If YES: Approve and add location to trusted list (optional)
If NO: Password reset + full account audit
Document: Security incident

Alert: Bulk Changes by User
──────────────────────────────
Review: What changes were made?
Verify: Are they legitimate/authorized?
If legitimate: Document business reason
If suspicious: Roll back changes immediately
Contact user: Investigate if account compromised

Step 4: Test Monitoring & Alerts

Simulate suspicious activity:

1. Test Failed Sign-ins: Attempt to sign in with wrong password 6 times

- Verify: Account locks after 5 failed attempts

- Verify: Alert fires

- Verify: Email received

1. Test Unusual Location: Use a VPN to sign in

- Verify: Location shows differently

- Verify: Conditional Access triggers MFA

- Verify: Alert created (if configured)

Validation Checklist

1. [ ] Reviewed sign-in logs and documented findings
2. [ ] Created at least 2 monitor alert rules
3. [ ] Tested alert by triggering suspicious activity
4. [ ] Received alert notification (email/Teams)
5. [ ] Created incident response playbook
6. [ ] Established escalation process

Success Criteria

✅ Complete: Monitor alerts detect suspicious sign-in patterns

✅ All alerts configured and tested

✅ Incident response procedures documented

✅ Security team knows escalation process

Part 5 – Group-Based Access Governance

The Challenge

180+ individual role assignments instead of group-based. Migrate all human access to groups for scalability.

What You'll Learn

1. How to create security groups for access management
2. How to migrate individual assignments to groups
3. How to implement group-based RBAC
4. How to audit group membership at scale

Step-by-Step Tasks

Step 1: Plan Group Structure

Create a group naming scheme and structure:

Group Naming Convention: grp-[department]-[role]

Examples:
├─ grp-engineering-contributors (Contributor role)
├─ grp-engineering-readers (Reader role)
├─ grp-operations-admins (Owner role on OPS resources)
├─ grp-marketing-readers (Reader role)
├─ grp-finance-auditors (Reader role on billing)
├─ grp-support-vm-managers (VM Operator role)
└─ grp-security-admins (Global Admin)

Step 2: Create Security Groups

1. Go to Azure Portal > Entra ID > Groups > New group
2. Create security groups based on your plan:

For each group:

1. Group type: Security
2. Group name: grp-[department]-[role]
3. Description: "Access [resource] with [role] for [department]"
4. Membership: Start empty (add users in next step)

Example creation:

Group: grp-engineering-contributors
├─ Type: Security
├─ Description: Engineering team with Contributor role on development resources
├─ Members: (to be populated)
└─ Owners: Engineering Lead + Security Team

Step 3: Populate Groups

1. For each group, identify current users with that role
2. Add them to appropriate group:

- Go to Entra ID > Groups > [Group Name]

- Click Members > Add members

- Select all users needing that role

- Click Select

1. Document migration:

Migration Plan
──────────────

grp-engineering-contributors:
├─ From: 15 individual Contributor assignments
├─ To: grp-engineering-contributors (15 members)
├─ Verification: Each member can still perform their job
└─ Status: ✅ Migrated

grp-operations-admins:
├─ From: 8 individual Owner assignments
├─ To: grp-operations-admins (8 members)
├─ Verification: OPS team confirms access
└─ Status: ✅ Migrated

Step 4: Assign Roles to Groups

1. Go to Azure Portal > Subscriptions > Access control (IAM)
2. Click + Add > Add role assignment
3. For each group:

- Role: [Appropriate role - e.g., Contributor]

- Assign access to: Groups

- Members: Select group (e.g., grp-engineering-contributors)

- Click Assign

1. Verify group now has the role:

- Go back to Access control (IAM)

- Confirm group appears with assigned role

Step 5: Remove Individual Assignments

Once groups are in place and tested:

1. Go to Access control (IAM)
2. For each individual user with a role:

- If they're now in a group with same role: Remove individual assignment

- Click their role, select Remove

- Confirm removal

1. Document removals:

Individual Assignments Removed:
├─ Alice Smith: Removed Contributor (now in grp-engineering-contributors)
├─ Bob Johnson: Removed Contributor (now in grp-operations-admins)
├─ Charlie Lee: Removed Reader (now in grp-marketing-readers)
└─ Total: 45 individual assignments removed

Step 6: Audit Group Membership

Create a process for regular group audits:

1. Monthly group review:

Group Audit Checklist (Monthly)
──────────────────────────────

For each group:
 Review member list
 Verify each member still needs the role
 Verify no one is missing who should be in it
 Check owner is still appropriate person
 Document any changes
``


<h3 id="validation-checklist">Validation Checklist</h3>

[ ] Created at least 5 security groups
[ ] Migrated minimum 50 individual assignments to groups
[ ] Assigned groups to appropriate roles
[ ] Removed individual assignments (groups in place)
[ ] Verified group members can still perform their jobs
[ ] Zero individual user role assignments remain (except service principals)

<h3 id="success-criteria">Success Criteria</h3>

✅ Complete: All human access is group-based
✅ All individual assignments migrated
✅ Group audit process established
✅ Scalable, auditable access model in place



<h2 id="part-6-approval-workflows-entitlement-management">Part 6 – Approval Workflows & Entitlement Management</h2>

<h3 id="the-challenge">The Challenge</h3>

No formal approval process. Implement Entitlement Management so privileged roles require proper authorization.

<h3 id="what-youll-learn">What You'll Learn</h3>

How to set up Entitlement Management
How to create access packages
How to configure approval workflows
How to enforce separation of duty

<h3 id="step-by-step-tasks">Step-by-Step Tasks</h3>

<strong>Step 1: Enable Entitlement Management</strong>

Go to <strong>Azure Portal</strong> > <strong>Entra ID</strong> > <strong>Identity Governance</strong> > <strong>Entitlement Management</strong>
If not already enabled, click <strong>Enable</strong>
Confirm you want to enable Entitlement Management for your tenant

<strong>Step 2: Create Sensitive Role Access Package</strong>

Click <strong>Access packages</strong> > <strong>New access package</strong>
Create access package for sensitive roles:

<strong>Access Package 1: Production Contributor Access</strong>

<strong>Step 3: Set Up Approval Workflow Details</strong>

For each access package, define:

<strong>Step 4: Test Approval Workflow</strong>

Create a test user account (or have colleague test)
Request access: Go to <strong>Access packages</strong> (as test user)
Find: "Production-Contributor-Access"
Click <strong>Request access</strong>
Submit request with business justification

Track approval flow:
[ ] Manager receives approval request
[ ] Manager approves (or denies)
[ ] Security team receives approval request
[ ] Security team approves
[ ] Resource owner receives approval request
[ ] Resource owner approves
[ ] Access provisioned automatically
[ ] User can now access production

<strong>Step 5: Document Approval Audit Trail</strong>

Verify audit trail is captured:

Go to <strong>Entitlement Management</strong> > <strong>Catalogs</strong> > <strong>Default</strong>
Click <strong>Access package</strong>: Production-Contributor-Access
Review request history:
- Requester
- What was requested
- Approval chain
- Who approved when
- When access was provisioned
- When access expires

Document in audit log:

<h3 id="validation-checklist">Validation Checklist</h3>

[ ] Entitlement Management enabled
[ ] Created access package for sensitive role
[ ] Configured 3-stage approval workflow
[ ] Assigned approvers for each stage
[ ] Tested request submission
[ ] Tested approval process (all 3 stages)
[ ] Verified access provisioned after approval
[ ] Reviewed audit trail

<h3 id="success-criteria">Success Criteria</h3>

✅ Complete: Formal approval process for all privileged access
✅ Separation of duty enforced (no self-approval)
✅ All approvals logged with full audit trail
✅ Access automatically expires after 90 days



<h2 id="part-7-secure-offboarding-account-cleanup">Part 7 – Secure Offboarding & Account Cleanup</h2>

<h3 id="the-challenge">The Challenge</h3>

Former employees still have access. Implement rapid offboarding process to disable accounts within 24 hours.

<h3 id="what-youll-learn">What You'll Learn</h3>

How to disable user accounts safely
How to remove all access in bulk
How to audit for orphaned accounts
How to create offboarding checklist

<h3 id="step-by-step-tasks">Step-by-Step Tasks</h3>

<strong>Step 1: Create Offboarding Process</strong>

Document offboarding checklist to give to HR/managers:

<strong>Step 2: Disable Account (Immediate)</strong>

Simulate offboarding for a test user:

Go to <strong>Entra ID</strong> > <strong>Users</strong>
Find employee to offboard
Click their name
Click <strong>Disable account</strong>
Confirm: Account is now disabled

Verify disabled:
[ ] User cannot sign in
[ ] All Sessions are signed out
[ ] User marked "Blocked Sign in" = Yes

<strong>Step 3: Remove All Access</strong>

For the disabled user, remove:

<strong>Remove from Groups:</strong>
Go to <strong>Entra ID</strong> > <strong>Groups</strong>
For each group the user is in:
- Click group name
- Click <strong>Members</strong>
- Find user
- Click <strong>Remove</strong>

Example removals:

<strong>Remove Role Assignments:</strong>
Go to <strong>Subscriptions</strong> > <strong>Access control (IAM)</strong>
Search for user
For each role:
- Click role
- Click <strong>Remove</strong>
- Confirm

<strong>Step 4: Verify All Access Removed</strong>

Try to sign in as departing employee:
- Username: [their email]
- Password: [any password]
- Expected: "Sign in failed" message
- ✅ Verification: Cannot sign in

Check no remaining access:
- Go to <strong>Entra ID</strong> > <strong>Users</strong> > [User]
- Group memberships: None
- Role assignments: None
- MFA methods: Disabled

<strong>Step 5: Delete Account (After 30 days)</strong>

If employee data retention period passed:

Go to <strong>Entra ID</strong> > <strong>Users</strong>
Click disabled user
Click <strong>Delete user</strong>
Confirm deletion
Log deletion in audit trail

<strong>Step 6: Audit for Orphaned Accounts</strong>

Monthly task - find accounts we missed:

Go to <strong>Entra ID</strong> > <strong>Users</strong>
Filter: Status = Disabled
For each disabled user >30 days old:
- Verify: They were supposed to be disabled
- Verify: No lingering access
- Action: Delete if retention passed
Create audit report

<h3 id="validation-checklist">Validation Checklist</h3>

[ ] Created offboarding checklist
[ ] Disabled test user account
[ ] Verified disabled user cannot sign in
[ ] Removed from all groups
[ ] Removed all role assignments
[ ] Verified zero remaining access
[ ] Planned account deletion after retention

<h3 id="success-criteria">Success Criteria</h3>

✅ Complete: All departing employees disabled within 24 hours
✅ Zero access remains for disabled accounts
✅ Offboarding process documented
✅ Monthly audit process established



<h2 id="part-8-app-authentication-best-practices">Part 8 – App Authentication Best Practices</h2>

<h3 id="the-challenge">The Challenge</h3>

12 apps using hardcoded passwords for Azure authentication. Migrate to managed identities (zero secrets).

<h3 id="what-youll-learn">What You'll Learn</h3>

How to compare authentication methods
How to create and use managed identities
How to create and rotate certificates
How to eliminate hardcoded secrets

<h3 id="step-by-step-tasks">Step-by-Step Tasks</h3>

<strong>Step 1: Audit Current App Authentication</strong>

Document how each app authenticates:

<strong>Step 2: Create Managed Identity for Azure App</strong>

For apps running ON Azure (VM, App Service, Container, Function):

<strong>Scenario: WebApi running on Azure App Service</strong>

Go to <strong>Azure Portal</strong> > <strong>App Services</strong> > [App Name]
Click <strong>Identity</strong> (left menu)
Click <strong>System assigned</strong> tab
Set <strong>Status</strong>: ON
Click <strong>Save</strong>

Verify managed identity created:
[ ] Principal ID is displayed
[ ] Tenant ID is shown
[ ] Status: Enabled

<strong>Step 3: Grant Permissions to Managed Identity</strong>

The managed identity needs permissions to access Azure resources:

Go to <strong>Subscriptions</strong> > <strong>Access control (IAM)</strong>
Click <strong>+ Add</strong> > <strong>Add role assignment</strong>
Configure:
- <strong>Role</strong>: Appropriate for app (e.g., Contributor for deployment)
- <strong>Assign access to</strong>: Managed Identity
- <strong>Members</strong>: Select your app (e.g., "WebApi-prod")
Click <strong>Assign</strong>

Verify permissions:
[ ] App role appears in IAM
[ ] App can authenticate without password

<strong>Step 4: Update App Code to Use Managed Identity</strong>

Update app to use managed identity instead of password:

<strong>Before (Hardcoded Password - INSECURE):</strong>

<strong>After (Managed Identity - SECURE):</strong>

No credentials needed!

<strong>Step 5: Remove Hardcoded Passwords</strong>

Once app is updated and tested:

Remove password from code:
- Delete from appsettings.json
- Delete from appsettings.production.json
- Delete from environment variables
- Delete from Key Vault (if stored there)

Remove old service principal:
- Go to <strong>Entra ID</strong> > <strong>App registrations</strong>
- Find old app service principal
- Click <strong>Delete</strong>

Verify no passwords remain:
- Code review
- Configuration check
- Grep for "password" in codebase

<strong>Step 6: Compare Authentication Methods for Off-Azure Apps</strong>

For apps NOT running on Azure (on-premises, external cloud):



Method
Security
Effort
Use Case


<strong>Password</strong>
🔴 Low
⚠️ Minimal
Never. Seriously.


<strong>Certificate</strong>
🟢 Good
📌 Medium
Off-Azure apps, set rotation reminder


<strong>Managed ID</strong>
🟢️ Best
✅ None
Apps on Azure only




<strong>For On-Premises Apps: Use Certificate</strong>

Create service principal with certificate
Set calendar reminder for rotation (every 12 months)
Document certificate thumbprint
Plan rotation process before expiration

<strong>Step 7: Create Secrets Cleanup Checklist</strong>

Audit all passwords/secrets still in use:
`

find . -type f \( -name "<em>.json" -o -name "</em>.config" \) \
| xargs grep -l "password\|secret\|credential"
`


For each found:
 Is it needed?
 Can it be replaced with managed identity/certificate?
 If needed: Move to Azure Key Vault (not in code)

<h3 id="validation-checklist">Validation Checklist</h3>

[ ] Audited all app authentication methods
[ ] Created managed identity for at least 1 Azure app
[ ] Granted role permissions to managed identity
[ ] Updated app code to use managed identity
[ ] Verified app works without hardcoded password
[ ] Removed hardcoded password from code
[ ] Deleted old service principal
[ ] Documented off-Azure app authentication (certificate)
[ ] Created secrets cleanup checklist

<h3 id="success-criteria">Success Criteria</h3>

✅ Complete: All hardcoded passwords removed
✅ Zero secrets in code
✅ Apps using zero-secret authentication
✅ Certificate rotation process documented



<h2 id="final-assessment-security-hardening-checklist">Final Assessment: Security Hardening Checklist</h2>

After completing all 8 parts, verify all best practices are implemented:

``

Key Takeaways

✅ Least Privilege - Give minimum access needed, nothing more

✅ Regular Reviews - Quarterly access audits catch permission creep

✅ MFA - Makes password theft much less valuable

✅ Monitoring - Sign-in logs detect compromise early

✅ Groups - Easier to manage than individual assignments

✅ Approvals - Formal workflow prevents unauthorized access

✅ Offboarding - Disable accounts within 24 hours

✅ Secrets - Zero hardcoded passwords, use managed identities

Success Indicators

After completing this lab, you should:

✅ Understand how to audit and enforce least privilege

✅ Know how to conduct quarterly access reviews

✅ Be able to implement MFA and conditional access

✅ Understand sign-in log analysis

✅ Know how to scale access with groups

✅ Be able to implement approval workflows

✅ Understand rapid offboarding procedures

✅ Know when to use managed identities vs certificates

Next Steps

1. Complete all 8 parts of this lab
2. Document findings in your audit report
3. Share with security team for validation
4. Create remediation plan with timeline
5. Implement changes in production
6. Schedule quarterly reviews to maintain compliance
7. Train team on new security processes
8. Consider advanced topics: Passwordless sign-in, risk-based access, zero trust