Forem: Shiphrah

The First Password Breach Wasn’t a Hacker — It Was OperationsQuestion for IAM/PAM folks:

Shiphrah — Mon, 16 Feb 2026 22:41:11 +0000

One of the earliest “password breaches” stories in computing wasn’t caused by a genius attacker.

It happened because the password file got exposed during normal operations—think debugging, printing logs, moving files around. Not malware. Not zero-days. Just everyday workflow colliding with sensitive data.

Even if you’ve heard different versions of the story, the lesson is the same:

Credential failures often look like routine work.

The “printer moment” still exists today

We’ve upgraded from printed password lists to:

secrets pasted into tickets “just for today”

admin creds sitting in scripts “until the release”

shared accounts because “everyone needs access”

over-permissioned groups that are “temporary” for months

vendor access that never expires

None of these are rare. They’re what happens when convenience becomes policy.

Why IAM/PAM exists?

IAM gives structure. PAM adds discipline to privilege.

PAM done well is not just a product—it’s a system that enforces:

Ownership: who is accountable for this identity?

Time limits (JIT): why is this permanent?

Verification: can we prove who did what?

Evidence: can we defend it in an audit and an incident?

If your controls don’t produce evidence, they don’t exist when it matters.

A tiny checklist that prevents “printer moments”

When someone requests access, ask:

Does this map to a role/group, or is it a one-off?

Does it need privilege, or standard access?

Does it need to be permanent, or time-bound?

What’s the review cadence?

Where’s the evidence (ticket/approval/export/log/screenshot)?

That’s the difference between “we think we’re secure” and “we can prove it.”

From “User Creation” to Real IAM: Building RBAC in Active Directory

Shiphrah — Mon, 16 Feb 2026 17:01:56 +0000

Identity & Access Management clicked for me when I stopped thinking about “creating users” and started thinking about governance.

Last week I built a hands-on Active Directory lab to model how enterprise identity environments actually work. The focus wasn’t just setting up a domain — it was implementing role-based access control (RBAC) the way real organizations do it: through structure, groups, and inheritance.

1) Identity Structure: Organizational Units (OUs)

I created departmental OUs (HR, IT, Service Accounts, Users) to model how businesses segment identities. This structure supports delegation, policy consistency, and clean administration boundaries.

2) Provisioning Identities

I provisioned demo identities (ex: HR users) inside the appropriate OU. The key lesson here: identity organization isn’t cosmetic — it’s foundational to scalable governance.

3) RBAC Assignment: Security Groups

Instead of assigning permissions directly to users, I created security groups aligned to roles (ex: HR_Group). In enterprise IAM, groups are the control plane — they make access scalable and auditable.

4) RBAC Enforcement: Access Inheritance

Finally, I verified the user’s “Member Of” relationships to prove the access model is enforced through group membership. This is what makes RBAC reliable and easy to audit.

This lab reinforced the “why” behind IAM tooling: building access systems that enforce least privilege, reduce operational overhead, and stay clean under audit.

Next I plan to extend this lab into Microsoft Entra ID to demonstrate cloud identity security controls like Conditional Access, access reviews, and privileged access management.

Building an Enterprise IAM Lab: Active Directory, Entra ID, RBAC & Access Governance

Shiphrah — Wed, 11 Feb 2026 03:59:19 +0000

Building an Enterprise IAM Lab: Active Directory, Entra ID, RBAC & Access Governance

Most Identity & Access Management (IAM) skills are taught in theory — but real-world identity flows, access governance, and privileged access management require hands-on experience.

To bridge this gap, I built a full enterprise-style IAM lab simulating how organizations manage identities, enforce least privilege, and protect privileged accounts across the lifecycle.

Instead of just reading about IAM, I designed and configured everything myself.

Goal

Recreate a realistic enterprise IAM environment to demonstrate responsibilities of an IAM Analyst, including:

Identity provisioning & lifecycle automation (Joiner–Mover–Leaver workflows)
Role-Based Access Control (RBAC) and group-based access management
Conditional Access policies and Multi-Factor Authentication (MFA)
Access reviews, audit logging, and governance checks
Privileged access management (PAM/PIM)
Audit-ready compliance workflows (SOC 2, ISO 27001 concepts)

The goal was to understand not just how to create users — but how identity flows through a system, and how proper governance reduces organizational risk.

Architecture Overview

GitHub link: https://github.com/Shiphrah-identity/enterprise-iam-lab/tree/main