Active Directory hardening for SMBs: the priorities, in order

The short answer: in most ransomware attacks against a Windows-based company, the attacker’s goal is Active Directory. Once domain admin, they push their payload to every PC through Group Policy, disable protections and encrypt the servers. Hardening an SMB’s Active Directory follows a simple order: first privileged accounts and domain controllers, then weak protocols (SMB and LDAP signing, NTLM, RC4), then service accounts, directory backup and regular audits. This guide details each priority, including what breaks and what to test first.

At ALLSAFE SOLUTIONS, a managed IT provider in Casablanca, we audit and harden Active Directory environments as part of our business cybersecurity in Morocco offering. The settings quoted come from Microsoft Learn documentation (Windows Server, Defender for Identity); ANSSI’s Active Directory recommendations are a good complementary read.

Why Active Directory is target number one

The directory holds everything an attacker wants: every employee account, rights over every server and the ability to push configuration to the whole fleet. In an SMB it has often grown without a plan: a server installed years ago, former employees’ accounts still active, a “backup” service account that is a domain admin with a password that has never changed, and domain controllers that also act as file and print servers.

None of this is visible day to day; everything works. But each point shortens the path between a PC compromised by an email and full control of the domain. We describe this sequence in ransomware: 7 measures for an SMB.

Priority 1: reduce and isolate privileged accounts

This is the measure with the greatest effect, and it breaks almost nothing.

• Empty the Domain Admins group: only named admin accounts remain, never everyday accounts, never a service account.
• Separate accounts: each administrator has an everyday account with no rights and an admin account with no mailbox or browsing. We detail this rule and Windows LAPS in our guide to privileged admin account management.
• Check the other powerful groups: Enterprise Admins, Schema Admins, Account Operators, Backup Operators, Server Operators. They should be empty or nearly so.
• Disable unused accounts: former employees, former contractors, test accounts. A disabled account is no use to anyone, including an attacker.

The tier model, SMB edition

In its enterprise access model, Microsoft describes separating accounts by what they administer. For an SMB, three levels are enough:

Tier	What it contains	Rule
Tier 0	Domain controllers, Domain Admins accounts, Entra Connect sync server, certificate authority	These accounts only sign in to Tier 0
Tier 1	Business servers, file servers, ERP, backup	Dedicated server admin accounts
Tier 2	Desktops and laptops	A unique local admin password per device (Windows LAPS)

The rule to remember: a Domain Admins account never signs in to a user PC. If that PC is compromised, the credentials left in memory open the whole domain. This is enforced through Group Policy, with “Deny log on” rights on workstations for Tier 0 groups.

The Protected Users group

Windows Server provides a built-in security group, Protected Users, that applies several protections to its members at once. According to Microsoft:

• NTLM authentication is blocked against domain controllers;
• Kerberos only uses AES encryption, with no DES or RC4;
• the account cannot be delegated;
• no credentials are cached on the device, so no offline sign-in;
• Kerberos tickets have a four-hour lifetime.

Admin accounts go in it, after testing: an administrator who connects over Remote Desktop by IP address rather than by name falls back to NTLM and will be refused. Never add service accounts or computer accounts, which Microsoft explicitly advises against.

Priority 2: protect domain controllers

A domain controller should do one thing: the directory and internal DNS.

• No other role: no file sharing, no business software, no web browsing from the console.
• Print Spooler disabled: in its Defender for Identity security assessments, Microsoft recommends turning off the Print Spooler service on domain controllers and directory admin systems, through a Group Policy linked to the Domain Controllers OU. This service has been the entry point for several serious vulnerabilities. Check beforehand that no printer is shared from them.
• Patches applied first: domain controllers are among the first servers to update each month; see our security alerts.
• Restricted admin access: Remote Desktop limited to Tier 0 accounts, from an identified admin workstation, never exposed to the internet.
• At least two domain controllers, so that a failure or a restore does not stop the business.

Priority 3: shut down weak protocols

This step needs more preparation, because old devices may stop working. So first enable logging, identify what still depends on legacy protocols, then harden.

Setting	What it prevents	What may break
SMB signing required	Relay attacks and tampering with file traffic	Old NAS units, copiers that scan to a folder, guest access to shares
LDAP signing required on DCs	Relaying and altering LDAP requests	Applications and devices querying the directory over plain LDAP on port 389
LDAP channel binding	Relaying to LDAPS	Older LDAPS clients
NTLM restriction	Theft and relaying of NTLM hashes	Legacy applications, access by IP address
Ending RC4 for Kerberos	Offline cracking of service account tickets	Very old service accounts or non-Windows systems

Recent Windows versions move in this direction by default. According to Microsoft, Windows 11 24H2 (Pro, Enterprise and Education editions) requires SMB signing inbound and outbound, and Windows Server 2025 requires it for outbound connections; new Active Directory deployments on Windows Server 2025 also require LDAP signing. In an existing domain these settings do not apply themselves: they have to be configured through Group Policy, after an inventory. Copiers and NAS units that send scans to a share are the most common case to deal with.

Priority 4: service accounts

Service accounts (backup, antivirus, ERP, database, scanner) are often the most dangerous: a password that never changes, rights that are too broad, sometimes Domain Admins membership granted for convenience during installation.

• Inventory each service account, the application using it and its actual rights.
• Remove domain admin rights and grant only what the application needs.
• Move to group Managed Service Accounts (gMSA) where the application supports them: according to Microsoft, Windows then manages the password instead of the administrator, without any human knowing it.
• Otherwise, a long, unique password, stored in the IT team’s vault and changed according to a defined rule.

Service accounts with a service principal name (SPN) and a weak password are the target of a well-known attack, “Kerberoasting”: any domain user can request a ticket for that account and try to crack its password offline. A managed or very long password and the end of RC4 make this attack ineffective.

Priority 5: back up the directory and prepare its restore

An encrypted or destroyed Active Directory stops the whole company: no sign-in, no shares, no ERP.

• Back up the system state of domain controllers with your backup solution, with at least one offline or immutable copy, following the rule described in our 3-2-1 immutable backup guide.
• Enable the Active Directory Recycle Bin, which restores a deleted object (user, group, OU) with its attributes. Microsoft notes that once enabled, it cannot be disabled.
• Document and test the restore of a domain controller at least once, in an isolated environment.
• Plan the krbtgt reset: this account signs every Kerberos ticket in the domain. Microsoft says to reset its password twice, waiting at least the maximum ticket lifetime (ten hours by default) and for replication between the two. Do it after a compromise, after a domain admin leaves and, as routine hygiene, periodically.

Priority 6: monitor and audit

A directory hardened once degrades over time: a contractor adds an account to Domain Admins for an installation, a new copier demands a legacy protocol, a test account stays active.

• Log additions to privileged groups, admin account sign-ins and Group Policy changes, and forward these logs to a monitoring tool.
• Alert in real time when an account is added to a sensitive group: it is often the first sign of an attack in progress.
• Audit the directory regularly with a specialised tool that ranks weaknesses by severity, and track remediation, as in a security audit and penetration test.
• Pair this monitoring with managed EDR with 24/7 monitoring on PCs and servers.

If your users are also in Microsoft 365, on-premises Active Directory and Microsoft Entra ID are linked by synchronisation: the Entra Connect server belongs to Tier 0, and multi-factor authentication protects the cloud side; see our MFA rollout guide.

The mistakes we fix most often

1. The built-in Administrator account used daily by several people, with a password everyone knows.
2. A service account in Domain Admins, with a password unchanged since installation.
3. The domain controller doubling as a file server, print server and sometimes a workstation.
4. Domain admins signing in to their own PC with their privileged account.
5. Hundreds of inactive accounts, including those of former contractors.
6. No tested directory backup, or a backup reachable with the same credentials as the domain.

Hardening checklist

• Domain Admins group reduced to named admin accounts.
• Separate admin accounts, placed in Protected Users after testing.
• Tier 0 accounts denied sign-in on workstations and business servers.
• Windows LAPS deployed on workstations and member servers.
• Dedicated domain controllers, Print Spooler disabled, patches applied first.
• SMB and LDAP signing required, NTLM and RC4 restricted after inventory.
• Service accounts inventoried, rights reduced, gMSA where possible.
• Offline or immutable DC backup, AD Recycle Bin enabled, restore tested.
• krbtgt reset procedure documented.
• Alerts on privileged groups and regular audits.

How we do it

We start with a free initial audit of your Active Directory: privileged groups, inactive and service accounts, Group Policies, allowed protocols, the state of domain controllers and their backup. We hand you a list of fixes ranked by risk, then apply them in stages, testing each setting on a pilot scope so as not to disrupt operations. Sensitive directory events are then watched by our 24/7 monitoring team, and a critical incident is handled in under 15 minutes, as part of our managed IT services in Morocco.

As a Microsoft partner, we administer Windows Server, Active Directory, Microsoft Entra ID and Intune every day. Request your free initial audit: we reply within 24 business hours.