'Deny log on through Terminal Services' and 'Deny log on locally'to the domain service account that runs SQL Server AlwaysOn cluster

Applying “Deny log on locally” and “Deny log on through Terminal Services” to the domain service account that runs SQL Server, SQL Agent, and Always On/WSFC will not, by itself, break Always On availability groups, WSFC health, or failover, provided that:

1. The SQL Server and SQL Agent services are already configured to run under that account as a service account, and
2. No operational or maintenance process depends on that account performing interactive logons (console or RDP).

Key points from the documented behavior:

• SQL Server Always On availability groups rely on:
  • WSFC health monitoring and quorum (cluster service and its own accounts/SIDs).
  • The SQL Server service account having required permissions to registry, cluster, storage, and databases.
  • The SQL Server instance driving availability group state; administrators must not manipulate AGs directly from Failover Cluster Manager.
• WSFC security and Always On AGs:
  • Always On AGs inherit security from WSFC; enabling AGs gives the SQL Server instance full control of the cluster via its service SID, not via interactive logon rights.
  • Cluster security for the SQL Server instance is managed via SQL Server Configuration Manager or WMI, not by granting it local/RDP logon rights.
• User rights guidance:
  • “Allow log on locally” is required for users logging on at the console or starting services interactively; services themselves run under the Service Control Manager and do not require that right.
  • Removing interactive logon rights can cause issues only if an account is expected to log on from the network/console; it does not affect service authentication as long as the account has the required “log on as a service” and network access rights.
• Cluster-specific local accounts (for example, CLIUSR) are sensitive to network logon deny settings, but that is a different policy (“Deny access to this computer from the network”), not “Deny log on locally” or “Deny log on through Remote Desktop Services.”

Therefore, from the documented behavior:

• Always On availability group functionality, automatic/manual failover, and WSFC health are driven by:
  • WSFC quorum and health monitoring.
  • SQL Server and cluster services running and being able to communicate and access required resources.
• These do not depend on the SQL Server domain service account having interactive logon rights (local or RDP).

Operational considerations before enforcing the policy:

1. Ensure the SQL Server and SQL Agent services are configured with that domain account and that it has:
   • “Log on as a service” right.
   • Required permissions to SQL data/log/backup paths, registry, and cluster.
2. Verify that no scripts, scheduled tasks, or admin procedures rely on logging on as that service account via console or RDP.
3. Do not apply “Deny access to this computer from the network” to cluster-related local accounts (for example, CLIUSR) or to accounts required for cluster communication, as that is known to break cluster services.

If those conditions are met, applying “Deny log on locally” and “Deny log on through Terminal Services” to the SQL Server domain service account is compatible with SQL Server Always On availability groups and WSFC and should not affect cluster health or failover behavior.

References:

• Prerequisites, restrictions, and recommendations for Always On availability groups
• Windows Server Failover Clustering with SQL Server
• Block the remote use of local accounts in Windows
• Client, service, and program issues can occur if you change security settings and user rights assignments
• Always On failover cluster instances (SQL Server)
• Manage logins for jobs using databases in an Always On availability group