Module 10 Lesson 5 of 6 🕑 ~40 min

> cat module-10-5-enterprise-architecture.md

Enterprise IAM Architecture

Lessons 1–4 covered IAM concepts individually. This lesson zooms out: what a Directory, Identity Provider, IGA platform and PAM platform each actually are, how Active Directory groups drive real access, the vendors you'll actually encounter, and what happens when a real 40-country, 120,000-employee company tries to make all of this work at once.

1 Directory, Identity Provider, IGA & PAM

These four terms get used almost interchangeably in casual conversation, but they're genuinely different layers.

Directory
Stores identity information — Active Directory, LDAP directories, Entra ID, OpenLDAP, Oracle Internet Directory, IBM Security Directory Server. Typically holds username, first/last name, email, employee number, department, office, manager, groups, and account status.
Identity Provider (IdP)
Authenticates users and hands identity information to applications — Entra ID, Okta, Ping Identity, Google Identity, Auth0. After authenticating a user, an IdP may issue SAML assertions, ID tokens, or access tokens (Module 9).
Identity Governance and Administration (IGA)
Answers who should have access, who approved it, whether it's still needed, whether conflicting permissions exist, whether access should auto-expire, and whether an auditor can see why it exists. Common platforms: SailPoint, Saviynt, Entra ID Governance, Omada, One Identity, Oracle. IAM and IGA overlap heavily in practice.
Privileged Access Management (PAM)
Focuses specifically on the highest-value identities — Domain Admin, Linux root, database admin, AWS/Azure admin, firewall/network admin, service accounts. Common platforms: CyberArk, BeyondTrust, Delinea.

A mature organisation therefore usually runs IAM + IGA + PAM as separate, deliberately overlapping layers — not one product trying to do every identity function at once.

2 IAM and Active Directory

For most enterprises, Active Directory is still a major identity platform. A typical flow is HR → IGA → Active Directory → Entra ID → Cloud applications, with access represented as AD groups — GG-Salesforce-Users, GG-SAP-Finance, GG-VPN-Users, GG-SQL-Reporting. IAM adds and removes users from these groups; applications then authorise based on group membership.

Large AD environments often nest groups several layers deep — Alice → Finance-Employees → London-Employees → SAP-Finance-Access. Nesting simplifies management but makes troubleshooting genuinely harder: an IAM engineer trying to answer "why does this user have access?" may need to trace several levels of group membership to find the actual source — a skill worth practising deliberately, since it comes up constantly in real support work.

3 Legacy & Modern IAM Technologies

Organisations don't replace identity systems every few years — some environments carry decades of technology at once. You may encounter Active Directory, LDAP, Novell/eDirectory, IBM and Oracle directories, Microsoft Identity Manager (and its predecessors Forefront/MIIS), Oracle Identity Manager, IBM Tivoli Identity Manager, CA Identity Manager, custom Java provisioning systems, PowerShell/Perl provisioning scripts, database triggers, scheduled batch jobs, and flat-file identity feeds. Mainframe environments may run identity systems like IBM RACF, ACF2, or Top Secret. A company can genuinely have a 2026 cloud application talking SCIM to modern IAM, sitting right alongside a 1990s mainframe application secured by RACF — both equally business-critical.

On the modern side, you're likely to meet ecosystems built around:

Microsoft
Entra ID, Entra ID Governance, Conditional Access, Privileged Identity Management, Active Directory.
Okta
Identity Provider, SSO, lifecycle management, Universal Directory, SCIM integrations.
SailPoint / Saviynt
Identity governance, lifecycle management, access requests, provisioning, certification, cloud entitlement governance.
Ping Identity
Enterprise authentication, federation, SSO, identity services.
CyberArk
Often specifically associated with privileged identity and PAM.

Large organisations frequently integrate several of these vendors rather than standardising on one platform for everything.

4 Example: A Global Enterprise

Consider a fictional multinational bank: 120,000 employees, 40 countries, 7,000+ applications, 8 Active Directory forests, and AWS + Azure + GCP all in use.

Workday (HR)↓ SailPoint (IGA)↓ Active Directory + Entra ID + RACF (mainframe)↓ Windows Apps + SaaS Apps + Mainframe Apps

Authentication might run on Entra ID + MFA + FIDO2; privileged access on CyberArk; thousands of SaaS applications on SAML/OIDC/SCIM; legacy applications still on LDAP, CSV, JDBC, SOAP, or manual provisioning. This mixed, several-generations-deep architecture is much closer to reality than any environment built purely on modern cloud technology — and it's exactly why IAM engineers need fluency across old and new alike, not just the newest platform.

5 Global IAM Challenges

IAM gets significantly harder at multinational scale.

Multiple HR systems
Growth through acquisition often leaves a company with Workday, SAP, Oracle HR, a local payroll system, a contractor database, and an acquired subsidiary's own HR platform all feeding identity data at once — IAM has to consolidate them into one coherent identity picture.
Duplicate identities
"John Smith, Employee 12345" later shows up in another subsidiary's HR system as "John Smith, EU88422." Is that the same person, or two different people? This is identity correlation, and it's genuinely hard at scale.
Names are not reliable identifiers
A multinational can easily have hundreds of employees sharing a name. Use stable identifiers instead — employeeNumber, workerID, immutableID. Email addresses can change too, so they're not ideal as immutable identifiers either.
International names
IAM systems must correctly handle accented characters, multiple surnames, long names, non-Latin scripts (Arabic, Chinese, Japanese, Korean, Cyrillic, Devanagari, and more), different naming conventions, and preferred vs legal names. Poor username-generation rules built around one culture's naming assumptions create real operational problems elsewhere.
Time zones
An employee's termination is "Friday 17:00 Tokyo" — a lifecycle system running on UTC has to correctly translate that, or access gets removed too early (disrupting a still-employed person) or too late (a security gap).

Mergers and acquisitions

Company A (Entra ID + SailPoint + Active Directory) buys Company B (Okta + Google Workspace + OpenLDAP).

🔮 Think it through

What decisions does the combined IAM team now have to make, and roughly in what order?

Reveal the typical decision list

Which identity platform becomes authoritative going forward? Will the directories actually merge, or stay federated? Should federation be used as a temporary bridge while migration happens? How will Company B's users reach Company A's systems (and vice versa) in the meantime? And critically — what happens to duplicate accounts where the same person exists in both companies' systems? There's rarely a fast, clean answer to all of these; mergers frequently leave a genuinely tangled identity architecture in place for years, which is part of why "M&A support" shows up so often in real IAM job descriptions.

Lesson Outcome

You should now be able to distinguish a Directory, an Identity Provider, an IGA platform and a PAM platform, explain how AD group membership (including nested groups) drives real application access, recognise both legacy and modern IAM technology by name, and describe the specific challenges (duplicate identities, unreliable names, time zones, M&A) that only show up once IAM operates at genuine global scale. Lesson 6 closes the module with day-to-day IAM operations: logs, the identity/account/entitlement model, Zero Trust, methodical troubleshooting, and real incident scenarios.