Identity Management
Active Directory is the Microsoft directory service — the system that stores user accounts, groups, and computers for a Windows network and answers the question every other system eventually asks: who is this, and what are they allowed to do? In a small-business stack it is the piece I stand up first, because identity is the foundation everything else leans on.
I run it as a Windows Server 2022 domain controller on a Proxmox VM. This write-up covers why centralized identity comes first, how to build and promote the domain controller, how to organize it, and how it is meant to become the single source of identity for the rest of the stack — the helpdesk, the HR system, and email.
Approaching this as a solutions architect, the first real problem a growing company hits is not HR or email — it is identity. The moment there is more than a handful of people and more than one system, you need a single, authoritative answer to who works here, what they can access, and how that changes when they join, move, or leave. Without it you get the familiar mess: a separate login for every app, passwords reused or forgotten, accounts that linger long after someone has gone, and no consistent way to enforce policy.
Active Directory solves exactly that problem. It is a central directory of identities with built-in authentication (Kerberos and LDAP), group-based authorization, and policy enforcement through Group Policy. Solve identity first and every system you add afterward can defer to it instead of inventing its own user list.
Start with a clean Windows Server 2022 VM on Proxmox. If you followed my Proxmox templating workflow, this is just another clone; otherwise install Server 2022 from ISO the normal way. A domain controller is not demanding for a small environment — 2 vCPUs, 4 GB of RAM, and a 60 GB disk are comfortable.
Before promoting it, get the basics right, because a domain controller is fussy about its own networking:
DC01 before you promote it; renaming afterward is painful.From an elevated PowerShell prompt:
# Set a static IP (adjust to your subnet)
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 10.10.0.10 `
-PrefixLength 24 -DefaultGateway 10.10.0.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1
# Name the server, then reboot
Rename-Computer -NewName "DC01" -RestartWith the server named and addressed, install the AD DS role and promote the machine into a brand-new forest. You can do this from Server Manager (Add Roles and Features, then the post-deployment promotion wizard), but PowerShell is faster and repeatable:
# Install the AD Domain Services role
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
# Promote to the first DC in a new forest (installs DNS too)
Install-ADDSForest -DomainName "corp.example.com" `
-DomainNetbiosName "CORP" -InstallDns -ForcePick an internal domain name you control — a subdomain of a domain you own (for example corp.example.com) is a safe choice and avoids clashing with public DNS. The server reboots into its new role as a domain controller, now also serving DNS for the domain.
Active Directory lives and dies by DNS. Every domain-joined machine must use the domain controller for DNS, and the DC must resolve its own domain. Most AD problems people hit are really DNS problems -- get this right and the rest behaves.
A flat directory works for five users and falls apart at fifty. Before adding people, lay out a structure that mirrors how the business is organized, using Organizational Units (OUs) as containers you can target with policy:
# Create an OU for staff accounts
New-ADOrganizationalUnit -Name "Staff" -Path "DC=corp,DC=example,DC=com"
# Create a user inside it
New-ADUser -Name "Jane Doe" -SamAccountName "jdoe" `
-UserPrincipalName "[email protected]" `
-Path "OU=Staff,DC=corp,DC=example,DC=com" `
-AccountPassword (Read-Host -AsSecureString) -Enabled $true
# Create a group and add the user to it
New-ADGroup -Name "Helpdesk" -GroupScope Global `
-Path "OU=Staff,DC=corp,DC=example,DC=com"
Add-ADGroupMember -Identity "Helpdesk" -Members "jdoe"Groups are how you grant access — you assign permissions to a group once, then control access by adding and removing members. On top of OUs, Group Policy lets you push consistent settings to every machine and user in an OU: password rules, screen locks, drive mappings, security baselines. This is the leverage that makes central identity worth it — one change applied everywhere.
Here is where it ties together. On its own, a domain controller manages Windows logins. The bigger goal — and the reason it goes in first — is to make Active Directory the single source of identity for every other application in the stack. Faveo, OrangeHRM, and Mailcow all support external authentication over LDAP, which means they can defer to AD instead of keeping their own separate user lists.
That integration is the next step on my roadmap rather than something already wired up, but the design intent is clear: one account per person, created once in AD. When someone is hired, they get an account and a group membership, and that flows to the helpdesk, the HR portal, and their mailbox. When they leave, disabling one account closes every door at once. That single onboarding and offboarding path is the difference between four separate apps and one coherent system.
If you want to practice AD cmdlets without standing up a domain controller, I also built CSVActiveDirectory, a PowerShell module that simulates the AD cmdlets against a CSV backend -- handy for labs and training.
Reduced to outcomes, a central directory gives a small business:
A domain controller is the keys to the kingdom — if it falls, everything does — so a few practices are non-negotiable:
Active Directory is not the flashiest piece of the stack, but it is the one I build first on purpose. Identity is the problem every other system depends on, and solving it once — with a Windows Server 2022 domain controller on Proxmox — gives the helpdesk, HR, and email a backbone to authenticate against. Get identity right and the rest of the stack stops being four separate logins and starts being one system.