Windows Securing Server 2019/2022: LAPS, SMB‑Signing, GPO hardening and PowerShell RESTrictions

In this article I describe how to secure Windows Server 2019/2022, with a focus on four practically relevant components: LAPS (Local Administrator Password Solution), SMB‑Signing (protocol integrity), GPO‑based hardening and PowerShell RESTrictions including logging. The focus keyword „Windows Server 2019/2022 secure“ is deliberately placed early because these four measures together reduce a large part of the attack surface in typical Windows domain environments. The target audience is administrators, system engineers and technical service providers — the guides are operationally oriented: prerequisites, typical risks, checks, concrete implementation steps and fallback strategies.

Windows Server 2019/2022 secure: Why prioritize these four components?

The listed measures address different attack vectors and operational requirements:

• LAPS reduces the risk of stolen, static local administrator passwords on individual hosts.
• SMB‑Signing protects file and print traffic from tampering and man‑in‑the‑middle attacks at the protocol layer.
• GPO hardening enables centralized, consistent rules for security settings and prevents configuration drift.
• PowerShell RESTrictions and logging reduce abuse potential of the powerful shell and provide forensic telemetry.

Together these measures improve confidentiality, integrity and auditability — important for compliance and incident response.

Plan and approach

Never harden production servers blindly. My recommended sequence:

1. Inventory and risk analysis: Which servers, which clients, which legacy services (NAS, printers, backup appliances) are affected?
2. Test environment: Provide pilot OUs (Organizational Units) where you can validate changes.
3. Scripting and automation: Use reproducible PowerShell scripts and GPO backups for rollbacks.
4. Monitor & validate: Enable logging and monitor effects before the rollout.
5. Staged rollout: By OU, prioritize server roles (Domain Controller, File Server, application servers).

LAPS: managing local administrator passwords securely

What is LAPS? LAPS is Microsoft’s solution to manage local administrator passwords individually, cyclically and securely in Active Directory. Technically, LAPS stores passwords in a protected AD attribute (e.g. ms‑Mcs‑AdmPwd) and applies ACLs so that only authorized accounts can read them. Advantage: No more static, shared credentials, which significantly hinders lateral movement.

Prerequisites and risks

• Active Directory with write rights for schema modification if you deploy the schema extension. (Classic LAPS requires a schema extension.)
• Client side: LAPS agent or CSE (Client Side Extension) must be installed on servers/clients.
• Risk: If ACLs are incorrectly configured, unauthorized accounts can read passwords. Test permissions thoroughly.

Implementation steps (practical)

1. Install the LAPS MSI (for the management workstation) and update the AD schema.

# Beispiel: LAPS Modul installieren (Admin-Rechner)
Install-Package -Name LAPS -ProviderName Programs -Scope CurrentUser

2. Extend the schema (only with Schema Admin rights). This action is one-time and must be tested.

# Schema erweitern (erfordert Schema Admins und entsprechend vorbereitete MSI/Module)
Import-Module AdmPwd.PS
Update-AdmPwdADSchema

3. Grant computer self-permission so that clients can write their own passwords.

# Computer erlauben, ihr eigenes Kennwort zu setzen
Set-AdmPwdComputerSelfPermission -OrgUnit 'OU=Servers,DC=contoso,DC=local'

4. Delegate read rights to Helpdesk/privileged groups.

# Leseberechtigungen für eine Benutzergruppe hinzufügen
Add-AdmPwdReadPasswordPermission -Identity 'OU=Servers,DC=contoso,DC=local' -AllowedPrincipals 'CONTOSOHelpdesk'
# Optionell: Erlauben Password-Expiration-Reset durch Gruppe
Set-AdmPwdPasswordProtection -AllowedPrincipals 'CONTOSOHelpdesk' -PasswordAgeDays 14

5. Deploy GPO: Configure password complexity, length and rotation interval in the LAPS‑GPO.

Verification steps and troubleshooting

• Verify that the AD‑attribute is populated: use ADSIEdit or the PowerShell cmdlets from the LAPS module.
• Check ACLs with Get-AdmPwdReadPasswordPermission.
• If no values are written: check the client agent, GPO application (gpresult) and permissions.

Rollback and emergency access

Maintain a documented emergency access (e.g. a specially delegated account or vault) for critical servers before rolling out LAPS. If GPOs fail, you can uninstall LAPS on the affected server and temporarily use a service account password — document every exception.

SMB‑Signing: integrity for file and print traffic

SMB‑Signing ensures that SMB packets between client and server are cryptographically signed. This protects against tampering and certain man-in-the-middle attacks. In modern environments you should disable SMBv1 and use SMB‑Signing for SMBv2/v3 where possible.

Prerequisites and impact

SMB‑Signing is largely compatible with Windows Server 2019/2022, but can disrupt legacy devices (older NAS, printers, backup appliances). Test in a lab OU. Performance degradations are usually moderate; with high I/O throughput or many small files you should perform load testing. If your storage appliances do not support SMB‑Signing, plan exceptions or firmware updates.

Practical commands and GPO settings

GPO path (Security Options):

• Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → „Microsoft network client: Digitally sign communications (always)“
• Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → „Microsoft network server: Digitally sign communications (always)“

Check/set via PowerShell:

# Prüfen SMB-Serverkonfiguration
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EnableSecuritySignature

# Erforderliche Signatur erzwingen (Server)
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force

# Prüfen SMB-Clientkonfiguration
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature,EnableSecuritySignature

# Erforderliche Signatur erzwingen (Client)
Set-SmbClientConfiguration -RequireSecuritySignature $true -Force

Testing and rollout

1. First enable on pilot file servers and test file access from different client operating systems.
2. Monitor error messages in the event log (System/Application) and on clients.

Typical pitfalls

• Backup software or agents that use SMBv1 — verify and update.
• SMB signing and encryption (SMB Encryption) are not the same: signing protects integrity, encryption protects confidentiality.

GPO hardening: baselines, testing and policy management

Group Policy (GPO) is the central control mechanism for Windows configurations. A clean GPO strategy prevents drift, facilitates audits and accelerates incident response.

Important GPO components

• Security options: disable LM/NTLM where possible, disable SMBv1, policies for LAN Manager and NTLM RESTrictions.
• Account policies: complexity, maximum password age, lockout policy.
• User Rights Assignments: who is allowed to log on locally, Remote Desktop, batch jobs, install services.
• Administrative Templates: UAC hardening, Windows update configuration, telemetry settings.
• Firewall and Windows Defender ATP / EDR integrations.

Practical: Disabling SMBv1 and NTLM RESTrictions

# Disable SMBv1 (remote/on local machine)
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol -NoRESTart

# NTLM RESTrictions via GPO are preferred; check locally:
# Shows current NTLM settings (example value only):
Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlLsa' -Name LmCompatibilityLevel

For NTLM a staged approach is recommended: Monitoring → Alerting → Blocking. Some applications still require NTLM; maintain an NTLM map and an exceptions list.

Management, testing and rollback

Use the following tools:

• Group Policy Management Console (GPMC) with Modeling and Results (gpresult /h report.html).
• Automated test scripts that check essential services after GPO application (SMB mounts, services, scheduled tasks).
• Versioning: export GPOs as backup before changes.

# GPO backup example
Import-Module GroupPolicy
Backup-GPO -Name 'Security Baseline - Servers' -Path 'C:GPO-Backups'

# GPO RESTore example
RESTore-GPO -Name 'Security Baseline - Servers' -Path 'C:GPO-Backups' -Force

PowerShell RESTrictions and logging: control and auditability

PowerShell is a powerful tool — that also makes it an attack vector. Crucial are: proper enforcement methods (Execution Policy is NOT a security boundary), strict whitelisting control (AppLocker/WDAC) and extensive logging (ScriptBlock, ModuleLogging, Transcription).

Why Execution Policy alone is not enough

The PowerShell Execution Policy (Set-ExecutionPolicy) is a configuration preference. It is not a security boundary because it can be bypassed by a user with sufficient rights. For real enforcement use AppLocker (Application Control) or Windows Defender Application Control (WDAC), which enforce device-specific policies in an enterprise environment.

Concrete settings: logging and verification

Centrally enable the following telemetry via GPO or registry to obtain forensic information:

• Script Block Logging: records executed script contents (important for detection).
• Module Logging: logs loaded modules and commands.
• PowerShell Transcription: full session transcripts.

# Enable ScriptBlockLogging via registry (example; prefer via GPO)
New-Item -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging' -Name 'EnableScriptBlockLogging' -Value 1 -Type DWord

# Enable ModuleLogging
New-Item -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellModuleLogging' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellModuleLogging' -Name 'EnableModuleLogging' -Value 1 -Type DWord
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellModuleLogging' -Name 'ModuleNames' -Value '*' -Type MultiString

# Enable Transcription
New-Item -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellTranscription' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellTranscription' -Name 'EnableTranscripting' -Value 1 -Type DWord
Set-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsPowerShellTranscription' -Name 'OutputDirectory' -Value 'C:ProgramDataPowerShellTranscripts' -Type ExpandString

Check the current PowerShell language mode setting

# Returns the current PowerShell language mode (ConstrainedLanguage, FullLanguage, etc.)
$ExecutionContext.SessionState.LanguageMode

Use AppLocker or WDAC

For strict enforcement use AppLocker (filters by publisher, path, hash) or WDAC for kernel-enforced policies. Both solutions require test scenarios, as they can easily interrupt production workloads. Approach:

1. Audit mode (AppLocker/WDAC) for 2–4 weeks, collect events.
2. Create whitelist rules (signed scripts, administrative tools) and gradually move to enforce mode.
3. Fallback plan: GPO with a disabled rule-user group or boot options if critical services fail.

Hardware: NAS, backup appliances and printers — exercise special caution

Hardware devices such as NAS, older printers and backup appliances are often compatibility traps. Many devices implement SMB incompletely or use outdated dialects. Audit and document these devices before a large-scale security hardening project.

Checklist: Verify hardware compatibility

• Check vendor documentation: supported SMB dialects and signing/encryption support.
• Firmware level: outdated firmware is often the cause of missing SMB features.
• Test lab: connect a test client with signing enabled and verify file transfers.
• Fallback option: VLAN or firewall rule that keeps legacy devices operating separately and in a controlled manner.

Practical testing tool: SMB dialect and session details

# On the client: shows negotiated SMB dialects
Get-SmbConnection | Select-Object -Property ServerName,ShareName,Dialect

# On the server: shows active SMB sessions
Get-SmbSession | Select-Object -Property ClientComputerName,ClientUserName,Dialect

If a device only offers SMBv1, plan replacement or network slicing, as SMBv1 poses significant active risks.

Monitoring, SIEM and log retention

Hardening only has practical effect when deviations are detected. Set up event forwarding or an agent (e.g. NXLog, Winlogbeat) to send critical events to SIEM.

Important event IDs and sources

• PowerShell: 4103, 4104 (ScriptBlock Logging), 4105 (Module Logging).
• SMB/Server: Events under Microsoft‑Windows‑SMBServer/Operational — connection failures, signature violations.
• AD/LAPS: AD audit events on read access to ms‑Mcs‑AdmPwd (when AD auditing is enabled).

Retention and storage

PowerShell transcripts and ScriptBlock logs can become very large. Plan storage, collection points (e.g., a central log share or SIEM), and retention policies (e.g., 90 days active, long‑term archive 1 year). Use compression and indexing in the SIEM to reduce query costs.

Concrete mini‑runbook: If services fail after a GPO rollout

1. Narrow the scope: Identify affected OUs/hosts (gpresult, event logs).
2. Immediate action: Temporarily disable the GPO link for the affected OU in the GPMC.
3. Rollback: RESTore the GPO from backup or reapply the previously backed‑up GPO.
4. Access: For authentication issues use the local console or retrieve a maintenance account from the Vault.
5. Post‑processing: Analyze the root cause, test the fix, document it and reapply to the pilot.

Final checks and operational knowledge

Before a large‑scale rollout check: GPO backups available? LAPS delegation correct? SIEM pipelines active? Backup appliances compatible? Maintain a clearly documented change window and a communications plan with operations and application teams.

Conclusion

Securing Windows Server 2019/2022 is not a single switch but a phased project: LAPS reduces credential risk, SMB‑Signing increases protocol integrity, GPO hardening creates central consistency, and PowerShell RESTrictions plus logging enable control and forensics. In practice, structured tests, pilot rollouts and a clear rollback plan pay off. Implement the measures stepwise, measure impact and automate checks. This achieves long‑term secure operation without unnecessary service outages.

This guide can serve as a basis for an internal runbook or proposal; it contains the key validation and fallback mechanisms that reconcile security and availability in real projects.

For this topic, installing LAPS and enabling SMB Signing are also important. The article places these aspects in context and shows what matters in day‑to‑day operations.