Network Authentication & Thin Client Architecture

Part 1: Unix/Linux Home Directory Auto-Mounting

In traditional Unix/Linux environments, users' home directories were stored on a central file server, not on individual workstations. When a user logged in, the system would automatically mount their home directory from the network.

The Players:

NFS (Network File System): The protocol that shares files over the network
LDAP/NIS: The directory service that stores user credentials and information
autofs/automount: The service that automatically mounts directories when needed

How It Works

1. User Login User enters username/password

→

2. Authentication Check credentials against LDAP/NIS server

→

3. User Info Retrieve user details (UID, GID, home dir path)

4. Auto-Mount autofs mounts /home/username from NFS server

→

5. Session Start User gets their files, settings, and desktop

Key Concept: The workstation only provides compute power. All user data lives on the server. Log in from any workstation, get the same home directory!

Part 2: Thin Client + Netbooting (The Full Package)

Thin clients took this concept further: even the operating system could come from the network. The local machine had minimal hardware - just enough to boot and display graphics.

Additional Components:

PXE (Preboot Execution Environment): Lets computers boot from network
TFTP/NFS Boot: Serves the OS image over network
DHCP: Assigns IP and points to boot server

Complete Thin Client Boot Process

1. Power On Thin client has no OS installed

→

2. PXE Boot Network card requests boot image

→

3. OS Download Linux kernel/OS loads over network

4. OS Runs Minimal OS boots in RAM

→

5. Login User authenticates (LDAP/NIS)

→

6. Home Mount /home/username appears via NFS

The Beauty: The thin client has no hard drive, no local storage. Everything - OS, apps, user data - comes from servers. Turn it off, nothing is saved locally. Perfect for security and management!

Part 3: The Windows Way - Terminal Services / RDS

Windows took a different approach with Terminal Services (later called Remote Desktop Services). Instead of netbooting and mounting files, Windows thin clients connect to a server that runs everything.

🐧 Unix/Linux Approach

OS runs on local machine (even if netbooted)
Apps run locally
Only files stored remotely (NFS)
User sees local desktop

🪟 Windows Approach

OS runs on server
Apps run on server
Files stored on server
User sees remote desktop (RDP stream)

Windows RDS/Terminal Services Flow

1. Thin Client Basic Windows or Linux device with RDP client

→

2. RDP Connection Connect to Terminal Server

→

3. Authentication Active Directory validates user

4. Session Created Server creates unique Windows session

→

5. Profile Loads User's roaming profile/redirected folders

→

6. Desktop Displayed Screen pixels sent to thin client

Windows Components:

Active Directory: User authentication (like LDAP)
Terminal Server / RD Session Host: Runs multiple user sessions
Roaming Profiles: User settings follow them (like mounted home dirs)
Folder Redirection: Documents/Desktop stored on file server
RDP Protocol: Sends screen updates and receives keyboard/mouse input

Key Differences & Why It Matters

Unix/Linux Thin Client

Processing: Distributed

CPU/RAM used on thin client
Good for apps needing local graphics
Each client needs decent specs

Storage: Centralized via NFS

Management: Netboot makes updates easy - change server image, all clients get it

Windows Terminal Services/RDS

Processing: Centralized

All CPU/RAM on server
100 users? Server needs LOTS of RAM
Thin clients can be extremely basic

Storage: Centralized on file servers

Management: Update one server, all users get new apps

Bottom Line: Unix/Linux said "boot from network, run locally, store remotely." Windows said "connect to server, everything runs there, we just show you the screen." Both achieve the same goal: users can log in anywhere and get their stuff!

📘 Network Authentication & Thin Client Architecture Guide