Overview

After a Group Policy Object (GPO) update, RightFax services may fail to start and lose connectivity to the SQL Server backend. The Windows Security event log on the RightFax application server will contain a Kerberos error referencing KRB_AP_ERR_MODIFIED, and the RightFax Database Service configuration will return an SSPI error when attempting to look up the SQL Server connection.

Ingenium Software support engineers and technicians are scoped exclusively to the RightFax application and its associated files and configuration. While Ingenium Support can help interpret diagnostic results and advise on next steps, any remediation involving Active Directory, Group Policy, or SQL Server configuration must be carried out by the customer's AD or SQL Server administration team. Ingenium cannot make changes to these systems on the customer's behalf.

Affected Products

• RightFax 20.2, 22.2, 23.4, 24.4
• Microsoft SQL Server 2016 and later
• Windows Server (domain-joined environments)

Symptoms

• Most or all RightFax services are stopped and fail to start
• Opening the RightFax Database Service configuration and clicking Lookup on the SQL Connection returns an SSPI error
• The Windows Security or Application event log contains an error similar to the following:

  The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server <SQLServerName>. The target name used was MSSQLSvc/<SQLServerFQDN>:<port>. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using.

• Issue appears on one server (e.g., pre-production) but not another (e.g., production), even though the same GPO was applied to both

Root Cause

RightFax uses Windows Integrated Security (Kerberos/NTLM) to authenticate to SQL Server. Kerberos relies on Service Principal Names (SPNs) registered in Active Directory for the SQL Server service account. A KRB_AP_ERR_MODIFIED error indicates one of the following conditions on the infrastructure side — outside the RightFax application itself:

• Duplicate SPN: The SQL Server SPN is registered on more than one AD account
• SPN on wrong account: The SPN exists but is associated with a different account than the one currently running SQL Server
• Missing SPN: The SPN does not exist, causing authentication failure under certain GPO security configurations
• SQL service account password reset: A GPO forced a password change on the SQL Server service account, making existing Kerberos tickets invalid until the SQL service is restarted

Because the root cause lies in Active Directory and SQL Server configuration, Ingenium Support's role in these cases is to assist with diagnosis and advise the appropriate customer team on remediation steps.

Diagnosis

Ingenium Support will guide the customer through the following diagnostic steps. All commands should be run from an elevated command prompt on any domain-joined machine by the customer's IT team.

Step 1 – Confirm the Kerberos error

On the RightFax application server, open Event Viewer and check the Security and Application logs around the time the services stopped. Confirm the error references KRB_AP_ERR_MODIFIED and note the exact SPN listed (e.g., MSSQLSvc/VWRFDBT001.bcbsncps.com:8433). This is within the RightFax server environment and Ingenium Support can assist in locating and interpreting these logs.

Step 2 – Check RightFax service account SPNs

Ingenium Support can advise on this step. Confirm the RightFax service account has no SPN issues:

setspn -L <RightFaxServiceAccountName>

An empty result is normal for the RightFax service account. SPNs are only required on the SQL Server service account. If SPNs need to be added or modified for the RightFax service account, this must be performed by the customer's AD team.

Step 3 – Query the SQL Server SPN

This step must be performed by the customer's AD or SQL Server team. Ingenium Support can advise on what to run and how to interpret the results.

Run both commands, substituting the SQL Server hostname and port from the event log error:

setspn -Q MSSQLSvc/<SQLServerFQDN>:<port>

setspn -Q MSSQLSvc/<SQLServerShortName>:<port>

Interpret results:

• Found on multiple accounts → Duplicate SPN (Scenario A)
• Found on one account, but wrong account → Misregistered SPN (Scenario B)
• No such SPN found → Missing SPN (Scenario C)
• Found on correct SQL service account → Likely a password issue (Scenario D)

Share the output with Ingenium Support and we can help determine which scenario applies and what to tell your AD or SQL team.

Resolution

Important: All resolution steps below involve Active Directory and SQL Server and are outside the scope of Ingenium Software support. Ingenium engineers and technicians are scoped to the RightFax application and its associated files and configuration only. We can provide guidance and advise your team on the correct steps, but the actual changes must be made by your AD or SQL Server administrators. If you are unsure who to engage internally, contact your Windows infrastructure or database team.

Scenario A – Duplicate SPN

To be performed by the customer's AD team. Remove the SPN from the incorrect account:

setspn -D MSSQLSvc/<SQLServerFQDN>:<port> <WrongAccountName>

Verify it remains registered on the correct SQL service account:

setspn -Q MSSQLSvc/<SQLServerFQDN>:<port>

Scenario B – SPN registered on wrong account

To be performed by the customer's AD team. Remove from the wrong account and re-register on the correct one:

setspn -D MSSQLSvc/<SQLServerFQDN>:<port> <WrongAccountName>
setspn -S MSSQLSvc/<SQLServerFQDN>:<port> <CorrectSQLServiceAccount>
setspn -S MSSQLSvc/<SQLServerShortName>:<port> <CorrectSQLServiceAccount>

Scenario C – SPN missing

To be performed by the customer's AD team. Register both FQDN and short-name SPNs on the SQL Server service account:

setspn -S MSSQLSvc/<SQLServerFQDN>:<port> <SQLServiceAccount>
setspn -S MSSQLSvc/<SQLServerShortName>:<port> <SQLServiceAccount>

Scenario D – SPN correct but GPO reset service account password

To be performed by the customer's SQL Server team. Restart the SQL Server service to force re-registration of credentials with the KDC:

net stop MSSQLSERVER && net start MSSQLSERVER

For a named instance:

net stop "MSSQL$<InstanceName>" && net start "MSSQL$<InstanceName>"

Verification

Once the customer's AD or SQL team has completed the remediation steps, Ingenium Support can assist with verifying the RightFax side:

1.   Open the RightFax Database Service configuration on the application server
2.   Click Lookup on the SQL Connection — it should resolve without error
3.   Start all RightFax services via Enterprise Fax Manager
4.   Confirm services remain in a Running state after 5–10 minutes
5.   Send a test fax to verify end-to-end functionality
6. Monitor <Drive>:\Program Files (x86)\RightFax\Logs\RFServer.log for residual errors

Additional Notes

• This issue can affect one environment (e.g., pre-production) but not another (e.g., production) even when the same GPO is applied, as SPN registration is per-server and GPO password policy effects may not be uniform across environments
• For SQL Server Always On or named instances, ensure SPNs are registered for all listener names and ports in use — your SQL team should verify this
• As a temporary workaround only, SQL Server can fall back to NTLM by using the SQL Server's IP address in the RightFax connection string instead of the hostname. Ingenium Support can assist with updating the RightFax connection string if needed, but this is not recommended as a permanent solution
• If you are unsure which team to engage for AD or SQL remediation, Ingenium Support is happy to help you frame the problem for your internal teams or vendor