Enhance Windows & SQL Server Security: Block Remote Access to Local Accounts

Table of Contents

This article details the critical security practice of preventing local user accounts from being used for remote access on Windows systems. This measure is particularly vital in environments where Active Directory is present and helps mitigate significant security risks that can impact various services, including SQL Server deployments. Implementing this control is a key step in strengthening your overall security posture against common attack vectors.

Understanding the Risk of Remote Local Accounts¶

In many network environments, particularly those relying heavily on Active Directory for central identity management, the use of local user accounts for remote access presents a notable security vulnerability. This risk is significantly amplified when administrative local accounts exist across multiple devices and share the same username and password. Such duplication creates a dangerous dependency that attackers can exploit.

A primary concern is the threat of “pass the hash” attacks. If an attacker gains administrative access to one machine where a local administrator account exists, they can often extract the NTLM hash of that account’s password from the local Security Accounts Manager (SAM) database. This hash can then be used to authenticate remotely to other machines where the same local account (identified by SID and name) with the same password hash exists, without ever needing the actual plaintext password. This allows attackers to move laterally across the network, gaining administrative control over numerous systems very rapidly.

This technique is particularly effective against systems with identical local administrative credentials, a scenario that was unfortunately common in some legacy IT management practices. Preventing remote logon for local accounts directly addresses this lateral movement risk, limiting the scope of a potential breach to the compromised machine and preventing its use as a pivot point to compromise other systems in the domain. While domain accounts are generally preferred for remote management, local accounts are sometimes necessary for specific purposes or during domain unavailability; securing their remote access capabilities is paramount.

Utilizing Security Identifiers (SIDs) for Granular Control¶

To effectively mitigate the risk associated with remote local account usage, modern Windows versions offer enhanced security features centered around specific Security Identifiers (SIDs). These SIDs provide a more granular and efficient way to define policy controls compared to managing individual accounts manually. Instead of listing every single local account you wish to restrict, you can apply policies based on these general SIDs.

Windows 8.1 and Windows Server 2012 R2 were pivotal in introducing two key SIDs for this purpose: S-1-5-113, representing NT AUTHORITY\Local account, and S-1-5-114, representing NT AUTHORITY\Local account and member of Administrators group. These SIDs were subsequently made available on Windows 7, Windows 8, Windows Server 2008 R2, and Windows Server 2012 through a specific security update (KB2871997). Their introduction revolutionized the ability to manage remote access permissions for local accounts across an entire network segment or domain via Group Policy.

The S-1-5-113 SID encompasses all local accounts on a system, regardless of their membership in the local Administrators group. In contrast, the S-1-5-114 SID specifically targets only those local accounts that are members of the built-in Administrators group. This distinction is crucial for implementing policies that differentiate between standard local users and those with elevated privileges. By using these SIDs in User Rights Assignments policies within Group Policy Objects (GPOs), administrators can define who is allowed or denied certain logon types, such as network access or remote desktop logon, based solely on whether the account is local and/or an administrator.

Implementing Policy Controls via Group Policy¶

The most common and effective method for implementing restrictions based on these SIDs is through Group Policy. By configuring specific User Rights Assignment policies, you can centrally manage remote access permissions for systems within your domain. The primary policies used for this purpose are “Deny access to this computer from the network” and “Deny log on through Remote Desktop Services”. Adding the appropriate SIDs to these policies prevents local accounts from using network protocols (like SMB for file shares, or RPC) or RDP for remote connections, respectively.

Initially, security guidance recommended adding S-1-5-113 (Local account) to the “Deny access to this computer from the network” policy. This effectively blocked all local accounts from accessing the machine over the network. While providing strong security against pass-the-hash involving any local account, this blanket restriction was found to interfere with the functionality of certain Windows features that legitimately rely on non-administrative local accounts for inter-machine communication. One significant example is the Failover Clustering feature, which utilizes a specific local account for cluster node management.

Consequently, security guidance was revised to strike a balance between security and functionality. The updated recommendation, particularly for Windows Server member servers, is to add S-1-5-114 (Local account and member of Administrators group) to the “Deny access to this computer from the network” policy instead of S-1-5-113. This revised policy continues to block remote network logon for administrative local accounts, thus mitigating the primary “pass the hash” risk, while allowing non-administrative local accounts (like the one used by Failover Clustering) to function correctly over the network.

Here’s a summary of the policy change:

Policy Path	Policy Name	Original Recommended Value	New Recommended Value (for Member Servers)
Computer Configuration\Windows Settings\Local Policies\User Rights Assignment	Deny access to this computer from the network	Guests, Local account (S-1-5-113)*	Guests, Local account, and members of Administrators group (S-1-5-114)*

Note: While not explicitly part of this specific SID discussion, recommended security baselines also often suggest adding Domain Administrators and Enterprise Administrators to remote access denial policies on member servers, restricting their interactive logon capabilities to dedicated administrative workstations or domain controllers. This layer of defense further reduces the attack surface for high-privilege domain accounts.

Implementing this policy requires careful planning and testing to ensure compatibility with all applications and services running on the target servers. Deploying this change via GPO allows for consistent enforcement across your server infrastructure. It is advisable to test the policy on a small group of non-production servers before rolling it out widely. This phased approach helps identify any potential conflicts with specific software or configurations that might rely on administrative local accounts for remote communication.

For environments hosting SQL Server, applying this policy is a critical security control. While SQL Server service accounts are typically domain accounts (Managed Service Accounts or standard domain users) or sometimes the built-in Network Service or Local System accounts, local user accounts might still exist for various administrative or legacy purposes. Preventing these local accounts, especially those in the Administrators group, from being used for remote access to the SQL Server machine significantly reduces the risk of attackers gaining control via credential theft and lateral movement, even if they compromise another system on the network.

Deep Dive into the CLIUSR Account¶

The discussion around restricting local account remote access often intersects with the functionality of Windows Failover Clustering, specifically involving a local account known as CLIUSR. Understanding this account is vital because it directly influenced the change in the recommended security guidance from denying S-1-5-113 to denying S-1-5-114. The CLIUSR account is a local user account that is automatically created when the Failover Clustering feature is installed and configured on Windows Server 2012 or later versions.

Historically, earlier versions of the Cluster Service (Windows Server 2003 and older) relied on a dedicated domain user account to start the service and handle inter-node communication. This Cluster Service Account (CSA) performed critical functions like forming the cluster, adding nodes, and managing registry replication. However, this approach had significant drawbacks. Domain administrators could inadvertently strip necessary permissions from the CSA through generic domain Group Policies, leading to service failures. Managing passwords for a single domain account used across multiple clusters also became cumbersome, requiring coordinated password changes in Active Directory and on all associated cluster nodes.

Windows Server 2008 saw an improvement with the Cluster Service primarily using the built-in Network Service account for starting the service. Inter-node authentication transitioned to using the Cluster Name Object (CNO), a computer object in the domain associated with the cluster’s network name. The CNO’s password is automatically managed by the domain, addressing the manual password change problem. However, this still presented challenges in highly virtualized environments. For example, clusters hosting virtualized domain controllers on Cluster Shared Volumes (CSV) faced a “Catch-22”: accessing the CSV required authenticating the CNO via a domain controller, but the domain controller resided on the CSV, inaccessible until the volume was mounted. Slow or unreliable domain controller connections also impacted CSV I/O performance, as CSV uses SMB for intra-cluster communication, which requires authentication.

Windows Server 2012 introduced the CLIUSR account to overcome these dependencies and improve resilience. While still using the Network Service for starting the cluster service, a local, non-domain user account (CLIUSR) was introduced specifically for authentication between cluster nodes. This local account is not a member of the local Administrators group. It is automatically created and managed by the Cluster Service itself, including self-managed password rotation synchronized across nodes at the same frequency as the CNO (default 30 days). Because it’s a local account, it can authenticate and facilitate mounting CSVs even when domain controllers are unavailable or slow to respond, crucially enabling virtualized domain controllers to start successfully from a CSV.

The CLIUSR account is an internal component of the Failover Cluster feature. Its existence and function are tied directly to the clustering capabilities introduced in Windows Server 2012. It can be identified in the Computer Management snap-in by its specific description: “Failover Cluster Local Identity”. Despite its non-administrative nature, administrators unfamiliar with its purpose might flag or attempt to delete it during security audits due to it being an unexpected local account. It is essential to understand that CLIUSR is required for cluster communication and functionality. As a safeguard, if the CLIUSR account is accidentally deleted, the Cluster Service will automatically recreate it when a node attempts to join the cluster, although this might cause temporary disruption.

In subsequent versions, like Windows Server 2016, Microsoft further enhanced cluster communication security by enabling the use of certificates, allowing cluster operations even in workgroup or multi-domain scenarios without relying on domain accounts or specific local accounts like CLIUSR for primary authentication flows, although CLIUSR might still be present for compatibility or specific internal operations depending on the cluster configuration and version. However, the CLIUSR account remains a key component for clusters leveraging the authentication method introduced in Windows Server 2012/2012 R2.

Understanding the CLIUSR account’s role highlights why blanket denial of remote access to all local accounts (using S-1-5-113) on servers intended for clustering was problematic. The revised guidance to specifically deny access to administrative local accounts (using S-1-5-114) provides strong security against lateral movement using compromised administrative credentials while preserving the necessary network access for non-administrative system accounts like CLIUSR, thereby allowing features like Failover Clustering to operate correctly and reliably.

Pass-the-Hash Explained¶

To better understand the core vulnerability this security measure addresses, let’s briefly explore the “Pass-the-Hash” attack. When a user authenticates to a Windows system over the network using protocols like NTLM, the system doesn’t necessarily transmit the plaintext password. Instead, it uses a hash of the password. The “Pass-the-Hash” technique exploits this. An attacker who obtains a user’s password hash (often by dumping credential caches or the SAM database on a compromised machine) can use this hash directly to authenticate to other systems on the network that accept NTLM authentication, without ever needing the original password.

This is particularly dangerous with local administrator accounts that have identical passwords (and thus identical hashes) across multiple machines. Once an attacker compromises one machine and extracts the hash of a common local administrator account, they can effectively use that hash to log in as an administrator to any other machine on the network sharing those same credentials. This enables rapid lateral movement and privilege escalation across the environment.

Denying remote network logon for local administrator accounts breaks this attack chain. If a local administrator account cannot authenticate remotely, an attacker cannot use its hash (even if compromised) to access other machines over the network using that account’s identity. This security measure is a critical layer in defending against modern credential theft attacks.

Here is a video that explains the concept of Pass-the-Hash in more detail:

What is Pass-the-Hash? (PtH)

Note: The video above provides conceptual information about the Pass-the-Hash attack, which is a primary threat mitigated by blocking remote access for local administrative accounts.

Strengthening SQL Server Security¶

The security of SQL Server instances relies heavily on the security of the underlying Windows operating system and network environment. Implementing the recommended policy of denying remote network logon for local administrative accounts is a significant step in protecting your SQL Server infrastructure from lateral movement attacks. If a server hosting a SQL Server instance is compromised, and an attacker manages to obtain the hash of a local administrator account, blocking remote access for that account prevents them from easily using those compromised credentials to access other servers (including other SQL servers or domain controllers) on the network.

Furthermore, while SQL Server service accounts are ideally managed domain accounts, configurations sometimes exist where local accounts are used. Ensuring that these local accounts, if they are administrators, are covered by the “Deny access to this computer from the network” policy protects the SQL Server host itself from credential reuse originating from other systems. Even if the service account itself is non-administrative, the presence of administrative local accounts on the same server poses a risk if those accounts can be compromised and used remotely.

Implementing this GPO setting on all member servers hosting SQL Server, alongside other security best practices like using Managed Service Accounts or Virtual Accounts for SQL Server services, restricting SQL Server logon permissions, patching systems regularly, and employing network segmentation, provides a robust, layered defense against sophisticated cyber threats targeting your data. It is one piece of the puzzle in building a secure foundation for your SQL Server deployments.

Consider the specific environment your SQL Servers operate in. Are they in a flat network? Are there multiple servers with identical local administrative passwords? If so, this GPO is not just recommended; it’s essential. By limiting the remote capabilities of local administrator accounts, you significantly reduce the potential blast radius of a security incident. This policy should be a standard part of your server hardening process for all Windows servers, including those dedicated to hosting SQL Server.

Conclusion and Call to Action¶

Blocking remote network access for local administrative accounts using the S-1-5-114 SID is a crucial security enhancement for Windows environments, offering significant protection against lateral movement attacks like Pass-the-Hash. This policy is particularly relevant for servers hosting critical services like SQL Server, where the underlying operating system’s security directly impacts data protection. Understanding the evolution of this guidance and the specific role of accounts like CLIUSR helps ensure proper implementation without disrupting necessary functionality.

We encourage you to evaluate your current security posture and implement this policy through Group Policy Objects on your Windows member servers. Remember to plan, test thoroughly in a lab environment, and deploy in phases to minimize potential disruptions.

What are your thoughts on implementing this security measure? Have you encountered challenges with balancing security policies and feature compatibility in your environment? Share your experiences and questions below.