Why is a CLIUSR Account Important? What is a CLIUSR certificate and why am I getting an expired warning?
You may have occasionally encountered a local account called CLIUSR on Windows Server systems. So, why is this account important? In this article, we'll discuss the importance and role of the CLIUSR account.
Before the CLIUSR account emerged, domain user accounts were generally used for Failover Cluster services. Failover Clustering required a domain user account for authentication and communication between nodes. This account was linked to the Active Directory domain that included all nodes and was configured with the necessary rights for cluster operations.
The CLIUSR account, introduced in Windows Server 2012, emerged as a solution to these problems created by domain user accounts. Being a local account that operates independently of the domain, it enabled more flexible and reliable management of Failover Clusters. This change simplified the management of Failover Clustering and, by eliminating the dependency on the domain infrastructure, provided a more secure and stable solution. It also plays a similarly important role in systems with Failover Cluster configurations, such as Exchange Server. In the Exchange Server context, this account becomes even more critical because cluster-based architectures like Database Availability Groups (DAGs) are used to ensure high availability and continuous data access.
CLIUSR Account Features
The password for the CLIUSR account is automatically updated every 30 days by default. This password is synchronized across all nodes in the cluster, eliminating the need for administrators to manually change passwords. CLIUSR is a local account, not a domain-bound account. This allows Failover Cluster to operate without domain dependency. Even if the CLIUSR account is accidentally deleted, it will be automatically recreated when a node attempts to join the cluster.
Why You Should Not Delete CLIUSR Account?
The CLIUSR account is vital for the operation of the Failover Cluster. Deleting or restricting the CLIUSR account on the Exchange Server can cause problems.
In this case, DAG operations halt, authentication between nodes cannot be established, and data replication is interrupted. Exchange Server's email services generally function, but unexpected outages may occur in services that touch the cluster. The risk of data loss due to replication issues in the DAG configuration increases.
If accidentally deleted, communication between cluster nodes may be disrupted. The CLIUSR account will be automatically recreated by the system. However, to avoid this re-creation and interruption of operations, it's best not to delete the CLIUSR account.
CLIUSR ve Cluster Shared Volumes (CSV)
The CLIUSR account is also critical for Cluster Shared Volume (CSV). CSV allows nodes within a cluster to share storage. CLIUSR regulates access to such storage and manages secure connections.
Hardening Settings Affecting the CLIUSR Account
When implementing hardening measures, remember that the CLIUSR account requires certain rights. Otherwise, communication between cluster nodes may be interrupted, or nodes may not be able to join the cluster. Especially when hardening Exchange environments, hardening the local account will affect the CLIUSR account's permissions, which will disrupt your cluster operations. Remember that even if you obtain these permissions, you must grant them again before cluster operations.
- Access this computer over the network:
- Deny log on locally:
- Deny log on as a service
What is a CLIUSR Certificate? Can I delete it?
When CLIUSR's password became a problem, its authentication process was made certificate-based. Of course, this certificate also has a specific validity period. CLIUSR certificates are usually automatically renewed by Failover Clustering. Manual intervention by system administrators is generally not required. However, if automatic renewal fails, the certificate can be renewed manually. The most common question we receive is whether to delete expired certificates. Expired CLIUSR certificates can be manually deleted, but this is generally not necessary since they are automatically managed by the system. Before deleting a certificate, ensure that the cluster is functioning properly and a new certificate is generated. Deleting the wrong certificate can cause problems with authentication and communication within the cluster.
