Roadmap

IAM / Identity Engineer

The engineer who designs, implements, and maintains the systems that control who can access what. Builds identity providers, SSO integrations, MFA deployments, privileged access management, and identity governance programs that enforce least privilege across hybrid and cloud environments.

OPTIMISTIC 18–24 monthsREALISTIC 2–3 years

Stage 00

Computer & IT Fundamentals

IAM engineers configure systems that govern access to all other systems. IT literacy across OS, networking, and directory services is the foundation.

Systems and OS Basics

Windows — user accounts, NTFS permissions, registry, services, event log
Linux — user management, PAM (/etc/pam.d/), file permissions, SSH key auth, sudoers
Networking — TCP/IP, DNS, LDAP (389/636), Kerberos (88), HTTP/HTTPS — all protocols IAM uses
Active Directory — the most important prerequisite; see Stage 2

Directory Services

What a directory service is — hierarchical, searchable database optimized for reads; stores identity information
LDAP (Lightweight Directory Access Protocol) — the protocol for querying and modifying directories
Distinguished Name (DN) — cn=John Smith,ou=Users,dc=corp,dc=example,dc=com
Attributes — cn, sn, givenName, mail, telephoneNumber, memberOf, userPrincipalName
Schema — defines what attributes objects can have
LDAP operations — bind (authenticate), search, add, modify, delete, compare
Bind types — simple bind (username/password), SASL (Kerberos, NTLM, certificate)
Anonymous bind — reading directory without authentication; often restricted
Base DN, search scope (base, one-level, subtree), filter syntax

Cryptography Essentials for IAM

Symmetric vs asymmetric encryption
Hash functions — password hashing (bcrypt, PBKDF2, Argon2), NTLM vs Kerberos hash types
Digital signatures — signing assertions, tokens, SAML responses
PKI — certificates, CA hierarchy, certificate validation — used everywhere in IAM
TLS — securing LDAP (LDAPS), HTTPS — all IAM traffic should be encrypted
Token concepts — opaque tokens vs self-contained tokens; signing and verification

Resources

Professor Messer CompTIA A+ and Security+ (free YouTube)
TryHackMe Pre-Security (free)

Stage 01

Security Fundamentals

IAM is a security discipline. The threat context of credential theft, privilege escalation, and lateral movement drives every IAM design decision.

Authentication Concepts

Something you know — passwords, PINs, security questions
Something you have — hardware tokens (YubiKey, RSA SecurID), TOTP apps (Authenticator), push notifications, SMS (weakest)
Something you are — biometrics: fingerprint, face, retina, voice, behavioral
Multi-factor authentication (MFA) — combining two or more factors
Passwordless authentication — FIDO2/WebAuthn, passkeys — eliminating shared secrets
Adaptive authentication — risk-based authentication; step-up when risk increases

Authorization Concepts

RBAC (Role-Based Access Control) — access based on assigned roles; roles assigned to users
ABAC (Attribute-Based Access Control) — access based on attributes of user, resource, and environment; more granular
PBAC (Policy-Based Access Control) — policies expressed in a policy language combining attributes
DAC (Discretionary Access Control) — resource owner controls access
MAC (Mandatory Access Control) — system enforces access based on labels; military-grade
Least privilege principle — grant minimum access required for the job function
Separation of duties — no single user should have end-to-end control over a sensitive process

Identity Attack Vectors

Credential stuffing — using breached username/password combos against other services
Password spraying — trying one common password against many accounts to avoid lockout
Phishing — stealing credentials via fake login pages (especially adversary-in-the-middle phishing that bypasses MFA)
Pass-the-Hash — using NTLM hash without knowing plaintext password
Pass-the-Ticket / Golden Ticket — forging or stealing Kerberos tickets
Token theft — stealing OAuth access tokens, JWT tokens, session cookies
MFA fatigue/push bombing — flooding user with MFA push notifications to get accidental approval
AITM (Adversary-in-the-Middle) phishing — Evilginx2-style session token capture bypassing MFA
Privilege escalation via IAM — cloud IAM policy misconfiguration enabling admin access
Shadow IT / Shadow SaaS — unauthorized app access outside IAM governance

Zero Trust Principles

Never trust, always verify — no implicit trust based on network location
Verify explicitly — authenticate and authorize every access request considering all available signals
Assume breach — minimize blast radius, microsegment access
Least privilege access — just-in-time, just-enough-access, risk-based adaptive policies

Resources

Professor Messer Security+ SY0-701 (free YouTube)
NIST SP 800-63B (Digital Identity Guidelines, free)

Stage 02

Active Directory — Deep Administration

Active Directory is the identity backbone of most enterprise environments. IAM engineers must master it completely.

Active Directory Architecture

Forest — trust boundary; multiple domains sharing schema and global catalog
Domain — administrative boundary; contains objects; Kerberos realm
Trees — domains sharing contiguous DNS namespace
Organizational Units (OUs) — GPO application containers; delegation targets
Sites and Services — controlling replication and authentication topology
Global Catalog — forest-wide search index; required for logon with UPN
FSMO roles — PDC Emulator (password changes, time authority), RID Master, Infrastructure Master, Schema Master, Domain Naming Master

Kerberos Authentication — Deep

Kerberos components — KDC (Key Distribution Center) = AS (Authentication Service) + TGS (Ticket Granting Service); Kerberos database (AD)
Authentication flow:
AS-REQ — client requests TGT using long-term secret (password hash)
AS-REP — KDC issues TGT encrypted with KRBTGT key
TGS-REQ — client presents TGT to request service ticket
TGS-REP — KDC issues service ticket encrypted with service account key
AP-REQ — client presents service ticket to service
AP-REP — service confirms client identity
Encryption types — RC4 (NTLM hash, weaker), AES128-CTS-HMAC-SHA1, AES256-CTS-HMAC-SHA1 (preferred)
Pre-authentication — AS-REQ includes encrypted timestamp; prevents offline brute force; when disabled = AS-REP Roasting
Service Principal Names (SPNs) — service/host:port format; enables Kerberos for services; Kerberoasting target
Kerberos delegation:
Unconstrained — service can request tickets on behalf of user for any service; high risk
Constrained — service can only delegate to specified services
Resource-Based Constrained Delegation (RBCD) — defined on resource, not service; exploitable via computer object write access
Kerberoasting — requesting service tickets for accounts with SPNs; cracking offline
AS-REP Roasting — requesting AS-REP for accounts without pre-auth; cracking offline
Golden Ticket — forged TGT using KRBTGT hash; persists even after password resets
Silver Ticket — forged service ticket for specific service

NTLM Authentication

Challenge-response mechanism:
Client sends NEGOTIATE message
Server sends CHALLENGE (8-byte nonce)
Client sends AUTHENTICATE with response derived from password hash + challenge
NTLMv1 vs NTLMv2 — v1 is weak, v2 is stronger but still vulnerable to relay
Net-NTLMv2 hash — hash captured via Responder; can be cracked offline
NTLM relay — captured hash relayed to another system for authentication without cracking
Pass-the-Hash — using NTLM hash directly for authentication (SMB, WMI, etc.)
Disabling NTLM — NTLMv1 should be disabled; reducing NTLM usage reduces attack surface

Active Directory Security

Protected Users group — prevents NTLM auth, Kerberos unconstrained delegation, credential caching; use for privileged accounts
Authentication policies and silos — restricting which accounts can log on to which systems
Tiered administration model:
Tier 0 — Domain Controllers, AD administration
Tier 1 — Servers and services
Tier 2 — Workstations and end users
Preventing Tier escalation — admins use different accounts per tier
AdminSDHolder — template ACL applied to protected accounts; prevents ACL inheritance modification
AdminSDHolder abuse — attacker modifying AdminSDHolder ACL for persistence
DCSync — replicating AD to extract all password hashes (requires Replicating Directory Changes rights)
AD attack detection — monitoring for golden/silver ticket use, unusual TGT requests, DCSync, LDAP enumeration

Microsoft Entra ID (Azure AD)

Relationship to on-premises AD — cloud identity service; can be standalone or synced with on-premises AD
Entra ID Connect (Azure AD Connect) — synchronizing on-premises AD to Entra ID
Sync scopes — filtering which OUs and objects sync
Password Hash Synchronization (PHS) — hash of password hash synced to cloud; enables cloud auth
Pass-Through Authentication (PTA) — cloud auth request passed to on-premises
Federation with AD FS — cloud redirects auth to on-premises AD FS
Entra ID Object Types — Users, Groups, Service Principals, Managed Identities, Devices
User types — Member (internal), Guest (B2B external collaboration)
Group types — Assigned, Dynamic User, Dynamic Device — dynamic groups based on attribute rules
Entra ID roles — Global Administrator, User Administrator, Security Administrator, Conditional Access Administrator
Managed Identities — system-assigned (tied to resource lifecycle), user-assigned (standalone) — eliminating stored credentials for Azure resources
Enterprise Applications — app registrations for SaaS and custom apps; linked to service principal
App Registrations — defining apps; client ID, client secret, redirect URIs, API permissions
Entra ID Conditional Access — policy engine for access decisions:
Signals: user identity, device compliance, location, application, risk level
Controls: require MFA, require compliant device, block, session controls
Named locations — IP ranges and countries for location-based policies
Risk-based policies — sign-in risk and user risk from Entra ID Protection
Entra ID Protection — detecting risky sign-ins and compromised users; risk levels (Low, Medium, High)
Privileged Identity Management (PIM) — JIT access for Entra ID and Azure RBAC roles
Eligible vs active — eligible requires activation; active is persistent
Activation requirements — justification, approval, MFA, duration limit
Access reviews — periodic review of active and eligible role assignments

Resources

TryHackMe Active Directory rooms (free)
Microsoft Learn Entra ID documentation (free)
John Savill's YouTube channel (free)

Stage 03

Identity Protocols — Deep

IAM engineers configure these protocols daily. Protocol depth is tested in every IAM technical interview.

SAML 2.0 (Security Assertion Markup Language)

What SAML does — enables SSO by passing authentication assertions between IdP and SP
Components — Identity Provider (IdP, authenticates user), Service Provider (SP, app being accessed)
Assertion types:
Authentication statement — user was authenticated by IdP at specific time
Attribute statement — user attributes (email, role, department)
Authorization decision statement — whether access is permitted
Bindings — HTTP Redirect (assertion in URL), HTTP POST (assertion in HTML form), Artifact (reference to assertion)
Flows:
SP-initiated — user goes to SP → redirected to IdP → authenticates → SAML response to SP
IdP-initiated — user logs into IdP → selects app → SAML response sent to SP
SAML response structure — XML; signed by IdP; may be encrypted
RelayState — URL to redirect to after successful authentication
NameID — identifier for the user (email, persistent, transient)
Attribute mapping — configuring which IdP attributes map to SP attributes
SAML security — signature validation, audience restriction, time validity, replay prevention
Common SAML misconfigurations — not validating signature, wrapping attacks, XML injection

OAuth 2.0

What OAuth does — delegated authorization; apps access resources on behalf of users without sharing credentials
Roles — Resource Owner (user), Client (app), Authorization Server (IdP), Resource Server (API)
Grant types:
Authorization Code — most secure; code exchanged for token; used for web apps
Authorization Code + PKCE — mobile and SPA; Proof Key for Code Exchange; prevents interception
Client Credentials — machine-to-machine; no user involved
Device Authorization — TV/IoT devices; user approves on separate device
Implicit — deprecated; tokens in URL; replaced by Authorization Code + PKCE
Resource Owner Password Credentials — deprecated; user credentials to client directly
Tokens:
Access Token — grants access to resources; short-lived (minutes to hours)
Refresh Token — obtains new access tokens without re-authentication; long-lived
ID Token — OIDC extension; contains user identity claims; JWT format
Scopes — permissions requested by app (read:profile, email, openid)
Token storage — secure storage critical; localStorage is vulnerable to XSS; httpOnly cookies preferred
OAuth attack vectors — open redirects, CSRF on authorization endpoint, token leakage

OpenID Connect (OIDC)

What OIDC adds — identity layer on top of OAuth 2.0; standardized user info
ID Token — JWT containing user claims (sub, iss, aud, exp, iat, nonce, email, name)
UserInfo endpoint — /userinfo; returns additional claims with access token
Discovery endpoint — /.well-known/openid-configuration; describes IdP capabilities
Standard claims — sub (unique user ID), iss (issuer), aud (audience), exp, iat, nonce, email, email_verified, name, given_name, family_name, picture, locale
PKCE in OIDC — code_challenge and code_verifier protecting authorization code flow
Hybrid flow — combining authorization code and implicit; returns tokens at authorization endpoint

JWT (JSON Web Token)

Structure — header.payload.signature (base64url encoded, dot-separated)
Header — alg (signing algorithm: RS256, HS256, ES256), typ (JWT)
Payload — claims: registered (iss, sub, aud, exp, nbf, iat, jti), public, private
Signature — HMAC-SHA256 (symmetric secret) or RSA/ECDSA (asymmetric key pair)
Validation — verify signature, check exp and nbf, validate iss and aud, check jti for replay
JWT attacks — alg:none bypass, weak HMAC secret brute force, RS256 to HS256 confusion, JKU/X5U injection, embedded JWK injection
JWK (JSON Web Key) — public key representation; JWK Set at /.well-known/jwks.json

SCIM (System for Cross-domain Identity Management)

What SCIM does — standardized user provisioning API; IdP pushes user changes to apps automatically
SCIM 2.0 — REST API; JSON payloads; CRUD operations on Users and Groups
Endpoints — /Users, /Groups, /Bulk, /Schemas, /ServiceProviderConfig
Provisioning events — create user, update user (department change), deactivate user, delete user
Why SCIM matters — eliminates manual account provisioning; ensures immediate deprovisioning
SCIM in Okta / Entra ID — configuring app provisioning to push changes automatically

WS-Federation and WS-Trust

Legacy protocols used by some Microsoft applications (SharePoint, older .NET apps)
WS-Federation — similar to SAML; passive requestor and active requestor profiles
WS-Trust — Security Token Service (STS) protocol; requesting and issuing security tokens
AD FS — Microsoft's STS; implements SAML, WS-Federation, WS-Trust, OAuth 2.0

FIDO2 and WebAuthn (Passwordless)

FIDO2 — Fast IDentity Online standard; replacing passwords with cryptographic credentials
WebAuthn — W3C standard; browser API for FIDO2; public key stored at relying party; private key on authenticator
Authenticators — platform authenticators (Windows Hello, Touch ID, Face ID), roaming authenticators (YubiKey)
Registration — generate key pair; send public key to server; private key never leaves authenticator
Authentication — server sends challenge; authenticator signs with private key; server verifies with public key
Passkeys — synced WebAuthn credentials; stored in cloud (iCloud Keychain, Google Password Manager); cross-device use
Phishing resistance — domain binding; authenticator only works for registered domain; bypasses AITM attacks

Kerberos

see Stage 2

Resources

OAuth 2.0 specification (RFC 6749, free)
OIDC specification (openid.net, free)
JWT.io (free JWT debugging)
Aaron Parecki's OAuth tutorials (free)
Microsoft Identity Platform documentation (free)

Stage 04

Identity Platforms — Operations

IAM engineers must be proficient in at least one major identity platform. Okta and Entra ID are the dominant platforms in 2026.

Okta

Okta architecture — cloud-hosted IdP; Universal Directory; OIDC/SAML/LDAP integration
Universal Directory:
User attributes — Okta profile attributes vs app-specific attributes; mapping between them
User lifecycle states — Staged, Provisioned, Active, Locked Out, Password Expired, Suspended, Deactivated
Groups — used for app assignment, policy targeting, attribute population
Group rules — auto-assigning users to groups based on expression conditions
Application integration:
SAML app integration — entity ID, ACS URL, attribute statements, group attribute statements
OIDC app integration — client ID/secret, redirect URIs, scopes, token claims
System Log for app troubleshooting — okta.user.session.start, application.user.sso
Authentication Policies:
Assurance levels — password, MFA, phishing-resistant MFA
Factor requirements — any factor, specific factor types, hardware FIDO2
Network conditions — location-based policy enforcement
Device conditions — device trust, platform restrictions
Risk-based conditions — behavior-based risk detection
MFA factors — Okta Verify (push + TOTP), Google Authenticator, YubiKey (FIDO2/U2F), SMS, email, security questions
Okta Workflows — no-code/low-code automation; triggers, actions, connectors; provisioning logic
Lifecycle Management:
SCIM provisioning to downstream apps
Inbound provisioning from HR systems (Workday, BambooHR)
Deprovisioning — suspension vs deactivation; downstream app access removal
Profile sourcing — which directory is authoritative for each attribute
Okta Identity Engine (OIE) — next-gen Okta architecture; flexible identity graph; progressive profiling
Okta Administrator roles — Super Admin, Org Admin, App Admin, Group Admin, Report Admin
System Log — event stream for all Okta activity; essential for investigation and compliance
okta.user.session.start / end
user.authentication.sso
policy.evaluate_sign_on
application.user_membership.add / remove

Microsoft Entra ID

see Stage 2

AD FS (Active Directory Federation Services)

What AD FS does — on-premises STS; SAML 2.0, WS-Federation, OAuth 2.0/OIDC
Relying Party Trusts — configuring SAML trust to federate with external services
Claims Provider Trusts — trusting external identity sources
Claims rules — transformation and issuance rules; PowerShell Get-AdfsRelyingPartyTrust
Proxy (WAP) — publishing AD FS to internet; Web Application Proxy role
AD FS vs Entra ID — AD FS is on-premises; increasingly replaced by Entra ID + PHS or PTA

Ping Identity / PingFederate

Enterprise-grade federation server; often seen in large financial services and healthcare
Similar to AD FS but multi-protocol and multi-directory; agentless integration
PingAccess — access gateway; header-based authentication injection
PingDirectory — high-performance LDAP directory
PingOne — cloud IDaaS equivalent of Okta

ForgeRock (OpenAM / AM)

Open-source heritage; now part of Ping Identity
Identity Platform — AM (access management), IDM (identity management), DS (directory services)
Journey-based authentication — visual authentication tree designer
Common in healthcare, government, telecommunications

CyberArk (Privileged Access)

CyberArk Privileged Access Manager (PAM) — vault for privileged credentials
Components — Digital Vault, Central Policy Manager (CPM), Privileged Session Manager (PSM), Password Upload Utility
Safes — containers for privileged accounts with configurable access and policy
CPM — automatically rotating passwords per policy; pluggable platforms (Windows, Linux, Oracle, MSSQL, network devices)
PSM — recording and monitoring privileged sessions; RDP and SSH proxy
CyberArk Conjur — secrets management for DevOps; API-based credential retrieval
Just-in-time provisioning — temporary privileged access, not persistent

BeyondTrust

Password Safe — privileged account and session management
Privilege Management for Windows/Mac/Linux — endpoint privilege management
Remote Support — enterprise remote access tool
BeyondInsight — central management platform

SailPoint IIQ / IdentityNow

Identity Governance and Administration (IGA) — certifications, entitlement management, role management
Provisioning — automated account provisioning/deprovisioning via connectors
Access certifications (access reviews) — periodic review of user access; revocation of inappropriate access
Role modeling — defining RBAC roles from entitlement data
Separation of duties (SOD) — detecting and preventing conflicting access
SailPoint IdentityNow — SaaS IGA platform
Common in regulated industries — SOX, HIPAA, PCI-DSS compliance

Saviynt

Cloud-native IGA and PAM platform
Application risk and compliance — integrating GRC into IGA
Growing adoption as SailPoint IIQ replacement

Resources

Okta free developer account (developer.okta.com)
Microsoft Learn Entra ID modules (free)
Okta documentation (free)
SailPoint community (free)

Stage 05

Privileged Access Management (PAM)

Privileged accounts are the highest-value targets for attackers. PAM is a distinct and critical IAM discipline.

PAM Fundamentals

What privileged access is — accounts with elevated permissions: local admin, domain admin, service accounts, root, DBA, network device admin
Why PAM matters — privileged account compromise is in the kill chain of nearly every serious breach
Privileged account types:
Human privileged — named admin accounts, sysadmin accounts
Service accounts — used by applications and services; often overprivileged; rarely rotated
Emergency/break-glass accounts — for disaster scenarios when normal access is unavailable
Shared accounts — administrator, root — must be discovered, vaulted, and rotated
Cloud privileged — AWS root, Azure Global Admin, GCP owner

PAM Capabilities

Discovery — finding all privileged accounts across on-premises and cloud
Vaulting — storing credentials in an encrypted vault; applications retrieve via API
Rotation — automatically changing passwords on schedule or after use
Session management — proxying privileged sessions through a jump server
Session recording — full recording of privileged sessions for forensics and compliance
Just-in-Time (JIT) access — temporary elevated access on request; expires automatically
Dual control — requiring two approvals for specific actions
Least privilege enforcement — limiting what privileged accounts can do

PAM Architecture

Vault — encrypted credential store; CyberArk Digital Vault, BeyondTrust Password Safe, HashiCorp Vault
CPM/password manager — connecting to targets and rotating credentials automatically
PSM/session manager — proxying sessions; user connects to PSM, PSM connects to target
SIEM integration — shipping PAM events to SIEM for correlation
Application-to-application password management (AAPM) — replacing hardcoded passwords in applications

HashiCorp Vault for PAM

Dynamic secrets — generates credentials on-demand that expire automatically
AWS IAM roles — temporary AWS credentials
Database credentials — rotating database passwords per request
SSH signed certificates — short-lived SSH access
Static secret storage — API key, password, certificate storage with versioning
Auth methods — Kubernetes, AWS IAM, LDAP, JWT, AppRole
Policy as code — Vault policies in HCL defining access to secret paths
Secret engines — KV, AWS, Database, SSH, PKI, Transit (encryption as a service)

Endpoint Privilege Management

Local admin removal — removing local admin rights from workstations (zero-standing-privilege)
Application control — allowing specific applications to run with elevated rights without full admin
CyberArk Endpoint Privilege Manager — Windows/macOS endpoint privilege management
BeyondTrust Privilege Management — similar capability

Resources

CyberArk documentation (free)
HashiCorp Vault documentation (free)
BeyondTrust resources (free)
NIST SP 800-53 AC controls (free)

Stage 06

Identity Governance & Administration (IGA)

Access reviews, role management, and entitlement governance are compliance requirements and core IAM responsibilities.

IGA Fundamentals

What IGA does — governing who has access to what, ensuring it is appropriate, and certifying it periodically
IGA vs IAM — IAM handles authentication and access provisioning; IGA provides governance, review, and remediation
Key IGA capabilities:
Identity lifecycle — joiner/mover/leaver processes
Entitlement management — managing fine-grained access rights
Role management — defining and maintaining RBAC roles
Access certification — periodic review and revalidation of access
Separation of duties — detecting and preventing conflicting access
Access requests — self-service with approval workflow
Policy enforcement — automatic remediation of policy violations

Identity Lifecycle Management

Joiner process — new employee starts; account created, roles assigned, apps provisioned
HR system as source of truth — Workday, ADP, SAP HR driving identity creation
Day 0 provisioning — critical apps available before first day
SCIM push to downstream apps
Mover process — employee changes role, department, or location
Attribute changes triggering access modifications
Entitlements no longer appropriate removed; new ones added
Time-based review of access after role change
Leaver process — employee terminates; all access must be removed
Immediate deactivation — disable all accounts within hours of termination
Email retention — configuring forwarding or retention per policy
Asset recovery — laptop, badges, access cards
Service account ownership transfer
Orphaned accounts — accounts without an active owner; discovery and remediation

Access Certification / Access Reviews

Why access reviews matter — compliance (SOX, HIPAA, SOC 2) and security (entitlement creep)
Certification types — user access reviews, entitlement reviews, role reviews, privileged access reviews
Reviewer types — manager (can they certify direct reports' access?), application owner, data owner, IT admin
Certification outcomes — certify (approve), revoke (remove access), delegate (someone else reviews)
Automated remediation — revocation automatically removing access in connected systems
Bulk operations — allowing reviewers to action many items efficiently
Attestation evidence — capturing decisions and timestamps for compliance evidence
Entitlement creep — accumulation of access over time as roles change; certification prevents long-term buildup

Role Management

Role mining — discovering roles from existing access patterns using analytics
Role definition — mapping job functions to required entitlements
Role conflicts — identifying roles with inherent SOD violations
Role lifecycle — creating, modifying, deprecating, merging roles
RBAC vs fine-grained entitlements — balance between role simplicity and granularity

Separation of Duties (SOD)

SOD violations — user holds two entitlements that together create excessive risk
Classic SOD conflicts — create vendor + approve payment; request purchase + approve purchase; enter timesheet + approve timesheet
Compensating controls — when SOD cannot be enforced, detective controls (monitoring, periodic review) substitute
SOD matrix — documenting all conflicting entitlement pairs
Preventive vs detective SOD — blocking violations at provisioning vs detecting after the fact

Resources

SailPoint community (free)
Saviynt documentation (free)
ISACA IGA guidance (free member content)

Stage 07

Scripting & Automation for IAM

IAM at scale requires automation. Identity engineers who cannot write automation scripts are limited in their impact.

PowerShell for IAM

Active Directory module:
Get-ADUser, New-ADUser, Set-ADUser, Remove-ADUser, Disable-ADAccount, Enable-ADAccount
Get-ADGroupMember, Add-ADGroupMember, Remove-ADGroupMember
Get-ADComputer, Search-ADAccount (locked, disabled, expired, inactive)
Bulk operations — Import-Csv | New-ADUser
Stale account reporting — last logon, password age, account status
Microsoft Graph API (PowerShell):
Connect-MgGraph — authenticate to Microsoft Graph
Get-MgUser, New-MgUser, Update-MgUser, Remove-MgUser
Get-MgGroup, Add-MgGroupMember, Remove-MgGroupMember
Get-MgApplication, Get-MgServicePrincipal
Exchange Online / M365:
Set-Mailbox, Set-DistributionGroup, Add-DistributionGroupMember
Managing shared mailboxes, delegate access
Entra ID Conditional Access via Graph:
Get-MgIdentityConditionalAccessPolicy, New-MgIdentityConditionalAccessPolicy

Python for IAM

Okta SDK (okta-sdk-python):
Creating, updating, deactivating users
Assigning and removing apps
Group management
Bulk operations from HR feed
Microsoft Graph SDK (msgraph-sdk-python):
User lifecycle management
Conditional access policy management
Service principal management
LDAP queries (python-ldap, ldap3):
Querying Active Directory programmatically
Modifying user attributes
Group membership management
SCIM client — building custom SCIM provisioning for applications without native support
CSV/Excel processing — HR feed ingestion for joiners/movers/leavers
Reporting — generating access reports, orphaned account reports, privilege reports

API Integrations

REST API basics — GET, POST, PUT, PATCH, DELETE; JSON payloads; Bearer token auth
Okta API — user management, app assignment, group management, system log queries
Microsoft Graph API — unified API for all Microsoft 365 and Entra ID operations
AWS IAM API — user, role, policy management via boto3
CyberArk PVWA REST API — safe management, account management, session monitoring

Infrastructure as Code for IAM

Terraform for Okta — okta Terraform provider; managing Okta resources as code
Terraform for Entra ID — AzureAD provider; managing users, groups, applications, conditional access
Terraform for AWS IAM — managing users, roles, policies, OIDC providers
Benefits — version control, peer review, automated drift detection

Resources

Okta developer documentation (free)
Microsoft Graph documentation (free)
HashiCorp Terraform registry providers (free)

Stage 08

Hands-On Practice & Portfolio

Lab Setup

Okta free developer tenant — developer.okta.com; full-featured; unlimited for development
Microsoft Entra ID — free tier with Microsoft 365 developer subscription (25 user licenses)
Active Directory lab — Windows Server VM with AD DS, DNS, DHCP (see Sysadmin path)
HashiCorp Vault — free download; install locally or Docker for PAM lab
Keycloak — open-source IdP; great for learning SAML, OIDC, OAuth 2.0 concepts

Practice Projects

Configure SAML SSO between Okta (IdP) and a test SP (ServiceNow, Salesforce dev, AWS)
Configure OIDC integration between Entra ID and a custom app
Set up Okta to AD sync via LDAP interface
Build an Okta workflow for new user provisioning trigger from group membership
Configure Conditional Access policy in Entra ID — require MFA from outside trusted locations
Set up Vault with LDAP auth method and generate dynamic database credentials
Write a PowerShell script for stale account detection and automated disable
Build an access certification mock using SailPoint IdentityNow free trial

What to Document on LabList

SSO integration walk-throughs — SAML assertion diagrams, OIDC flow documentation
Lab architecture — identity flow diagrams showing how authentication works in your lab
Automation scripts — GitHub with Python/PowerShell IAM automation
Protocol analysis — JWT decoding, SAML assertion reading with explanations
Cert progression — Security+ → SC-300 or Okta Certified Administrator
IGA conceptual designs — documented access review and provisioning processes

FAQ

Common questions

How long does it take to become an IAM Engineer?

18–24 months optimistic at 20–25 hours/week, 2–3 years realistic. Identity engineering rewards deep platform expertise — Okta, Entra ID, SailPoint, CyberArk — combined with security thinking. The fastest paths come from sysadmin, security analyst, or directory services backgrounds. IAM-related roles are among the hardest to fill in cybersecurity because the platform learning curve is steep and the role demands both technical and governance skills.

Which certifications matter for IAM?

Okta Certified Professional or Administrator for Okta-heavy organizations. SC-300 (Microsoft Identity and Access Administrator) for Entra ID. SailPoint IdentityIQ Engineer for SailPoint shops. CyberArk Defender + Sentry for PAM-adjacent IAM work. CIAM specialization for customer identity platforms. 70%+ of IAM specialist postings require expertise in at least one platform — generic 'IAM knowledge' isn't enough.

Do I need a CS degree?

No. The path rewards demonstrated platform configuration over academic credentials. What you do need: hands-on experience with at least one major IDP, SAML/OIDC protocol depth, RBAC and ABAC modeling, and access certification process design. Identity is the primary attack surface in cloud environments — cloud IAM misconfigurations are among the most common breach causes — so security-thinking is mandatory, not optional.

What separates a hired IAM Engineer?

A demonstrated SAML/OIDC integration in your portfolio. Most candidates can talk about identity protocols; few have actually wired up SAML SSO end-to-end with Okta or Entra ID for a non-trivial application. Other differentiators: lifecycle management depth (provisioning, deprovisioning, joiner/mover/leaver flows), policy-as-code for access governance, and at least one ZTNA/conditional access policy design. 33% projected job growth 2023–2033.

IAM / Identity Engineer

Common questions

Related roles