LPIC-2 Network Client Management: DHCP, PAM, and LDAP

Picture a laptop that just plugged into the office network. Before anyone can log in to it, three separate questions have to be answered, and LPIC-2 topic 210 is really these three questions wearing different hats:

• "What is my address?" — answered by DHCP, which hands out IP addresses automatically.
• "Is this person allowed to log in, and how do we check?" — answered by PAM, the pluggable framework every login path runs through.
• "Who is this person, centrally?" — answered by LDAP, a shared directory of users and groups so you don't recreate every account on every box.

Think of arriving at a large hotel. The front desk assigns you a room number the moment you arrive (DHCP). Your keycard is checked at every door by the same lock mechanism, no matter which door (PAM). And the hotel's guest registry in the back office knows who you are across the whole property, so the spa and the restaurant don't each need their own copy of your details (LDAP).

The ISC DHCP server (dhcpd) leases IP addresses to clients that ask for one. Its entire behaviour lives in `/etc/dhcp/dhcpd.conf`, and that file does just two jobs:

• Pools — a subnet block with a range says "any client on this network may borrow an address from this band." This is the dynamic, anonymous case: a guest laptop, a phone, a printer you don't care to name.
• Reservations — a host block with fixed-address ties a specific IP to a specific client, identified by its MAC address. This is the static case: the office printer that scripts hardcode, a server that DNS points at.

Analogy: the range is general admission seating — sit anywhere that's free. A reservation is a named seat with your name taped to it; it's yours whether you show up or not.

PAM (Pluggable Authentication Modules) is the layer every login path — login, sshd, sudo, su — calls instead of checking passwords itself. That's the power of it: change the PAM rules once and every login program inherits the new policy.

Each service has a file in `/etc/pam.d/` built from stacked lines. Every line names one of four management groups — the phases of a login:

• auth — prove you are who you say (password, key, token).
• account — are you allowed right now? (account expired? wrong time of day? login disabled?)
• password — the rules for changing a credential (complexity, history).
• session — set up and tear down the session itself (mount home dir, write the log, set limits).

Think of the four groups as airport checkpoints in order: auth = show your passport, account = is your visa still valid, password = renew the passport if it expired, session = the gate agent seats you and logs the boarding.

OpenLDAP's server daemon is `slapd`. It serves a directory: a tree of entries about people, groups, and machines that many systems can share, so you define a user once centrally instead of running useradd on fifty boxes.

Every entry has a Distinguished Name (DN) — its full, unique address read from the leaf up to the root, like uid=jdoe,ou=people,dc=example,dc=com. That reads right-to-left as a path: within domain example.com, organisational unit people, the user jdoe.

Analogy: a DN is a postal address written inside-out — name, then street, then city, then country. Each component narrows down exactly one entry in the tree, the same way uid=jdoe narrows within ou=people narrows within dc=example,dc=com.

You rarely edit the database files directly. Instead you describe changes in LDIF (LDAP Data Interchange Format) — a plain-text record of an entry's attributes — and feed it to the client tools.

Here is the single most important operational fact about LDAP: a plain `ldap://` simple bind sends the bind DN's password across the network in cleartext. Anyone who can sniff the segment — a malicious switch port, a compromised host, an attacker on the same Wi-Fi — reads your directory admin password straight off the wire.

Because LDAP is the authentication backbone, that one captured password often unlocks the whole identity system. So TLS is not a hardening nicety here; it's the baseline.

There are two ways to wrap LDAP in TLS:

• ldaps:// — TLS from the first byte, on the dedicated port 636. The whole conversation is encrypted before any bind happens.
• StartTLS — connect on the normal port 389, then issue a STARTTLS command to upgrade the existing connection to TLS before binding.

Analogy: plain LDAP is shouting your password across a crowded room. ldaps/StartTLS is stepping into a soundproof booth first, then talking.

You have a real root shell to your right. The DHCP, LDAP, and slapd servers may not be installed on this box — they're services you'd add deliberately — so these commands are pure inspection: they read what's already there and never change a thing. Run them in order and connect each back to a concept above.