LAB 01: Enterprise Directory Foundation
with OpenLDAP

Lab Metadata

Lab Title and Description

Enterprise Directory Foundation: Deploying and Structuring OpenLDAP as a Central Identity Store

Northgate Financial is a fictional UK financial services firm with 5,000 employees, four internal web applications, a VPN, and a Linux server estate. Today, every one of those systems keeps its own list of usernames and passwords. When a new analyst joins, the IT team creates five separate accounts by hand. When someone leaves, at least one account is usually forgotten and stays active. The audit team has flagged this repeatedly, and the security team cannot answer a basic question: who has access to what?

In this lab you take the role of the identity engineer hired to fix the foundation. You will deploy an OpenLDAP directory server, the open source implementation of the Lightweight Directory Access Protocol, and turn it into a single, authoritative store of people, groups, and service accounts. You will design a directory tree that mirrors how enterprises actually organise identity data, load it with users and groups using LDIF files, prove that applications can authenticate people against it, and secure the connection with TLS so credentials never cross the network in plain text.

Everything runs in Docker containers on your own machine, so nothing you do here touches any real system, and the whole environment can be destroyed and rebuilt in minutes. Estimated completion time is 2.5 to 3 hours at a careful, read-everything pace.

Prerequisites

3.1 Prior labs required

None. This is the first lab of the track and assumes zero prior IAM experience. If you can open a terminal and type commands, you are ready.

3.2 System requirements

3.3 Required tools and versions

3.4 Installation commands

# Update the package index so apt knows about current package versions
sudo apt-get update

# Install Docker Engine from the Ubuntu repository
# Purpose: provides the container runtime for the whole track
sudo apt-get install -y docker.io

# Start Docker now and enable it to start on every boot
sudo systemctl enable --now docker

# Add your user to the docker group so you can run docker without sudo
# SECURITY NOTE: membership of the docker group is equivalent to root on this
# machine. Acceptable on a disposable lab VM, a risk on a shared workstation.
sudo usermod -aG docker $USER

# Apply the new group membership to your current shell session
newgrp docker

# Install the LDAP command line client tools
# Purpose: ldapsearch, ldapadd, ldapwhoami and ldappasswd are the tools an
# identity engineer uses daily to query and manage any directory
sudo apt-get install -y ldap-utils

# Install Docker Desktop using Homebrew (https://brew.sh if not installed)
brew install --cask docker

# Launch Docker Desktop once so its background service starts
open -a Docker

# macOS ships LDAP client tools by default at /usr/bin
# Verify they are present:
which ldapsearch ldapwhoami

# Run in PowerShell as Administrator
# Installs the Windows Subsystem for Linux with an Ubuntu distribution.
# WSL2 gives you a real Linux environment inside Windows, which is where
# you will run every lab command in this track.
wsl --install -d Ubuntu-22.04

# Reboot when prompted, then create your Linux username and password.

# Open the Ubuntu terminal (Start menu, type Ubuntu) and install ldap-utils
sudo apt-get update && sudo apt-get install -y ldap-utils

3.5 Verification of tools

# Confirm the Docker version. Any 24.x or later value passes.
docker --version

# Confirm the Docker daemon is running by launching a test container
docker run --rm hello-world

# Confirm the LDAP client tools respond. -VV prints version information.
ldapsearch -VV

Real World Problem Statement

This lab solves the single oldest problem in enterprise IT: identity sprawl. Without a central directory, every application, VPN, database, and server maintains its own private list of accounts. Users juggle multiple passwords, IT teams duplicate every joiner and leaver action across systems, and nobody can produce a trustworthy answer to the question auditors always ask first: show me everyone who can access this system.

A directory service is the enterprise answer. It is a purpose built database, optimised for millions of fast reads, that holds people, groups, machines, and service accounts in one hierarchical tree, and exposes them to every other system over a standard protocol, LDAP. Microsoft Active Directory, the identity backbone of roughly 90 percent of large enterprises, is at its core an LDAP directory paired with Kerberos. Master OpenLDAP and you have mastered the mental model behind AD, Entra ID sync, and every HR driven provisioning pipeline you will ever meet.

Why it matters, across four dimensions

Concrete scenario

Northgate Financial, 5,000 employees, has failed an internal audit because 340 active accounts belonged to people who left the company more than 90 days ago, spread across an HR portal, a trading tool, a wiki, and 200 Linux servers. The remediation programme's first deliverable, and your task in this lab, is a central LDAP directory holding every person, structured by organisational unit, with groups that applications can query for authorisation decisions, and a dedicated low privilege service account that applications use to connect. Every later phase of the programme, single sign-on in IB-SIA-02 and federation in IB-SIA-03, builds directly on what you deploy today.

Skills Mapped to Production Solutions

Architecture Overview

Component breakdown

Data flow

1. Admin bind: your terminal connects to port 389 and authenticates as cn=admin,dc=identitybytes,dc=lab. Why: every write to a directory must come from an authenticated, authorised identity, exactly as in production change control.
2. LDIF load: ldapadd streams your LDIF files to the server, which validates each entry against its schema before writing it. Why: schema enforcement is the directory's data quality guarantee; malformed identity data is rejected at the door.
3. User authentication: a simulated application performs a bind as uid=asmith,ou=people,... with that user's password. The server verifies the password hash and returns success or failure. Why: this bind operation is precisely how VPNs, wikis, and legacy applications authenticate users against corporate directories today.
4. Authorisation lookup: the application searches ou=groups with a membership filter to decide what the user may do. Why: separating authentication (who you are) from authorisation (what you may do) is the core architectural pattern of the entire IAM discipline.
5. Encrypted transport: the same operations repeat over LDAPS on port 636, wrapped in TLS. Why: bind requests carry passwords; unencrypted LDAP exposes them to anyone on the network path.

Security considerations

Step by Step Implementation

# Create a project directory and move into it.
# All LDIF files in this lab will live here.
mkdir -p ~/ib-sia-01/ldif && cd ~/ib-sia-01

# Create an isolated Docker bridge network for this lab.
# Enterprise context: identity infrastructure always sits in its own
# network segment with controlled ingress. This is the lab scale version.
docker network create ib-lab-net

# Deploy OpenLDAP in a Docker container.
# Purpose: provides the centralised identity store for the whole track.
# Enterprise context: mirrors a corporate directory such as AD or FreeIPA.
#
# SECURITY NOTE: port 389 is unencrypted LDAP, exposed here for learning.
# Production directories require 636 (LDAPS) or StartTLS for all clients.

docker run -d \
  --name ib-openldap \
  --hostname ldap.identitybytes.lab \
  --network ib-lab-net \
  -p 389:389 \
  -p 636:636 \
  -e LDAP_ORGANISATION="Identity Bytes Lab" \
  -e LDAP_DOMAIN="identitybytes.lab" \
  -e LDAP_ADMIN_PASSWORD="<YOUR_ADMIN_PASSWORD>" \
  -e LDAP_TLS_VERIFY_CLIENT="never" \
  -v ib-ldap-data:/var/lib/ldap \
  -v ib-ldap-config:/etc/ldap/slapd.d \
  osixia/openldap:1.5.0

# -x        use a simple bind (DN + password) rather than SASL
# -H        the server URL: protocol, host, port
# -b        base DN: where in the tree to start searching
# -D        the DN to bind (authenticate) as
# -w        the bind password (prompted securely with -W instead)

ldapsearch -x -H ldap://localhost:389 \
  -b "dc=identitybytes,dc=lab" \
  -D "cn=admin,dc=identitybytes,dc=lab" \
  -w "<YOUR_ADMIN_PASSWORD>"

# extended LDIF
# ... 
dn: dc=identitybytes,dc=lab
objectClass: top
objectClass: dcObject
objectClass: organization
o: Identity Bytes Lab
dc: identitybytes

# numResponses: 2
# numEntries: 1

# Web based LDAP browser, pointed at our server by container name.
# HTTPS is disabled because this listens only on localhost in a lab.

docker run -d \
  --name ib-phpldapadmin \
  --network ib-lab-net \
  -p 8080:80 \
  -e PHPLDAPADMIN_LDAP_HOSTS="ib-openldap" \
  -e PHPLDAPADMIN_HTTPS="false" \
  osixia/phpldapadmin:0.9.0

# Write the LDIF file defining three organisational units
cat > ~/ib-sia-01/ldif/01-structure.ldif << 'EOF'
# Container for human user accounts
dn: ou=people,dc=identitybytes,dc=lab
objectClass: organizationalUnit
ou: people

# Container for authorisation groups
dn: ou=groups,dc=identitybytes,dc=lab
objectClass: organizationalUnit
ou: groups

# Container for non human application identities
dn: ou=service-accounts,dc=identitybytes,dc=lab
objectClass: organizationalUnit
ou: service-accounts
EOF

# Load it into the directory as the admin identity
ldapadd -x -H ldap://localhost:389 \
  -D "cn=admin,dc=identitybytes,dc=lab" \
  -w "<YOUR_ADMIN_PASSWORD>" \
  -f ~/ib-sia-01/ldif/01-structure.ldif

adding new entry "ou=people,dc=identitybytes,dc=lab"
adding new entry "ou=groups,dc=identitybytes,dc=lab"
adding new entry "ou=service-accounts,dc=identitybytes,dc=lab"

cat > ~/ib-sia-01/ldif/02-users.ldif << 'EOF'
# Finance analyst
dn: uid=asmith,ou=people,dc=identitybytes,dc=lab
objectClass: inetOrgPerson
uid: asmith
givenName: Amina
sn: Smith
cn: Amina Smith
mail: amina.smith@identitybytes.lab
title: Finance Analyst
departmentNumber: FIN

# Platform engineer
dn: uid=jpatel,ou=people,dc=identitybytes,dc=lab
objectClass: inetOrgPerson
uid: jpatel
givenName: Jay
sn: Patel
cn: Jay Patel
mail: jay.patel@identitybytes.lab
title: Platform Engineer
departmentNumber: IT

# HR advisor
dn: uid=lokafor,ou=people,dc=identitybytes,dc=lab
objectClass: inetOrgPerson
uid: lokafor
givenName: Lara
sn: Okafor
cn: Lara Okafor
mail: lara.okafor@identitybytes.lab
title: HR Advisor
departmentNumber: HR

# Application bind account for the HR web portal
dn: uid=svc-hrportal,ou=service-accounts,dc=identitybytes,dc=lab
objectClass: inetOrgPerson
uid: svc-hrportal
sn: Service Account
cn: svc-hrportal
description: Bind account used by the HR portal to authenticate users. Owner: Identity Team.
EOF

ldapadd -x -H ldap://localhost:389 \
  -D "cn=admin,dc=identitybytes,dc=lab" \
  -w "<YOUR_ADMIN_PASSWORD>" \
  -f ~/ib-sia-01/ldif/02-users.ldif

# -s sets the new password for the target DN (the final argument).
# The admin DN authorises the change. Repeat for each account.

ldappasswd -x -H ldap://localhost:389 \
  -D "cn=admin,dc=identitybytes,dc=lab" -w "<YOUR_ADMIN_PASSWORD>" \
  -s "<USER_PASSWORD>" "uid=asmith,ou=people,dc=identitybytes,dc=lab"

ldappasswd -x -H ldap://localhost:389 \
  -D "cn=admin,dc=identitybytes,dc=lab" -w "<YOUR_ADMIN_PASSWORD>" \
  -s "<USER_PASSWORD>" "uid=jpatel,ou=people,dc=identitybytes,dc=lab"

ldappasswd -x -H ldap://localhost:389 \
  -D "cn=admin,dc=identitybytes,dc=lab" -w "<YOUR_ADMIN_PASSWORD>" \
  -s "<USER_PASSWORD>" "uid=lokafor,ou=people,dc=identitybytes,dc=lab"

ldappasswd -x -H ldap://localhost:389 \
  -D "cn=admin,dc=identitybytes,dc=lab" -w "<YOUR_ADMIN_PASSWORD>" \
  -s "<USER_PASSWORD>" "uid=svc-hrportal,ou=service-accounts,dc=identitybytes,dc=lab"

cat > ~/ib-sia-01/ldif/03-groups.ldif << 'EOF'
# Group granting access to finance applications
dn: cn=finance-team,ou=groups,dc=identitybytes,dc=lab
objectClass: groupOfNames
cn: finance-team
description: Members may access Northgate finance applications
member: uid=asmith,ou=people,dc=identitybytes,dc=lab

# Group granting administrative access to IT platforms
dn: cn=it-admins,ou=groups,dc=identitybytes,dc=lab
objectClass: groupOfNames
cn: it-admins
description: Members hold administrative access to IT platforms
member: uid=jpatel,ou=people,dc=identitybytes,dc=lab
EOF

ldapadd -x -H ldap://localhost:389 \
  -D "cn=admin,dc=identitybytes,dc=lab" \
  -w "<YOUR_ADMIN_PASSWORD>" \
  -f ~/ib-sia-01/ldif/03-groups.ldif

# LDAPTLS_REQCERT=never tells the client to accept a certificate it cannot
# verify. Required here because the lab certificate is self signed and no
# client trusts it yet. See the security warning below before ever using
# this outside a lab.

LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://localhost:636 \
  -b "dc=identitybytes,dc=lab" \
  -D "uid=asmith,ou=people,dc=identitybytes,dc=lab" \
  -w "<USER_PASSWORD>" \
  "(uid=asmith)" cn mail title

dn: uid=asmith,ou=people,dc=identitybytes,dc=lab
cn: Amina Smith
mail: amina.smith@identitybytes.lab
title: Finance Analyst

result: 0 Success

Testing and Validation

End to end scenario: the HR portal authenticates a user

This test replays, step by step, what a real LDAP integrated application does when Amina Smith logs in. The application first binds with its own service account, searches for the user's entry by username, then attempts a bind as the found DN with the password the user typed, and finally checks group membership. Run all four stages and compare outputs.

# STAGE 1: the application authenticates as itself
ldapwhoami -x -H ldaps://localhost:636 \
  -D "uid=svc-hrportal,ou=service-accounts,dc=identitybytes,dc=lab" \
  -w "<USER_PASSWORD>"
# Expected: dn:uid=svc-hrportal,ou=service-accounts,dc=identitybytes,dc=lab

# STAGE 2: the application finds the user who typed "asmith"
ldapsearch -x -H ldaps://localhost:636 \
  -D "uid=svc-hrportal,ou=service-accounts,dc=identitybytes,dc=lab" \
  -w "<USER_PASSWORD>" \
  -b "ou=people,dc=identitybytes,dc=lab" "(uid=asmith)" dn
# Expected: one entry, dn: uid=asmith,ou=people,dc=identitybytes,dc=lab

# STAGE 3: the application verifies the user's password by binding as them
ldapwhoami -x -H ldaps://localhost:636 \
  -D "uid=asmith,ou=people,dc=identitybytes,dc=lab" \
  -w "<USER_PASSWORD>"
# Expected: dn:uid=asmith,ou=people,dc=identitybytes,dc=lab

# STAGE 4: the application checks authorisation via group membership
ldapsearch -x -H ldaps://localhost:636 \
  -D "uid=svc-hrportal,ou=service-accounts,dc=identitybytes,dc=lab" \
  -w "<USER_PASSWORD>" \
  -b "ou=groups,dc=identitybytes,dc=lab" \
  "(member=uid=asmith,ou=people,dc=identitybytes,dc=lab)" cn
# Expected: cn: finance-team

Negative tests, because security testing means proving failure works

# TEST N1: wrong password must be rejected
ldapwhoami -x -H ldap://localhost:389 \
  -D "uid=asmith,ou=people,dc=identitybytes,dc=lab" -w "WrongPassword1"
# Expected: ldap_bind: Invalid credentials (49)

# TEST N2: a non existent user must be rejected identically
ldapwhoami -x -H ldap://localhost:389 \
  -D "uid=ghost,ou=people,dc=identitybytes,dc=lab" -w "Anything123"
# Expected: ldap_bind: Invalid credentials (49)
# The identical error for wrong user and wrong password is deliberate:
# it prevents attackers enumerating which usernames exist.

# TEST N3: a normal user must not be able to change another user's password
ldappasswd -x -H ldap://localhost:389 \
  -D "uid=asmith,ou=people,dc=identitybytes,dc=lab" -w "<USER_PASSWORD>" \
  -s "Hijacked123!" "uid=jpatel,ou=people,dc=identitybytes,dc=lab"
# Expected: Result: Insufficient access (50)

Common failure modes and solutions

Security Analysis

What makes this implementation secure

• Passwords are stored as salted SSHA hashes, set through ldappasswd, and never appear in LDIF files or shell history as directory data.
• Authentication and authorisation are separated: applications verify identity by user bind and derive permissions from group membership, so no application stores credentials.
• A dedicated service account exists for application binds, in its own ou with a documented owner, so application access can be monitored and revoked independently of any human.
• TLS on port 636 protects credentials and directory data in transit, and the negative tests confirm that wrong passwords, unknown users, and unauthorised writes fail with the correct errors.
• Both container images are version pinned, giving a reproducible and reviewable software supply chain.

What is intentionally simplified for the lab

• The TLS certificate is self signed and clients skip verification; there is no CA hierarchy or certificate lifecycle management yet.
• Plain LDAP on 389 remains enabled for learning and comparison.
• A single directory server: no replication, so no high availability.
• Default access controls and no password policy overlay, so no lockout, complexity, or expiry rules.
• Shared demonstration passwords across accounts, and logs remain local to the container.

Production hardening recommendations

Cleanup Instructions

Option A: pause the lab, keep everything

# Stops both containers. Directory data stays in the Docker volumes.
docker stop ib-openldap ib-phpldapadmin

# Resume later with:
docker start ib-openldap ib-phpldapadmin

Option B: full removal

# Remove containers
docker rm -f ib-openldap ib-phpldapadmin

# Remove the persistent data and configuration volumes.
# WARNING: this permanently deletes the directory contents.
docker volume rm ib-ldap-data ib-ldap-config

# Remove the lab network
docker network rm ib-lab-net

# Optionally remove the images to reclaim disk space
docker rmi osixia/openldap:1.5.0 osixia/phpldapadmin:0.9.0

# Keep ~/ib-sia-01 if you are publishing the portfolio in Section 12;
# otherwise remove it too:
# rm -rf ~/ib-sia-01

Recommended Learning Links

• OpenLDAP 2.4 Administrator's Guide (primary vendor documentation)
• RFC 4511: LDAP, The Protocol
• RFC 4514: String Representation of Distinguished Names
• RFC 2849: The LDAP Data Interchange Format (LDIF)
• RFC 2798: The inetOrgPerson Object Class
• LDAP.com reference guides (excellent protocol level explanations)
• osixia/docker-openldap image documentation (all environment variables used in this lab)
• NIST SP 800-63B: Digital Identity Guidelines, Authentication

Portfolio Publishing Guide: Git, GitHub, and LinkedIn

A completed lab that lives only on your laptop advances your skills; a completed lab published well advances your career. This section takes the artefacts you produced, LDIF files, this guide, and your notes, and turns them into public evidence of capability. Assume you have never used Git before.

12.1 What goes in the repository, and what never does

Recommended structure, one repository for the whole track so it grows visibly over time:

identity-bytes-architect-labs/
├── README.md                  <- the shop window: track overview + lab index
├── .gitignore
└── lab-01-openldap-directory/
    ├── README.md              <- what, why, architecture image, key commands
    ├── docs/
    │   └── IB-SIA-01-openldap-enterprise-directory.html
    ├── ldif/
    │   ├── 01-structure.ldif
    │   ├── 02-users.ldif
    │   └── 03-groups.ldif
    ├── scripts/
    │   └── deploy.sh          <- optional: the docker commands as a script
    └── screenshots/
        ├── phpldapadmin-tree.png
        └── ldapwhoami-success.png

Take the two screenshots now if you have not: the phpLDAPadmin tree showing your three OUs and users, and a terminal showing the successful four stage test from Section 8. Evidence of verification is what separates a portfolio from a tutorial copy.

12.2 Git from zero

# Install Git (Ubuntu; macOS ships it, or use: brew install git)
sudo apt-get install -y git

# Tell Git who you are. This name and email appear on every commit.
git config --global user.name "Muhammad Rizwan Afzal"
git config --global user.email "<YOUR_GITHUB_EMAIL>"
git config --global init.defaultBranch main

# Create the repository folder and copy your lab artefacts in
mkdir -p ~/identity-bytes-architect-labs/lab-01-openldap-directory/{docs,ldif,scripts,screenshots}
cp ~/ib-sia-01/ldif/*.ldif ~/identity-bytes-architect-labs/lab-01-openldap-directory/ldif/

# Initialise Git: this turns the folder into a version controlled repository
cd ~/identity-bytes-architect-labs
git init

# Create a .gitignore so secret and junk files can never be committed
cat > .gitignore << 'EOF'
*.env
*secret*
*password*
.DS_Store
EOF

cat > lab-01-openldap-directory/README.md << 'EOF'
# Lab 01: Enterprise Directory Foundation with OpenLDAP

Part of my Identity Bytes Senior IAM Architect lab series (IB-SIA-01).

## Problem this solves
Identity sprawl: five applications, five account stores, orphaned accounts
surviving leavers. This lab builds the enterprise answer, a central LDAP
directory acting as the single source of truth for people, groups, and
service accounts.

## What I built
- OpenLDAP 2.4 (Docker, version pinned) with persistent volumes
- Directory tree: ou=people, ou=groups, ou=service-accounts under
  dc=identitybytes,dc=lab
- Users and groups loaded via change controlled LDIF (RFC 2849)
- Dedicated least privilege service account for application binds
- TLS secured transport on LDAPS 636
- Four stage application login simulation plus negative security tests

## Skills demonstrated
Directory design (DIT, DNs, objectClasses), LDIF, LDAP search filters,
bind based authentication, group based authorisation, TLS for LDAP,
Docker operations, verification driven troubleshooting.

## Key verification
ldapwhoami as an end user returned the bound DN, group membership
queries returned the expected authorisation data, and negative tests
confirmed invalid credentials and unauthorised writes are rejected.

Full step by step guide: docs/IB-SIA-01-openldap-enterprise-directory.html
EOF

# Stage everything and make the first commit.
# A commit is a snapshot with a message explaining the change.
git add .
git commit -m "Lab 01: OpenLDAP enterprise directory with LDIF, groups, service account, LDAPS"

12.3 Publish to GitHub

# Connect your local repository to GitHub and push (upload) it.
# Replace <YOUR_GITHUB_USERNAME> with your actual username.
git remote add origin https://github.com/<YOUR_GITHUB_USERNAME>/identity-bytes-architect-labs.git
git push -u origin main

12.4 Share it on LinkedIn

Publish within a day or two of finishing while the details are fresh. Attach one screenshot, the architecture diagram or the phpLDAPadmin tree, because posts with a single strong image outperform bare text. Place the GitHub link in the first comment rather than the post body. A draft in the Identity Bytes thought leadership style, ready to adapt:

Posting mechanics: publish Tuesday to Thursday, between 8 and 10 in the morning UK time, when your professional audience is commuting or settling at their desks. Reply to every comment within the first two hours, because early engagement determines reach. Add three to five hashtags at the end of the post, for example #IAM #IdentityManagement #CyberSecurity #OpenLDAP #InfoSec. Repost the series index monthly as new labs land, so the portfolio compounds instead of scrolling into the void.

12.5 The compounding effect

One lab is a post. Thirty six labs, published consistently under one repository and one hashtag series, become a body of work that interviewers reference before you enter the room. When a hiring panel for a role like the Senior IAM Platform Architect position asks about directory design, you will not claim experience; you will send a link.