Windows Server 2022 Domain Controller

Deploy a Windows AD domain controller and join AlmaLinux 9 to the domain.

Introduction

30 Second Summary

Think about what happens when a new employee joins a company with dozens of servers. Without a centralized system, an admin would need to create that user's account on every single machine individually.

In this project, you will set up a Windows Server 2022 Domain Controller running Active Directory and join an AlmaLinux 9 server to that domain. By the end, adding or removing a user from one security group controls their access across your entire network.

What You'll Build

A two-server enterprise identity infrastructure with a Windows Domain Controller providing centralized authentication and an AlmaLinux server joined to the domain via Kerberos.

By the end of this project, you'll have:

A Windows Server 2022 Domain Controller running Active Directory Domain Services with integrated DNS on your ESXi lab network.
An AlmaLinux 9 server joined to the Windows domain using realmd and SSSD for enterprise-grade authentication.
AD group-based access control where membership in a single security group grants SSH and sudo privileges on the Linux server.
Secret Mission: Configure a Group Policy Object that enforces password complexity and account lockout policy across the domain.

Are there any prerequisites?

Yes. You need a completed AlmaLinux 9 VM running on your ESXi host (from Project 1), the Windows Server 2022 ISO uploaded to your ESXi datastore, and access to the ESXi web client.

Your ESXi host should have at least 48 GB of RAM and a port group configured for the 10.1.9.0/24 network.

Create the Windows Server 2022 VM on ESXi

Every enterprise domain needs a central server that controls identity and access for the entire network.

In this step, you'll create a Windows Server 2022 virtual machine on your ESXi host, install the operating system with a graphical interface, and configure its network settings so it's ready to become your Domain Controller.

In this step, get ready to:

Create a new VM on ESXi with the correct hardware specs and attach the Windows Server 2022 ISO.
Install Windows Server 2022 Standard with Desktop Experience.
Configure a static IP address and rename the computer to DC01.

Create the VM in the ESXi web client

The ESXi web client provides a wizard that walks you through creating a virtual machine step by step.

In your browser, return to the ESXi web client and log in if needed.
Click Virtual Machines in the left sidebar.
Click Create / Register VM to open the creation wizard.
Select Create a new virtual machine and click Next.
Enter DC01 as the VM name.
Set Guest OS family to Windows.
Set Guest OS version to Microsoft Windows Server 2022 (64-bit).
Click Next.
Select the datastore where you want to store the VM files and click Next.

Now you'll configure the virtual hardware for the VM.

Set CPU to 2.
Set Memory to 4096 MB.
Set Hard disk 1 to 60 GB.
Expand the hard disk settings and set Disk Provisioning to Thick provisioned, eagerly zeroed.
Under Network Adapter 1, confirm it is connected to the same port group your AlmaLinux VM uses (the 10.1.9.0/24 network).
Under CD/DVD Drive 1, select Datastore ISO file and browse to your Windows Server 2022 ISO.
Check the Connect at power on checkbox next to the CD/DVD drive.
Click Next, review the summary, and click Finish.

Why these specs?

2 vCPUs and 4 GB RAM are enough to run Active Directory Domain Services comfortably in a lab.

The 60 GB thick-provisioned disk ensures Windows has sufficient space for the OS, AD database, and logs without fragmentation issues.

You should now see DC01 listed in the Virtual Machines inventory in the ESXi web client.

Don't see your VM in the list?

Make sure you clicked Finish on the final page of the wizard. If you clicked Back or closed the browser tab, the VM was not created.

If the datastore is full, the wizard will show an error. Check your available storage under Storage in the left sidebar.

help me troubleshoot why my VM didn't appear in the ESXi inventory

Install Windows Server 2022 with Desktop Experience

With the VM created, you'll now power it on and walk through the Windows Server installer.

Select DC01 in the Virtual Machines list and click Power on.
Click the VM's thumbnail or the Console link to open the virtual console window.
When prompted, press any key to boot from the CD/DVD drive.

What if I don't see the boot prompt?

The "Press any key to boot from CD or DVD" message appears briefly. If you miss it, the VM may boot to a blank screen. Power off the VM, then power it back on and press a key quickly.

The Windows Setup wizard will appear. Walk through it with these steps:

Select your language, time/currency format, and keyboard layout, then click Next.
Click Install now.
When prompted for a product key, click I don't have a product key to use the 180-day evaluation.
Select Windows Server 2022 Standard (Desktop Experience) and click Next.
Accept the license terms and click Next.
Select Custom: Install Windows Server only (advanced).
Select the 60 GB unallocated disk and click Next.

Windows will copy files, install features, and reboot the VM several times. This process takes 10-15 minutes.

After the final reboot, you'll see the Customize settings screen. Enter a strong Administrator password and click Finish.
Press Ctrl+Alt+Delete (use the virtual console's send keys option) to reach the login screen.
Log in with the Administrator password you just set.

You should see the Windows Server Desktop with Server Manager launching automatically.

Why Desktop Experience?

Windows Server offers two install modes: Server Core (command-line only) and Desktop Experience (full GUI). You chose Desktop Experience because you'll need graphical tools like Active Directory Users and Computers, DNS Manager, and Group Policy Management Console throughout this project.

You cannot convert between these modes after installation. If you accidentally picked Server Core, you would need to reinstall from scratch.

🙋‍♀️ Stuck at a black screen after reboot?

The VM may be trying to boot from the ISO again instead of the hard disk. In the ESXi web client, edit the VM settings, uncheck Connect at power on for the CD/DVD drive, then reboot the VM.

help me troubleshoot my Windows Server 2022 VM that is stuck on a black screen

Configure a static IP and rename the computer

A Domain Controller must have a static IP address so other machines can reliably find it. You'll also rename the machine to DC01 so it's easily identifiable on the network.

On the Windows Server desktop, right-click the network icon in the system tray (bottom-right corner).
Click Open Network & Internet settings.
Click Change adapter options.
Right-click your Ethernet adapter and select Properties.
Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
Select Use the following IP address and enter these values:

IP address: 10.1.9.20
Subnet mask: 255.255.255.0
Default gateway: 10.1.9.1

Select Use the following DNS server addresses and set the Preferred DNS server to 127.0.0.1.
Click OK to close all network dialogs.

Why set DNS to 127.0.0.1?

After you promote this server to a Domain Controller in the next step, it will run its own DNS server. Setting the DNS client to 127.0.0.1 (localhost) means the server queries itself for name resolution.

Microsoft best practice states the first DC in a domain should point its DNS client to itself so the Netlogon service can register the required SRV records.

Now rename the computer to DC01.

Right-click the Start button and select System.
Click Rename this PC (or click Change settings next to the computer name, then click Change).
Enter DC01 as the computer name and click OK.
When prompted, click Restart Now to apply the new name.

After the restart, log back in as Administrator. You should see the computer name displayed as DC01 in Server Manager's dashboard.

Computer name didn't change?

The rename only takes effect after a restart. If you skipped the restart prompt, right-click Start, select Shut down or sign out, then Restart.

help me troubleshoot why my Windows Server computer name did not change to DC01

Your Windows Server 2022 VM is ready. It has a static IP, a clean name, and a graphical interface for the tools you'll need. Next up, you'll install Active Directory Domain Services and promote this server to a Domain Controller.

Install AD DS and Promote to Domain Controller

Your Windows Server VM is ready with a static IP and a clean hostname. Now it's time to turn it into the brain of your network.

A Domain Controller is a server that runs Active Directory Domain Services (AD DS) and authenticates every user and computer in the domain. In this step, you will install the AD DS role, promote DC01 to the first Domain Controller in a brand new forest called lab.local, and configure DNS forwarding so the network can still resolve external names.

In this step, get ready to:

Install the Active Directory Domain Services role via Server Manager.
Promote DC01 to a Domain Controller and create the lab.local forest.
Verify AD DS and DNS are working, then configure a DNS forwarder.

Install the Active Directory Domain Services role

Before a server can become a Domain Controller, it needs the AD DS role binaries installed. This is a two-stage process: first you install the role, then you promote the server.

In Server Manager, click Manage in the top-right corner.
Select Add Roles and Features.
On the Before you begin page, click Next.
On Installation Type, select Role-based or feature-based installation, then click Next.
On Server Selection, confirm DC01 is selected in the server pool, then click Next.
On Server Roles, check the box for Active Directory Domain Services.
A dialog appears asking to add required features. Click Add Features, then click Next.
On Features, leave the defaults and click Next.
On the AD DS information page, click Next.
On Confirmation, click Install.
Wait for the installation to complete. This takes a minute or two.
After installation succeeds, click the yellow notification flag in Server Manager and select Promote this server to a domain controller.

What is Active Directory Domain Services?

AD DS is a directory service that stores information about users, computers, and groups on your network. It handles authentication (proving who you are) and authorization (deciding what you can access).

When you promote a server to a Domain Controller, it becomes the central authority that every other machine in the domain trusts for identity decisions.

🙋‍♀️ Don't see the yellow notification flag?

Make sure the installation status shows Installation succeeded on the Results page. If the wizard is still open, look for the Promote this server to a domain controller link directly on the Results page.

If you accidentally closed the wizard, reopen Server Manager and click the yellow triangle icon in the top menu bar.

Help me troubleshoot the AD DS role installation

Promote DC01 to a Domain Controller

The AD DS Configuration Wizard walks you through creating a new forest. A forest is the top-level container in Active Directory. Everything you build (domains, users, groups) lives inside it.

On the Deployment Configuration page, select Add a new forest.
In the Root domain name field, type lab.local.
Click Next.
On Domain Controller Options, leave the Forest functional level and Domain functional level at Windows Server 2016 (this is the highest named level available on Server 2022).
Confirm Domain Name System (DNS) server and Global Catalog (GC) are both checked. They should be checked by default.
Enter a strong DSRM password and confirm it. This is a recovery password you would use if you ever need to boot the DC in safe mode.
Click Next.
On DNS Options, you may see a warning about delegation. Ignore it and click Next.
On Additional Options, verify the NetBIOS domain name shows LAB. Click Next.
On Paths, accept the default locations for the database, log files, and SYSVOL. Click Next.
On Review Options, review your settings and click Next.
On Prerequisites Check, wait for validation to complete. You may see a few warnings (this is normal for the first DC). Click Install.
The server restarts automatically after promotion completes. This takes several minutes.

Why Windows Server 2016 functional level?

Windows Server 2022 did not introduce a new functional level. The highest named functional level is still called "Windows Server 2016". This is expected and correct.

💡 What is DSRM?

Directory Services Restore Mode is a special boot mode that lets you repair or recover the Active Directory database if it becomes corrupted. The DSRM password is your emergency backup key. Store it somewhere safe.

🙋‍♀️ Prerequisites Check showing errors?

A warning about DNS delegation is normal for the first DC in a new forest. You can safely ignore it.

If you see a hard error about the DNS client settings, confirm that DC01's preferred DNS is set to 127.0.0.1 (itself). You configured this in the previous step.

Help me fix my AD DS prerequisites check errors

Verify AD DS and configure DNS forwarding

After the restart, DC01 is officially a Domain Controller. You need to verify that Active Directory and DNS are both running correctly, then set up a DNS forwarder so machines using this DC as their DNS server can still reach the internet.

Log in as LAB\Administrator using the same password you set during Windows installation.
Open Server Manager (it should launch automatically on login).
Click Tools in the top menu bar, then select Active Directory Users and Computers.
Expand the lab.local domain in the left panel. Confirm you see the default containers: Computers, Domain Controllers, and Users.
Close Active Directory Users and Computers.

What are these default containers?

Active Directory creates several default Organizational Units (OUs) and containers when you build a new forest. Domain Controllers holds your DC computer accounts. Computers is where new domain-joined machines land by default. Users contains built-in accounts and groups.

Now verify that the DNS zone was created correctly.

In Server Manager, click Tools, then select DNS.
In DNS Manager, expand DC01, then expand Forward Lookup Zones.
Click on lab.local. Verify you see subfolders: _msdcs, _sites, _tcp, and _udp. These contain the SRV records that allow other machines to discover the Domain Controller.

What are SRV records?

SRV (service) records tell clients where to find specific services on the network. When your AlmaLinux box joins the domain later, it queries these exact SRV records to locate the Domain Controller for authentication.

Finally, configure a DNS forwarder so that clients using DC01 as their DNS server can still resolve external domains like google.com.

In DNS Manager, right-click DC01 in the left panel and select Properties.
Click the Forwarders tab.
Click Edit.
Type 8.8.8.8 in the IP address field and press Enter.
Click OK to close the Edit Forwarders dialog.
Click OK to close the server properties.

Why add a DNS forwarder?

Your DC handles DNS for the lab.local zone, but it does not know how to resolve external names on its own. A forwarder tells the DC: "If you don't know the answer, ask Google's DNS (8.8.8.8) instead."

Without this, any machine pointing to DC01 for DNS would lose the ability to resolve anything outside your lab network.

🙋‍♀️ Can't find the Forwarders tab?

Make sure you right-clicked the server name (DC01) in the left panel of DNS Manager, not the zone name. The Forwarders tab only appears in the server-level properties.

Help me configure DNS forwarders on my Domain Controller

DC01 is now a fully functional Domain Controller with integrated DNS. Next up, you will create the AD users and groups that will control who can log in to your Linux server.

Create AD Users and Groups for Linux Access

Your Domain Controller is live and serving DNS for the lab.local forest. The next challenge is giving your Linux server a way to authenticate users against this domain.

For that to work, Active Directory needs a user account and a security group that you will later map to SSH and sudo access on the AlmaLinux box. You will also verify that the DNS SRV records are healthy, because AlmaLinux relies on those records to discover the Domain Controller automatically.

In this step, get ready to:

Create a "Linux Admins" security group in Active Directory.
Create a test user and add it to the group.
Verify DNS SRV records that AlmaLinux will use for domain discovery.

Create the Linux Admins security group

Security groups in AD let you bundle users together and grant permissions to the whole group at once. You will create a group called "Linux Admins" that later controls who can SSH into the Linux server.

In Active Directory Users and Computers (already open from the previous step), expand lab.local in the left pane.
Right-click the Users container.
Select New, then Group.
In the Group name field, type Linux Admins.
Set Group scope to Global.
Set Group type to Security.
Click OK.

Why a Security group and not a Distribution group?

Security groups can be used in access control lists (permissions, login restrictions, sudo rules). Distribution groups are only for email distribution. Since you need to control SSH access, a Security group is the correct choice.

You should now see Linux Admins listed in the Users container alongside the built-in groups.

Create a test user and add it to the group

You need at least one user in the Linux Admins group so you can test the full authentication flow later. You will create a user called testadmin and add it to the group.

Right-click the Users container again.
Select New, then User.
Enter Test in the First name field.
Enter Admin in the Last name field.
Enter testadmin in the User logon name field.
Click Next.
Enter a password of your choice. Make it something you will remember for testing later.
Uncheck User must change password at next logon.
Check Password never expires.
Click Next, then Finish.

Why disable password expiration in a lab?

In production, you would enforce password rotation. In a lab environment, an expired password can silently break your domain-join tests days later. Disabling expiration avoids that frustration while you are learning.

Now add the new user to the Linux Admins group:

In the Users container, right-click the Linux Admins group.
Select Properties.
Click the Members tab.
Click Add.
Type testadmin in the text box.
Click Check Names. The name should resolve to Test Admin with an underline, confirming it was found.
Click OK, then Apply, then OK.

The Members tab should now list testadmin as a member of the Linux Admins group.

Check Names not resolving?

If the name does not resolve, make sure you typed testadmin exactly as you entered it in the User logon name field. Also confirm the user was created successfully by checking that it appears in the Users container list.

Help me troubleshoot why Check Names is not finding my user in AD.

Verify DNS SRV records from the Domain Controller

When AlmaLinux joins the domain, it queries DNS for SRV records to locate the Domain Controller automatically. If those records are missing or broken, the domain join will fail silently. You will verify them now so you can troubleshoot on the DC side before touching the Linux box.

Open PowerShell on DC01. Press Win and type PowerShell, then press Enter.
Run the DNS diagnostics test by entering this command:

dcdiag /test:dns

What does this command do?

The dcdiag /test:dns command runs a battery of DNS health checks against your Domain Controller. It verifies connectivity, basic DNS configuration, forwarder settings, dynamic update capability, and SRV record registration.

When all tests pass, the final line reads something like lab.local passed test DNS. If any test fails, the output tells you exactly which check failed so you can fix it before proceeding.

Confirm that all tests pass. The output ends with a line confirming the domain passed the DNS test.

Now confirm the specific LDAP SRV record that AlmaLinux will query by running:

nslookup -type=SRV _ldap._tcp.lab.local 127.0.0.1

What does this command do?

This queries the local DNS server (127.0.0.1) for the LDAP SRV record. The SRV record tells clients which server provides the LDAP service for lab.local and on which port.

You should see output showing the svr hostname as dc01.lab.local with port 389 and the internet address resolving to 10.1.9.10. This is the exact record that AlmaLinux will query during the domain join in the next step.

🙋‍♀️ SRV record not found or query timed out?

If nslookup returns an error or no records, check that the DNS Server service is running on DC01. Open Server Manager, click Tools, then DNS, and verify the lab.local forward lookup zone exists with records under _tcp.

If the zone exists but SRV records are missing, restart the Netlogon service to re-register them. In PowerShell, run net stop netlogon followed by net start netlogon.

Help me troubleshoot missing DNS SRV records on my Domain Controller.

Your Active Directory is now populated with a security group and a test user, and DNS is confirmed healthy. Next up, you will switch over to the AlmaLinux VM and join it to this domain.

Prepare AlmaLinux 9 and Join the Domain

Your Domain Controller is fully operational with Active Directory, integrated DNS, and user accounts ready to authenticate. Now it's time to bring your Linux server into the domain.

In this step, you'll configure your AlmaLinux 9 VM to use DC01 as its DNS server, install the packages needed for Active Directory integration, and join the machine to your lab.local domain using realmd and SSSD.

In this step, get ready to:

Configure AlmaLinux DNS to point to DC01.
Install AD integration packages and set the crypto policy.
Join AlmaLinux 9 to the lab.local domain.

Point AlmaLinux DNS to the Domain Controller

For AlmaLinux to discover and join the domain, it needs to resolve the DNS SRV records that Active Directory registered on DC01. You'll point the Linux VM's DNS to the Domain Controller so it can find those records.

SSH into your AlmaLinux 9 VM from your workstation by running this command:

ssh [[ALMA_USER="your AlmaLinux username, e.g. root"]]@[[ALMA_IP="your AlmaLinux VM IP address, e.g. 10.1.9.100"]]

Use the ESXi console instead

If you prefer, you can open the AlmaLinux VM console directly from the ESXi web client instead of using SSH.

Find your network connection name by running:

nmcli connection show

You should see a table with a NAME column listing your connection profiles. Look for the name of your Ethernet connection (it might be something like ens192, eth0, or Wired connection 1).

Don't see any connections listed?

Make sure NetworkManager is running. Run sudo systemctl status NetworkManager and confirm it shows active (running).

Help me troubleshoot my nmcli connection on AlmaLinux 9.

Configure your DNS to point to DC01 by running these commands (replace the connection name with yours):

sudo nmcli connection modify [[CONNECTION_NAME="your connection name, e.g. ens192"]] ipv4.dns "10.1.9.20"
sudo nmcli connection modify [[CONNECTION_NAME="your connection name, e.g. ens192"]] ipv4.ignore-auto-dns yes
sudo nmcli connection up [[CONNECTION_NAME="your connection name, e.g. ens192"]]

What do these commands do?

The first command sets 10.1.9.20 (DC01) as the DNS server for this connection. The second command tells NetworkManager to ignore any DNS servers provided automatically by DHCP.

The third command reactivates the connection so the new settings take effect immediately. This approach persists across reboots, unlike editing /etc/resolv.conf directly (which NetworkManager would overwrite).

Verify your DNS is now pointing to the Domain Controller by running:

cat /etc/resolv.conf

You should see nameserver 10.1.9.20 in the output.

Test that AlmaLinux can resolve the domain's SRV records by running:

dig -t SRV _ldap._tcp.lab.local

You should see an ANSWER SECTION that resolves to 10.1.9.20 (your Domain Controller's IP). This is the exact record that AlmaLinux uses to locate the domain when joining.

Command not found when running dig?

The dig command is not installed by default on AlmaLinux 9 minimal installs. Install it by running sudo dnf install -y bind-utils, then try the dig command again.

Help me get dig working on my AlmaLinux 9 VM.

Install AD integration packages and set the crypto policy

AlmaLinux needs several packages to communicate with Active Directory. These handle Kerberos authentication, domain discovery, and automatic home directory creation for AD users.

Install all the required packages by running:

sudo dnf install -y adcli realmd sssd oddjob oddjob-mkhomedir samba-common-tools krb5-workstation authselect-compat

What are these packages?

realmd discovers and joins domains automatically.
sssd handles user lookups and authentication against AD.
adcli manages the machine account in Active Directory.
oddjob-mkhomedir creates home directories automatically when AD users log in for the first time.
krb5-workstation provides Kerberos tools for ticket-based authentication.

You should see a Complete! message when the installation finishes.

Packages failing to install?

Make sure your AlmaLinux VM can reach the internet for package downloads. Since you just changed DNS to point to DC01, the DC needs its DNS forwarder (8.8.8.8) working to resolve external package repositories.

Run ping google.com to test external name resolution. If it fails, go back to DC01 and verify the DNS forwarder is configured (DNS Manager, right-click the server, Properties, Forwarders tab).

Help me troubleshoot package installation failures on my AlmaLinux 9 VM.

Set the crypto policy to allow AD-compatible encryption by running:

sudo update-crypto-policies --set DEFAULT:AD-SUPPORT-LEGACY

Why this crypto policy?

AlmaLinux 9 ships with strict default crypto policies that block some older encryption algorithms. Active Directory uses certain protocols that these defaults reject.

The DEFAULT:AD-SUPPORT-LEGACY policy relaxes just enough to allow AD integration while keeping everything else secure. Without this, the domain join will fail with authentication errors.

You should see a confirmation message indicating the policy was set successfully.

Discover the domain to confirm AlmaLinux can see your Active Directory environment by running:

sudo realm discover lab.local

You should see output that includes type: kerberos, realm-name: LAB.LOCAL, server-software: active-directory, and configured: no.

Realm discover showing no results?

This means DNS resolution to the domain isn't working. Double-check that cat /etc/resolv.conf shows nameserver 10.1.9.20.

Also verify the DC is reachable by running ping 10.1.9.20. If the ping succeeds but realm discover fails, the DNS service on DC01 may not be running properly.

Help me troubleshoot why realm discover can't find my domain.

Join AlmaLinux to the lab.local domain

Everything is in place. DNS resolves the domain, the packages are installed, and the crypto policy is set. Time to join the domain.

Join the domain by running this command:

sudo realm join lab.local -U Administrator

Enter the LAB\Administrator password when prompted.

What happens during realm join?

Behind the scenes, realmd is doing several things for you. It obtains a Kerberos ticket for the Administrator account, creates a computer account in Active Directory for this Linux machine, configures SSSD to authenticate against the domain, and starts the necessary services.

This is the enterprise-recommended method for joining Linux to AD. Red Hat documentation explicitly recommends SSSD as the component to connect RHEL systems with Active Directory.

Verify the domain join was successful by running:

realm list

You should see lab.local listed with configured: kerberos-member in the output. This confirms your machine is now part of the domain.

Test that AD user lookups work by running:

id testadmin@lab.local

You should see UID and GID information for the testadmin AD user. This proves that AlmaLinux can query Active Directory and resolve user identities.

Realm join failing with authentication errors?

Make sure you're typing the correct Administrator password (the one you set on DC01). The password is case-sensitive.

If you see errors about encryption types, confirm you set the crypto policy correctly by running update-crypto-policies --show. It should display DEFAULT:AD-SUPPORT-LEGACY.

Help me troubleshoot my realm join failure.

Your AlmaLinux server is now a member of the lab.local domain. Next up, you'll lock down SSH access so only members of the Linux Admins AD group can log in, and give them sudo privileges.

Configure AD Group-Based SSH Access and Sudo

Your AlmaLinux server is joined to the domain and can look up AD users. But right now, every AD user in the domain could potentially log in.

In a real enterprise, you lock down access so only specific groups can SSH in and run privileged commands. This step configures group-based access control using realmd for SSH and /etc/sudoers.d/ for sudo privileges.

In this step, get ready to:

Restrict SSH access to only the "Linux Admins" AD group.
Configure sudo privileges for that AD group via a drop-in file.
Test the full authentication flow by logging in as the AD user.

Restrict SSH access to the Linux Admins group

By default, after joining a domain, all AD users can log in. The realm permit command lets you lock login access down to specific groups.

In your SSH session on the AlmaLinux VM, restrict login access to only the "Linux Admins" group by running this command:

sudo realm permit -g "Linux Admins@lab.local"

What does this command do?

The -g flag tells realm you are permitting a group (not an individual user). After this, only members of the "Linux Admins" security group can log in via SSH. All other AD users are denied.

This is the enterprise approach to access control. Instead of managing user lists on each server, you manage group membership in one place (Active Directory) and it applies everywhere.

Verify the restriction is active by running:

sudo realm list

You should see permitted-groups: Linux Admins@lab.local in the output. This confirms only that group can log in.

Don't see permitted-groups in the output?

Make sure you included the -g flag. Without it, realm expects a username, not a group name.

Also check the group name is exactly Linux Admins@lab.local with a space between "Linux" and "Admins". AD group names are case-insensitive, but the format matters.

help me troubleshoot why realm permit did not apply the group restriction

Now configure SSSD for simpler logins. By default, AD users must log in with their full qualified name (like testadmin@lab.local). You can simplify this so they only need to type testadmin.

Open the SSSD configuration file by running:

sudo vi /etc/sssd/sssd.conf

Find the [domain/lab.local] section in the file.
Add or change these two settings inside that section:

use_fully_qualified_names = False
fallback_homedir = /home/%u

What do these settings do?

The use_fully_qualified_names = False setting lets users log in as just testadmin instead of testadmin@lab.local. This makes day-to-day SSH access much more convenient.

The fallback_homedir = /home/%u setting creates home directories at /home/testadmin instead of /home/testadmin@lab.local. The %u is a variable that expands to the short username.

Save and exit the file (press Esc, then type :wq and press Enter).
Restart the SSSD service to apply the changes by running:

sudo systemctl restart sssd

Verify SSSD is running without errors by running:

sudo systemctl status sssd

You should see active (running) in the output. Press q to exit the status view.

SSSD failed to start?

Check the configuration file syntax. A common mistake is a typo in the section name or missing the equals sign. Run sudo cat /etc/sssd/sssd.conf and confirm your edits are inside the [domain/lab.local] section.

help me troubleshoot why SSSD failed to restart after editing sssd.conf

Configure sudo for the AD group via /etc/sudoers.d/

SSH access alone is not enough. AD users also need elevated privileges for system administration tasks. The enterprise practice is to use a drop-in file in /etc/sudoers.d/ rather than editing /etc/sudoers directly. Drop-in files survive package upgrades and are easier to manage with automation tools.

Create the sudoers drop-in file for the Linux Admins group by running:

echo '%Linux\ Admins@lab.local ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/domain_admins

What does this sudoers line mean?

The % prefix tells sudo this is a group (not a user). The backslash before the space (Linux\ Admins) escapes the space in the group name. ALL=(ALL) ALL means members can run any command as any user on any host.

Using /etc/sudoers.d/ is the enterprise best practice. If you edit /etc/sudoers directly, a system update could overwrite your changes. Drop-in files are safe from upgrades.

Set the correct permissions on the file by running:

sudo chmod 440 /etc/sudoers.d/domain_admins

Validate the sudoers syntax by running:

sudo visudo -c

You should see output indicating all files parsed OK. This confirms your sudoers syntax is correct and sudo will not break.

Seeing a syntax error from visudo?

The most common cause is a missing backslash before the space in the group name. The file must contain %Linux\ Admins@lab.local (with the backslash). Without it, sudo treats "Admins@lab.local" as a separate token and the parse fails.

Check the file contents with sudo cat /etc/sudoers.d/domain_admins and verify the line is exactly %Linux\ Admins@lab.local ALL=(ALL) ALL.

help me fix a sudoers syntax error in my domain_admins drop-in file

Test the full authentication flow

Everything is configured. Time to prove it works end-to-end: AD authentication, group-based SSH access, and centralized sudo privileges all in one test.

From your workstation or the ESXi console, SSH into the AlmaLinux box as the AD user by running:

ssh testadmin@[[ALMA_IP="your AlmaLinux VM IP address, e.g. 10.1.9.100"]]

Enter the AD password for the testadmin account when prompted.
You should land at a shell prompt as testadmin. This proves Kerberos authentication and the AD group-based SSH restriction are working.

Why just testadmin and not testadmin@lab.local?

Because you set use_fully_qualified_names = False in the SSSD config, you can log in with just the short username. If you skipped that optional config change, you would need to use testadmin@lab.local as the SSH username instead.

Now test sudo access by running:

sudo whoami

Enter the testadmin AD password when prompted.
The command should return root. This proves the AD group-based sudo privileges are working.

What did you just prove?

Three enterprise systems all working together in one test:

AD authentication: the user's password was verified against the Domain Controller via Kerberos.
Group-based access control: only members of "Linux Admins" can SSH in at all.
Centralized sudo: adding or removing a user from the AD group instantly changes their privileges on every domain-joined Linux server.

🙋‍♀️ SSH login rejected or sudo denied?

If SSH rejects the password, verify the testadmin user is still a member of the "Linux Admins" group in Active Directory Users and Computers on the DC. Also confirm the SSSD service is running on the AlmaLinux box with systemctl status sssd.

If SSH works but sudo whoami says the user is not in the sudoers file, check the permissions on /etc/sudoers.d/domain_admins with ls -l /etc/sudoers.d/domain_admins. Permissions must be 440 (read-only for root and group). If they are wrong, run sudo chmod 440 /etc/sudoers.d/domain_admins again.

help me troubleshoot why my AD user cannot SSH or get sudo on the domain-joined AlmaLinux box

Your enterprise identity infrastructure is fully operational. Next up, the Secret Mission challenges you to enforce domain-wide password policy using Group Policy Objects.

Secret mission

Configure Domain Password Policy via Group Policy

Your domain is running, your Linux box is joined, and AD group access is working. But right now any user could set a one-character password. In a real enterprise, Group Policy Objects enforce security standards domain-wide. Can you configure password complexity and account lockout policies that protect every account in the forest?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on your local ESXi host, so there are no ongoing cloud costs.

Resources you used:

Windows Server 2022 VM (DC01) on ESXi with Active Directory Domain Services, DNS, and Group Policy configured.
AlmaLinux 9 VM domain join configuration (realmd, SSSD, DNS pointing to DC01).
AD objects: lab.local forest, Linux Admins security group, testadmin user account.
Local config files on AlmaLinux: /etc/sudoers.d/domain_admins and /etc/sssd/sssd.conf modifications.

Keep everything running

No action needed. Choose this if you plan to continue building on this lab environment, such as adding more Linux servers to the domain or experimenting with Group Policy.

Both VMs remain powered on and fully functional.
The domain join, SSH access control, and sudo configuration stay active.
You can continue adding users and groups to Active Directory at any time.

Pause - I'll come back to this later

Shut down the VMs to free up RAM and CPU on your ESXi host. Your configurations are preserved on disk and will resume when you power the VMs back on.

In the ESXi web client, select the DC01 VM and click Shut down (under Actions).
Shut down the AlmaLinux 9 VM the same way, or SSH in and run sudo shutdown now.
When you return, power on DC01 first. Wait 1-2 minutes for AD DS and DNS to start, then power on the AlmaLinux VM.

Delete - I don't want to use this again

Remove the Windows Server VM and undo the domain join on AlmaLinux to return your environment to its pre-project state.

Unjoin AlmaLinux from the domain

SSH into the AlmaLinux 9 VM and leave the domain by running:

sudo realm leave lab.local

Remove the sudoers drop-in file:

sudo rm /etc/sudoers.d/domain_admins

Revert DNS to your original upstream DNS server (replace ens192 with your connection name and 10.1.9.1 with your gateway or preferred DNS):

sudo nmcli connection modify ens192 ipv4.dns "10.1.9.1"
sudo nmcli connection modify ens192 ipv4.ignore-auto-dns no
sudo nmcli connection up ens192

Delete the Windows Server 2022 VM from ESXi

In the ESXi web client, select the DC01 VM.
If it is powered on, click Actions, then Power, then Power off.
Click Actions, then Delete.
Select Delete from disk to remove the VM and its virtual disk files from the datastore.

Clean up the Windows Server ISO (optional)

In the ESXi web client, navigate to Storage, open your datastore, and browse to the folder containing the Windows Server 2022 ISO.
Select the ISO file and click Delete to free up datastore space.

Nice Work!

You just built a production-grade enterprise identity infrastructure from scratch. A Windows Server 2022 Domain Controller and a domain-joined AlmaLinux 9 server now work together to provide centralized authentication, access control, and privilege management across your mixed-OS lab.

You've learned how to:

Build a Windows Server 2022 Domain Controller with Active Directory Domain Services and integrated DNS from scratch on ESXi, creating a fully functional AD forest with automatic SRV record registration.
Join an AlmaLinux 9 server to a Windows domain using realmd and SSSD, the enterprise-recommended method for Linux-AD integration.
Configure centralized, AD group-based SSH access control and sudo privileges via /etc/sudoers.d/ tied to an AD security group, eliminating per-box user management.
Secret Mission: Enforced domain-wide password complexity and account lockout policy via Group Policy Objects.

Ready to quiz yourself?