# PART 6: IDENTITY & ACCESS MANAGEMENT

---

## 6.1 Microsoft Entra ID (Azure Active Directory)

### Overview
Cloud identity and access management. SSO, MFA, conditional access, B2B, B2C. The backbone of Azure security.

### Key Concepts
- **Tenant** — Your organization's dedicated Entra ID instance. Identified by .onmicrosoft.com domain.
- **Users** — Cloud-only or synced from on-prem AD (via Entra Connect / Cloud Sync).
- **Groups** — Security groups (for auth) or Microsoft 365 groups (for collaboration). Dynamic groups (auto-add based on attributes).
- **App Registrations** — Register apps for auth. OAuth2/OIDC endpoints.
- **Enterprise Applications** — Instances of app registrations for SSO. Service principals.
- **Managed Identities** — Auto-managed identities for Azure resources. No credentials to manage.
  - **System-assigned** — Tied to resource lifecycle. One per resource.
  - **User-assigned** — Standalone identity. Multiple resources can use it.

### Authentication Methods
- **Password + MFA** — Password + something you have (authenticator app, phone, FIDO2 key)
- **Passwordless** — FIDO2 security keys, Microsoft Authenticator, Windows Hello
- **Conditional Access** — If-then policies. E.g., "If user is admin AND location is outside US, block access." Signal-based: user, group, location, device, app, risk.
- **Identity Protection** — Risk-based policies. Sign-in risk (is this really the user?) and User risk (is the account compromised?).

### App Registration & Permissions
- **App Registration** — Define the app in Entra ID. Get client ID, configure redirect URIs, define permissions.
- **Delegated Permissions** — App acts on behalf of user. Needs user consent.
- **Application Permissions** — App acts as itself. Needs admin consent. More powerful.
- **Consent** — User consents to delegated permissions. Admin consents to application permissions.

### Key Features
- **SSO** — One login for all cloud apps (SAML, OIDC, WS-Fed)
- **B2B** — Invite external users (guest accounts). They use their own identity.
- **B2C** — Customer identity (now Entra External ID). Social login (Google, Facebook) + local accounts.
- **PIM (Privileged Identity Management)** — Just-in-time admin access. Time-bound, approval-based. Reduces standing privileges.
- **Access Reviews** — Periodic review of access. Remove unused access.
- **Entitlement Management** — Automated access packages for onboarding/offboarding.
- **Self-Service Password Reset (SSPR)** — Users reset own passwords. Requires MFA.

### Entra ID Editions
| Feature | Free | P1 | P2 |
|---|---|---|---|
| SSO, MFA | Yes | Yes | Yes |
| Conditional Access | No | Yes | Yes |
| Identity Protection | No | No | Yes |
| PIM | No | No | Yes |
| Access Reviews | No | No | Yes |

### Interview Q&A
**Q: What is Conditional Access?**
A: If-then policies for access control. Signals: user/group, location, device, app, risk level. Actions: allow, block, require MFA, require compliant device. Most powerful tool in Entra ID. Always use for admin accounts.

**Q: System-assigned vs User-assigned Managed Identity?**
A: System-assigned = one identity per resource, deleted with resource. User-assigned = standalone, shared across resources, independent lifecycle. Use user-assigned when multiple resources need same identity or you need identity to survive resource recreation.

**Q: What is PIM?**
A: Privileged Identity Management. Provides just-in-time, time-bound, approval-based access to privileged roles. Reduces attack surface by eliminating permanent admin access.

---

## 6.2 Microsoft Entra External ID (B2C)

### Overview
Customer identity and access management (CIAM). Social login, custom branding, millions of users.

- Social identity providers: Google, Facebook, Apple, Amazon
- Custom policies (XML-based) for complex flows
- User flows (built-in): sign up, sign in, password reset, profile edit
- API connectors for custom validation/enrichment
- Brand customization

---

## 6.3 Microsoft Entra Domain Services

### Overview
Managed domain services in the cloud. LDAP, Kerberos, NTLM. Domain-join VMs without deploying domain controllers.

- For lift-and-shift of legacy apps requiring AD domain
- Not a replacement for on-prem AD (no schema extensions, no GPOs beyond baseline)
- Kerberos + NTLM authentication
- LDAP read/write
- Domain join for Azure VMs
- Secure LDAP (LDAPS)

---

## 6.4 Role-Based Access Control (RBAC)

### Overview
Control who can do what on Azure resources. Built on ARM.

### Key Concepts
- **Security Principal** — Who: User, Group, Service Principal, Managed Identity
- **Role Definition** — What: Set of permissions (Actions, NotActions, DataActions, NotDataActions)
- **Scope** — Where: Management Group, Subscription, Resource Group, Resource
- **Assignment** — Binding: Principal + Role + Scope

### Built-in Roles (Key Ones)
| Role | What It Can Do |
|---|---|
| **Owner** | Full access + manage access |
| **Contributor** | Full access, cannot manage access |
| **Reader** | View everything, cannot change |
| **User Access Administrator** | Manage access only |
| **Key Vault Contributor** | Manage Key Vault (not secrets) |

### Key Principles
- **Principle of Least Privilege** — Grant minimum needed
- **Use built-in roles** before custom roles
- **Assign at highest scope that makes sense** (prefer RG over subscription)
- **Use PIM for privileged roles** — Just-in-time, not permanent
- **Separate duties** — No one person should control entire lifecycle

### Interview Q&A
**Q: What's the difference between RBAC roles and Entra ID roles?**
A: RBAC roles = manage Azure resources (VMs, Storage, etc.). Entra ID roles = manage Entra ID itself (users, groups, apps). They are separate role systems.

---

## 6.5 Azure Key Vault

### Overview
Centralized secret management. Store keys, secrets, certificates securely.

### What It Stores
- **Secrets** — Passwords, connection strings, API keys. Up to 25 KB each.
- **Keys** — Cryptographic keys (RSA, EC). Hardware-protected (HSM) in Premium tier.
- **Certificates** — X.509 certificates. Auto-renewal with integrated CAs (DigiCert, GlobalSign).

### Access Models
- **Vault access policy** — Legacy. Per-application access policies. Granular per-secret.
- **Azure RBAC** — Recommended. Role-based. Built-in roles: Key Vault Administrator, Secrets User, etc.

### Key Features
- **Soft Delete** — Recover deleted vaults/secrets (7-90 days retention). Enabled by default.
- **Purge Protection** — Prevent permanent deletion during retention period.
- **Firewall** — Restrict access to specific networks.
- **Private Endpoint** — Access via private IP.
- **HSM-backed keys** — Premium tier. FIPS 140-2 Level 2.
- **Managed HSM** — Dedicated, single-tenant HSM. FIPS 140-2 Level 3.

### Interview Q&A
**Q: How do you access Key Vault from an application?**
A: Use Managed Identity + RBAC. No credentials in code. App gets token from IMDS endpoint, authenticates to Key Vault. For AKS: use Secret Store CSI Driver or Workload Identity.

**Q: Vault access policy vs RBAC?**
A: RBAC is recommended (consistent with Azure model, supports PIM). Access policy is legacy but offers per-secret granularity. New deployments should use RBAC.
