What Zero Trust Actually Means

The traditional “castle-and-moat” security model assumed everything inside the network was safe. Zero Trust flips this: trust is never implicit, always earned. The core principles are:

• Verify explicitly — always authenticate and authorize based on all available data points
• Use least privilege access — limit user access with just-in-time and just-enough access
• Assume breach — minimize blast radius and segment access to limit lateral movement

“Zero Trust is not a product you buy — it’s an architecture you build. Start small, prioritize identity, and iterate.”

Step 1: Start with Identity

Identity is the new perimeter. Before you touch anything else, get your identity infrastructure solid. This means deploying Multi-Factor Authentication (MFA) everywhere, using a centralized identity provider (IdP), and enforcing conditional access policies.

For Microsoft shops, Azure AD (now Entra ID) is the obvious choice. For Google Workspace environments, Google Cloud Identity works similarly. Both support Conditional Access policies that can enforce MFA, device compliance checks, and sign-in risk scoring.

Step 2: Inventory and Classify Your Assets

You can’t protect what you can’t see. Run an asset discovery scan across your environment. Tools like nmap, Lansweeper, or even the built-in Windows SCCM can give you a full picture of what’s on your network. Once you have the list, classify assets by sensitivity:

# Quick nmap host discovery scan
nmap -sn 192.168.1.0/24 -oG - | grep "Status: Up" | cut -d " " -f2

# Export to CSV for asset tracking
nmap -sn 192.168.1.0/24 --open -oX assets.xml
xsltproc nmap.xsl assets.xml > assets.csv

Step 3: Micro-segment Your Network

Network segmentation is a core Zero Trust control. Instead of one flat network, break it into segments — servers, endpoints, IoT devices, guest Wi-Fi — each with explicit firewall rules. On a tight budget, this can be done with VLANs on a managed switch and firewall ACLs.

The goal is to ensure that if an attacker compromises a device on one segment, they can’t freely move to others. Even basic segmentation (servers separate from workstations) dramatically reduces your attack surface.

Step 4: Device Compliance Checking

Zero Trust requires knowing the health of devices before granting access. This means checking for:

• OS patch level (is the device up to date?)
• Endpoint protection (is antivirus/EDR running and current?)
• Disk encryption (is BitLocker/FileVault enabled?)
• Jailbreak/root detection for mobile devices

Microsoft Intune and Jamf handle this for managed fleets. For unmanaged or BYOD devices, conditional access policies can block or limit access until compliance is confirmed.

The Bottom Line

Zero Trust doesn’t happen overnight. Pick one pillar — start with Identity — and harden it completely before moving to the next. The journey matters more than reaching a theoretical “Zero Trust complete” state, which doesn’t really exist. Keep iterating, keep monitoring, and assume the breach is already happening.

The post Zero Trust Architecture: A Practical Implementation Guide for SMBs appeared first on InfoTech Ninja.

Why AD Defaults Are an Attacker’s Dream

Out of the box, Active Directory ships with configurations that made sense in the early 2000s but are dangerous today. Pre-Windows 2000 compatibility groups, default permissive ACLs on objects like AdminSDHolder, unrestricted Kerberos delegation, and the universal availability of NTLM authentication all create conditions that attackers exploit with freely available tools like BloodHound, Mimikatz, and Impacket.

BloodHound analysis on a typical enterprise AD environment consistently reveals hundreds of unintended privilege escalation paths — most of them created not by attackers, but by years of accumulated admin shortcuts. A user gets added to Domain Admins “temporarily” and never removed. A service account gets unnecessary replication rights. These misconfigurations compound over time, and without deliberate hardening, your AD becomes a house of cards.

Implement a Tiered Administration Model

Microsoft’s tiered administration model (also called the Enterprise Access Model) separates administrative access into three distinct tiers. Tier 0 covers your most critical assets: domain controllers, ADFS servers, PKI infrastructure, and identity management systems. Tier 1 covers server workloads and applications. Tier 2 covers end-user workstations and devices. Credentials from a lower tier must never be able to access a higher tier.

Privileged Access Workstations (PAWs) are a critical implementation detail. Tier 0 administrators should only perform privileged actions from dedicated, hardened workstations that are not used for email, web browsing, or general productivity work. These PAWs should be enrolled in their own OU with restrictive GPOs, application whitelisting via AppLocker or WDAC, and credential guard enabled. Yes, it adds friction — that friction is the point.

Lock Down NTLM and Legacy Protocols

NTLM is responsible for more lateral movement and credential relay attacks than almost any other protocol in Windows environments. Pass-the-Hash, NTLM relay (via tools like Responder + ntlmrelayx), and credential capture attacks all depend on NTLM being available. The good news: you can audit and progressively restrict it without breaking things, if you’re systematic about it.

Start by auditing who is using NTLM and why. Enable NTLM auditing via Group Policy, collect the logs in your SIEM, and identify which applications still require it. Modern applications should use Kerberos. Once you’ve cleaned up the dependencies, move to restricting outbound NTLM from workstations and eventually enabling the “Deny all” policy on DCs. Don’t rush this — a phased approach prevents outages.

# Audit NTLM authentication events via PowerShell
# Enable NTLM auditing first via GPO:
# Security Settings > Local Policies > Security Options
# "Network security: Restrict NTLM: Audit NTLM authentication in this domain" = Enable all

# Then query the Security event log for NTLM events (Event ID 8004)
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
    Where-Object { $_.Id -eq 8004 } |
    Select-Object TimeCreated,
        @{N='User';E={$_.Properties[0].Value}},
        @{N='Workstation';E={$_.Properties[1].Value}},
        @{N='TargetServer';E={$_.Properties[2].Value}} |
    Sort-Object TimeCreated -Descending |
    Export-Csv -Path "C:\Logs\ntlm-audit.csv" -NoTypeInformation

Write-Host "NTLM audit exported to C:\Logs\ntlm-audit.csv"

Privileged Access Controls That Actually Work

Local Administrator Password Solution (LAPS) should be non-negotiable in any environment with more than a handful of machines. Without LAPS, local administrator accounts typically have the same password across all machines — one credential compromise means every workstation is owned. LAPS rotates unique passwords per machine and stores them in AD with ACL-controlled access. Microsoft LAPS (the updated version shipping with Windows 2022/11) adds even more capability including managed service account support.

Just-in-Time (JIT) administration takes privilege reduction further by eliminating standing privileged access entirely. Instead of accounts permanently in Domain Admins, admins request elevated access for a specific time window and purpose. Microsoft Privileged Identity Management (PIM) in Entra ID handles this for cloud/hybrid scenarios. For pure on-prem, Microsoft Identity Manager or third-party PAM solutions like CyberArk or BeyondTrust can provide JIT. The Protected Users security group is a quick, free win — adding privileged accounts to it disables NTLM, DES, and RC4 Kerberos, and prevents credential caching.

The post Active Directory Hardening: 10 Security Controls You Should Implement Today appeared first on InfoTech Ninja.