Redis RESP Protocol Server Security in Windows

NCache RESP Server provides security for Redis-compatible applications by integrating with NCache's existing LDAP/Active Directory authentication and cache-level authorization mechanisms to control user access and administrative permissions. It also supports TLS to encrypt client communication and Mutual TLS (mTLS) to verify client certificates. Together, these mechanisms protect credentials, commands, and cached data during transmission while controlling access to NCache servers and caches.

TLS Encryption

TLS encryption protects communication between Redis clients and NCache RESP Server, including commands, credentials, keys, values, and responses. NCache RESP Server uses the same TLS configuration and server certificate as NCache, so TLS does not need to be configured separately for RESP. You can use an NCache-managed certificate or a custom PEM certificate, with settings maintained in tls.ncconf. Once TLS is enabled, Redis clients must establish an encrypted connection. For a two-node CRC-Compliant Cluster, configure TLS consistently on both servers and ensure clients trust the certificates presented by each node. If Mutual TLS (mTLS) is enabled, clients must also present a certificate issued by a trusted Certificate Authority (CA).

TLS

TLS establishes an encrypted connection in which the Redis client verifies the NCache server certificate. The server does not require a client certificate. The Redis client must trust the server's issuing CA and, for normal hostname verification, connect using a hostname or IP address included in the server certificate's Subject Alternative Name (SAN).

Configure Server

Open PowerShell 7 on the NCache server and import the NCache PowerShell module. To enable TLS with an NCache-managed server certificate, run:

Import-Module 'C:\Program Files\NCache\bin\tools\ncacheps'
Enable-NCacheTLS

To use a custom server certificate instead, specify the absolute path to the PEM file:

Enable-NCacheTLS -CustomCertificatePath "C:\certs\ncache-chain.pem"

The custom PEM file must contain the private key, server leaf certificate, and intermediate certificates, in that order. Ensure that the file is valid and available at the configured path on each participating node. Restart the affected cache to load the updated TLS settings:

Stop-Cache defaultCache
Start-Cache defaultCache

Alternatively, configure TLS through the NCache Management Center. For PowerShell parameters, see Enable-NCacheTLS.

Connect Client

For a TLS connection, redis-cli must trust the CA certificate that issued the NCache server certificate. Download the root.crt and root.pem certificate files from the following link:

<certificate-download-link>

If using a DER-encoded root.crt with a Redis client that requires PEM, convert it using:

certutil -encode root.crt root.pem

Connect to the configured RESP port using --tls and --cacert:

redis-cli -c -h 20.200.20.11 -p 9981 --tls --cacert root.pem --insecure PING

The default NCache-managed server certificate has no Subject Alternative Name (SAN). In this example, --insecure skips hostname verification but does not skip certificate-chain verification performed using --cacert. For production, use a custom server certificate with a SAN matching the Redis endpoint and omit --insecure. See Certificate Architecture.

Mutual TLS (mTLS)

Mutual TLS verifies both endpoints during the TLS handshake. The Redis client validates the NCache server certificate, while NCache RESP Server requires and validates a certificate presented by the Redis client. This limits connections to clients with certificates issued by a trusted CA. mTLS establishes transport-level trust but does not replace RESP username/password authentication or cache authorization when those controls are enabled.

Configure Server

  • Obtain a client certificate and matching private key from your organization's CA, or generate a client certificate using New-NCacheTlsCertificate.
  • Ensure that every participating NCache server trusts the CA that issued the Redis client certificate. On Windows, install the issuing root CA in Trusted Root Certification Authorities.
  • In NCache Management Center, open Settings > Environment > TLS Security, select the participating nodes, and enable Mutual TLS (require clients to present a certificate).
  • Save the settings and restart the affected cache processes.

Alternatively, you can also enable mTLS using PowerShell 7. For detailed steps, see Configure Mutual TLS and New-NCacheTlsCertificate.

Connect Client

For mTLS, the Redis client needs the server CA certificate (root.pem), a client certificate (client.crt), and its matching private key (client.key). --cacert verifies the NCache server certificate, while --cert and --key supply the client credentials required by NCache. If the NCache root certificate is DER encoded, convert it to PEM as shown under TLS.

redis-cli -c -h 20.200.20.11 -p 9981 --tls --cacert root.pem --cert client.crt --key client.key --insecure PING

Here, --insecure skips hostname verification for the default NCache-managed server certificate but retains CA-chain verification. For production, use a server certificate with a matching SAN and omit --insecure. To verify that mTLS is enforced, attempt a TLS connection without --cert and --key; the server should reject it. See TLS Troubleshooting.

User Security (LDAP/Active Directory)

NCache RESP Server uses NCache User Security to authenticate Redis client accounts against LDAP/Active Directory and authorize access to the target cache. Authentication verifies the supplied identity; authorization determines whether that identity may use the selected cache. Valid directory credentials alone do not grant access.

Node Administrators can manage authorized NCache nodes and access their caches, whereas Cache Users have cache-level access without node-management permissions. Applications can authenticate using standard Redis username/password options. A shared RESP password is also available as an alternative authentication mechanism, but it does not identify individual users or enforce per-user cache permissions.

Configure Server

Configure the LDAP directory and enable NCache node security before assigning users to individual caches. For a two-node CRC-Compliant Cluster, apply consistent authentication, authorization, and shared RESP password settings on both NCache servers.

  1. Open NCache Management Center at http://localhost:9801 and select Settings > Environment > User Security.
  2. Under Domain Info, specify the Domain Controller, Port, and Search Base. Provide a Secondary Domain Controller if required, and select Use SSL Port when using a secure LDAP port.
  3. Click Verify, provide valid directory credentials when prompted, and click Save to apply the domain settings.
  4. Under Configure Security for Node, enter the NCache server IP address and click Fetch Details.
  5. Select Enable Security, add the required Users or Groups as Node Administrators, and click Save. Apply the same security settings to the remaining cluster nodes.

For the complete Management Center procedure, see Add Server to Active Directory and Enable NCache Node Security. Alternatively, use PowerShell as described in Enable Security Using PowerShell and Enable-NCacheSecurity.

NCache Admin

Node Administrators are LDAP users or groups authorized to manage NCache nodes and their caches. The first administrator is assigned when node security is enabled; additional administrators can be added as required.

  1. In NCache Management Center, open Settings > Environment > User Security.
  2. Under Configure Security for Node, enter the server IP address and click Fetch Details.
  3. Add the required administrator Users or Groups and click Save. Keep the settings consistent across participating nodes.

For details, see Enable NCache Node Security. Alternatively, add administrators using PowerShell with Add-NCacheUserOrGroup.

Cache Users

Cache Users are LDAP users or groups authorized to access a specific cache without node-management permissions. Assign only the users or groups that require access to the selected cache.

  1. In NCache Management Center, select Clustered Caches or Local Caches, and click View Details for the required cache.
  2. Under Advanced Settings > Security and Encryption, add the required Users or Groups as Cache Users.
  3. Click Save Changes to apply the cache-level access settings.

For the complete procedure, see Adding Cache Users. Alternatively, manage Cache Users through PowerShell using Add-NCacheUserOrGroup or Remove-NCacheUserOrGroup.

Shared RESP Password (Alternative)

When LDAP-based NCache Security is not enabled, a shared password can be configured through the machine-level NCACHE_RESP_PASSWORD environment variable. Set the same value on each participating server:

[Environment]::SetEnvironmentVariable("NCACHE_RESP_PASSWORD", "<strong-password>", "Machine")

Ensure that the processes launching CacheHost receive the updated environment variable, and restart the affected caches. The shared password authenticates connections but does not identify individual users or provide per-user cache authorization.

Connect Client

Redis clients authenticate using the standard Redis AUTH mechanism or equivalent library connection options. With NCache User Security enabled, the two-argument form AUTH <username> <password> validates the directory account and its cache access. The following example uses an authorized Cache User:

redis-cli -c -h 20.200.20.11 -p 9981 --user john_smith --pass "<password>" PING

For a shared RESP password, clients can use the one-argument form AUTH <password> (or AUTH default <password>). With redis-cli, omit the username:

redis-cli -c -h 20.200.20.11 -p 9981 --pass "<shared-password>" PING

For URI-based Redis libraries, the general connection format is:

redis[s]://[username]:[password]@host:port/[database_number]

Use redis:// for an unencrypted connection or rediss:// for TLS. Include a username for LDAP authentication; shared-password clients can omit it. The database number is optional in Redis URI syntax; do not assume that selecting multiple Redis logical databases is supported by NCache RESP Server. For mTLS, also configure the client certificate and private key using the library's TLS options.

Note

When authentication is required, unauthenticated clients cannot run cache commands such as PING until authentication succeeds. NCache RESP Server supports RESP2; clients must not require RESP3 (HELLO 3). LDAP credentials alone do not grant cache access: the account must be an authorized Cache User, belong to an authorized group, or have applicable Node Administrator permissions. Previously authenticated connections may remain active after permissions change; disconnect existing sessions if immediate revocation is required.

How NCache RESP Server Security Works

When TLS and User Security are enabled, client access follows this sequence:

  1. Establish transport security: The client validates the NCache server certificate. With mTLS, NCache also validates the client certificate.
  2. Authenticate: The Redis client supplies its LDAP credentials or the configured shared RESP password.
  3. Authorize: For LDAP authentication, NCache verifies that the account has access to the target cache or applicable Node Administrator permissions.
  4. Execute commands: The client can run the RESP operations supported by the configured cache.

TLS and RESP authentication are independent controls. Enabling TLS does not automatically authorize a user, and authenticating a user does not encrypt an otherwise plaintext connection.

For production deployments, enable NCache User Security with LDAP/Active Directory and configure separate administrator and application identities. Grant Cache Users access only to required caches, enable TLS for all RESP connections, and validate server certificates rather than bypassing certificate verification. Use mTLS when client-certificate verification is required. Apply consistent security settings and certificate trust across participating nodes, and restrict access to RESP ports to authorized client networks.

A shared RESP password is an alternative for deployments without LDAP-based security, but it does not provide individual user identities or per-user authorization. Avoid embedding passwords in source code or command histories; use your application’s secret-management mechanism.

See Also

Install and Configure NCache RESP Server
Connect Redis Applications to NCache RESP Server
User Security
Configure TLS Encryption in Windows and Linux