Unable to Login to SQL Server Availability Group Listener
Incorrect Service Provider Name (SPN)
SQL Server Availability Groups typically use a domain account as the service account for running the SQL Server service. Deep Security Manager (DSM) relies on the Kerberos protocol to authenticate database logins that use domain accounts. For Kerberos authentication to function correctly, a valid Service Principal Name (SPN) must be registered to the SQL Server service account. The SPN should include the Fully Qualified Domain Name (FQDN) of the Availability Group listener to ensure DSM can successfully connect to the database.
- To check if SPN is correctly configured, open command prompt in Windows of the device with DSM.
Input command below and replace the text inside the angle brackets "<>" with your environment value.
setspn -T <domain-name>: -F -Q MSSQLSvc/<listener-FQDN>*The result should indicate that a SPN is registered into a domain account, which is used as a SQL Server service account.
- If the command above does not return any values or it is registered to the wrong domain account, contact your domain administrator to troubleshoot or register appropriate SPN.
SQL Server Service Account Uses Unsupported Encryption
Deep Security Manager (DSM) does not support legacy Kerberos encryption algorithms such as DES or RC4, which may still be used by older Windows Server domain controllers by default.
If a legacy encryption algorithm is detected, DSM will generate the following error log:
KrbException: KDC has no support for encryption type (14)
To mitigate this issue, please contact your domain administrator and enable AES128 or AES256 for that particular domain/service account.
SQL Server Login Account does not exist in Secondary Replica After Failover
SQL Server Always On Availability Groups synchronize only database objects and data; they do not replicate login credentials or server-level objects. If a user account is able to log in before a database failover but encounters issues after failover to another replica, verify that the login exists on the target replica as well.
There are several methods available to synchronize login accounts between replicas, as described in Synchronize logins between Availability replicas in SQL Server Always On Availability Groups.
For domain accounts, simply create the login on each replica and assign the same SQL Server roles. Domain accounts retain the same Security Identifier (SID) across all replicas, ensuring consistent permissions.
Unable to Connect to SQL Server Availability Group Listener After Database Failover in Azure
The SQL Server Always On Availability Group listener requires one or more dedicated IP addresses to serve as database client endpoints. In on-premises environments, these IP addresses are typically selected from available addresses within the local subnet.
In Azure environments, however, listener IP addresses must be registered with network resources such as virtual machine network interfaces or Azure load balancers.
Please refer to the official Azure documentation and guidelines linked below to properly configure the SQL Server Always On Availability Group listener on Azure virtual machines.